keepalived vip漂移基本原理及选举算法

Posted 大数据从业者

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了keepalived vip漂移基本原理及选举算法相关的知识,希望对你有一定的参考价值。

keepalived可以将多个无状态的单点通过虚拟IP(以下称为VIP)漂移的方式搭建成一个高可用服务,常用组合比如 keepalived+nginx,lvs,haproxy和memcached等。它的实现基础是VRRP协议,包括核心的MASTER竞选机制都是在VRRP协议所约定的。

一、配置说明:
keepalived的配置位于/etc/keepalived/keepalived.conf,配置文件格式包含多个必填/可选的配置段,部分重要配置含义如下:
global_defs: 全局定义块,定义主从切换时通知邮件的SMTP配置。
vrrp_instance: vrrp实例配置。
vrrp_script: 健康检查脚本配置。

细分下去,vrrp_instance配置段包括:
state: 实例角色。分为一个MASTER和一(多)个BACKUP。
virtual_router_id: 标识该虚拟路由器的ID,有效范围为0-255。
priority: 优先级初始值,竞选MASTER用到,有效范围为0-255。
advert_int: VRRP协议通告间隔。
interface: VIP所绑定的网卡,指定处理VRRP多播协议包的网卡。
mcast_src_ip: 指定发送VRRP协议通告的本机IP地址。
authentication: 认证方式。
virtual_ipaddress: VIP。
track_script: 健康检查脚本。

vrrp_script配置段包括:
script: 一句指令或者一个脚本文件,需返回0(成功)或非0(失败),keepalived以此为依据判断其监控的服务状态。
interval: 健康检查周期。
weight: 优先级变化幅度。
fall: 判定服务异常的检查次数。
rise: 判定服务正常的检查次数。

这里有MASTERBACKUP的参考配置。

二、选举算法
keepalived中优先级高的节点为MASTER。MASTER其中一个职责就是响应VIP的arp包,将VIP和mac地址映射关系告诉局域网内其 他主机,同时,它还会以多播的形式(目的地址224.0.0.18)向局域网中发送VRRP通告,告知自己的优先级。网络中的所有BACKUP节点只负责 处理MASTER发出的多播包,当发现MASTER的优先级没自己高,或者没收到MASTER的VRRP通告时,BACKUP将自己切换到MASTER状 态,然后做MASTER该做的事:1.响应arp包,2.发送VRRP通告。

MASTER和BACKUP节点的优先级如何调整?
首先,每个节点有一个初始优先级,由配置文件中的priority配置项指定,MASTER节点的priority应比BAKCUP高。运行过程中keepalived根据vrrp_script的weight设定,增加或减小节点优先级。规则如下:

1. 当weight > 0时,vrrp_script script脚本执行返回0(成功)时优先级为priority + weight, 否则为priority。当BACKUP发现自己的优先级大于MASTER通告的优先级时,进行主从切换。
2. 当weight < 0时,vrrp_script script脚本执行返回非0(失败)时优先级为priority + weight, 否则为priority。当BACKUP发现自己的优先级大于MASTER通告的优先级时,进行主从切换。 3. 当两个节点的优先级相同时,以节点发送VRRP通告的IP作为比较对象,IP较大者为MASTER。 以上文中的配置为例: HOST1: 10.15.8.100, priority=91, MASTER(default) HOST2: 10.15.8.101, priority=90, BACKUP VIP: 10.15.8.102 weight = 2 抓包命令: tcpdump -nn vrrp 示例一:HOST1和HOST2上keepalived和nginx均正常。

1
2
3
4
16:33:07.697281 IP 10.15.8.100 > 224.0.0.18: VRRPv2, Advertisement, vrid 102, 
prio 93, authtype simple, intvl 1s, length 20
16:33:08.697588 IP 10.15.8.100 > 224.0.0.18: VRRPv2, Advertisement, vrid 102, 
prio 93, authtype simple, intvl 1s, length 20

此时HOST1优先级为priority + weight = 93,HOST2优先级为priority + weight = 92,HOST1仍为MASTER。

示例二:关闭HOST1上的nginx。

1
2
3
4
5
6
7
8
16:33:09.697928 IP 10.15.8.100 > 224.0.0.18: VRRPv2, Advertisement, vrid 102, 
prio 93, authtype simple, intvl 1s, length 20
16:33:10.698285 IP 10.15.8.100 > 224.0.0.18: VRRPv2, Advertisement, vrid 102, 
prio 91, authtype simple, intvl 1s, length 20
16:33:10.698482 IP 10.15.8.101 > 224.0.0.18: VRRPv2, Advertisement, vrid 102, 
prio 92, authtype simple, intvl 1s, length 20
16:33:11.699441 IP 10.15.8.101 > 224.0.0.18: VRRPv2, Advertisement, vrid 102, 
prio 92, authtype simple, intvl 1s, length 20

HOST1上的nginx关闭后,killall -0 nginx返回非0,HOST1通告的优先级为priority = 91,HOST2的优先级为priority + weight = 92,HOST2抢占成功,被选举为MASTER。相关日志可tail /var/log/messages。

由此可见,主从的优先级初始值priority和变化量weight设置非常关键,配错的话会导致无法进行主从切换。比如,当MASTER初始值定 得太高,即使script脚本执行失败,也比BACKUP的priority + weight大,就没法进行VIP漂移了。所以priority和weight值的设定应遵循: abs(MASTER priority - BAKCUP priority) < abs(weight)。 另外,当网络中不支持多播(例如某些云环境),或者出现网络分区的情况,keepalived BACKUP节点收不到MASTER的VRRP通告,就会出现脑裂(split brain)现象,此时集群中会存在多个MASTER节点。

 

转载:http://fengchj.com/?p=2156

以上是关于keepalived vip漂移基本原理及选举算法的主要内容,如果未能解决你的问题,请参考以下文章

keepalived 安装及配置VIP漂移

keepalived漂移VIP故障

负载均衡实现故障vip自动漂移

keepalived

postgresql+keepalived HA实现VIP漂移

Redis 主从 keepalived高可用 实现 VIP 自动漂移