Keepalived工作原理及简单理解

一、keepalived的前世今生

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

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

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

二、简单理解keepalived

1、keepalived服务简单来说，就是用来防止单点故障的。

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

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

三、官方理解

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

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

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

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

四、Keepalived服务的重要功能

1、实现对LVS集群节点健康检查功能（healthcheck）

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

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

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

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

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

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

五、keepalived的通信原理

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

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

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

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

5、VRRP路由器在运行过程中有三种状态：

a、Initialize状态：系统启动后就进入Initialize，此状态下路由器不对VRRP报文做任何处理；

b、 Master状态；

c、 Backup状态；

一般主路由器处于Master状态，备份路由器处于Backup状态。

6、VRRP选举机制

a、VRRP组中IP拥有者。如果虚拟IP地址与VRRP组中的某台VRRP路由器IP地址相同，则此路由器为IP地址拥有者，这台路由器将被定位主路由器。

b、比较优先级。如果没有IP地址拥有者，则比较路由器的优先级，优先级的范围是0~255，优先级大的作为主路由器

c、比较IP地址。在没有Ip地址拥有者和优先级相同的情况下，IP地址大的作为主路由器。

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

六、keepalived服务的工作原理

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

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

七、高可用的设计思路

冗余+故障自动发现转移

八、保证高可用性

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

九、zookeeper和keepalived高可用区别

一、常见的高可用解决方案

1、zookeeper

2、keepalived

3、DNS

二、keepalived和zookeeper对比

1、Keepalived

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

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

2、zookeeper

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

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

3、DNS优点

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

缺点：DNS容灾是更新DNS服务器需要时间，宕机时间比较长。

所以，区别很明显。从简单性来说：Keepalived最简单，DNS次之，ZK最复杂。

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

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

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

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

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

三、具体明细对比

1、以主动和被动的角度考虑

keepalived是主动向nginx发送请求，如果有响应，那么则nginx可用。

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

2、从负载的角度来考虑

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

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

3、从存储数据的角度

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

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

4、从业务的角度

keepalived相对来说比较简单，我们只需要关注配置文件，进行简单的配置就可以使用keepalived服务。使用keepalived的业务场景：如果我们只需要简单的知道当前的业务中哪个是主，哪个是从，那么可以选用keepalived。

如果除了高可用以外，比如kafka，storm等复杂操作，还要想zookeeper中写一些数据，这时候就需要zookeeper。