- LVS负载均衡群集
- 一、集群定义及分类
- 二、LVS
- LVS模式
- LVS集群的通用体系结构
- LVS集群的负载调度
- 轮询调度(Round-Robin Scheduling)
- 加权轮询调度(Weighted Round-Robin Scheduling)
- 最小连接调度(Least-Connection Scheduling)
- 加权最小连接调度(Weighted Least-Connection Scheduling)
- 基于局部性的最少链接(Locality-Based Least Connections Scheduling)
- 带复制的基于局部性最少链接(Locality-Based Least Connections with Replication Scheduling)
- 目标地址散列调度(Destination Hashing Scheduling)
- 源地址散列调度(Source Hashing Scheduling)
- 最短的预期延迟调度(Shortest Expected Delay Scheduling)
- 从不排队调度(Never Queue Scheduling)
- LVS-NAT部署实战
LVS负载均衡群集
本章结构
1、理解负载均衡群集的原理
2、掌握LVS-NAT的部署
一、集群定义及分类
集群:
Cluster,集群、群集。由多台主机构成,但对外只表现为一个逻辑整体。
在互联网应用中,随着站点对硬件性能、响应速度、服务稳定性、数据可靠性等要求越来越高,单台服务器力不从心,由于小型机、大型机价格昂贵,所以可以使用普通X86服务器构建成集群来进行解决以上需求。
集群分类:
1、高可用集群
高可用集群的英文全称是High Availability,简称HA cluster。高可用的含义是限度地可以使用。从集群的名字上可以看出,此类集群实现的功能是保障用户的应用程序持久、不间断地提供服务。当应用程序出现故障,或者系统硬件、网络出现故障时,应用可以自动、快速地从一个节点切换到另一个节点,从而保证应用持续、不间断地对外提供服务,这是高可用集群实现的功能。双机热备、双机互备等都属于高可用集群的范畴,这类集群一般都由两个或两个以上节点组成。
高可用集群一般是通过高可用软件来实现的。在Linux下常用的高可用软件有Hearbeat HA,Red Hat提供的RHCS,商业软件ROSE,keepalived等。
2、负载平衡集群
负载均衡集群(Load Balance Cluster)也是由两台或者两台以上的服务器组成。分为前端负载调度和后端服务两个部分。负载调度部分负载把客户端的请求按照不同的策略分配给后端服务节点,而后端节点是真正提供营养程序服务的部分。与HA Cluster不同的是,负载均衡集群中,所有的后端节点都处于活动动态,它们都对外提供服务,分摊系统的工作负载。负载均衡集群可以把一个高负荷的应用分散到多个节点共同完成,适用于业务繁忙、大负荷访问的应用系统。
负载均衡集群可以通过软件方式实现,也可以由硬件设备来完成。
3、高性能计算集群
高性能运算群集(High Performance Computer Cluster)以提高应用系统的CPU运算速度、扩展硬件资源和分析能力为目标,获得相当于大型、超级计算机的高性能运算(HPC)能力。高性能运算群集的高性能依赖于“分布式运算”、“并行计算”,通过专用硬件和软件将多个服务器的CPU、内存等资源整合在一起,实现只有大型、超级计算机才具备的计算能力。
典型应用有科学研究、基因测试对比、数据挖掘应用、石油和天然气勘探、图像呈现等。
二、LVS
LVS是Linux Virtual Server的简写,意即Linux虚拟服务器,是一个虚拟的服务器集群系统,在1998年5月由章文嵩先生主导开发。LVS集群实现了IP负载均衡技术和基于内容请求分发技术。调度器通过将请求均衡地转移到不同的服务器上执行,且可以屏蔽掉后台故障的服务器,从而将一组服务器构成一个高性能的、高可用的服务器集群,而这样的结构对客户端来说是完全透明的,所以无需修改客户端和服务器端的程序。
LVS服务器可以让客户端将LVS服务器作为一个连接的单点,仅仅通过连接LVS服务器便可以得到后端一整个服务器集群的处理与存储能力,这样能够大大提高系统的扩展性与可用性,同时也能够提供服务的安全性,单一入侵一台服务器并不会破坏其他与该服务器隔离的服务。
LVS服务器集群系统具有良好的伸缩性,可支持几百万个并发连接。配置100M网卡,采用VS/TUN或VS/DR调度技术,集群系统的吞吐量可高达1Gbits/s;如配置千兆网卡,则系统的最大吞吐量可接近10Gbits/s。
官方网站:http://www.linuxvirtualserver.org/
LVS模式
LVS可以支持如下三种模式:
Virtual Server via Network Address Translation(VS/NAT)
通过网络地址转换,调度器重写请求报文的目标地址,根据预设的调度算法,将请求分派给后端的真实服务器;真实服务器的响应报文通过调度器时,报文的源地址被重写,再返回给客户,完成整个负载调度过程。
- 客户端将请求发往前端的负载均衡器,请求报文源地址是CIP(客户端IP),后面统称为CIP),目标地址为VIP(负载均衡器前端地址,后面统称为VIP);
- 负载均衡器收到报文后,发现请求的是在规则里面存在的地址,那么它将客户端请求报文的目标地址改为了后端服务器的RIP地址并将报文根据算法发送出去;
- 报文送到Real Server后,由于报文的目标地址是自己,所以会响应该请求,并将响应报文返还给LVS;
- 然后lvs将此报文的源地址修改为本机并发送给客户端。
- 注意:在NAT模式中,Real Server的网关必须指向LVS,否则报文无法送达客户端;
- 特点
:- NAT技术将请求的报文和响应的报文都需要通过LB进行地址改写,因此网站访问量比较大的时候,LB负载均衡调度器有比较大的瓶颈,一般要求最多只能10-20台节点;
- 只需要在LB上配置一个公网IP地址就可以;
- 每台内部的realserver服务器的网关地址必须是调度器LB的内网地址;
- NAT模式支持对IP地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。
- 优点:
集群中的物理服务器可以使用任何支持TCP/IP操作系统,只有负载均衡器需要一个合法的IP地址。 - 缺点:
扩展性有限。当服务器节点(普通PC服务器)增长过多时,负载均衡器将成为整个系统的瓶颈,因为所有的请求包和应答包的流向都经过负载均衡器。当服务器节点过多时,大量的数据包都交汇在负载均衡器那,速度就会变慢。
Virtual Server via IP Tunneling(VS/TUN)
采用NAT技术时,由于请求和响应报文都必须经过调度器地址重写,当客户请求越来越多时,调度器的处理能力将成为瓶颈。为了解决这个问题,调度器把请求报 文通过IP隧道转发至真实服务器,而真实服务器将响应直接返回给客户,所以调度器只处理请求报文。由于一般网络服务应答比请求报文大许多,采用 VS/TUN技术后,集群系统的最大吞吐量可以提高10倍。
- 客户端将请求发往前端的负载均衡器,请求报文源地址是CIP,目标地址为VIP;
- 负载均衡器收到报文后,发现请求的是在规则里面存在的地址,那么它将在客户端请求报文的首部再封装一层IP报文,将源地址改为DIP,目标地址改为RIP,并将此包发送给RS;
- RS收到请求报文后,会首先拆开第一层封装,然后发现里面还有一层IP首部的目标地址是自己lo接口上的VIP,所以会处理次请求报文,并将响应报文通过lo接口送给eth0网卡直接发送给客户端。
- 注意:需要设置lo接口的VIP不能在公网上出现。
- 总结
:- TUNNEL模式必须在所有的realserver机器上面绑定VIP的IP地址;
- TUNNEL模式的vip ———>realserver 的包通信通过TUNNEL 模式,不管是内网和外网都能通信,所以不需要LVS VIP跟realserver 在同一个网段内;
- TUNNEL模式realserver会把packet直接发给client,不会给LVS了;
- TUNNEL模式走的隧道模式,所以运维起来比较难,所以一般不用。
- 优点:
负载均衡器只负责将请求包分发给后端节点服务器,而RS将应答包直接发给用户。所以,减少了负载均衡器的大量数据流动,负载均衡器不再是系统的瓶颈,就能处理很巨大的请求量,这种方式,一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。 - 缺点:
隧道模式的RS节点需要合法IP,这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议,服务器可能只局限在部分Linux系统上。
Virtual Server via Direct Routing(VS/DR)
VS/DR通过改写请求报文的MAC地址,将请求发送到真实服务器,而真实服务器将响应直接返回给客户。同VS/TUN技术一样,VS/DR技术可极大地 提高集群系统的伸缩性。这种方法没有IP隧道的开销,对集群中的真实服务器也没有必须支持IP隧道协议的要求,但是要求调度器与真实服务器都有一块网卡连 在同一物理网段上。
- 客户端将请求发往前端的负载均衡器,请求报文源地址是CIP,目标地址为VIP;
- 负载均衡器收到报文后,发现请求的是在规则里面存在的地址,那么它将客户端请求报文的源MAC地址改为自己DIP的MAC地址,目标MAC改为了RIP的MAC地址,并将此包发送给RS;
- RS发现请求报文中的目的MAC是自己,就会将次报文接收下来,处理完请求报文后,将响应报文通过lo接口送给eth0网卡直接发送给客户端。
- 注意:需要设置lo接口的VIP不能响应本地网络内的arp请求。
- 总结
:- 通过在调度器LB上修改数据包的目的MAC地址实现转发。注意源地址仍然是CIP,目的地址仍然是 VIP 地址;
- 请求的报文经过调度器,而RS响应处理后的报文无需经过调度器LB,因此并发访问量大时使用效率很高(和 NAT 模式比);
- 因为DR模式是通过MAC地址改写机制实现转发,因此所有RS节点和调度器LB只能在一个局域网里面;
- RS主机需要绑定VIP地址在LO接口(掩码32位)上,并且需要配置ARP抑制;
- RS节点的默认网关不需要配置成LB,而是直接配置为上级路由的网关,能让RS直接出网就可以;
- 由于DR模式的调度器仅做MAC地址的改写,所以调度器LB就不能改写目标端口,那么RS服务器就得使用和VIP相同的端口提供服务;
- 直接对外的业务比如WEB等,RS的IP最好是使用公网IP。对外的服务,比如数据库等最好使用内网IP。
- 优点:
和TUN(隧道模式)一样,负载均衡器也只是分发请求,应答包通过单独的路由方法返回给客户端。与VS-TUN相比,VS-DR这种实现方式不需要隧道结构,因此可以使用大多数操作系统做为物理服务器。DR模式的效率很高,但是配置稍微复杂一点,因此对于访问量不是特别大的公司可以用haproxy/nginx取代。日1000-2000W PV或者并发请求1万以下都可以考虑用haproxy/nginx。 - 缺点:所有RS节点和调度器LB只能在一个局域网里面。
三种方法比较
VS/NAT | VS/TUN | VS/DR | |
---|---|---|---|
Server | any | Tunneling | Non-arp device |
server network | private | LAN/WAN | LAN |
server number | low (10~20) | High (100) | High (100) |
server gateway | load balancer | own router | Own router |
LVS集群的通用体系结构
LVS集群采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率,将请求均衡地转移到不同的服务器上执行,且调度器自动屏蔽掉服 务器的故障,从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的,而且无需修改客户端和服务器端的程序。
LVS集群采用三层结构,三层主要组成部分为:
- 负载调度器(load balancer),它是整个集群对外面的前端机,负责将客户的请求发送到一组服务器上执行,而客户认为服务是来自一个IP地址(我们可称之为虚拟IP地址)上的。
- 服务器池(server pool),是一组真正执行客户请求的服务器,执行的服务有WEB、MAIL、FTP和DNS等。
- 共享存储(shared storage),它为服务器池提供一个共享的存储区,这样很容易使得服务器池拥有相同的内容,提供相同的服务。共享存储通常是数据库、网络文件系统或者分布式文件系统。一般来说,NFS/CIFS服务器只能支持3~6个繁忙的服务器结点。对于规模较大的集群系统,可以考虑用分布式文件系统。
LVS集群的负载调度
IPVS在内核中的负载均衡调度是以连接为粒度的。在HTTP协议(非持久)中,每个对象从WEB服务器上获取都需要建立一个TCP连接,同一用户 的不同请求会被调度到不同的服务器上,所以这种细粒度的调度在一定程度上可以避免单个用户访问的突发性引起服务器间的负载不平衡。
在内核中的连接调度算法上,IPVS已实现了以下十种调度算法:
- 轮询调度(Round-Robin Scheduling)
- 加权轮询调度(Weighted Round-Robin Scheduling)
- 最小连接调度(Least-Connection Scheduling)
- 加权最小连接调度(Weighted Least-Connection Scheduling)
- 基于局部性的最少链接(Locality-Based Least Connections Scheduling)
- 带复制的基于局部性最少链接(Locality-Based Least Connections with Replication Scheduling)
- 目标地址散列调度(Destination Hashing Scheduling)
- 源地址散列调度(Source Hashing Scheduling)
- 最短的预期延迟调度(Shortest Expected Delay Scheduling)
- 从不排队调度(Never Queue Scheduling)
轮询调度(Round-Robin Scheduling)
轮询调度算法将每个传入请求发送到其列表中的下一个服务器。因此,在三个服务器集群(服务器A,B和C)中,请求1将转到服务器A,请求2将转到服务器B,请求3将转到服务器C,请求4将转到服务器A,从而完成骑自行车或服务器’循环’。无论每个服务器遇到的传入连接数或响应时间如何,它都将所有真实服务器视为相等。
加权轮询调度(Weighted Round-Robin Scheduling)
加权轮询调度旨在更好地处理具有不同处理能力的服务器。可以为每个服务器分配一个权重,一个表示处理能力的整数值。具有较高权重的服务器首先接收新连接而不是权重较小的服务器,具有较高权重的服务器获得的连接多于权重较小的服务器和具有相同权重的服务器获得相等连接。例如,真实服务器A,B和C分别具有权重4,3,2,在调度周期(mod sum(Wi))中良好的调度序列将是AABABCABC。在加权轮询调度的实现中,在修改虚拟服务器的规则之后,将根据服务器权重生成调度序列。
最小连接调度(Least-Connection Scheduling)
最少连接调度算法将网络连接定向到具有最少数量的已建立连接的服务器。这是动态调度算法之一;因为它需要动态计算每个服务器的实时连接。对于管理具有类似性能的服务器集合的虚拟服务器,当请求的负载变化很大时,最少连接调度可以平滑分发。虚拟服务器将使用最少的活动连接将请求定向到真实服务器。
当各个服务器有相同的处理性能时,最小连接调度算法能把负载变化大的请求分布平滑到各个服务器上,所有处理时间比较长的请求不可能被发送到同一台服 务器上。但是,当各个服务器的处理能力不同时,该算法并不理想,因为TCP连接处理请求后会进入TIME_WAIT状态,TCP的TIME_WAIT一般为2分钟,此时连接还占用服务器的资源,所以会出现这样情形,性能高的服务器已处理所收到的连接,连接处于TIME_WAIT状态,而性能低的服务器已经忙于处理所收到的连接,还不断地收到新的连接请求。
加权最小连接调度(Weighted Least-Connection Scheduling)
加权最小连接调度是最小连接调度的超集,您可以在其中为每个真实服务器分配性能权重。重量值较高的服务器在任何时候都会获得更大比例的实时连接。虚拟服务器管理员可以为每个真实服务器分配权重,并且将网络连接安排到每个服务器,其中每个服务器的当前活动连接数的百分比是与其权重的比率。默认权重为1。
基于局部性的最少链接(Locality-Based Least Connections Scheduling)
基于局部性的最少链接调度(Locality-Based Least Connections Scheduling,以下简称为LBLC)算法是针对请求报文的目标IP地址的负载均衡调度,目前主要用于Cache集群系统,因为在Cache集群中客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求,算法的设计目标是在服务器的负载基本平衡情况下,将相同目标IP地址的请求调度到同一台服务器,来提高各台服务器的访问局部性和主存Cache命中率,从而整个集群系统的处理能力。
LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于其一半的工作负载,则用“最少链接”的原则选出一个可用的服务器,将请求发送到该服务器。
带复制的基于局部性最少链接(Locality-Based Least Connections with Replication Scheduling)
带复制的基于局部性最少链接调度(Locality-Based Least Connections with Replication Scheduling,以下简称为LBLCR)算法也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要 维护从一个目标IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射。对于一个“热门”站点的服务请求,一台Cache服务器可能会忙不过来处理这些请求。这时,LBLC调度算法会从所有的Cache服务器中按“最小连接”原则选出一台Cache服务器,映射该“热门”站点到这台Cache服务器,很快这台Cache服务器也会超载,就会重复上述过程选出新的Cache服务器。这样,可能会导致该“热门”站点的映像会出现在所有的Cache服务器上,降低了Cache服务器的使用效率。LBLCR调度算法将“热门”站点映射到一组Cache服务器(服务器集合),当该“热门”站点的请求负载增加时,会增加集合里的Cache服务器,来处理不断增长的负载;当该“热门”站点的请求负载降低时,会减少集合里的Cache服务器数目。这样,该“热门”站点的映像不太可能出现在所有的Cache服务器上,从而提供Cache集群系统的使用效率。
目标地址散列调度(Destination Hashing Scheduling)
目标地址散列调度(Destination Hashing Scheduling)算法也是针对目标IP地址的负载均衡,但它是一种静态映射算法,通过一个散列(Hash)函数将一个目标IP地址映射到一台服务器。
源地址散列调度(Source Hashing Scheduling)
源地址散列调度(Source Hashing Scheduling)算法正好与目标地址散列调度算法相反,它根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。它采用的散列函数与目标地址散列调度算法的相同。
在实际应用中,源地址散列调度和目标地址散列调度可以结合使用在防火墙集群中,它们可以保证整个系统的唯一出入口。
最短的预期延迟调度(Shortest Expected Delay Scheduling)
最短的预期延迟调度算法以最短的预期延迟将网络连接分配给服务器。如果发送到第i个服务器,作业将经历的预期延迟是(Ci + 1)/ Ui,其中Ci是第i个服务器上的连接数,Ui是第i个服务器的固定服务速率(权重)。
从不排队调度(Never Queue Scheduling)
永不排队调度算法采用双速模型。当有空闲服务器可用时,作业将被发送到空闲服务器,而不是等待快速服务器。当没有可用的空闲服务器时,作业将被发送到服务器,以最小化其预期延迟(最短预期延迟调度算法)。
LVS-NAT部署实战
案例环境
主机 | IP地址 | 系统 |
---|---|---|
LVS | 192.168.1.10/24 192.168.100.100/24 | CentOS 7.7 |
web01 | 192.168.100.110/24 192.168.254.10/24 | CentOS 7.7 |
web02 | 192.168.100.120/24 192.168.254.20/24 | CentOS 7.7 |
NFS Server | 192.168.254.100/24 | CentOS 7.7 |
一. 基本环境部署
- IP地址配置
- 主机名设置
- 关闭Selinux
- 设置web01、web02主机的网关指向LVS主机
[root@web01 ~]# nmcli connection modify ens32 ipv4.gateway 192.168.100.100
[root@web01 ~]# nmcli connection up ens32
连接已成功激活(D-Bus 活动路径:/org/freedesktop/NetworkManager/ActiveConnection/3)
[root@web01 ~]# ip route show
default via 192.168.100.100 dev ens32 proto static metric 102
192.168.100.0/24 dev ens32 proto kernel scope link src 192.168.100.110 metric 102
192.168.254.0/24 dev ens34 proto kernel scope link src 192.168.254.10 metric 101
[root@web02 ~]# nmcli connection modify ens32 ipv4.gateway 192.168.100.100
[root@web02 ~]# nmcli connection up ens32
连接已成功激活(D-Bus 活动路径:/org/freedesktop/NetworkManager/ActiveConnection/3)
[root@web02 ~]# ip route show
default via 192.168.100.100 dev ens32 proto static metric 102
192.168.100.0/24 dev ens32 proto kernel scope link src 192.168.100.120 metric 102
192.168.254.0/24 dev ens34 proto kernel scope link src 192.168.254.20 metric 101
二. 配置LVS
安装ipvsadm
[root@lvs ~]# yum install ipvsadm -y
开启路由功能
[root@lvs ~]# vim /etc/sysctl.conf
net.ipv4.ip_forward = 1 #末行添加即可
[root@lvs ~]# sysctl -p
net.ipv4.ip_forward = 1
[root@lvs ~]# cat /proc/sys/net/ipv4/ip_forward
1
加载ip_vs模块
[root@lvs ~]# modprobe ip_vs
[root@lvs ~]# lsmod | grep ip_vs
ip_vs 145497 0
nf_conntrack 139224 7 ip_vs,nf_nat,nf_nat_ipv4,nf_nat_ipv6,xt_conntrack,nf_conntrack_ipv4,nf_conntrack_ipv6
libcrc32c 12644 4 xfs,ip_vs,nf_nat,nf_conntrack
[root@lvs ~]# cat /proc/net/ip_vs
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
启动服务
[root@lvs ~]# ipvsadm --save > /etc/sysconfig/ipvsadm
[root@lvs ~]# systemctl start ipvsadm.service
[root@lvs ~]# systemctl status ipvsadm.service
● ipvsadm.service - Initialise the Linux Virtual Server
Loaded: loaded (/usr/lib/systemd/system/ipvsadm.service; enabled; vendor preset: disabled)
Active: active (exited) since 六 2020-01-11 16:07:17 CST; 7min ago
Process: 1186 ExecStart=/bin/bash -c exec /sbin/ipvsadm-restore < /etc/sysconfig/ipvsadm (code=exited, status=0/SUCCESS)
Main PID: 1186 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/ipvsadm.service
1月 11 16:07:17 lvs systemd[1]: Starting Initialise the Linux Virtual Server...
1月 11 16:07:17 lvs systemd[1]: Started Initialise the Linux Virtual Server.
编写配置脚本如下:
[root@lvs ~]# vim lvs_rule.sh
#!/bin/bash
ipvsadm -C
ipvsadm -A -t 192.168.1.10:80 -s rr
ipvsadm -a -t 192.168.1.10:80 -r 192.168.100.110:80 -m
ipvsadm -a -t 192.168.1.10:80 -r 192.168.100.120:80 -m
ipvsadm -L -n
- -C: 清空规则
- -A:添加一个虚拟服务,一个虚拟服务是由:IP地址、端口号和协议三元组组成
- -t: tcp服务地址:ip:port形式
- -u: udp服务地址
- -s: 调度方法:rr、wrr、lc、wlc、lblc、lblcr、dh、sh、sed、nq
- -a: 添加一个真实服务器到一个虚拟服务
- -r: 指定真正服务器地址和端口
- -m: 使用地址伪装,即NAT模式
执行脚本并设置开机运行脚本
[root@lvs ~]# chmod +x lvs_rule.sh
[root@lvs ~]# source lvs_rule.sh
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.1.10:80 rr
-> 192.168.100.110:80 Masq 1 0 0
-> 192.168.100.120:80 Masq 1 0 0
#设置开机启动脚本
[root@lvs ~]# chmod +x /etc/rc.d/rc.local
[root@lvs ~]# vim /etc/rc.local
source /root/nat.sh &> /dev/null
关闭firewalld
[root@lvs ~]# systemctl stop firewalld.service
[root@lvs ~]# systemctl disable firewalld.service
三. 配置网站
设置web01的网站界面为:
[root@web01 ~]# cat /usr/share/nginx/html/index.html
<h1>web01</h1>
设置web02的网站界面:
[root@web02 ~]# cat /usr/share/nginx/html/index.html
<h1>web02</h1>
四. 访问测试
[root@lvs ~]# curl http://192.168.1.10
<h1>web02</h1>
[root@lvs ~]# curl http://192.168.1.10
<h1>web01</h1>
五. 配置NFS服务器
安装nfs-utils软件包
[root@nfs-server ~]# yum install nfs-utils -y
[root@nfs-server ~]# firewall-cmd --add-service=nfs --add-service=mountd --add-service=rpc-bind --permanent
[root@nfs-server ~]# firewall-cmd --reload
[root@nfs-server ~]# systemctl restart nfs-server.service
[root@nfs-server ~]# systemctl enable nfs-server.service
配置共享目录
[root@nfs-server ~]# mkdir /webroot
[root@nfs-server ~]# cat /etc/exports
/webroot 192.168.254.0/24(sync,rw,no_root_squash)
[root@nfs-server ~]# vim /webroot/index.html
<h1>this is test!</h1>
六. 网站挂载NFS目录
也需要安装nfs-utils软件包,然后挂载
[root@web01 yum.repos.d]# mount 192.168.254.100:/webroot /usr/share/nginx/html/
[root@web02 yum.repos.d]# mount 192.168.254.100:/webroot /usr/share/nginx/html/
设置永久挂载
[root@web02 yum.repos.d]# vim /etc/fstab
192.168.254.100:/webroot /usr/share/nginx/html nfs defaults 0 0
这样所有的网站页面统一,实现负载分担