Keepalived — VRRP 的 Linux 软件实现

目录

Keepalived

官方网站：https://www.keepalived.org/
官方手册：https://www.keepalived.org/doc/
官方仓库：https://github.com/acassen/keepalived

Keepalived 起初是为 LVS 设计的，专门用来监控集群系统中各个服务节点的状态，它根据 TCP/IP L3-L5 层交换机制检测每个服务节点的状态，每个服务节点异常或者工作障碍，Keepalived 将立刻检测到，并把障碍节点剔除，是毫秒级的，当后台节点恢复正常以后，Keepalived有自动将服务节点重新添加在服务器集群中。

Keepalived 后来又加入了 VRRP 功能，目的就是解决静态路由单点故障的问题，通过 VRRP 可以实现网络不间断稳定运行。

简而言之，Keepalived 是一个使用 C 编写的，基于 VRRP 协议的高可用解决方案。通过 VIP 地址和心跳检测支持高可用功能，避免发生单点故障。该项目的主要目标是为 Linux 系统和基于 Linux 的基础结构提供负载均衡和高可用性的简单而强大的功能。

Keepalived 的架构

上图可见，Keepalived 的架构分为两大层：内核空间（Kernel Space）、用户空间（User Space）。其中，IPVS（IP Virtual Server）实现了 L4 传输层负载平衡；NETLINK 则用于在内核和用户空间进程之间传输信息。

Keepalived 分为 3 个守护进程：

1. 父进程：很简单，负责 fork 子进程，并监视子进程健康状态，图中 WatchDog 周期性发送检测包，在需要时重启子进程。
2. 子进程 A：负责 VRRP 框架，图中 VRRP Stack。
3. 子进程 B：负责健康检查，图中 Checkers。

Keepalived 的运行原理

Keepalived 通过选举（根据服务器设置的权重）挑选出一台热备服务器做 Master 机器，Master 会被分配到一个指定的 VIP，外部程序可通过该 VIP 访问这台服务器，如果这台服务器出现故障（断网，重启，或者本机器上的 Keepalived Crash 等），Keepalived 会从其他的备份机器上重选（还是看服务器设置的权重）一台机器做 Master 并分配同样的 VIP，充当前一台 Master 的角色。权重越高，备用机器被拉起来的占比就越大，一般的主备就可以满足我们的需求。

Keepalived 的选举策略

选举策略是根据 VRRP 协议，完全按照权重大小，权重最大的是 Master 机器，下面几种情况会触发选举：

• Keepalived 启动的时候。
• Master 服务器出现故障（断网，重启，或者本机器上的 keepalived crash 等）。
• 有新的备份服务器加入且权重最大。

Keepalived 的脑裂

在高可用系统中，作为主备节点的两台服务器，可能因为一些比如说网络断开，两台机器的心跳检测会认为主挂了，但是主其实是正常的，只是网络断开了，心跳检测没法检查到主还活着，由于主从之间失去了联系，都以为是对方发生了故障，所以两个节点都会主动的抢占资源，争抢应用服务，争抢 VIP，这样就发发生一些严重的后果，或者资源被瓜分了、或者是两边的节点都启动不起来了、或者是都起来了，但是同时读写共享存储，导致数据损坏。

脑裂产生的原因：

• 高可用服务器对之间心跳线链路发生故障，导致无法正常通信。
• 因心跳线断开（包括网线断裂、水晶头松动等物理原因）。
• 网卡及相关驱动坏了，IP 配置及冲突问题（网卡直连）。
• 因心跳线间连接的设备故障（网卡及交换机）。
• 因仲裁的机器出问题（采用仲裁的方案）。
  • 高可用服务器上开启了 iptables 防火墙阻挡了心跳消息传输。
  • 高可用服务器上心跳网卡地址等信息配置不正确，导致发送心跳失败。
  • 其他服务配置不当等原因，如心跳方式不同，心跳广插冲突、软件 Bug 等。

脑裂常见的解决方案：

• 同时使用串行电缆和以太网电缆连接，同时用两条心跳线路，这样一条线路坏了，另一个还是好的，依然能传送心跳消息。
• 当检测到裂脑时强行关闭一个心跳节点（这个功能需特殊设备支持，e.g. Stonith、Feyce）。相当于备节点接收不到心跳消患，通过单独的线路发送关机命令关闭主节点的电源。
• 做好对裂脑的监控报警（如邮件及手机短信等或值班），在问题发生时人为第一时间介入仲裁，降低损失。例如，百度的监控报警短倍就有上行和下行的区别。报警消息发送到管理员手机上，管理员可以通过手机回复对应数字或简单的字符串操作返回给服务器.让服务器根据指令自动处理相应故障，这样解决故障的时间更短。

当然，在实施高可用方案时，要根据业务实际需求确定是否能容忍这样的损失。对于一般的网站常规业务。这个损失是可容忍的。

配置文档

https://www.keepalived.org/doc/configuration_synopsis.html