Keepalived会不会挂掉?keepliaved为什么能保证代理服务器的高可用?

源自Keepalived高可用：https://www.jianshu.com/p/3e55e7449898 …Zhang21

Keepalived

Keepalived介绍

Keepalived软件最初是专为LVS设计的，用来管理并监控LVS集群系统中的各个服务节点状态，后来又加入了实现高可用的 VRRP功能。因此，Keepalived除了能管理LVS外，还可以作为Nginx、Haproxy等的高可用解决软件。

Keepalived主要是通过VRRP协议实现高可用功能。
VRRP（Virtual Router Redundancy Protocol），虚拟路由冗余协议。
VRRP目的是为了解决静态路由单点故障问题，它能保证当个别节点宕机时，整个网络可以不间断地运行。

所以，Keepalived一方面具有配置管理LVS的功能，同时还具有对LVS下面节点进行健康检查的功能，另一方面也可实现系统网络服务的高可用功能。

Keepalived的三个重要功能

管理LVS负载均衡软件

可以说，Keepalived起初是专为解决LVS的问题而诞生的。因此，Keepalived和LVS的关系如夫妻一样，可紧密结合。

实现对LVS集群节点健康检查

当LVS集群中某个节点服务器发生故障时，Keepalived服务会自动将失效的节点从正常队列中剔除，并将请求调度到别的正常的节点服务器上，从而保证用户访问不受影响。当故障节点被修复后，Keepalived服务又会自动把它切换回来。

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

Keepalived可以实现任意两台主机之间，如Master和Backup间的故障转移和自动切换。这个主机是不能停机的业务服务器，如LVS负载均衡、Nginx反向代理服务器等。

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

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

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

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

VRRP（Virtual Router Redundancy Protocol）虚拟路由协议，为了解决静态路由的单点故障问题，VRRP通过一种竞选机制来将路由的任务交给某台VRRP路由器。
VRRP早期是用来解决交换机、路由器等设备单点故障。交互、路由的Master和Backup的切换原理同样适用于Keepalived的工作原理。
在一组VRRP路由器集群中，有多台物理VRRP路由器，但并不是同时工作，而是由一台Master的机器负责路由工作，其他机器都是Backup。Master并不是一成不变，VRRP会让每个VRRP路由参与竞选，最终获胜的就是Master。获胜的Master有一些特权，比如拥有虚拟路由器的IP地址等。
拥有系统资源的Master负责转发发送给网关地址的包和响应ARP请求。

VRRP通过竞选机制来实现虚拟路由器的功能，所有的协议报文都是通过IP多播（Multicast）包形式来发送，默认多播地址224.0.0.18。在一组虚拟路由器中，不管谁是 Master，对外都是相同的MAC和IP，称之为VIP。客户端主机并不需要因Master的改变而修改自己的路由配置。对他们来说，这种切换时透明的。

在一组虚拟路由器中，只有作为Master的VRRP路由器会一直发送VRRP广播包，此时Backup不会抢占Master。当Master不可用时，Backup就收不到来自Master的广播包了，此时多台Backup中优先级最高的路由器会抢占为Master。
这种抢占非常快速，以保证服务的连续性。处于安全性考虑，VRRP数据报使用了加密协议进行加密。

Keepalived挂掉后，VIP实现了自动漂移切换。因此，仅适合两台服务器提供的服务均开启的应用场景，这也是工作中常用的高可用解决方案。

Keepalived高可用服务的裂脑问题

什么是裂脑

由于某些原因，导致两台高可用服务器在指定时间内，无法检测到对方的心跳消息，各自取得资源及服务的所有权，而此时的两台高可用服务器对都还活着并正常运行，这样就会导致同一个ip或服务在两端同时存在而发生冲突。
最严重的是两台主机占用同一个VIP地址，当用户写入数据时可能会分别写入到两端，这可能会导致服务器两端的数据不一致或造成数据丢失，这种情况被称为裂脑。

裂脑发生的原因

一般来说，有以下几种原因：

• 高可用服务器对之间心跳线路发生故障，导致无法正常通信；
• 高可用服务器上开启了防火墙阻挡了心跳信息传输；
• 高可用服务器网卡等信息配置不正确，导致心跳信息发送失败；
• 其他服务配置不当，如vrrp实例的virtual_router_id不一致；

解决裂脑常见方案

• 保证通信线路完整；
• 当检测到裂脑时强行关闭一个心跳节点；
• 做好多裂脑的监控报警，发生问题时及时解决；
• 如果有防火墙，要让心跳信息通过；

解决多组Keepalived服务器在同一个局域网的冲突问题

当在同一个局域网内部部署了多组Keepalived服务器对，而又未使用专门的心跳线通信时，可能会发生高可用接管的严重故障问题。
Keepalived高可用是通过VRRP协议来实现的，VRRP协议默认通过IP多播的形式实现高可用对之间的通信。多组Keepalived服务器对会造成IP多播地址冲突问题，导致接管错乱，不同组的Keepalived都是使用默认的 224.0.0.18 作为多播地址。
此时解决办法是，在同组的Keepalived服务器所有的配置文件里指定独一无二的多播地址。
不同实例的通信认证密码也最好不同，以确保接管正确。

指定Keepalived日志

默认情况下，Keepalived服务的日志会输出到 /var/log/messages ，和其他日志混杂在一起，很不方便。

开发检查Keepalived脑裂的脚本

思路：在备节点上执行脚本，如果可以ping通主节点，并且备节点有VIP就报警，让人员介入检查。