1. 概述

Keepalived是通过vrrp 协议的实现高可用性，对网络比较了解的IT人，对这个技术应该非常熟悉了，早期核心交换机用来实现双机双线的标准协议，现在随着技术发展出现了更好的核心设备的双活技术，vrrp/hrrp慢慢被取代了，但目前在Linux主机类应用场景使用还比较广泛。它的原生设计目的为了解决 ipvs高可用性。它与HeartBeat实现类似的功能，都可以实现服务或者网络的高可用，但是又有差别，HeartBeat是一个专业的、功能完善的高可用软件，它提供HA软件所需的基本功能，比如：心跳检测、资源接管，检测集群中的服务，在集群节点转移共享IP地址的所有者等等。HeartBeat功能强大，但是部署和使用相对比较麻烦，与HeartBeat相比，Keepalived主要是通过虚拟路由冗余来实现高可用功能，虽然它没有HeartBeat功能强大，但是Keepalived部署和使用非常的简单，所有配置只需要一个配置文件即可以完成。

官网：http://keepalived.org/

功能：

  • 基于vrrp协议完成地址漂移；
  • 为vip地址所在的节点生成ipvs规则 (在配置文件中预先定义)；
  • 为ipvs集群的各RS做健康状态检测；（ keepalived 可以搭配 LVS、haproxy等成为黄金组合，尤其是 keepalived + haproxy 在很多企业生产中使用）
  • 基于脚本调用接口完成脚本中定义的功能，进而影响集群事务，以此支持nginx、haproxy等服务。


2. 工作原理及技术架构

2.1 Keepalived体系结构

Keepalived 起初是为LVS设计的，由于Keeplalived可以实现对集群节点的状态检测，而IPVS可以实现负载均衡功能，因此,Keepalived借助于第三方模块IPVS就可以很方便地搭建一套负载均衡系统。在Keepalived当中IPVS模块是可配置的，如果需要负载均衡功能，可以在编译Keepalived时开打负载均衡功能，也可以通过编译参数关闭。

keepalived工作原理简述_负载均衡

官方文档：

https://keepalived.org/doc/
http://keepalived.org/documentation.html
  • 用户空间核心组件：

vrrp stack：VIP消息通告；

checkers：监测real server；

system call：实现 vrrp 协议状态转换时调用脚本的功能；

SMTP：邮件组件；

IPVS wrapper：生成IPVS规则；

Netlink Reflector：网络接口；

WatchDog：监控进程；

  • 控制组件：提供keepalived.conf 的解析器，完成Keepalived配置。
  • IO复用器：针对网络目的而优化的自己的线程抽象。
  • 内存管理组件：为某些通用的内存管理功能（例如分配，重新分配，发布等）提供访问权限。


2.2 VRRP协议

VRRP协议是keepalived工作的核心，其用于早期解决网络设备单点问题的，理解了其工作原理就非常容易理解 Keepalived 的工作原理了。

  1. 在网络中，跨网段的主机之间的通信需要通过网关来完成的，而担当网关的设备（如：路由器或者防火墙等）一旦发生故障，就会造成服务中断，为了解决网关设备的单点故障问题，引入了VRRP协议。
  2. VRRP协议是一种容错的主备模式的协议，当主路由等网关设备出现故障时，由另一台设备来接替其工作，通过VRRP可以在网络发生故障时完成自动切换，而不影响用户主机间的通信。
  3. VRRP是通过竞选机制来将路由任务交给某台VRRP路由器的。其竞争的规则由用户定义。
  4. 正常工作时主节点发健康检测数据包，备节点接受数据包，当备节点接收不到主节点发的数据包的时，就启动接管程序接管主节点的工作，如果有多个备节点，按照用户定义的优先级选出新主节点。
  5. VRRP路由器在运行过程中有三种状态：Initialize状态、 Master状态、Backup状态，一般主路由器处于Master状态，备份路由器处于Backup状态。


2.3 三种状态监测方式

  • 基于四层的传输端口做状态监测，此为默认方式
  • 基于指定 URI 做状态监测,需要访问整个页面资源,占用更多带宽
  • 基于指定 URI 的request请求头部内容做状态监测，占用较少带宽,建议使用此方式


2.4 keepalived工作原理

整个Keepalived高可用集群的故障切换转移，是通过VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议）来实现的，正常工作时VIP是漂移在主节点上，它承担接收和返回用户的任务请求，其他备用节点都处于待机状态，或者承担其他业务的主工作状态；主Master节点会不断地向备节点发送（多播的方式）心跳消息，用以告诉备Backup节点自己还活着，当主Master节点发生故障时，就无法发送心跳消息，备节点也就因此无法继续检测到来自主Master节点的心跳了，于是调用自身的接管程序，接管主Master节点的VIP资源及服务。如果设置成抢占模式的情况下，主Master节点恢复后，备Backup节点又会释放主节点故障时自身接管的VIP资源及服务，恢复到原来的备用角色。如果是非抢占模式，备用节点接管主节点的VIP和服务后，在其没发生故障情况下不会让出其主节点角色，原主节点修复后会充当从节点角色运行。