LVS+KeepAlived高可用部署架构

1 构建高可用集群

1.1 什么是高可用集群

高可用集群(High Availability Cluster，简称HA Cluster)，是指以减少服务中断时间为目的得服务器集群技术。它通过保护用户得业务程序对外部间断提供的服务，把因为软件，硬件，认为造成的故障对业务得影响降低到最小程度。总而言之就是保证公司业务7*24小时不宕机。

1.2 高可用衡量标准

衡量集群的可用性(HA)高低，可以从MTTF(平均无故障时间)和MTTR(平均故障维修时间)进行考量，公式为:HA=MTTF/(MTTF+MTTR)*100%，具体衡量标准可以参考下表

1.3 高可用保障

对集群中的服务器进行负载均衡、健康监测，并在服务器出现故障时能进行故障转移，自动切换到正常服务器是高可用保障的必要手段。

1.3.1 负载均衡

常见的负载均衡手段如下:
硬件负载均衡，如F5 软件负载均衡，如nginx、haproxy、lvs 几种软件负载均衡技术比较

1.3.2 健康监测和自动切换

常见的健康监测和自动切换软件有keepAlived和heartBeat，其二者对比如下:
Keepalived使用更简单:从安装、配置、使用、维护等角度上对比，Keepalived都比Heartbeat要简单;
Heartbeat功能更强大:Heartbeat虽然复杂，但功能更强大，配套工具更全，适合做大型集群管理，而Keepalived主要用于集群倒换，基本没有管理功能。

1.4 高可用拓扑图

2 软件负载均衡技术LVS

2.1 LVS简介

2.1.1 什么是lvs

LVS是Linux Virtual Server的简写，在1998年5月由章文嵩博士成立。工作在OSI模型的四层，基于IP进行负载均衡。在linux2.2内核时，IPVS就已经以内核补丁的形式出现。从2.4版本以后，IPVS已经成为linux官方标准内核的一部分。

2.1.2 LVS官方资料链接

lvs项目介绍 [http://www.linuxvirtualserver.org/zh/lvs1.html]
lvs集群的体系结构 [http://www.linuxvirtualserver.org/zh/lvs2.html]
lvs集群中的IP负载均衡技术 [http://www.linuxvirtualserver.org/zh/lvs3.html]
lvs集群的负载调度 [http://www.linuxvirtualserver.org/zh/lvs4.html]
lvs中文站点 [http://zh.linuxvirtualserver.org]

2.2 LVS场景术语

LVS服务器(DS)
集群中节点服务器(RS)
虚拟IP地址(VIP)，用于向客户端提供服务的IP地址(配置于负载均衡器上)
真实服务器的IP地址(RIP)，集群中节点服务器的IP地址
负载均衡器IP地址(DIP)，负载均衡器的IP地址，物理网卡上的IP
客户端主机IP地址(CIP)，终端请求用户的主机IP地址

2.3 工作原理

LVS负载均衡调度技术是在linux内核中实现的，使用配置LVS时，不是直接配置内核中的IPVS，而是通过IPVS的管理工具IPVSADM来管理配置，LVS集群负载均衡器接受所有入站客户端的请求，并根据算法来决定由哪个集群的节点来处理请求。

2.4 LVS的四种工作模式

2.4.1 NAT模式

NAT(Network Address Translation)模式是基于NAT技术实现的。在此模式中，LVS服务器既要处理请求的接入，又要处理请求的响应。因此存在较大的性能瓶颈。

客户端将请求发往前端的负载均衡器，请求报文源地址是CIP(客户端IP),后面统称为CIP)，目标地址为VIP(负载均衡器前端地址，后面统称为VIP)。
负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将客户端请求报文的目标地址改为了后端服务器的RIP地址并将报文根据算法发送出去。
报文送到Real Server后，由于报文的目标地址是自己，所以会响应该请求，并将响应报文返还给LVS。
然后lvs将此报文的源地址修改为本机并发送给客户端。
注意：在NAT模式中，Real Server的网关必须指向LVS，否则报文无法送达客户端。
NAT模式缺点：
扩展性有限。当服务器节点（普通PC服务器）增长过多时,负载均衡器将成为整个系统的瓶颈，因为所有的请求包和应答包的流向都经过负载均衡器。当服务器节点过多时，大量的数据包都交汇在负载均衡器那，速度就会变慢！

2.4.2 DR模式

DR(Direct Routing)模式是LVS的默认工作模式，也叫直接路由模式。只处理请求的接入，不处理请求的响应。因此性能高，瓶颈小。

客户端将请求发往前端的负载均衡器，请求报文源地址是CIP，目标地址为VIP。
负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将客户端请求报文的源MAC地址改为自己DIP的MAC地址，目标MAC改为了RIP的MAC地址，并将此包发送给RS。
RS发现请求报文中的目的MAC是自己，就会将次报文接收下来，处理完请求报文后，将响应报文通过lo接口送给eth0网卡直接发送给客户端。
注意：需要设置lo接口的VIP不能响应本地网络内的arp请求。
优点：
负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户端。因此DR模式的效率很高，但是配置稍微复杂一点，因此对于访问量不是特别大的公司可以用Haproxy/Nginx取代。日1000-2000W PV或者并发请求1万一下都可以考虑用Haproxy/Nginx。
缺点：所有节点和调度器只能在一个局域网里面。

2.4.3 TUN模式（隧道模式）

客户端将请求发往前端的负载均衡器，请求报文源地址是CIP，目标地址为VIP。
负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将在客户端请求报文的首部再封装一层IP报文,将源地址改为DIP，目标地址改为RIP,并将此包发送给RS。
RS收到请求报文后，会首先拆开第一层封装,然后发现里面还有一层IP首部的目标地址是自己lo接口上的VIP，所以会处理次请求报文，并将响应报文通过lo接口送给eth0网卡直接发送给客户端。

注意：需要设置lo接口的VIP不能在共网上出现。
总结：

TUN模式必须在所有的 realserver 机器上面绑定 VIP 的 IP 地址
TUN模式的 vip ------>realserver 的包通信通过 TUNNEL 模式，不管是内网和外网都能通信，所以不需要 lvs vip 跟 realserver 在同一个网段内
TUN模式 realserver 会把 packet 直接发给 client 不会给 lvs 了
TUN模式走的隧道模式，所以运维起来比较难，所以一般不用。
优点：
负载均衡器只负责将请求包分发给后端节点服务器，而RS将应答包直接发给用户。所以，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，就能处理很巨大的请求量，这种方式，一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。
缺点：
隧道模式的RS节点需要合法IP，这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议，服务器可能只局限在部分Linux系统上。

2.4.4 FULLNAT模式

淘宝定制化的技术，linux内核不支持。
无论是 DR 还是 NAT 模式，不可避免的都有一个问题：LVS 和 RS 必须在同一个 VLAN 下，否则 LVS 无法作为 RS 的网关。
这引发的两个问题是：

同一个 VLAN 的限制导致运维不方便，跨 VLAN 的 RS 无法接入。
LVS 的水平扩展受到制约。当RS水平扩容时，总有一天其上的单点 LVS 会成为瓶颈。
Full-NAT 由此而生，解决的是LVS和RS跨VLAN的问题，而跨VLAN问题解决后，LVS和RS不再存在VLAN上的从属关系，可以做到多个LVS对应多个RS，解决水平扩容的问题。
在包从 LVS 转到 RS 的过程中，源地址从客户端 IP 被替换成了 LVS 的内网 IP。内网 IP 之间可以通过多个交换机跨 VLAN 通信。当 RS 处理完接受到的包，返回时，会将这个包返回给 LVS 的内网 IP，这一步也不受限于 VLAN。LVS 收到包后，在 NAT 模式修改源地址的基础上，再把 RS 发来的包中的目标地址从 LVS 内网 IP 改为客户端的 IP。
Full-NAT 主要的思想是把网关和其下机器的通信，改为了普通的网络通信，从而解决了跨 VLAN 的问题。采用这种方式，LVS 和 RS 的部署在 VLAN 上将不再有任何限制，大大提高了运维部署的便利性。

2.5 LVS 调度算法

2.5.1 静态调度算法

RR：Round Robin 轮询调度
WRR：Weighted RR 加权轮询调度
SH：Source Hashing源地址哈希调度
DH：Destination Hashing目标地址哈希调度

2.5.2 动态调度算法

LC：Least Connections最小连接数调度
WLC：Weighted LC加权最小连接数调度 (默认)
SED：Shortest Expection Delay初始连接高权重优先
NQ：Nerver Queue 第一轮平均分配，后续SED
LBLC：Locality-Based LC 动态的DH算法
LBLCR：LBLC with Replication 带复制功能的LBLC
FO: Weighted Fail Over，linux内核4.15后新增的调度算法
OVF：Overflow-connection，linux内核4.15后新增的调度算法

2.5.3 LVS 基本命令

对于lvs的操作，主要是通过ipvsadm软件实现，Linux内核已集成lvs。常用的lvs操作命令如下：

集群服务管理：

# 此命令用来添加一个lvs策略，IP指VIP，调度算法是12种调度算法 的一种
ipvsadm -A -t IP -s 调度算法
# 此命令用来清除一个lvs策略
ipvsadm -C
# 此命令用来保存一个lvs策略
ipvsadm -S
# 此命令用来加载一个lvs策略
ipvsadm -R
# 此命令用来查看策略
ipvsadm -L

集群RS管理

# 添加一台RS，
# IP1指VIP
# IP2指RIP
# -m|g|i中m是NAT
# g是 DR，
ipvsadm -a -t IP1 -r IP2 - m|g|i
# 此命令用来删除一台RS，IP1指VIP，IP2指RIP
ipvsadm -d -t IP1 -r IP2

2.6 LVS 实战（DR模式）

ARP(Address Resolution Protocol)地址解析协议，是根据IP地址获取物理地址 (MAC)的一个 TCP/IP协议。主机发送信息时将包含目标IP地址的ARP请求广播到局域网络上的所有主机，并接收返回消息，以此确定目标的物理地址;收到返回消息后将该IP地址和物理地址存入本机ARP缓存中并保留一定时间，下次请求时直接查询ARP缓存以节约资源。

2.6.1 DR模式服务器拓扑图

服务器准备：

LVS（Q110）：CentOS7 DIP：192.168.88.110 VIP：192.168.88.88
RS1（Q111）： CentOS7 RIP：192.168.88.111 VIP：192.168.88.88
RS2（Q112）： CentOS7 RIP：192.168.88.112 VIP：192.168.88.88

2.6.2 DR模式实现

通过拓扑图可以发现，需要让LVS和RS在同一个网段，并且在两个RS服务器上也需要绑定VIP。操作步骤如下：

在两台RS服务器Q111和Q112上进行如下ARP抑制操作，并配置VIP到lo网卡上，如下:

# arp抑制，修改内核
echo 1 > /proc/sys/net/ipv4/conf/ens33/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce 
echo 2 > /proc/sys/net/ipv4/conf/ens33/arp_announce

# 安装ifconfig,centos7没有ifconfig
yum install net-tools.x86_64 -y
# 配置VIP到lo网卡 这里的子网掩码需要4个255。
ifconfig lo:8 192.168.88.88 netmask 255.255.255.255
# 查看IP
ifconfig

查看网关是否生效

[root@q111 ~]# route -n

在两台RS服务器Q111和Q112上都安装httpd服务器（测试使用）：

# 下载安装httpd服务，命令如下
yum install -y httpd
# 设置首页内容(RS2把内容改为this is RS2)
echo this is RS01 > /var/www/html/index.html
# 启动httpd
systemctl start httpd

通过单独访问192.168.88.111和192.168.88.112可以正常访问。

在LVS服务器Q110上安装ipvsadm，绑定VIP192.168.88.88：

# 1）安装ipvsadm
yum install -y ipvsadm
# 2）在lvs的ens33网卡上绑定VIP192.168.88.100
ifconfig ens33:8 192.168.88.88/24
# 查看ip
ifconfig

4. LVS服务器上设置DR策略和负载规则

# 设置规则
ipvsadm -A -t 192.168.88.88:80 -s rr
# 添加RS
ipvsadm -a -t 192.168.88.88:80 -r 192.168.88.111 -g -w 1
ipvsadm -a -t 192.168.88.88:80 -r 192.168.88.112 -g -w 1
#查看策略
ipvsadm -Ln

验证
客户端测试：192.168.88.88，可以使用浏览器或者curl命令

LVS上查看调度情况

[root@q110 ~]# ipvsadm -Lnc

FIN_WAIT：正常情况

2.6.3 小结

以上以DR模型搭建了一套简单的负载均衡环境，但是存在几个问题：

如果LVS服务器挂了会出现什么问题?
如何进行故障转移、自动切换?
如果后端某台RS服务器挂了会出现什么问题?
如何获知RS服务器状态?
解决方案：通过使用LVS+KeepAlived实现高可用架构。

3 KeepAlived

3.1 keepAlived简介

Keepalived的作用是检测服务器状态，如果有一台web服务器宕机，或工作出现故障，Keepalived将检测到，并将有故障的服务器从系统中剔除，同时使用其他服务器代替该服务器的工作，当服务器工作正常后Keepalived自动将服务器加入到服务器群中。

3.2 keepAlived特点

3.2.1 健康检测

tcp_check：
工作在第4层，keepalived向后端服务器发起一个tcp连接请求，如果后端服务器没有响应或超时，那么这个后端将从服务器池中移除。
http_get：
工作在第5层，向指定的URL执行http请求，将得到的结果用md5加密并与指定的 md5值比较看是否匹配，不匹配则从服务器池中移除;此外还可以指定http返回码来判断检测是否成功。HTTP_GET可以指定多个URL用于检测，这个一台服务器有多个虚拟主机的情况下比较好用。
misc_check：
用脚本来检测，脚本如果带有参数，需将脚本和参数放入双引号内。
ssl_get：
和http_get相似，不同的只是用SSL连接。
smtp_check：
主要用于邮件系统SMTP协议的检测

3.2.2 故障迁移

VRRP协议
在现实的网络环境中。主机之间的通信都是通过配置静态路由或者(默认网关)来完成的，而主机之间的路由器一旦发生故障，通信就会失效，因此这种通信模式当中，路由器就成了一个单点瓶颈，为了解决这个问题，就引入了VRRP协议。
VRRP协议是一种容错的主备模式的协议，保证当主机的下一跳路由出现故障时，由另一台路由器来代替出现故障的路由器进行工作，通过VRRP可以在网络发生故障时透明的进行设备切换而不影响主机之间的数据通信。
故障迁移原理
在 Keepalived 服务正常工作时，主 Master 节点会不断地向备节点发送(多播的方式)心跳消息，用以告诉备 Backup 节点自己还活着，当主 Master 节点发生故障时，就无法发送心跳消息，备节点也就因此无法继续检测到来自主 Master 节点的心跳了，于是调用自身的接管程序，接管主 Master 节点的 IP 资源及服务。而当主 Master 节点恢复时，备 Backup 节点又会释放主节点故障时自身接管的 IP 资源及服务，恢复到原来的备用角色。

3.3 keepAlived原理

Keepalived工作在TCP/IP参考模型的三层、四层、五层，其原理如下：
网络层
Keepalived通过ICMP协议向服务器集群中的每一个节点发送一个ICMP数据包(有点类似与 Ping的功能)，如果某个节点没有返回响应数据包，那么认为该节点发生了故障， Keepalived将报告这个节点失效，并从服务器集群中剔除故障节点。
传输层
Keepalived在传输层里利用了TCP协议的端口连接和扫描技术来判断集群节点的端口是否正常。 比如对于常见的WEB服务器80端口。或者SSH服务22端口，Keepalived一旦在传输层探测到这些端口号没有数据响应和数据返回，就认为这些端口发生异常，然后强制将这些端口所对应的节点从服务器集群中剔除掉。
应用层
Keepalived的运行方式更加全面化和复杂化，用户可以通过自定义Keepalived工作方式。例如:可以通过编写程序或者脚本来运行Keepalived，而Keepalived将根据用户的设定参数检测各种程序或者服务是否正常，如果Keepalived的检测结果和用户设定的不一致时， Keepalived将把对应的服务器从服务器集群中剔除。

3.4 分布式选举策略

3.4.1 仅设置priority

在一个一主多备的Keepalived集群中，priority值最大的将成为集群中的MASTER节点，而其他都是 BACKUP节点。在MASTER节点发生故障后，BACKUP节点之间将进行“民主选举”，通过对节点优先级值 priority和weight的计算，选出新的MASTER节点接管集群服务。

3.4.2 设置priority和weight

weight值为正数时
在vrrp_script中指定的脚本如果检测成功，那么MASTER节点的权值将是weight值与priority值之和;如果脚本检测失效，那么MASTER节点的权值保持为priority值
MASTER 节点vrrp_script脚本检测失败时，如果MASTER节点priority值小于BACKUP节点weight值与 priority值之和，将发生主、备切换。
MASTER节点vrrp_script脚本检测成功时，如果MASTER节点weight值与priority值之和大于BACKUP节点weight值与priority值之和，主节点依然为主节点，不发生切换。
weight值为负数时
在vrrp_script中指定的脚本如果检测成功，那么MASTER节点的权值仍为priority值，当脚本检测失败时，MASTER节点的权值将是priority值与weight值之差 MASTER节点vrrp_script脚本检测失败时，如果MASTER节点priority值与weight值之差小于BACKUP节点priority值，将发生主、备切换。 MASTER节点vrrp_scrip脚本检测成功时，如果MASTER节点priority值大于BACKUP节点priority值时，主节点依然为主节点，不发生切换。
对于weight值的设置，有一个简单的标准，即weight值的绝对值要大于MASTER和BACKUP节点priority 值之差。由此可见，对于weight值的设置要非常谨慎，如果设置不好，主节点发生故障时将导致集群角色选举失败，使集群陷于瘫痪状态。

4 LVS+keepAlived

4.1 网络拓扑图

为了测试lvs的高可用，这里需要增加一台lvs服务器，需在此服务器上安装ipvsadm。RS1 和 RS2保持不变。

4.2 keepAlived安装和配置

4.2.1 安装keepAlived

在两台lvs服务器上都需要安装keepAlived，安装命令如下:

yum install -y keepalived

keepAlived安装完成后，在/etc/keepalived目录下有一个keepalived.conf原配置文件，内容如下:

! Configuration File for keepalived
global_defs {
   notification_email {
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 192.168.200.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}
#上面的配置无需关注，重点关注和修改下面的配置 
vrrp_instance VI_1 {
	#标识当前lvs是主，根据实际lvs服务器规划确定，可选值
	state MASTER
	MASTER和BACKUP
	#lvs服务器提供服务器的网卡，根据实际服务器网卡进行修改
	interface eth0 
	#lvs提供的服务所属ID，目前无需修改
	virtual_router_id 51
	#lvs服务器的优先级，主服务器最高，备份服务器要低于主服务器
	priority 100 
	# VRRP Multicast 广播周期秒数
	advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
	}
	virtual_ipaddress {
        192.168.88.88/24 dev ens33 label ens33:8
    }
}
#virtual_ipaddress用于配置VIP和LVS服务器的网卡绑定关系，一般需要修改 
#示例: 192.168.25.100/24 dev ens33 label ens33:9 
virtual_ipaddress {
        192.168.200.16
        192.168.200.17
        192.168.200.18
} }
#配置lvs服务策略，相当于ipvsadm -A -t 192.168.25.100:80 -s rr，一般需要修改 
virtual_server 192.168.200.100 443 {
	delay_loop 6
	#配置lvs调度算法，默认轮询
	lb_algo rr
	#配置lvs工作模式，可以改为DR
	lb_kind NAT
	#用于指定同一个client在多久内，只去请求第一次提供服务的RS，为查看轮询效果，这里需要改为0
	persistence_timeout 50
	#TCP协议
	protocol TCP
	#配置RS信息，相当于ipvsadm -a -t 192.168.25.100:80 -r 192.168.25.112 -g 
	real_server 192.168.201.100 443 {
		#当前RS的权重
		weight 1
		#SSL_GET健康检查，一般改为HTTP_GET
		SSL_GET {
			#两个url可以删除一个，url内的内容改为path /和status_code 200，digest删除 
			url {
				path /
				  digest ff20ad2481f97b1754ef3e12ecd3a9cc
			}
			url {
			  path /mrtg/
			  digest 9b3a0c85a887a256d6939da88aabd8cd
			}
			connect_timeout 3
			nb_get_retry 3
			delay_before_retry 3
		} 
	}
}
#下面的配置实际是两组lvs服务的配置，含义和上面的lvs服务配置一致。如果用不到，下面的配置可以全部 删除
virtual_server 10.10.10.2 1358 {
    delay_loop 6
    lb_algo rr
    lb_kind NAT
    persistence_timeout 50
    protocol TCP
    sorry_server 192.168.200.200 1358
    real_server 192.168.200.2 1358 {
        weight 1
        HTTP_GET {
            url {
 ....

4.2.2 配置keepAlived

基于上述配置文件和实战拓扑图及服务器规划，对两台lvs服务器分别修改keepalived.conf配置如下:
LVS主服务器（Q110）

! Configuration File for keepalived
global_defs {
   router_id LVS_DEVEL
}
vrrp_instance VI_1 { 
	#主服务器
	state MASTER 
	interface ens33 
	virtual_router_id 51 
	#优先级高
	priority 100
	advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.88.88/24 dev ens33 label ens33:8
	} 
}
virtual_server 192.168.88.88 80 {
    delay_loop 6
    lb_algo rr
    lb_kind DR
    persistence_timeout 0
    protocol TCP
    real_server 192.168.88.111 80 {
        weight 1
        HTTP_GET {
            url {
				path /
				status_code 200
			}
			connect_timeout 3
			nb_get_retry 3
			delay_before_retry 3
		} 
	}
	real_server 192.168.88.112 80 {
        weight 1
        HTTP_GET {
            url {
				path /
				status_code 200
			}
			connect_timeout 3
			nb_get_retry 3
			delay_before_retry 3
		} 
	}
}

LVS备用服务器

# 拷贝主服务器配置到备用服务器并覆盖
scp /etc/keepalived/keepalived.conf root@192.168.88.120:`pwd`
# 进入备用服务器修改配置
vi /etc/keepalived/keepalived.conf
# 调整内容1：vrrp_instance VI_1 中state 改为 BACKUP，权重priority 50

注意：配置文件中的key和大括号之间一定要有空格

4.2.3 启动keepAlived

在两台lvs服务器上分别启动keepAlived，命令如下:

systemctl start keepalived

4.3 高可用测试

4.3.1 测试环境检查

上述步骤执行完毕后，可以在lvs主服务器和备份服务器分别执行ifconfig命令，可以查看到VIP被绑定到了主服务器，如下:

4.3.2 测试负载均衡

在客户端发起请求，测试负载均衡，如下:

# qin @ QinMac in ~ [8:54:24]
$ curl 192.168.88.88
this is RS02

# qin @ QinMac in ~ [8:56:05]
$ curl 192.168.88.88
this is RS01

# qin @ QinMac in ~ [8:56:15]
$ curl 192.168.88.88
this is RS02

# qin @ QinMac in ~ [8:56:16]
$ curl 192.168.88.88
this is RS01

4.3.3 测试RS高可用

关闭一台RS1后(这里可以使用systemctl stop httpd)，客户端继续发起请求，查看是否可以正常访问。

# qin @ QinMac in ~ [8:56:19]
$ curl 192.168.88.88
this is RS02

# qin @ QinMac in ~ [9:01:21]
$ curl 192.168.88.88
this is RS02

# qin @ QinMac in ~ [9:01:23]
$ curl 192.168.88.88
this is RS02

会发现，此时客户端可以正常访问，但只有RS2在提供服务。这说明，keepAlived检测到了RS1服务器异常，将其剔除了。
此时再启动RS1服务器，客户端继续访问，会发现响应结果如下，keepAlived检测到RS1服务器恢复正常，又将其加入服务列表了

4.3.4 测试LVS高可用

测试lvs主服务宕机
使用ifconfig 网卡名 down命令，关闭主服务器网卡，此时主服务器不能提供服务。观察备份服务器是否将VIP绑定到自己，以及客户端是否可以继续正常访问。如下: 关闭主服务器网卡

[root@q110 keepalived]# ifconfig ens33 down

观察备份服务器，会发现VIP已经绑定过来了。这里实际是keepAlived检测到了主服务器的异常，而做出的故障转移和自动切换。

观察客户端是否可以继续正常访问

# qin @ QinMac in ~ [9:02:32]
$ curl 192.168.88.88
this is RS01

# qin @ QinMac in ~ [9:04:24]
$ curl 192.168.88.88
this is RS02

测试lvs主服务器恢复上述测试通过后，可以开启主服务器网卡，让其能够提供服务，然后观察VIP是否会回到主服务器。开启主服务器网卡

ifconfig ens33 up

查看主服务器和备份服务器
主服务器

备服务器

会发现，VIP重新绑定到了主服务器。

posted @ 2022-02-26 16:44 Dvomu 阅读(1213) 评论(0) 编辑收藏举报

刷新页面返回顶部

Dvomu