引言
Keepalived 是一个基于VRRP协议来实现的LVS服务高可用方案，可以解决静态路由出现的单点故障问题。
一、Keepalive概述
-
keepalive软件起初是专为 LVS 负载均衡软件设计的，用来管理并监控 LVS集群中各个服务节点的状态，后来又加入了可以实现高可用的 VRRP 功能。因此，keepalive除了能够管理 LVS集群外，还可以为其他服务（例如：Nginx、Haproxy、MySQL等）实现高可用。
-
keepalive 软件主要是通过 VRRP 协议实现高可用功能的。VRRP 是 Virtual Router Redundancy Protocol（虚拟路由器冗余协议）的缩写，VRRP出现的目的就是为了解决静态路由单点故障的问题，它能够保证当个别节点宕机时，整个网络可以不间断地运行。
所以，keepalive 一方面具有配置管理 LVS 的功能，同时还具有对 LVS 下面节点进行健康检查的功能，另一方面也可实现系统网络服务的高可用。
1、什么是Keepalive
Keepalive是一款专为LVS和HA设计的一款健康检查工具：支持故障自动切换、支持节点健康状态检查。
官方地址：www.keepalive.org2、Keepalive工作原理
- Keepalive是一个基于VRRP协议来实现的LVS服务高可用方案，可以解决静态路由出现的单点故障问题
-
在一个LVS服务集群中通常有**主服务器（MASTER）和备份服务器（BACKUP）**两种角色的服务器，但是对外表现为个虚拟IP，主服务器会发送VRRP通告信息给备份服务器，当备份服务器收不到VRRP消息的时候，即主服务器异常的时候，备份服务器就会接管虚拟IP，继续提供服务，从而保证了高可用性。
- 在Keepalive服务之间，只有作为主的服务器会一直发送VRRP广播包，告诉备它还活着，此时备不会抢占主，当主不可用时，即备监听不到主发送的广播包时，就会启动相关服务接管资源，保证业务的连续性。接管速度最快可以小于1秒。
3、keepalive 体系主要模块及其作用
keepalive体系架构中主要有三个模块，分别是core、check和vrrp。
- core模块:为keepalive的核心，负责主进程的启动、维护及全局配置文件的加载和解析。
- vrrp模块:是来实现VRRP协议的。
- check模块:负责健康检查，常见的方式有端口检查及URL检查。
4、keepalive 服务重要功能
1.管理 LVS 负载均衡软件
Keepalive可以通过读取自身的配置文件，实现通过更底层的接口直接管理LVS的配置以及控制服务的启动，停止功能。
2. 支持故障自动切换（Failover）
Keepalive可以实现任意两台主机之间，例如Master和Backup主机之间的故障转移和自动切换，这个主机可以是普通的不能停机的业务服务器，也可以是LVS负载均衡，Nginx反向代理这样的服务器。
Keepalive高可用功能实现的简单原理为，两台主机同时安装好Keepalive软件并启动服务，开始正常工作时，由角色为Master的主机获得所有资源并对用户提供服务，角色为Backup的主机作为Master主机的热备；当角色为Master的主机失效或出现故障时，角色为Backup的主机将自动接管Master主机的所有工作，包括接管VIP资源及相应资源服务；而当角色为Master的主机故障修复后，又会自动接管回它原来处理的工作，角色为Backup的主机则同时释放Master主机失效时它接管的工作，此时，两台主机将恢复到最初启动时各自的原始角色及工作状态。
3.实现 LVS 集群中节点的健康检查（Health Checking）
Keepalive可以通过在自身的Keepalive.conf文件里配置LVS的节点IP和相关参数实现对LVS的直接管理；除此之外，当LVS集群中的某一个甚至是几个节点服务器同时发生故障无法提供服务时，Keepalive服务会自动将失效的节点服务器从LVS的正常转发队列中清除出去，并将请求调度到别的正常节点服务器上，从而保证最终用户的访问不受影响；当故障的节点服务器被修复以后，Keepalive服务又会自动地把它们加入到正常转发队列中，对客户提供服务。
4.实现 LVS 负载调度器、节点服务器的高可用性（HA）
一般企业集群需要满足的三个特点：负载均衡、健康检查、故障切换，使用 LVS + Keepalive完全可以满足需求。
5、keepalive高可用故障切换转移原理
keepalive 高可用服务对集群之间的故障切换转移，是通过 VRRP（虚拟路由器冗余协议）来实现的。
在 keepalive服务正常工作时，主（Master）节点会不断地向备（Backup）节点发送（多播的方式）心跳消息，用以告诉备节点自己还活看，当主节点发生故障时，就无法发送心跳消息，备节点也就因此无法继续检测到来自主节点的心跳了，于是调用自身的接管程序，接管主节点的 IP 资源及服务。而当主节点恢复时，备节点又会释放主节点故障时自身接管的 IP 资源及服务，恢复到原来的备用角色。
5、VRRP通信原理
- VRRP也就是虚拟路由冗余协议，它的出现就是为了解决静态路由的单点故障。
- VRRP是通过一种竞选协议机制来将路由任务交给某台VRRP路由器的。
- VRRP用IP多播的方式（默认多播地址（224.0.0.18））实现高可用之间通信。
- 工作时主节点发包，备节点接包，当备节点接收不到主节点发的数据包的时候，就启动接管程序接管主节点的资源。备节点可以有多个，通过优先级竞选，但一般Keepalive系统运维工作中都是一对。
- VRRP使用了加密协议加密数据，但Keepalive官方目前还是推荐用明文的方式配置认证类型和密码。
二、keepalive脑裂及解决办法
1、keepalive脑裂
在高可用（HA）系统中，当联系2个节点的“心跳线”断开时，本来为一整体、动作协调的HA系统，就分裂成为2个独立的个体。由于相互失去了联系，都以为是对方出了故障。两个节点上的HA软件像“裂脑人”一样，争抢“共享资源”、争起“应用服务”，就会发生严重后果——或者共享资源被瓜分、2边“服务”都起不来了；或者2边“服务”都起来了，但同时读写“共享存储”，导致数据损坏（常见如数据库轮询着的联机日志出错）。
2、脑裂的原因
- 高可用服务器对之间心跳线链路发生故障，导致无法正常通信。如心跳线坏了（包括断了，老化）。
- 因网卡及相关驱动坏了，ip配置及冲突问题（网卡直连）。
- 因心跳线间连接的设备故障（网卡及交换机）。
- 因仲裁的机器出问题（采用仲裁的方案）。
- 高可用服务器上开启了 iptables防火墙阻挡了心跳消息传输。
- Keepalive配置里同一 VRRP实例如果 virtual_router_id两端参数配置不一致也会导致裂脑问题发生。
- vrrp实例名字不一致、优先级一致。
3、应对策略
- 添加冗余的心跳线，例如：双线条线（心跳线也HA），尽量减少“裂脑”发生几率。
-
启用磁盘锁。正在服务一方锁住共享磁盘，“裂脑”发生时，让对方完全“抢不走”共享磁盘资源。但使用锁磁盘也会有一个不小的问题，如果占用共享盘的一方不主动“解锁”，另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃，就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了“智能”锁。即：正在服务的一方只在发现心跳线全部断开（察觉不到对端）时才启用磁盘锁。平时就不上锁了。
-
设置仲裁机制。例如设置参考IP（如网关IP），当心跳线完全断开时，2个节点都各自ping一下参考IP，不通则表明断点就出在本端。不仅“心跳”、还兼对外“服务”的本端网络链路断了，即使启动（或继续）应用服务也没有用了，那就主动放弃竞争，让能够ping通参考IP的一端去起服务。更保险一些，ping不通参考IP的一方干脆就自我重启，以彻底释放有可能还占用着的那些共享资源。
- 利用脚本检测、报警。
vim check_keepalived.sh
#!/bin/bash
$ip=192.168.10.100
while true
do
if [ `ip a show ens33 |grep $ip|wc -l` -ne 0 ]
then echo "keepalived is error!"
else echo "keepalived is OK !"
fi
done
三、部署LVS+Keepalived 群集
1、环境准备
| 主机 | IP地址 |
|---|---|
| 主DR 服务器 | 192.168.10.100 |
| 备DR 服务器 | 192.168.10.101 |
| Web 服务器1 | 192.168.10102 |
| Web 服务器2 | 192.168.10.103 |
| 客户端 | 192.168.10.104 |
| vip | 192.168.10.188 |
（一）两台节点服务器（web1、web2）的配置
①7-3和7-4web1配置
创建页面
检测：
关闭主的keepalived服务
（二）7-1 LVS四层代理的master主配置
修改7-1配置文件
（三）7-2 LVS四层代理的backup备配置
（四）去浏览器访问检测:
去浏览器访问：为啥只有7-4,因为apache默认开启长连接，所以要关闭长连接
再去浏览器访问就会一会是7-3一会是7-4：
如果我们7-4服务宕机了，那么就不会跳7-4了
keepalives支持节点服务器健康状态检查(Health Checking)
配置虚拟路由器
vrrp_instance <STRING> {
#<String>为vrrp的实例名,一般为业务名称
配置参数
......
}
#配置参数：
state MASTER|BACKUP
#当前节点在此虚拟路由器上的初始状态，状态为MASTER或者BACKUP
interface IFACE_NAME
#绑定为当前虚拟路由器使用的物理接口，如：eth0,bond0,br0,可以和VIP不在一个网卡
virtual_router_id VRID
#每个虚拟路由器惟一标识，范围：0-255，每个虚拟路由器此值必须唯一，否则服务无法启动，同属一个虚拟路由器的多个keepalived节点必须相同,务必要确认在同一网络中此值必须唯一
priority 100
#当前物理节点在此虚拟路由器的优先级，范围：1-254，值越大优先级越高,每个keepalived主机节点此值不同
advert_int 1
#vrrp通告的时间间隔，默认1s
authentication {
#认证机制
auth_type AH|PASS
#AH为IPSEC认证(不推荐),PASS为简单密码(建议使用)
auth_pass <PASSWORD>
#预共享密钥，仅前8位有效，同一个虚拟路由器的多个keepalived节点必须一样
}
include /etc/keealived/conf.d/*.conf
virtual_ipaddress {
#虚拟IP,生产环境可能指定上百个IP地址
<IPADDR>/<MASK> brd <IPADDR> dev <STRING> scope <SCOPE> label <LABEL>
192.168.200.100
#指定VIP，不指定网卡，默认为,注意：不指定/prefix,默认为/32
192.168.200.101/24 dev eth1
#指定VIP的网卡，建议和interface指令指定的岗卡不在一个网卡
192.168.200.102/24 dev eth2 label eth2:1
#指定VIP的网卡label
}
track_interface {
#配置监控网络接口，一旦出现故障，则转为FAULT状态实现地址转移
eth0
eth1
…
}各种模式实验
keepalive工作方式：抢占式，非抢占式，延迟抢占模式
#通告：
是宣告自己的主权，不要妄想抢班夺权，不停的向外
#抢占式：
主服务器宕机，过了一段时间修好了，再把主权抢过来
#非抢占式：
主服务器宕机，过了一段时间修好了，原来的主就作为备了
#延迟抢占：
主修好后，等待一定的时间（300s）后再次成为主①默认模式 抢占式
浏览器访问
发现它的地址换到了从服务器上，如下图，所以不影响访问
②非抢占式
主服务器修改配置
重启服务后检测
③延迟抢占
主服务器修改：
备服务器修改
重启以后检测
④单播多播地址
修改多播
主从两边都加入此行： vrrp_mcast_group4 234.6.6.6 然后抓包验证主备同时修改
②修改单播:
#在所有节点vrrp_instance语句块中设置对方主机的IP，建议设置为专用于对应心跳线网络的地址，而非使用业务网络
unicast_src_ip <IPADDR> #指定发送单播的源IP
unicast_peer {
<IPADDR> #指定接收单播的对方目标主机IP
......
}
主服务器并重启
备服务器并重启
抓包
通知脚本
当前节点成为主节点时触发的脚本
notify_master <STRING>|<QUOTED-STRING>
当前节点转为备节点时触发的脚本
notify_backup <STRING>|<QUOTED-STRING>
当前节点转为“失败”状态时触发的脚本
notify_fault <STRING>|<QUOTED-STRING>
通用格式的通知触发机制，一个脚本可完成以上三种状态的转换时的通知
notify <STRING>|<QUOTED-STRING>
当停止VRRP时触发的脚本
notify_stop <STRING>|<QUOTED-STRING>
配置邮箱
模拟master故障
日志功能
开启单独日志功能
四、脑裂介绍
1、什么是脑裂？
在高可用（HA）系统中，当联系2个节点的“心跳线”断开时，本来为一整体、动作协调的HA系统，
就分裂成为2个独立的个体。由于相互失去了联系，都以为是对方出了故障。
两个节点上的HA软件像“裂脑人”一样，争抢“共享资源”、争起“应用服务”，就会发生严重后果。共享资源被瓜分、两边“服务”都起不来了；或者两边“服务”都起来了，但同时读写“共享存储”，导致数据损坏
2、都有哪些原因导致脑裂？
高可用服务器对之间心跳线链路发生故障，导致无法正常通信。
因心跳线坏了（包括断了，老化）。
因网卡及相关驱动坏了，ip配置及冲突问题（网卡直连）
因心跳线间连接的设备故障（网卡及交换机）
高可用服务器上开启了 iptables防火墙阻挡了心跳消息传输。
高可用服务器上心跳网卡地址等信息配置不正确，导致发送心跳失败
其他服务配置不当等原因，如心跳方式不同，心跳广插冲突、软件Bug等。
3、模拟脑裂
可以在主备上都发现vip地址（虚拟IP）
4、如何解决keepalived脑裂问题？
在实际生产环境中，我们从以下方面防止脑裂：
#同时使用串行电缆和以太网电缆连接、同时使用两条心跳线路，这样一条线路断了，另外一条还是好的，依然能传送心跳消息
#当检查脑裂时强行关闭一个心跳节点（这个功能需要特殊设备支持，如stonith、fence）相当于备节点接收不到心跳消息，通过单独的线路发送关机命令关闭主节点的电源
5、做好对脑裂的监控报警解决常见方案：
如果开启防火墙，一定要让心跳消息通过，一般通过允许IP段的形式解决
可以拉一条以太网网线或者串口线作为主被节点心跳线路的冗余
开发检测程序通过监控软件检测脑裂
五、实现其它应用的高可用性 VRRP Script
keepalived利用 VRRP Script 技术，可以调用外部的辅助脚本进行资源监控，并根据监控的结果实现优先动态调整，从而实现其它应用的高可用性功能（例如：nginx、mysql、redis)
1、VRRP Script 配置
分两步实现：
-
定义脚本
vrrp_script：自定义资源监控脚本，vrrp实例根据脚本返回值，公共定义，可被多个实例调用，定义在vrrp实例之外的独立配置块，一般放在global_defs设置块之后。通常此脚本用于监控指定应用的状态。一旦发现应用的状态异常，则触发对MASTER节点的权重减至低于SLAVE节点，从而实现 VIP 切换到 SLAVE 节点
vrrp_script <SCRIPT_NAME> {
script <STRING>|<QUOTED-STRING> #此脚本返回值为非0时，会触发下面OPTIONS执行
OPTIONS
}-
调用脚本
track_script：调用vrrp_script定义的脚本去监控资源，定义在VRRP实例之内，调用事先定义的vrrp_script
track_script {
SCRIPT_NAME_1
SCRIPT_NAME_2
}2、定义VRRP script
vrrp_script <SCRIPT_NAME> { #定义一个检测脚本，在global_defs 之外配置
script <STRING>|<QUOTED-STRING> #shell命令或脚本路径(注意执行权限)
interval <INTEGER> #间隔时间，单位为秒，默认1秒
timeout <INTEGER> #超时时间
weight <INTEGER:-254..254> #默认为0,如果设置此值为负数，当上面脚本返回值为非0时，会将此值与本节点权重相加可以降低本节点权重，即表示fall. 如果是正数，当脚本返回值为0，会将此值与本节点权重相加可以提高本节点权重，即表示 rise.通常使用负值
fall <INTEGER> #执行脚本连续几次都失败,则转换为失败，建议设为2以上
rise <INTEGER> #执行脚本连续几次都成功，把服务器从失败标记为成功
user USERNAME [GROUPNAME] #执行监测脚本的用户或组
init_fail #设置默认标记为失败状态，监测成功之后再转换为成功状态
}3、keepalived利用 VRRP Script 技术，从而实现nginx高可用性功能
7-1/7-2配置
[root@zzzcentos1 opt]#systemctl stop ipvsadm.service
[root@zzzcentos1 opt]#yum install epel-release.noarch -y
[root@zzzcentos1 opt]#yum install nginx -y
[root@zzzcentos1 opt]#systemctl start nginx
[root@zzzcentos1 opt]#systemctl status nginx
vim /etc/nginx/nginx.conf
再次配置7-1
再次配置7-2
keepalived利用 VRRP Script 技术,可以调用外部的辅助脚本进行资源监控,还可以实现mysql 、redis的高可用，脚本换换就可以哦
559
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
