Keepalive：http://www.keepalived.org/
《老男孩Linux运维》
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高可用服务
安装Keepalived软件
可以通过官方下载源码来编译安装，也可以使用yum来安装。
yum search keepalived
yum install -y keepalived
rpm -q keepalived
Keepalived配置文件
利用yum安装，Keepalived的配置文件默认为：/etc/keepalived/keepalived.conf
全局定义（Global Definitions）部分：
! Configuration File for keepalived
#号 和 !号 都是注释
global_defs { #全局定义
notification_email { #定义报警邮件地址，当服务切换或RS节点有故障时，发送报警邮件
[email protected] #收件人1
[email protected] #收件人2
[email protected] #收件人3
}
notification_email_from [email protected] #发件人
smtp_server 192.168.200.1 #发送邮件的smtp服务器
smtp_connect_timeout 30 #连接smtp的超时时间
#所有邮件报警相关参数均可以不配，可以交由监控软件（如Nagios、Zabbix）实现
router_id LVS_DEVEL #Keepalived服务器的路由标识。在一个局域网内，此标识应该唯一
vrrp_skip_check_adv_addr
vrrp_strict
vrrp_garp_interval 0
vrrp_gna_interval 0
}
VRRP实例定义区块（VRRP instance）部分：
这部分主要用来定义具体服务的实例配置，包括Keepalived主备状态、接口、优先级、认证方式和IP信息等。
vrrp_instance VI_1 {
#定义一个vrrp实例，名字是 VI_1
#每个vrrp实例可以认为是Keepalived服务的一个实例或作为一个业务服务，在Keepalived服务配置中，vrrp实例可以有多个
#注意，存在于主节点中的vrrp实例在备节点中也要存在，这样才能实现故障切换转移
state MASTER
#当前vrrp实例状态，MASTER|BACKUP,大写
interface eth0
#网络通信接口，注意服务器的接口名称
virtual_router_id 51
#虚拟路由ID标识，这个标识最好是一个数字，并在keepalived.conf配置中唯一
#MASTER和BACKUP配置中相同vrrp实例的virtual_router_id必须一致，否则将出现脑裂问题
priority 100
#优先级，数字越大，表示实例优先级越高
#在同一个vrrp实例里，MASTER的优先级要高于BACKUP才行
advert_int 1
#同步通知间隔，MASTER和BACKUP之间通信检查的时间间隔，单位是秒
authentication {
#权限认证配置
auth_type PASS
#认证类型，有PASS（Simple Passwd）和 AH（IPSEC），官方推荐PASS
#验证密码为明文方式，最好长度不要超过8个字符，建议使用4位的数字。同一个vrrp实例的MASTER和BACKUP使用相同的密码才能正常通信
auth_pass 1111 #通信密码
}
virtual_ipaddress {
#虚拟ip，可以配置多个虚拟ip，配置是最好指定子网掩码和虚拟IP绑定的网络接口。否则子网掩码默认是32位，绑定的接口和前面的interface参数配置一致
#虚拟IP就是工作中需要和域名绑定的IP，和配置高可用服务监听的IP要保持一致
192.168.200.16
192.168.200.17
192.168.200.18
}
}
配置Keepalived高可用
Keepalived高可用服务器节点，MASTER 和 BACKUP 。两台的配置如下：
Ip：
MASTER：192.168.1.9
BACKUP：192.168.1.7
Virtual_ip：192.168.3.88
upstream.conf：
upstream zhang {
server 192.168.0.99:5678;
}
Nginx.conf：
http {
xxx;
include /xxx/nginx/conf.d/*.conf;
server {
listen 80;
server_name localhost;
proxy_pass http://zhang;
}
访问效果：
MASTER端Keepalived.conf：
! Configuration File for keepalived
global_defs {
router_id zhang #路由器ID主备可同可不同
}
vrrp_instance VI_1 {
state MASTER
interface ens33
virtual_router_id 51
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.3.88/22 dev ens33 label ens33:1
}
}
BACKUP端Keepalived.conf：
BACKUP在MASTER没有挂的情况下是没有VIP的哦！VIP同一时刻只能出现在同一台机器上。
! Configuration File for keepalived
global_defs {
router_id zhang #路由器ID主备可同可不同
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.3.88/22 dev eth0 label eth0:1
}
}
注意：
state 不一样；
priority 不一样；
修改hosts：
192.168.3.88 www.zhang.com
实际效果：
切换MASTER：
192.168.1.9上
service keepalived stop
这里1.9主机的Keepalived挂掉后，VIP实现了自动漂移切换。因此，仅适合两台服务器提供的服务均开启的应用场景，这也是工作中常用的高可用解决方案。
关于脑裂问题：
如果MASTER 和 BACKUP都出现了VIP，那说明两者高可用裂脑了，裂脑是两台服务器争抢同一资源导致的。
如出现两节点抢夺同一IP资源问题，可考虑排查：
主备服务器间通信是否正常，是否有防火墙阻挡；
主备对应的keepalived.conf配置文件是否有错？
Keepalived高可用服务的裂脑问题
什么是裂脑
由于某些原因，导致两台高可用服务器在指定时间内，无法检测到对方的心跳消息，各自取得资源及服务的所有权，而此时的两台高可用服务器对都还活着并正常运行，这样就会导致同一个ip或服务在两端同时存在而发生冲突。
最严重的是两台主机占用同一个VIP地址，当用户写入数据时可能会分别写入到两端，这可能会导致服务器两端的数据不一致或造成数据丢失，这种情况被称为裂脑。
裂脑发生的原因
一般来说，有以下几种原因：
- 高可用服务器对之间心跳线路发生故障，导致无法正常通信；
- 高可用服务器上开启了防火墙阻挡了心跳信息传输；
- 高可用服务器网卡等信息配置不正确，导致心跳信息发送失败；
- 其他服务配置不当，如vrrp实例的virtual_router_id不一致；
解决裂脑常见方案
- 保证通信线路完整；
- 当检测到裂脑时强行关闭一个心跳节点；
- 做好多裂脑的监控报警，发生问题时及时解决；
- 如果有防火墙，要让心跳信息通过；
Keepalived双实例双主模式
前面的Keepalived栗子是单实例主备模式，但Keepalived还支持双实例多业务双向主备模式。需要创建新实例。
双实例主备环境：
192.168.1.7 instance VI_1-BACKUP, instance VI_2-MASTER;
192.168.1.9 instance VI_1-MASTER, instance VI_2-BACKUP;
instance 1-VIP：192.168.3.88-www.zhang.com；
instance 2-VIP:192.168.3.99-www.zhang.cn；
#记得添加hosts
192.168.1.9-keepalived.conf：
! Configuration File for keepalived
global_defs {
router_id zhang
}
vrrp_instance VI_1 {
state MASTER
interface ens33
virtual_router_id 51
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.3.88/22 dev ens33 label ens33:1
}
}
vrrp_instance VI_2 {
state BACKUP
interface ens33
virtual_router_id 52
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 2222
}
virtual_ipaddress {
192.168.3.99/22 dev ens 33 label ens33:2
}
}
192.168.1.7-keepalived.conf：
! Configuration File for keepalived
global_defs {
router_id zhang
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.3.88/22 dev eth0 label eth0:1
}
}
vrrp_instance VI_2 {
state MASTER
interface eth0
virtual_router_id 52
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 2222
}
virtual_ipaddress {
192.168.3.99/22 dev eth0 label eth0:2
}
}
效果：
VIP漂移：
192.168.1.9
service keepalived stop
访问图：
解决高可用服务只针对物理服务器的问题
默认情况下，Keepalived软件仅仅在另外一台机器宕机或Keepalived停掉的时候才会接管业务。
但在实际工作中，有业务服务停止而Keepalived服务还存在的情况，这就会导致用户访问的VIP无法找到对应的服务。那么，如果让ip漂移到对端节点呢？
第一个方法：可以写守护进程脚本来处理
当Nginx业务有问题时，就停掉本地的Keepalived服务，实现IP漂移到对端继续提供服务。
举个栗子：
vim check_nginx.sh
#!/bin/bash
while true
do
if [ `netstat -nltup | grep nginx | wc -l` -ne 1 ];then
/sbin/service keepalived stop
fi
sleep 2
done
第二个方法：使用Keepalived配置文件触发写好的监测脚本
监测脚本：
vim chk_nginx.sh
#!/bin/bash
while true
do
if [ `netstat -nltup | grep nginx | wc -l` -ne 1 ];then
/sbin/service keepalived stop
fi
sleep 3
done
修改keepalived.conf：
! Configuration File for keepalived
global_defs {
xxx
}
vrrp_script chk_nginx { #定义vrrp脚本
script "/etc/keepalived/chk_nginx.sh"
interval 2 #间隔2s
weight 2
}
vrrp_instancd xxx {
xxx
virtual_ipaddress {
xxx
}
track_script { #触发检查
chk_nginx
}
}
解决多组Keepalived服务器在同一个局域网的冲突问题
当在同一个局域网内部部署了多组Keepalived服务器对，而又未使用专门的心跳线通信时，可能会发生高可用接管的严重故障问题。
Keepalived高可用是通过VRRP协议来实现的，VRRP协议默认通过IP多播的形式实现高可用对之间的通信。多组Keepalived服务器对会造成IP多播地址冲突问题，导致接管错乱，不同组的Keepalived都是使用默认的 224.0.0.18 作为多播地址。
此时解决办法是，在同组的Keepalived服务器所有的配置文件里指定独一无二的多播地址。
global_defs {
router_id zhang
vrrp_mcast_group4 224.0.0.19 #指定多播地址
不同实例的通信认证密码也最好不同，以确保接管正确。
指定Keepalived日志
默认情况下，Keepalived服务的日志会输出到 /var/log/messages ，和其他日志混杂在一起，很不方便。
操作如下：
vim /etc/sysconfig/keepalived
将 KEEPALIVED_OPTIONS="-D"
修改为 KEEPALIVED_OPTIONS="-D -d -S 0"
vim /etc/rsyslog.conf
#在末尾加入
#keepalived
local0.* /var/log/keepalived.log
#然后找到 *.info;mail.none;authpriv.none;cron.none /var/log/messages
#加上local0
*.info;mail.none;authpriv.none;cron.none;local0.none /var/log/messages
#重启rsyslog服务
service rsyslog restart
开发检查Keepalived脑裂的脚本
思路：在备节点上执行脚本，如果可以ping通主节点，并且备节点有VIP就报警，让人员介入检查。