Keepalived工作原理及简单理解

Keepalived 的前世今生

Keepalived 起初是为 LVS 设计的, 专门用来监控集群系统中各个服务节点的状态, 它根据 TCP/IP 参考模型的第三, 第四层, 第五层交换机制检测每个服务节点的状态, 如果某个服务器节点出现异常, 或者工作出现故障, Keepalived 将检测到, 并将出现的故障的服务器节点从集群系统中剔除, 这些工作全部是自动完成的, 不需要人工干涉, 需要人工完成的只是修复出现故障的服务节点.

后来 Keepalived 又加入了 VRRP 的功能, VRRP(Vritrual Router Redundancy Protocol, 虚拟路由冗余协议) 出现的目的是解决静态路由出现的单点故障问题, 通过 VRRP 可以实现网络不间断稳定运行, 因此 Keepalvied 一方面具有服务器状态检测和故障隔离功能, 另外一方面也有 HA cluster 功能.

健康检查和失败切换是 Keepalived 的两大核心功能. 所谓的健康检查, 就是采用 tcp 三次握手, icmp 请求, http 请求, udp echo 请求等方式对负载均衡器后面的实际的服务器 (通常是承载真实业务的服务器) 进行保活; 而失败切换主要是应用于配置了主备模式的负载均衡器, 利用 VRRP 维持主备负载均衡器的心跳, 当主负载均衡器出现问题时, 由备负载均衡器承载对应的业务, 从而在最大限度上减少流量损失, 并提供服务的稳定性.

简单理解 Keepalived

Keepalived 服务简单来说, 就是用来防止单点故障的.

所谓的单点故障就是, 主服务器挂了之后从服务器充当主服务器, 原来的主服务器恢复后, 当从服务器来使用, 保证服务的高可用性.

也可以这样理解, 老大挂了之后手下的小弟过来接班, 老大复活后, 当小弟使用.

官方理解

官方一点来说就是进行故障的切换转移, 是通过 VRRP 虚拟路由器冗余协议来实现的, VRRP 是通过一种竞选机制来将路由的任务交给某台 VRRP 路由器.

通常情况下, Keepalived 和 LVS 负载均衡软件一起出现, 用来管理和监控整个集群的节点状态.

Keepalived 软件起初是专为 LVS 负载均衡软件设计的, 用来管理并监控 LVS 集群系统中各个服务节点的状态, 后来又加入了可以实现高可用的 VRRP 功能. 因此, Keepalived 除了能够管理 LVS 软件外, 还可以作为其他服务 (例如:Nginx, Haproxy, MySQL 等) 的高可用解决方案软件.

Keepalived 软件主要是通过 VRRP 协议实现高可用功能的.VRRP 是 Virtual Router Redundancy Protocol(虚拟路由器冗余协议) 的缩写, VRRP 出现的目的就是为了解决静态路由单点故障问题的, 它能够保证当个别节点宕机时, 整个网络可以不间断地运行. 所以, Keepalived 一方面具有配置管理 LVS 的功能, 同时还具有对 LVS 下面节点进行健康检查的功能, 另一方面也可实现系统网络服务的高可用功能.

Keepalived 服务的重要功能

实现对 LVS 集群节点健康检查功能 (healthcheck)

Keepalived 可以通过在自身的 keepalived.conf 文件里配置 LVS 的节点 IP 和相关参数实现对 LVS 的直接管理; 除此之外, 当 LVS 集群中的某一个甚至是几个节点服务器同时发生故障无法提供服务时, Keepalived 服务会自动将失效的节点服务器从 LVS 的正常转发队列中清除出去, 并将请求调度到别的正常节点服务器上, 从而保证最终用户的访问不受影响; 当故障的节点服务器被修复以后, Keepalived 服务又会自动地把它们加入到正常转发队列中, 对客户提供服务.

作为系统网络服务的高可用功能

Keepalived 高可用功能实现的简单原理为, 两台主机同时安装好 Keepalived 软件并启动服务, 开始正常工作时, 由角色为 Master 的主机获得所有资源并对用户提供服务, 角色为 Backup 的主机作为 Master 主机的热备; 当角色为 Master 的主机失效或出现故障时, 角色为 Backup 的主机将自动接管 Master 主机的所有工作, 包括接管 VIP 资源及相应资源服务; 而当角色为 Master 的主机故障修复后, 又会自动接管回它原来处理的工作, 角色为 Backup 的主机则同时释放 Master 主机失效时它接管的工作, 此时, 两台主机将恢复到最初启动时各自的原始角色及工作状态.

Keepalived 高可用故障切换转移原理

Keepalived 高可用服务对之间的故障切换转移, 是通过 VRRP(Virtual Router Redundancy Protocol, 虚拟路由器冗余协议) 来实现的.

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

Keepalived 的通信原理

在网络中, 主机之间的通信都是通过配置静态路由或者 (默认网关) 来完成的, 而主机之间的路由器一旦发生故障, 服务就会中断, 因此这种通信模式当中, 路由器就成了一个单点瓶颈, 为了解决这个问题, 就引入了 VRRP 协议.

VRRP 协议是一种容错的主备模式的协议, 保证当主机的下一跳路由出现故障时, 由另一台路由器来代替出现故障的路由器进行工作, 通过 VRRP 可以在网络发生故障时透明的进行设备切换而不影响主机之间的数据通信.

VRRP 是通过一种竞选协议机制来将路由任务交给某台 VRRP 路由器的.

工作时主节点发包, 备节点接包, 当备节点接收不到主节点发的数据包的时候, 就启动接管程序接管主节点的资源. 备节点可以有多个, 通过优先级竞选, 但一般 Keepalived 系统运维工作中都是一对.

VRRP 路由器在运行过程中有三种状态:

initialize 状态: 系统启动后就进入 initialize, 此状态下路由器不对 VRRP 报文做任何处理;
master 状态;
backup 状态;

一般主路由器处于 master 状态, 备份路由器处于 backup 状态.

VRRP 选举机制

VRRP 组中 IP 拥有者. 如果虚拟 IP 地址与 VRRP 组中的某台 VRRP 路由器 IP 地址相同, 则此路由器为 IP 地址拥有者, 这台路由器将被定位主路由器.
比较优先级. 如果没有 IP 地址拥有者, 则比较路由器的优先级, 优先级的范围是 0~255, 优先级大的作为主路由器
比较 IP 地址. 在没有 Ip 地址拥有者和优先级相同的情况下, IP 地址大的作为主路由器.

VRRP 通过一竞选 (election) 协议来动态的将路由任务交给 LAN 中虚拟路由器中的某台 VRRP 路由器.

Keepalived 服务的工作原理

Keepalived 高可用对之间是通过 VRRP 进行通信的, VRRP 是通过竞选机制来确定主备的, 主的优先级高于备, 因此, 工作时主会优先获得所有的资源, 备节点处于等待状态, 当主挂了的时候, 备节点就会接管主节点的资源, 然后顶替主节点对外提供服务.

在 Keepalived 服务对之间, 只有作为主的服务器会一直发送 VRRP 广播包, 告诉备它还活着, 此时备不会抢占主, 当主不可用时, 即备监听不到主发送的广播包时, 就会启动相关服务接管资源, 保证业务的连续性. 接管速度最快可以小于 1 秒.

高可用的设计思路

冗余+故障自动发现转移

保证高可用性

一个 WEB 服务至少会有 2 台服务器运行 Keepalived, 一台为主服务器 (MASTER), 一台为备份服务器 (BACKUP), 但是对外表现为一个虚拟 IP, 主服务器会发送特定的消息给备份服务器, 当备份服务器收不到这个消息的时候, 即主服务器宕机的时候, 备份服务器就会接管虚拟 IP, 继续提供服务, 从而保证了高可用性.

zookeeper 和 keepalived 高可用区别

常见的高可用解决方案

zookeeper
keepalived
DNS

keepalived 和 zookeeper 对比

Keepalived

优点: 简单, 在实际接入 Keepalived 服务的时候, 基本上不需要我们在业务层面做任何操作, 就可以实现高可用, 主备容灾. 而且容灾的宕机时间也比较短.

缺点: 也是简单, 因为 VRRP, 主备切换都没有什么复杂的逻辑, 所以无法应对某些特殊场景, 比如主备通信链路出问题, 会导致脑裂. 同时, Keepalived 也不容易做负载均衡.

zookeeper

优点: 可以支持高可用, 负载均衡.zookeeper 服务本身就是个分布式的服务.

缺点:zookeeper 跟业务结合的比较紧密. 需要在业务代码中写好 ZK 使用的逻辑, 比如注册名字. 拉取名字对应的服务地址等.

DNS 优点

优点: 不复杂, 同时与业务结合的不是很紧密, 通过简单的逻辑就可以实现负载均衡.

缺点:DNS 容灾是更新 DNS 服务器需要时间, 宕机时间比较长.

小结

所以, 区别很明显. 从简单性来说:Keepalived 最简单, DNS 次之, ZK 最复杂.

从负载均衡能力来看, zookeeper 最强, DNS 次之, Keepalived 最弱.

从与业务的紧密程度来看:ZK 最紧密, DNS 次之, Keepalived 基本跟业务层面没有关系.

keepalive 只可以选出一台机器作为主机, 所以 keepalive 只能实现 M:1 的备份

zookeeper 可以选出 N 台机器作为主机, 它可以实现 M:N 的备份

所以使用场景, 个人看法, 对于框架级别的业务可能会选择 ZK, 仅仅需要做容灾的用 Keepalived.DNS 的方法介乎两者中间.

具体明细对比

以主动和被动的角度考虑

Keepalived 是主动向 nginx 发送请求, 如果有响应, 那么则 nginx 可用.

对于 zookeeper 而言, HDFS, HBase, Yarn 基于 zookeeper 做高可用, 这里的 zookeeper 就是被动的, 也就是说 HDFS, HBase, Yarn 主动向 zookeeper 中写数据.

从负载的角度来考虑

可以使用 Keepalived 服务做到主从, 主从的划分是通过配置文件 (主从的 priority 之差>50) 指定的, 如果主服务在正常工作, 那么大量的请求通过主然后负载到后端的 nginx.

而利用 zookeeper 做 HA, zookeeper 中可以说是 人人平等, 客户端无论访问 follower, 还是 observer, 亦或是 leader, 都能给我们返回相应的结果, 可以很好的实现了负载均衡, 这也可以说是 zookeeper 的一个优点

从存储数据的角度

Keepalived 服务本身不可以存储数据, 假设 Keepalived 的主现在有 50 个连接, 如果没有外部数据库存储这些连接的信息, 主服务器一旦挂了的话, 这些连接信息也就丢失了, 所以如果使用 Keepalived 需要一个外部的数据库, 但是如果主挂了的同时数据库也挂了, 那么信息就会丢失, 或者从起来后, 连不上数据库, 那么之前的连接信息也会丢失.

zookeeper 可以存储数据, zookeeper 中可以创建一个 zNode, 里面存放数据, zookeeper 可以做到一个分布式数据的一致性, zookeeper 中每个节点的视图是一致的, 数据本身可以做到最终一致性, 也就是说其中一个 server 挂了, 其他的 server 还有存的数据, 那么这样的话就不需要额外的数据库, zookeeper 本身就可以存储一定量的信息. 这也可以说是 zookeeper 的另一个优点.