Keepalived高可用切换过程

由于keepalived存在的时间很长，所以网络上对于其部署和应用的案例很多，这里我不再赘述其安装步骤，这里主要介绍其一些模式和使用场景，以及通过抓包的方式展现其高可用切换的流程。

2.1 非抢占模式

2.1.1 配置方式

• 1）将所有主机的优先级priority配置相同；
• 2）将所有主机的主备模式配置为BACKUP。

2.1.2 适用场景

• 1）适合master和backup的服务器配置相同，backup具有master相同的承载能力，能长时间稳定承载业务的场景。
• 2）适合master与backup网络波动较大的场景，减少vip在master和backup上频繁飘逸。

2.2 抢占模式

2.2.1 配置方式

• 1）将master主机的优先级大于其他的BACKUP。
• 2）将master主机的主备模式配置为BACKUP，将其他主机主备模式配置为BACKUP。

2.2.2 适用场景

• 1）适合master与backup服务器配置不同，backup性能低于master，无法长时间承载业务。backup仅作为master临时备份的场景。
• 2）适合master与backup网络波动较小的场景，当master恢复后能及时切换回去。

2.3 灵活模式

2.3.1 配置方式

• 1）将master主机的优先级大于其他的BACKUP。
• 2）在检测脚本中配置weight值，可以影响每个节点的优先级。

2.3.2 适用场景

2.4 组播模式

2.4.1 组播的优势

2.4.2 适用场景

• 1）适用于支持组播的网络的场景。
• 2）适用于后期需要向keepalived组内添加其他节点的场景。可以不用修改重启其他的keepalived，可以作为无感添加。

2.5 单播模式

2.5.1 单播的优势

• 1）虚拟路由ID只是在组播的模式下有意义，因为在组播模式下，BACKUP用来区分收到的组播VRRP报文是不是给自己的，所以在组播的模式下virtual_router_id在不同虚拟路由组不能重复。但是在单播中，采用的是点对点模式，所以在一个局域网内virtual_router_id重复也是可以的。
• 2）对环境的要求更低。可能某些环境下不支持组播。

2.5.2 适用场景

• 1）适用于不支持组播的网络环境，例如有些公有云不支持组播。

• 2）适用于keepalived组内成员后期变动小场景。

global_defs {
router_id k8s-11 #表示这台主机的ID，默认情况下为主机名
vrrp_skip_check_adv_addr #此配置为如果收到的报文和上一个报文是同一个路由器则跳过检查报文中的源地址。主要为了提高性能
vrrp_iptables #避免生成iptables input链 规则
vrrp_strict #严格遵守VRRP协议,不允许状况:1,没有VIP地址,2.配置了单播,3.在VRRP版本2中有IPv6地址
vrrp_garp_interval 0 #ARP报文发送延迟
vrrp_gna_interval 0 #消息发送延迟
vrrp_mcast_group 224.0.0.18    #指定组播IP地址，默认为224.0.0.18
}

vrrp_script check_nginx { #脚本配置
pass
}

vrrp_instance VI_1 {
state BACKUP #当前节点在此虚拟路由器上的状态，状态为MASTER或者BACKUP，一般都配置为backup，最终需要权重来进行比较
interface ens33 #绑定为当前虚拟路由器使用的物理接口，如eth0
virtual_router_id 11 #每个虚拟路由器唯一标识，范围0-255。同一组虚拟路由器的vrid需要保持一致。
priority 100 #当前物理节点在此虚拟路由器的优先级，范围1-254
advert_int 1 #vrrp通告的时间间隔（心跳），默认1s
authentication { #认证机制
auth_type PASS
auth_pass 88888888
}

virtual_ipaddress { #配置虚拟IP
192.168.200.16 #指定VIP，不指定网卡，默认为eth0。默认为/32
192.168.200.17/24 dev ens33
#指定VIP的网卡
192.168.200.18/24 dev ens33 label ens33:1
#指定VIP的网卡label
}

track_script { #执行脚本
check_nginx
}
}

组播模式下服务器抓包情况：

global_defs {
router_id k8s-21
vrrp_skip_check_adv_addr
vrrp_iptables
# vrrp_strict #此选项必须关闭
vrrp_garp_interval 0
vrrp_gna_interval 0
}

vrrp_script check_nginx {
pass
}

vrrp_instance VI_2 {
state MASTER
interface ens33
virtual_router_id 21
priority 100
advert_int 2

authentication {
auth_type PASS
auth_pass 88888888
}

unicast_src_ip 192.168.100.21 #本机IP地址
unicast_peer {
192.168.100.22 #同一keepalived组内其他节点IP地址
192.168.100.23 #同一keepalived组内其他节点IP地址
}

virtual_ipaddress {
192.168.100.200/24 dev ens33 #虚拟VIP地址
}

track_script {
check_nginx
}
}

单播模式下服务器抓包情况：

5.1 组播模式下master优先级降低选举过程

5.2 组播模式下当BACKUP超时未收到master的报文

通过以上抓包分析可见，keepalived的选举机制是很简单的，就是简单利用心跳报文+节点优先级进行选举master，这种方式不可避免的会产生分区脑裂的故障。如果要避免分区脑裂的问题，目前成熟的解决方案是采用分布式选举算法，例如zookeeper使用的ZAB算法，kafka使用的Raft算法。

6.3 通过抓包我们也可以很容易解释为什么网上说keepalived配置文件中的Virtual_ID必须要配置一样，因为在同一个组播地址中同一组keepalived的其他节点只会识别Virtual_ID与自己相同的VRRP报文。当然，在同一个局域网中如果有多组keepalived都采用组播模式，那么必须满足不同组keepalived的Virtual_ID必须不同，或者不同组keepalived的组播地址配置不同。不然会发生干扰，VIP可能会出现”跨组飘移”。