Keepalived简介
是什么?
keepalived是一个类似于layer3, 4 & 5交换机制的软件，也就是我们平时说的第3层、第4层和第5层交换。Keepalived的作用是检测web服务器的状态，如果有一台web服务器死机，或工作出现故障，Keepalived将检测到，并将有故障的web服务器从系统中剔除，当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的web服务器。
类似的HA工具还有heatbeat、drbd等，heatbeat、drbd,MHA配置都较为复杂。
Keepalived工作原理
Keepalived是一个基于VRRP协议来实现的WEB 服务高可用方案，可以利用其来避免单点故障。一个WEB服务至少会有2台服务器运行Keepalived，一台为主服务器（MASTER），一台为备份服务器（BACKUP），但是对外表现为一个虚拟IP，主服务器会发送特定的消息给备份服务器，当备份服务器收不到这个消息的时候，即主服务器宕机的时候，备份服务器就会接管虚拟IP，继续提供服务，从而保证了高可用性。
keepalived是VRRP的完美实现，因此在介绍keepalived之前，先介绍一下VRRP的原理。
VRRP协议简介
在现实的网络环境中，两台需要通信的主机大多数情况下并没有直接的物理连接。对于这样的情况，它们之间路由怎样选择？主机如何选定到达目的主机的下一跳路由，这个问题通常的解决方法有二种：
# 在主机上使用动态路由协议(RIP、OSPF等)
# 在主机上配置静态路由
很明显，在主机上配置路态路由是非常不切实际的，因为管理、维护成本以及是否支持等诸多问题。配置静态路由就变得十分流行，但路由器(或者说默认网关default gateway)却经常成为单点。
VRRP的目的就是为了解决静态路由单点故障问题。
VRRP通过一竞选(election)协议来动态的将路由任务交给LAN中虚拟路由器中的某台VRRP路由器。
vrrp简介
随着Internet的迅猛发展，基于网络的应用逐渐增多。这就对网络的可靠性提出了越来越高的要求。斥资对所有网络设备进行更新当然是一种很好的可靠性解决方案；但本着保护现有投资的角度考虑，可以采用廉价冗余的思路，在可靠性和经济性方面找到平衡点。
虚拟路由冗余协议就是一种很好的解决方案。在该协议中，对共享多存取访问介质（如以太网）上终端IP设备的默认网关(Default Gateway)进行冗余备份，从而在其中一台路由设备宕机时，备份路由设备及时接管转发工作，向用户提供透明的切换，提高了网络服务质量。
协议概述
在基于TCP/IP协议的网络中，为了保证不直接物理连接的设备之间的通信，必须指定路由。目前常用的指定路由的方法有两种：一种是通过路由协议（比如：内部路由协议RIP和OSPF）动态学习；另一种是静态配置。在每一个终端都运行动态路由协议是不现实的，大多客户端操作系统平台都不支持动态路由协议，即使支持也受到管理开销、收敛度、安全性等许多问题的限制。因此普遍采用对终端IP设备静态路由配置，一般是给终端设备指定一个或者多个默认网关(Default Gateway)。静态路由的方法简化了网络管理的复杂度和减轻了终端设备的通信开销，但是它仍然有一个缺点：如果作为默认网关的路由器损坏，所有使用该网关为下一跳主机的通信必然要中断。即便配置了多个默认网关，如不重新启动终端设备，也不能切换到新的网关。采用虚拟路由冗余协议 (Virtual Router Redundancy Protocol，简称VRRP)可以很好的避免静态指定网关的缺陷。
在VRRP协议中，有两组重要的概念：VRRP路由器和虚拟路由器，主控路由器和备份路由器。VRRP路由器是指运行VRRP的路由器，是物理实体，虚拟路由器是指VRRP协议创建的，是逻辑概念。一组VRRP路由器协同工作，共同构成一台虚拟路由器。该虚拟路由器对外表现为一个具有唯一固定IP地址和MAC地址的逻辑路由器。处于同一个VRRP组中的路由器具有两种互斥的角色：主控路由器和备份路由器，一个VRRP组中有且只有一台处于主控角色的路由器，可以有一个或者多个处于备份角色的路由器。VRRP协议使用选择策略从路由器组中选出一台作为主控，负责ARP相应和转发IP数据包，组中的其它路由器作为备份的角色处于待命状态。当由于某种原因主控路由器发生故障时，备份路由器能在几秒钟的时延后升级为主路由器。由于此切换非常迅速而且不用改变IP地址和MAC地址，故对终端使用者系统是透明的。
vrrp工作原理
一个VRRP路由器有唯一的标识：VRID，范围为0—255。该路由器对外表现为唯一的虚拟MAC地址，地址的格式为00-00-5E-00-01-[VRID]。主控路由器负责对ARP请求用该MAC地址做应答。这样，无论如何切换，保证给终端设备的是唯一一致的IP和MAC地址，减少了切换对终端设备的影响。
VRRP控制报文只有一种：VRRP通告(advertisement)。它使用IP多播数据包进行封装，组地址为224.0.0.18，发布范围只限于同一局域网内。这保证了VRID在不同网络中可以重复使用。为了减少网络带宽消耗只有主控路由器才可以周期性的发送VRRP通告报文。备份路由器在连续三个通告间隔内收不到VRRP或收到优先级为0的通告后启动新的一轮VRRP选举。
在VRRP路由器组中，按优先级选举主控路由器，VRRP协议中优先级范围是0—255。若VRRP路由器的IP地址和虚拟路由器的接口IP地址相同，则称该虚拟路由器作VRRP组中的IP地址所有者；IP地址所有者自动具有最高优先级：255。优先级0一般用在IP地址所有者主动放弃主控者角色时使用。可配置的优先级范围为1—254。优先级的配置原则可以依据链路的速度和成本、路由器性能和可靠性以及其它管理策略设定。主控路由器的选举中，高优先级的虚拟路由器获胜，因此，如果在VRRP组中有IP地址所有者，则它总是作为主控路由的角色出现。对于相同优先级的候选路由器，按照IP地址大小顺序选举。VRRP还提供了优先级抢占策略，如果配置了该策略，高优先级的备份路由器便会剥夺当前低优先级的主控路由器而成为新的主控路由器。
为了保证VRRP协议的安全性，提供了两种安全认证措施：明文认证和IP头认证。明文认证方式要求：在加入一个VRRP路由器组时，必须同时提供相同的VRID和明文密码。适合于避免在局域网内的配置错误，但不能防止通过网络监听方式获得密码。IP头认证的方式提供了更高的安全性，能够防止报文重放和修改等攻击。
keepalived工作机制
在一个VRRP虚拟路由器中，有多台物理的VRRP路由器，但是这多台的物理的机器并不能同时工作，而是由一台称为MASTER的负责路由工作，其它的都是BACKUP，MASTER并非一成不变，VRRP让每个VRRP路由器参与竞选，最终获胜的就是MASTER。MASTER拥有一些特权，比如 拥有虚拟路由器的IP地址，我们的主机就是用这个IP地址作为静态路由的。拥有特权的MASTER要负责转发发送给网关地址的包和响应ARP请求。
VRRP通过竞选协议来实现虚拟路由器的功能，所有的协议报文都是通过IP多播(multicast)包(多播地址 224.0.0.18)形式发送的。虚拟路由器由VRID(范围0-255)和一组IP地址组成，对外表现为一个周知的MAC地址。所以，在一个虚拟路由 器中，不管谁是MASTER，对外都是相同的MAC和IP(称之为VIP)。客户端主机并不需要因为MASTER的改变而修改自己的路由配置，对他们来 说，这种主从的切换是透明的。
在一个虚拟路由器中，只有作为MASTER的VRRP路由器会一直发送VRRP广告包(VRRPAdvertisement message)，BACKUP不会抢占MASTER，除非它的优先级(priority)更高。当MASTER不可用时(BACKUP收不到广告包)， 多台BACKUP中优先级最高的这台会被抢占为MASTER。这种抢占是非常快速的(<1s)，以保证服务的连续性。
由于安全性考虑，VRRP包使用了加密协议进行加密。
上图是Keepalived的功能体系结构，大致分两层：用户空间（user space）和内核空间（kernel space）。 内核空
间：主要包括IPVS（IP虚拟服务器，用于实现网络服务的负载均衡）和NETLINK（提供高级路由及其他相关的网络
功能）两个部份。 用户空间：
WatchDog：负载监控checkers和VRRP进程的状况
VRRP Stack：负载负载均衡器之间的失败切换FailOver，如果只用一个负载均稀器，则VRRP不是必须的。
Checkers：负责真实服务器的健康检查healthchecking，是keepalived最主要的功能。换言之，可以没有
VRRP Stack，但健康检查healthchecking是一定要有的。
IPVS wrapper：用户发送设定的规则到内核ipvs代码
Netlink Reflflector：用来设定vrrp的vip地址等。
Keepalived的所有功能是配置keepalived.conf文件来实现的
应用价值
最典型的VRRP应用：RTA、RTB组成一个VRRP路由器组，假设RTB的处理能力高于RTA，则将RTB配置成IP地址所有者，H1、H2、H3的默认网关设定为RTB。则RTB成为主控路由器，负责ICMP重定向、ARP应答和IP报文的转发；一旦RTB失败，RTA立即启动切换，成为主控，从而保证了对客户透明的安全切换。
在VRRP应用中，RTA在线时RTB只是作为后备，不参与转发工作，闲置了路由器RTA和链路L1。通过合理的网络设计，可以到达备份和负载分担双重效果。让RTA、RTB同时属于互为备份的两个VRRP组：在组1中RTA为IP地址所有者；组2中RTB为IP地址所有者。将H1的默认网关设定为RTA；H2、H3的默认网关设定为RTB。这样，既分担了设备负载和网络流量，又提高了网络可靠性。
VRRP协议的工作机理与CISCO公司的HSRP（Hot Standby Routing Protocol）有许多相似之处。但二者主要的区别是在CISCO的HSRP中，需要单独配置一个IP地址作为虚拟路由器对外体现的地址，这个地址不能是组中任何一个成员的接口地址。
使用VRRP协议，不用改造目前的网络结构，最大限度保护了当前投资，只需最少的管理费用，却大大提升了网络性能，具有重大的应用价值。
Keepalived部署
安装
yum -y install keepalived ipvsadm
rpm -ql keepalived
# /etc/keepalived
# /etc/keepalived/keepalived.conf 主配置文件
# /etc/sysconfig/keepalived
# /usr/bin/genhash
# /usr/lib/systemd/system/keepalived.service # 启动脚本
# /usr/libexec/keepalived
# /usr/sbin/keepalived
# /usr/share/doc/keepalived-1.3.5
配置Keepalived
keepalived只有一个配置文件keepalived.conf，里面主要包括以下几个配置区域，分别是global_defs、static_ipaddress、vrrp_script、vrrp_instance和virtual_server.
以下为keepalived默认配置文件解读
cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs { # 全局配置
notification_email {
acassen@firewall.loc # 定义报警人收件人邮件地址
failover@firewall.loc
sysadmin@firewall.loc
}
notification_email_from Alexandre.Cassen@firewall.loc # 定义报警发件人邮箱
smtp_server 192.168.200.1 # 邮箱服务器地址
smtp_connect_timeout 30 # 定义邮箱超时时间
router_id LVS_DEVEL # 定义路由标识信息,同区域网唯一
vrrp_skip_check_adv_addr
vrrp_strict
vrrp_garp_interval 0
vrrp_gna_interval 0
}
vrrp_instance VI_1 { # 定义实例
state MASTER # 指定keepalived节点的初始状态,可选值为MASTER | BACKUP
interface eth0 # VRRP实例绑定的网卡接口,用户发送的VRRP包
virtual_router_id 51 # 虚拟路由的ID,同一集群要一致
# nopreempt # 设置不抢占
priority 100 # 定义优先级,按优先级来决定主备角色,优先级越大
advert_int 1 # 主备通讯时间间隔
authentication { # 配置认证
auth_type PASS # 认证方式,此处为密码
auth_pass 1111 # 同一集群中的keepalived配置里的此处必须一致,推荐使用8位随机数
}
virtual_ipaddress { # 配置要使用的vip地址
192.168.200.16
192.168.200.17
192.168.200.18
}
}
virtual_server 192.168.200.100 443 { # 配置虚拟服务器
delay_loop 6 # 健康检查的时间间隔
lb_algo rr # lvs调度算法
lb_kind NAT # lvs模式
persistence_timeout 50 # 持久化超时时间,单位是秒
protocol TCP # 4层协议
sorry_server 192.168.200.200 1358 # 定义备用服务器，当所有RS都故障时用sorry_server来响应客户端
real_server 192.168.201.100 443 { # 定义真实处理请求的服务器
weight 1 # 给服务器权重,默认为1
SSL_GET {
url {
path / # 指定要检查的路径
digest ff20ad2481f97b1754ef3e12ecd3a9cc # 摘要信息
}
url {
path /mrtg/
digest 9b3a0c85a887a256d6939da88aabd8cd
}
connect_timeout 3 # 连接超时时间
nb_get_retry 3 # get尝试次数
delay_before_retry 3 # 在尝试之前延迟多长时间
}
}
}
real_server 192.168.200.3 1358 { # 定义真实处理请求的服务器
weight 1 # 给服务器指定权重,默认为1
HTTP_GET {
url {
path /testurl/test.jsp # 指定要检查的URL路径
digest 640205b7b0fc66c1ea91c463fac6334c # 摘要信息
}
url {
path /testurl2/test.jsp
digest 640205b7b0fc66c1ea91c463fac6334c
}
connect_timeout 3 # 连接超时时间
nb_get_retry 3 # get尝试次数
delay_before_retry 3 # 在尝试之前延迟时间
}
}
}
定制主配置文件
vrrp_instance段配置
nopreempt #设置为不抢占。默认是抢占的，当高优先级的机器恢复后，会抢占低优先级的机器成为MASTER，而不抢占，则允许低优先级的机器继续成为MASTER，即使高优先级的机器已经上线。如果要使用这个功能，则初始化状态必须为BACKUP。
preempt_delay # 设置抢占延迟。单位是秒，范围是0---1000，默认是0.发现低优先级的MASTER后多少秒开始抢占。
vrrp_script段配置
# 作用：添加一个周期性执行的脚本。脚本的退出状态码会被调用它的所有的VRRP Instance记录。
# 注意：至少有一个VRRP实例调用它并且优先级不能为0.优先级范围是1-254.
vrrp_script <SCRIPT_NAME> {
...
}
#选项说明：
script "/path/to/somewhere" # 指定要执行的脚本的路径。
interval <INTEGER> # 指定脚本执行的间隔。单位是秒。默认为1s。
timeout <INTEGER> # 指定在多少秒后，脚本被认为执行失败。
weight <-254 --- 254> # 调整优先级。默认为2.
rise <INTEGER> # 执行成功多少次才认为是成功。
fall <INTEGER> # 执行失败多少次才认为失败。
user <USERNAME> [GROUPNAME] # 运行脚本的用户和组。
init_fail # 假设脚本初始状态是失败状态。
#weight说明：
# 1. 如果脚本执行成功(退出状态码为0)，weight大于0，则priority增加。
# 2. 如果脚本执行失败(退出状态码为非0)，weight小于0，则priority减少。
# 3. 其他情况下，priority不变。
real_server段配置
weight <INT> # 给服务器指定权重。默认是1
inhibit_on_failure # 当服务器健康检查失败时，将其weight设置为0，而不是从Virtual Server中移除
notify_up <STRING> # 当服务器健康检查成功时，执行的脚本
notify_down <STRING> # 当服务器健康检查失败时，执行的脚本
uthreshold <INT> # 到这台服务器的最大连接数
lthreshold <INT> # 到这台服务器的最小连接数
tcp_check段配置
connect_ip <IP ADDRESS> # 连接的IP地址。默认是real server的ip地址
connect_port <PORT> # 连接的端口。默认是real server的端口
bindto <IP ADDRESS> # 发起连接的接口的地址。
bind_port <PORT> # 发起连接的源端口。
connect_timeout <INT> # 连接超时时间。默认是5s。
fwmark <INTEGER> # 使用fwmark对所有出去的检查数据包进行标记。
warmup <INT> # 指定一个随机延迟，最大为N秒。可防止网络阻塞。如果为0，则关闭该功能。
retry <INIT> # 重试次数。默认是1次。
delay_before_retry <INT> # 默认是1秒。在重试之前延迟多少秒。
Keepalived实现Nginx高可用
| 节点名 | IP | 软件版本 | 硬件 | 网络 | 说明 |
|---|---|---|---|---|---|
| nginx-1 | 192.168.171.145 | keepalived-1.3.5 | 2C4G | Nat，内网 | 测试环境 |
| nginx-2 | 192.168.171.130(vip为192.168.171.250) | keepalived-1.3.5 | 2C4G | Nat,内网 | 测试环境 |
安装nginx
yum -y install nginx
cd /usr/share/nginx/html/
mv index.html{,.bak}
echo 'slave' > index.html
systemctl start nginx
配置Keepalived配置文件
主配置文件
[root@nginx2 keepalived]# cat keepalived.conf
global_defs {
router_id nginx_master
}
vrrp_script check_nginx {
script "/etc/keepalived/check_nginx.sh"
interval 5
}
vrrp_instance VI_1 {
state BACKUP
nopreempt
interface ens33
virtual_router_id 50
priority 80
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.171.251
}
track_script {
check_nginx
}
}
从机配置
cat keepalived.conf
global_defs {
router_id nginx_slave
}
vrrp_script check_nginx {
script "/etc/keepalived/check_nginx.sh"
interval 5
}
vrrp_instance VI_1 {
state BACKUP
nopreempt
interface ens32
virtual_router_id 50
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.171.251
}
track_script {
check_nginx
}
}
keepalived监控nginx负载均衡
编写监控脚本
cat check_nginx.sh
#!/bin/bash
curl -I http://localhost &>/dev/null
if [ $? -ne 0 ];then
systemctl stop keepalived
fi
chmod a+x check_nginx.sh
测试
# 我们停掉一台Nginx
curl 192.168.171.251 -I
HTTP/1.1 200 OK
Server: nginx/1.16.1
Date: Thu, 28 May 2020 14:44:38 GMT
Content-Type: text/html
Content-Length: 4833
Last-Modified: Fri, 16 May 2014 15:12:48 GMT
Connection: keep-alive
ETag: "53762af0-12e1"
Accept-Ranges: bytes
# 我们可以发现还是可以访问,因为IP已经切换到另一台服务器了
[root@nginx1 keepalived]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:53:3e:07 brd ff:ff:ff:ff:ff:ff
inet 192.168.171.145/24 brd 192.168.171.255 scope global dynamic ens32
valid_lft 1414sec preferred_lft 1414sec
inet 192.168.171.251/32 scope global ens32
valid_lft forever preferred_lft forever
脑裂
在高可用（HA）系统中，当联系2个节点的“心跳线”断开时，本来为一整体、动作协调的HA系统，就分裂成为2个独立的个体。由于相互失去了联系，都以为是对方出了故障。两个节点上的HA软件像“裂脑人”一样，争抢“共享资源”、争起“应用服务”，就会发生严重后果——或者共享资源被瓜分、2边“服务”都起不来了；或者2边“服务”都起来了，但同时读写“共享存储”，导致数据损坏（常见如数据库轮询着的联机日志出错）。
对付HA系统“裂脑”的对策，目前达成共识的的大概有以下几条：
1 . 添加冗余的心跳线，例如：双线条线（心跳线也HA），尽量减少“裂脑”发生几率；
2 . 启用磁盘锁。正在服务一方锁住共享磁盘，“裂脑”发生时，让对方完全“抢不走”共享磁盘资源。但使用锁磁盘也会有一个不小的问题，如果占用共享盘的一方不主动“解锁”，另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃，就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了“智能”锁。即：正在服务的一方只在发现心跳线全部断开（察觉不到对端）时才启用磁盘锁。平时就不上锁了。
3 . 设置仲裁机制。例如设置参考IP（如网关IP），当心跳线完全断开时，2个节点都各自ping一下参考IP，不通则表明断点就出在本端。不仅“心跳”、还兼对外“服务”的本端网络链路断了，即使启动（或继续）应用服务也没有用了，那就主动放弃竞争，让能够ping通参考IP的一端去起服务。更保险一些，ping不通参考IP的一方干脆就自我重启，以彻底释放有可能还占用着的那些共享资源
脑裂产生的原因
一般来说，脑裂的发生，有以下几种原因：
# 高可用服务器对之间心跳线链路发生故障，导致无法正常通信
# 因心跳线断开（包括网线断裂、水晶头松动等物理原因）
# 因网卡及相关驱动坏了，ip配置及冲突问题（网卡直连）
# 因心跳线间连接的设备故障（网卡及交换机）
# 因仲裁的机器出问题（采用仲裁的方案）
# 高可用服务器上开启了 iptables防火墙阻挡了心跳消息传输
# 高可用服务器上心跳网卡地址等信息配置不正确，导致发送心跳失败
# 其他服务配置不当等原因，如心跳方式不同，心跳广插冲突、软件Bug等
注意
Keepalived配置里同一 VRRP实例如果 virtual_router_id两端参数配置不一致也会导致裂脑问题发生。
脑裂的常见解决方案
在实际生产环境中，我们可以从以下几个方面来防止裂脑问题的发生：
1 . 同时使用串行电缆和以太网电缆连接，同时用两条心跳线路，这样一条线路坏了，另一个还是好的，依然能传送心跳消息
2 . 当检测到裂脑时强行关闭一个心跳节点（这个功能需特殊设备支持，如Stonith、feyce）。相当于备节点接收不到心跳消患，通过单独的线路发送关机命令关闭主节点的电源
3 . 做好对裂脑的监控报警（如邮件及手机短信等或值班）.在问题发生时人为第一时间介入仲裁，降低损失。例如，百度的监控报警短倍就有上行和下行的区别。报警消息发送到管理员手机上，管理员可以通过手机回复对应数字或简单的字符串操作返回给服务器.让服务器根据指令自动处理相应故障，这样解决故障的时间更短.
当然，在实施高可用方案时，要根据业务实际需求确定是否能容忍这样的损失。对于一般的网站常规业务.这个损失是可容忍的
4 . 对脑裂进行监控
对脑裂的监控应在备用服务器上进行，通过添加zabbix自定义监控进行。
监控什么信息呢？监控备上有无VIP地址
备机上出现VIP有两种情况：
- 发生了脑裂
- 发生主备切换
监控只是监控发生脑裂的可能性，不能保证一定是发生了脑裂，因为正常的主备切换VIP也是会到备上的。
监控脚本如下（应放在备选服务器上）
#!/bin/bash
if [ $(ip a show ens33 |grep 172.16.12.250|wc -l) -ne 0 ]
then
#发现备选服务器上有VIP
echo "1"
else
#没发现备选服务器上有VIP
echo "0"
fi
done
# 编写脚本时要注意，网卡要改成你自己的网卡名称，VIP也要改成自己的VIP，并修改/scripts目录的属主&属组为zabbix