keepalived基础配置详解（一）
一、简介
keepalived是一个基于VRRP协议来实现的WEB服务高可用方案，可以利用其来避免单点故障，用于web服务器的健康状态检测，如果有一台web服务器工作出现故障，keepalived将检测到，并将有故障的web服务器从系统中下线，等待服务器故障排除之后，将服务器重新添加至系统中。
要想学习keepalived，必须先了解VRRP协议，keepalived就是在VRRP协议的基础之上实现的。
二、VRRP协议简介
1.VRRP协议
虚拟路由冗余协议 VRRP（Virtual Router Redundancy Protocol）通过把几台路由设备联合组成一台虚拟的路由设备，使用一定的机制保证当主机的下一跳路由器出现故障时，及时将业务切换到备份路由器，从而保持业务的连续性和可靠性。
2.VRRP协议备份示意图：
3.VRRP协议工作过程：
VRRP 备份组中的交换机根据优先级选举出 Master。Master交换机通过发送ARP 报文，将虚拟MAC地址通知给与它连接的设备或者主机，从而承担报文转发任务。
Master 交换机周期性向备份组内所有 Backup 交换机发送 VRRP 通告报文，以公布其配 置信息（优先级等）和工作状况。
如果 Master 交换机出现故障，VRRP 备份组中的 Backup 交换机将根据优先级重新选举 新的 Master。
VRRP 备份组状态切换时，Master 交换机由一台设备切换为另外一台设备，新的Master 交换机会立即发送携带虚拟路由器的虚拟MAC地址和虚拟IP（Virtual IP以下简称VIP）地址信息的ARP报文，刷新与它连接的主机或设备中的MAC表项，从而把用户流量引到新的 Master 交换机上来，整个过程对用户完全透明。
三、keepalived组件
Core compeonentd（核心组件）：
Checkers：健康状态检测
Vrrp Stack：虚拟路由栈
IPVS wrapper：ipvs规则添加
WatchDog：监控器
Scheduler - I/O Multiplexer : IO复用器
Memory Management：内存管理
Control Plane Configuration file parser：配置文件分析器
四、keepalived的安装
1.实验环境（两台CentOS 7主机）
(1)两个节点时间同步；
分别在两台主机上执行
# crontab -e */5* * * * /usr/sbin/ntpdate 172.16.0.1 &> /dev/null # 设定为每5分钟同步一次
(2) 确保iptables和selinux 不会成为障碍；
(3) 各节点之间可通过主机名互相通信；（可选）
节点的名称设定与hosts文件中解析的主机名都要保持一致；
#uname -n 获得的主机，与解析的主机名要相同
(4)各节点之间基于密钥认证的方式通过ssh互信通信；（可选）
2.安装keepalived
(1) 源码安装
[root@node1 ~]# cd /usr/local/src [root@node1 ~]# wget http://www.keepalived.org/software/keepalived-1.2.19.tar.gz [root@node1 ~]# tar zxf keepalived-1.2.6.tar.gz [root@node1 ~]# cd keepalived-1.2.6 [root@node1 ~]# ./configure --prefix=/usr/local/keepalived [root@node1 ~]# make & make install
(2) rpm包安装（在CentOS 7系统的epel源提供了rpm包，以下实验为rpm包安装）
[root@node1 ~]# yum install -y keepalive
五、配置文件
1.keepalived的程序环境：
主配置文件：/etc/keepalived/keepalived.conf
Unit file: /usr/lib/systemd/system/keepalived.service2.keepalived的配置文件：
GLOBAL CONFIGURATION：全局配置
global_defs # Block id
{
...
}
VRRPD CONFIGURATION：配置vrrp实例
vrrp instance：虚拟路由器
vrrp_instance NAME {
...
}
vrrp synchronization group
vrrp_sync_group NAME {
...
}
LVS CONFIGURATION：ipvs的相关配置
集群服务，服务内的RS；
(1)全局配置：
global_defs {
notification_email {
...
}：收件人邮箱地址
notification_email_from：发件人邮箱地址
smtp_server：邮件发送服务器IP；
smtp_connect_timeout：邮件服务器建立连接的超时时长；
router_id LVS_DEVEL：物理节点的标识符；建立使用主机名；
vrrp_mcast_group4：IPV4多播地址，默认224.0.0.18；
(2) VRRP实例配置：
vrrp_instance NAME {
...
}
常用配置：
state MASTER|BACKUP：在当前VRRP实例中此节点的初始状态；
interface IFACE_NAME：vrrp用于绑定vip的接口；
virtual_router_id #：当前VRRP实例的VRID，可用范围为0-255；
priority #：当前节点的优先级，可用范围0-255；
advert_int 1：通告时间间隔；
authentication { # Authentication block
auth_type PASS
auth_pass 1234
}
virtual_ipaddress {...
}
六、配置实例详解
1.主备模型
虚拟IP在属于主节点，另一个节点作为备用节点存在。当主节点不可用时，备用节点接管虚拟IP，提供正常服务。
(1) 主备模型拓扑图
(2)编辑配置文件
在node1上编辑配置文件
[root@node1 ~]# vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs{ #全局配置段
notification_email {
[email protected]
} #收件人邮箱
notification_email_from [email protected] #发件人邮箱
smtp_server 127.0.0.1 #邮件发送服务器IP，此处设置为本地
smtp_connect_timeout 30 #邮件服务器建立连接的超时时长；
router_id node1 #物理节点的标识符，此处使用主机名；
vrrp_mcast_group4 224.100.0.1 #IPV4多播地址，此处为默认；
}
vrrp_instanceVI_1 {
state MASTER #节点的初始状态，主节点为MASTER；
interface eno16777736 ##绑定虚拟IP的网络接口
virtual_router_id 80 #VRRP组名，指明各个节点属于同一VRRP组，主从一致；
priority 100 #当前节点的优先级，可用范围0-255；
advert_int 1 #通告时间间隔，此处设置为1s，主从节点一致；
authentication { #主从服务器验证方式
auth_type PASS
auth_pass 5QbqkQJj
}
virtual_ipaddress { #虚拟IP,格式为ADDR/NETMASK
172.16.22.5/16
}
}
将此文件复制至node2主机，并修改；
[root@node2 ~]# vim /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs{ notification_email { [email protected] } notification_email_from [email protected] smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id node2 #修改标识符为node2； vrrp_mcast_group4 224.100.0.1 } vrrp_instanceVI_1 { state BACKUP ##节点的初始状态，主节点为MASTER； interface eno16777736 virtual_router_id 80 priority 99 #备用节点的优先级应该比主节点低； advert_int 1 authentication { auth_type PASS auth_pass 5QbqkQJj } virtual_ipaddress { 172.16.22.5/16 } }(3) 验证并测试
启动node1，node2上配置好的keepalived服务，查看node1是否有VIP：
关闭node1的keepalived服务，查看日志，显示如下：
此时node1停止keepalived服务，发送通告，移除地址；查看node2已配置VIP，成为主节点；
2.双主模型
主备模型存在一个缺点：始终只有主节点处于工作状态，备用节点一直空闲，造成资源浪费。双主模式就是每个节点必须有两个VIP, 分别绑定至两个节点上。作为第一个VIP的主节点，并同时作为另外一个VIP的备用节点。两节点互相交叉备份，当一个节点发生故障，两个VIP将自动绑定至另外一个节点。
(1) 双主模型拓扑图
(2) 在node1上编辑配置文件
[root@node1 ~]# vim /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs{ notification_email { [email protected] } notification_email_from [email protected] smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id node1 vrrp_mcast_group4 224.100.0.1 } vrrp_instanceVI_1 { state MASTER #对应vrrp_instanceVI_1组中的主节点 interface eno16777736 virtual_router_id 80 #本机两个vrrp_instance组的此值不能相同，对应备用节点的此值必须相同 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 5QbqkQJj } virtual_ipaddress { 172.16.22.5/16 } } vrrp_instanceVI_2 { state BACKUP #对应vrrp_instanceVI_2组中的备用节点 interface eno16777736 virtual_router_id 81 #本机两个vrrp_instance组的此值不能相同，对应主节点的值必须相同 priority 99 #优先级比对应主节点小1 advert_int 1 authentication { auth_type PASS auth_pass c2Wyk1Dz } virtual_ipaddress { 172.16.22.6/16 } }将配置文件复制至node2，修改为；
[root@node1 ~]# vim /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs{ notification_email { [email protected] } notification_email_from [email protected] smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id node1 vrrp_mcast_group4 224.100.0.1 } vrrp_instanceVI_1 { state BACKUP #对应vrrp_instanceVI_1组中的备用节点 interface eno16777736 virtual_router_id 80 #对应vrrp_instanceVI_1组的节点值 priority 99 #优先级比对应主节点小1 advert_int 1 authentication { auth_type PASS auth_pass 5QbqkQJj } virtual_ipaddress { 172.16.22.5/16 } } vrrp_instanceVI_2 { state MASTER #对应vrrp_instanceVI_2组中的主节点 interface eno16777736 virtual_router_id 81 #对应vrrp_instanceVI_2组的节点值 priority 100 #优先级比对应主节点大1 advert_int 1 authentication { auth_type PASS auth_pass c2Wyk1Dz } virtual_ipaddress { 172.16.22.6/16 } }(3) 验证并测试
启动node1和node2上的keepalived服务，分别查看两节点的VIP；
手动停止node1的keepalived服务，node1的VIP将漂移至node2；
同样，停止node2上的keepalived服务，node2的VIP将漂移至node1；此处将不再进行测试，请各位读者自行测试；
[Warning]: 上面示例中的主备模型存在严重问题，这种方式存在脑裂的可能，即两个节点实际都处于正常工作状态，但是无法接收到彼此的组播通知，这时两个节点均强行绑定虚拟IP，导致不可预料的后果。
在实际的生产环境中可能会存在上图中的问题，node1为备用节点，node2为主节点，node2网络发生故障，node1收不到node2的组播信息，此时node1抢占node2的VIP，node1和node2同时拥有VIP将会导致脑裂(split-brain)。此时就需要我们设置仲裁机制。例如设置网关，当心跳线完全断开时，2个节点都各自ping一下网关，不通则表明断点就出在本节点，不仅“心跳”、还兼对外“服务”的本节点网络链路断了，即使启动（或继续）应用服务也没有用了，那就主动放弃竞争，让能够ping通网关的启动服务。