虚拟机环境中Keepalived虚拟IP自动漂移的研究

Data Base Technique •
数据库技术
Electronic Technology & Software Engineering 电子技术与软件工程• 153
【关键词】虚拟机 集群 高可用 Keepalived
在生产环境和对集群运行稳定性要求较高的环境里，一般都需要进行集群的高可用和负载均衡配置。

实现负载均衡既有硬件方案也有软件方案。

硬件方案的成本较高，很多集群都采用了软件方案。

在软件方案中，很多人选择使用Keepalived 与负载均衡软件配合使用以达到集群的高可用和负载均衡。

随着虚拟化技术和云计算的发展，集群的构成也发生了变化，以前的集群一般是以服务器裸机来构建，但现在随着业务的云化，很多集群实际上构建于虚拟机之上，也称虚拟机集群。

由于虚拟机不像裸机直接运行于服务器硬件之上，它的工作必须依赖hypervisor ，因此在虚拟机环境中，某些软件的行为也发生了变化。

本文将主要研究Keepalived 在部分虚拟机环境中虚拟IP 不能自动漂移的问题。

1 研究虚拟机环境中Keepalived虚拟IP 自动漂移的背景
在采用软件方案建设高可用负载均衡集群时，我们一般会考虑Keepalived 或Heartbeat 与LVS 、HAProxy 、NGNIX 等负载均衡软件配合使用，以实现集群的高可用和负载均衡。

以Keepalived 为例，Keepalived 负责负载均衡服务器的高可用，而负载均衡服务器上的负载均衡软件则根据具体的负载均衡算法将访问流量转发至后端服务器。

可以看出，Keepalived 是访问数据链中非常关键的一环，一旦Keepalived 不能正常工作，即使负载均衡服务器和后端服务器工作正常，整个集群也无法正常提供服务。

我们研究发现，在部分虚拟机集群中，Keepalived 的虚拟IP 自动漂移功能在某些情况下并不能正常工作。

如今公有云得到了大力发展，很多在公有云平台上建立的
虚拟机环境中Keepalived 虚拟IP 自动漂移的研究
文/盛乐标 周庆林
随着云计算的发展，各行各业的业务也开始云化。

随着云端业务的增长，以虚拟机为基础搭建的虚拟机集群也迅速增多。

但是，某些软件在虚拟机上的行为与在裸机上的行为却存在差异。

本文研究的Keepalived 在虚拟机环境中的某些场景，会因为虚拟IP 不能正常漂移而导致故障转移失效。

本文将详细分析Keepalived 虚拟IP 漂移异常的原因，并提出一套可行的解决方案。

摘 要
集群实际上都是基于虚拟机的虚拟机集群。

该
功能的失常，给虚拟机集群的正常运行带来了很大的隐患。

本文将分析该功能失常的原因，并给出具体的解决方案。

2 虚拟机环境中Keepalived虚拟IP漂移的行为分析
2.1 Keepalived工作原理
Keepalived 是以虚拟路由冗余协议（Virtual Router Redundancy Protocol ，VRRP ）为基础实现集群或多台服务器高可用的软件。

Keepalived 将一组服务器组成一个服务器组，
在这组服务器里有一个Master 节点，其它均为Backup 节点。

Master 节点会获得一个虚拟IP （Virtual IP ，VIP ），Backup 节点没有虚
拟IP 。

Master 节点正常工作时，会周期性地在同网段内发送VRRP 组播（心跳包）。

当Backup 节点接收不到VRRP 心跳包时，则认为Master 节点发生故障，此时故障转移机制开始工作。

所有的Backup 节点根据它们的优先级选出一个新的Master 节点，原Master 节点的虚拟IP 漂移至新的Master 节点继续对外提供服务。

Keepalived 服务器上如果安装了负载均衡软件，还可以将来访的流量分流至各个后端服务器。

Keepalived 的工作原理图详见图1。

2.2 Keepalived节点环境
在我们的测试环境中，所有虚拟机的hypervisor 均为VMware ESXi 6.5。

虚拟机中安装的操作系统为CentOS 7.4。

Master 节点的IP 地址为192.168.2.6，Backup 节点的IP 地址为192.168.2.7，虚拟IP 地址为192.168.2.5。

Keepalived 使用的网络接口名称为ens192。

两台Keepalived 节点的Keepalived 软件版本均为v1.3.5，另外还安装了负载均衡软件HAProxy ，软件版本均为1.5.18。

Keepalived 安装完以后，进行相关配置，步骤如下：
（1）关闭CentOS 的SELinux 功能。

（2）将系统参数net.ipv4.ip_forward 设置为1，以允许数据包转发。

（3）由于Keepalived 需要发送目的地为224.0.0.18的VRRP 组播信息，因此在Keepalived 节点添加相应的防火墙规则：
firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 0 --in-interface ens192 --destination 224.0.0.18 --protocol vrrp -j ACCEPT
firewall-cmd --direct --permanent --add-
rule ipv4 filter OUTPUT 0 --out-interface ens192 --destination 224.0.0.18 --protocol vrrp -j ACCEPT
firewall-cmd --reload
（4）进行Keepalived 的配置，配置文件如下：
! Configuration File for keepalived global_defs { router_id main_router vrrp_lower_prio_no_advert true }
vrrp_script check_haproxy {
script "/etc/keepalived/check_haproxy.sh" interval 3 weight -2 fall 10 rise 2}
vrrp_instance VI_1 { state MASTER interface ens192 virtual_router_id 51 advert_int 2 priority 101 authentication { auth_type PASS
auth_pass 6be37dc3b2c96197d1600c583e10ad1f
}
virtual_ipaddress { 192.168.2.5 }
图1：Keepalived 工作原理图
（注：以Keeapalived Master 节点和Backup
节点各一台为例。

带箭头的黑色实线代表正常的网络路径，蓝色虚线代表故障转移后的网络
路径。

）
154 •电子技术与软件工程 Electronic Technology & Software Engineering
数据库技术
• Data Base Technique
track_script {
check_haproxy }}
上述配置文件主要需要注意两点，vrrp_instance VI_1 的state 参数主节点设置为MASTER ，备份节点设置为BACKUP ，优先级参数priority 主节点要高于备份节点，本文中主节点优先级为101，备份节点优先级为100。

除了上述参数和router_id 各自命名外，两台Keepalived 节点其它参数的设置均一致。

check_haproxy.sh 是Keepalived 的健康检查脚本，主要用于检测节点上HAProxy 工作是否正常。

（5）启动Keepalived 服务。

2.3 虚拟IP不能自动漂移的故障特征
在两台Keepalived 节点部署完成以后，我们进行了四组测试，测试结果如下：
（1）停止、启动、重启Keepalived 服务，Keepalived 故障转移成功。

（2）重启Network 服务，Keepalived 故障转移成功。

（3）关闭或重启其中一台节点，Keepalived 故障转移成功。

（4）通过ifdown 、ifup 命令关闭和打开网络接口（ifdown ens192和ifup ens192），Keepalived 故障转移失败。

四组测试中，前三组Keepalived 均成功地进行了故障转移，将原Master 节点的虚拟IP 转移至Backup 节点，但是在第四组测试中，我们相继使用ifdown 和ifup 命令关闭和打开网络接口，Keepalived 均不能进行故障转移。

因为Keepalived 通过VRRP 协议实现故障转移，我们通过在BACKUP 节点运行tcpdump –i ens192 –n vrrp 命令来查看成功进行故障转移时VRRP 心跳包的变化。

下面是运行systemctl stop keepalived.service 命令前后tcpdump 命令输出的三条VRRP 心跳包内容：
11:51:11.137727 I P 192.168.2.6 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 101, authtype simple, intvl 2s, length 20
11:51:12.023422 I P 192.168.2.6 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 0, authtype simple, intvl 2s, length 20
11:51:12.633406 I P 192.168.2.7 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 2s, length 20
我们发现在Keepalived 服务被停止时，Master 节点会发送一条含有信息prio 0的VRRP 心跳包，Backup 节点收到该心跳包后随即进行故障转移。

我们又尝试了service network restart 命令，也可以正常收到包含prio 0的VRRP 心跳包。

但是当我们使用ifdown
ens192命令关闭网络接口时，异常情况发生了：ens192接口被禁用后，在Backup 节点仍然可以正常、持续收到Master 节点发送的VRRP 心跳包（prio 值非0），但此时Master 节点的IP 地址已经不可用（ens192上的两条IP 192.168.2.5、192.168.2.6均已丢失），而Master 节点的Keepalived 服务也因为获取不到IP 信息进入inactive （dead ）状态。

由于Backup 节点仍能持续收到Master 节点发来的VRRP 心跳包，因此Backup 节点此时仍认为Master 节点工作正常，导致虚拟IP 不能漂移至Backup 节点，故障转移失效。

3 恢复虚拟IP自动漂移的解决方案
经过四组不同行为的测试，我们找到了虚拟机环境中虚拟IP 不能完成自动漂移的根源，即Master 节点的网络接口被禁用后，该节点仍然持续向外广播正常的VRRP 心跳包。

要解决这个问题，我们首先必须找出让Master 节点在网口被禁用后停止发送VRRP 心跳包的方法。

经过测试，发现如果在此时重启Keepalived 服务，Keepalived 在几秒钟后会从active （running ）状态进入inactive （dead ）状态，但是在此间隙，它会向外广播一条含有prio 0的VRRP 心跳包，Backup 节点接收到该心跳包后成功获取了Keepalived 虚拟IP ，故障转移成功。

有了上面的发现，我们就比较容易通过Shell 脚本自动化地恢复虚拟IP 的漂移，完成故障转移。

其基本思路为：编写一个周期性执行的Shell 脚本放入cron 定时任务，持续监控网络接口ens192的状态，如果发现该接口不可用，则重启一次Keepalived 服务；如果该接口恢复正常，再重启一次Keepalived 服务。

该脚本的主要内容如下：
#!/bin/bash source /root/.bashrc IP=192.168.2.6step=2
for (( i = 0; i < 60; i=(i+step) )); do
d a t
e ="`d a t e '+%Y-%m -%d %H:%M:%S'`"
lost2=`ping -c 1 -w 1 $IP 2>&1` networkstate=`cat /etc/keepalived/networkstate`
if [[ $lost2 == "connect: Network is unreachable" ]]; then
if [[ $networkstate == "0" ]]; then systemctl restart keepalived > /dev/null 2>&1
echo "1" > /etc/keepalived/networkstate
fi else
if [[ $networkstate == "1" ]]; then systemctl restart keepalived > /dev/null 2>&1
echo "0" > /etc/keepalived/networkstate
fi fi
sleep $step done exit 0
在该脚本按计划（每两秒执行一次）运行以后，我们再次测试了虚拟IP 的漂移行为，发现虚拟IP 的自动漂移恢复正常，Master 节点与Backup 节点间的故障转移得到了完美解决。

4 结束语
很多集群采用了Keepalived 的高可用方案。

然而，在虚拟机集群环境中，在某些场景Keepalived 的虚拟IP 并不能正常漂移，从而导致了集群的高可用特性失效。

本文通过研究虚拟机环境中Keepalived 虚拟IP 漂移异常的行为，找出了具体的解决方案，可以为高可用虚拟机集群的建设提供参考。

参考文献
[1]祁伟.云计算:从基础架构到最佳时间
[M].清华大学出版社,2013.
[2]王理,姜新超.云计算环境下的基础架构
融合[J].信息系统工程,2013(11):32-35.
[3]Scott Carey.云计算2018年发展趋势：
无服务器计算、Kubernetes 和供应商垄断[N].计算机世界,2018-01-22(010).[4]Hwang, Kai, Geoffrey C Fox, J. J
Dongarra. Distributed and Cloud Computing: From Parallel Processing to the Internet of Things. Amsterdam: Morgan Kaufmann, 2012.
[5]汪海洋,凌永兴,包丽红,姚萌萌.基于
keepalived 的高可用性应用研究[J].电子技术,2014,43(07):21-24.
作者简介
盛乐标（1982-），男，江苏省盐城市人。

博士学历。

高级工程师，从事大规模并行计算方法研究。

周庆林（1951-），男，江苏省南京市人。

教授级高级工程师，从事天体力学及数值方法研究。

作者单位
南京大学高性能计算中心 江苏省南京市 210093。