LVS+Keepalived详解

在keepalive服务正常工作时，主（master）节点会不断的向备（backup）节点发送（多播的方式）心跳消息，用意告诉备节点自己还活着，当主节点发生故障时，就无法发型萧条消息，备节点也就因此无法检测到来自主节点的心跳，于是调用自身的接管程序，接管主节点的IP资源及服务。当主节点恢复时，备节点又会释放主节点故障时自身接管的IP资源及服务，恢复到原来的备用角色。

VRRP使用了加密协议加密数据，但Keepalived官方目前还是推荐用明文的方式配置认证类型和密码。

vrrp会把多台路由器组成一个虚拟路由组vrid，vrrp会生成一个虚拟路由（包含虚拟IP和虚拟MAC，局域网内用户不关心哪一个是主哪一个是备，它们只用虚拟路由器的虚拟IP作为它们的网关）实际上虚拟IP就是承载master路由器上，也就是说实际的数据是通过master转发的。

backup是通过优先级来决定哪个是master路由，优先级最大的那台就是master，backup只是用来监听master定时发来的vrrp报文，如果超时未收到master发来的vrrp报文backup就会抢占master，虚拟IP也会漂移到backup头上。

六、故障转移机制

Keepalived高可用服务之间的故障切换转移，是通过VRRP 来实现的。

在 Keepalived服务正常工作时，主 Master节点会不断地向备节点发送（多播的方式）心跳消息，用以告诉备Backup节点自己还活着，当主 Master节点发生故障时，就无法发送心跳消息，备节点也就因此无法继续检测到来自主 Master节点的心跳了，于是调用自身的接管程序，接管主Master节点的 IP资源及服务。

而当主 Master节点恢复时，备Backup节点又会释放主节点故障时自身接管的IP资源及服务，恢复到原来的备用角色。

七、Keepalived脑裂及解决方法

1. keepalived脑裂

在高可用（HA）系统中，当联系2个节点的“心跳线”断开时，本来为一整体、动作协调的HA系统，就分裂成为2个独立的个体。由于相互失去了联系，都以为是对方出了故障。两个节点上的HA软件像“裂脑人”一样，争抢“共享资源”、争起“应用服务”，就会发生严重后果——或者共享资源被瓜分、2边“服务”都起不来了；或者2边“服务”都起来了，但同时读写“共享存储”，导致数据损坏（常见如数据库轮询着的联机日志出错）。

2. 脑裂的原因

高可用服务器对之间心跳线链路发生故障，导致无法正常通信。如心跳线坏了（包括断了，老化）。

因网卡及相关驱动坏了，ip配置及冲突问题（网卡直连）。

因心跳线间连接的设备故障（网卡及交换机）。

因仲裁的机器出问题（采用仲裁的方案）。

高可用服务器上开启了 iptables防火墙阻挡了心跳消息传输。

Keepalived配置里同一 VRRP实例如果 virtual_router_id两端参数配置不一致也会导致裂脑问题发生。

vrrp实例名字不一致、优先级一致。

3. 解决对策

添加冗余的心跳线，例如：双线条线（心跳线也HA），尽量减少“裂脑”发生几率

启用磁盘锁。正在服务一方锁住共享磁盘，“裂脑”发生时，让对方完全“抢不走”共享磁盘资源。但使用锁磁盘也会有一个不小的问题，如果占用共享盘的一方不主动“解锁”，另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃，就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了“智能”锁。即：正在服务的一方只在发现心跳线全部断开（察觉不到对端）时才启用磁盘锁。平时就不上锁了。

设置仲裁机制。例如设置参考IP（如网关IP），当心跳线完全断开时，2个节点都各自ping一下参考IP，不通则表明断点就出在本端。不仅“心跳”、还兼对外“服务”的本端网络链路断了，即使启动（或继续）应用服务也没有用了，那就主动放弃竞争，让能够ping通参考IP的一端去起服务。更保险一些，ping不通参考IP的一方干脆就自我重启，以彻底释放有可能还占用着的那些共享资源。