高可用集群(High Availability Cluster,简称HA Cluster),是指以减少服务中断时间为目的得服务器集群技术。它通过保护用户得业务程序对外部间断提供的服务,把因为软件,硬件,认为造成的故障对业务得影响降低到最小程度。
之前部署的LVS有说到一个缺点就是LVS只是前端调度的功能,没有健康检查,导致如果后端服务器出现故障的话,请求还是会发到故障的服务器,今天我们通过Keepalive健康检查来解决这个问题,同时,Keepalive还对director做冗余,如果主director故障了,备director会及时顶上工作,实现高可用。
KeepAlived
keepAlived简介
Keepalived的作用是检测服务器状态,如果有一台web服务器宕机,或工作出现故障,Keepalived将检测到,并将有故障的服务器从系统中剔除,同时使用其他服务器代替该服务器的工作,当服务器工作正常后Keepalived自动将服务器加入到服务器群中。
VRRP协议
在现实的网络环境中。主机之间的通信都是通过配置静态路由或者(默认网关)来完成的,而主机之间的路由器一旦发生故障,通信就会失效,因此这种通信模式当中,路由器就成了一个单点瓶颈,为了解决这个问题,就引入了VRRP协议。
VRRP协议是一种容错的主备模式的协议,保证当主机的下一跳路由出现故障时,由另一台路由器来代替出现故障的路由器进行工作,通过VRRP可以在网络发生故障时透明的进行设备切换而不影响主机之间的数据通信。
故障迁移原理
在 Keepalived 服务正常工作时,主 Master 节点会不断地向备节点发送(多播的方式)心跳消息,用以告诉备 Backup 节点自己还活着,当主 Master 节点发生故障时,就无法发送心跳消息,备节点也就因此无法继续检测到来自主 Master 节点的心跳了,于是调用自身的接管程序,接管主 Master 节点的 IP 资源及服务。而当主 Master 节点恢复时,备 Backup 节点又会释放主节点故障时自身接管的 IP 资源及服务,恢复到原来的备用角色。
keepAlived原理
Keepalived工作在TCP/IP参考模型的三层、四层、五层
分布式选主策略
在一个一主多备的Keepalived集群中,priority值最大的将成为集群中的MASTER节点,而其他都是BACKUP节点。在MASTER节点发生故障后,BACKUP节点之间将进行“民主选举”,通过对节点优先级值priority和weight的计算,选出新的MASTER节点接管集群服务。
设置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值的设置,有一个简单的标准,即weight值的绝对值要大于MASTER和BACKUP节点priority值之差。由此可见,对于weight值的设置要非常谨慎,如果设置不好,主节点发生故障时将导致集群角色选举失败,使集群陷于瘫痪状态。
LVS+keepAlived实战
实战拓扑
为了测试lvs的高可用,这里需要增加一台lvs服务器,需在此服务器上安装ipvsadm。
keepAlived安装和配置
在两台lvs服务器上都需要安装keepAlived,安装命令如下:
1 | yum install -y keepalived |
keepAlived安装完成后,在/etc/keepalived目录下有一个keepalived.conf配置文件,内容如下:
1 | ! Configuration File for keepalived |
配置keepAlived
基于上述配置文件和实战拓扑图及服务器规划,对两台lvs服务器分别修改keepalived.conf配置如下:
lvs主服务器
1 | ! Configuration File for keepalived |
lvs备份服务器
1 | ! Configuration File for keepalived |
注意:配置文件中的key和大括号之间一定要有空格
启动keepAlived
在两台lvs服务器上分别启动keepAlived,命令如下:
1 | service keepalived start |
高可用测试 4.3.1 测试环境检查
上述步骤执行完毕后,可以在lvs主服务器和备份服务器分别执行ifconfig命令,可以查看到VIP被绑定到了主服务器,如下:
1 | [root@lvs01 ~]# ifconfig |
这样,就可以在客户端请求VIP192.168.116.134来进行测试。
测试负载均衡
在客户端发起请求,测试负载均衡,如下:
1 | [root@client ~]# curl 192.168.116.134 |
测试RS高可用
关闭一台RS后(这里可以使用ifconfig 网卡名 down命令暂时关闭网卡),客户端继续发起请求,查看是否可以正常访问,如下:
1 | [root@client ~]# curl 192.168.116.134 |
会发现,此时客户端可以正常访问,但只有RS2在提供服务。这说明,keepAlived检测到了RS1服务器异常,将其剔除了。
此时再启动RS1服务器,客户端继续访问,会发现响应结果如下,keepAlived检测到RS1服务器恢复正常,又将其加入服务列表了。
1 | [root@client ~]# curl 192.168.116.134 |
测试LVS高可用
这里主要进行两个测试:
测试lvs主服务宕机
使用ifconfig 网卡名 down命令,关闭主服务器网卡,此时主服务器不能提供服务。观察备份服务器是否将VIP绑定到自己,以及客户端是否可以继续正常访问。如下:
关闭主服务器网卡
1 | [root@lvs01 keepalived]# ifconfig ens33 down |
观察备份服务器,会发现VIP已经绑定过来了。这里实际是keepAlived检测到了主服务器的异常,而做出的故障转移和自动切换。
1 | [root@lvs02 ~]# ifconfig |
观察客户端是否可以继续正常访问
1 | [root@client ~]# curl 192.168.116.134 |
测试lvs主服务器恢复
上述测试通过后,可以开启主服务器网卡,让其能够提供服务,然后观察VIP是否会回到主服务器。
开启主服务器网卡
1 | ifconfig ens33 up |
查看主服务器和备份服务器
主服务器
1 | [root@lvs01 ~]# ifconfig |
备份服务器
1 | [root@lvs02 ~]# ifconfig |
会发现,VIP重新绑定到了主服务器。