Keepalived高可用集群

时间 2019-11-09

原文原文链接

Keepalived高可用集群前端

1、Keepalived介绍

Keepalived软件起初是专门为LVS负载均衡软件设计的，用来管理并监控LVS集群系统中各个服务节点的状态，后来又加入了能够实现高可用的VRRP功能。所以，Keepalived除了可以管理LVS软件外，还能够做为其余服务（例如：Nginx，Haproxy，MySQL等）的高可用解决方案软件。ios

Keepalived软件主要是经过VRRP协议实现高可用功能的。VRRP是Virtual Router Redundancy Protocol（虚拟路由器冗余协议）的缩写，VRRP出现的目的就是为了解决静态路由单点故障问题的，他可以保证当个别节点宕机时，整个网络能够不间断地运行。因此，Keepalived一方面具备配置管理LVS的功能，同时还具备对LVS下面节点进行健康检查的功能，另外一方面也可实现系统网络服务的高可用功能。数据库

Keepalived软件的官方站点是http://www.keepalived.orgvim

2、Keepalived服务的三个重要功能

（1）管理LVS负载均衡软件安全

早期的LVS软件，须要经过命令行或脚本实现管理，而且没有针对LVS节点的健康检查功能。为了解决LVS的这些使用不便问题，Keepalived诞生了，能够说，Keepalived软件起初是专为解决LVS的问题而诞生的。所以，Keepalived和LVS的感情很深，他们的关系如同夫妻同样，能够紧密地结合，愉快地工做。Keepalived能够经过读取自身的配置文件，实现经过更底层的接口直接管理LVS的配置以及控制服务的启动，中止功能，这使得LVS的应用更加简单方便了。服务器

（2）实现对LVS集群节点健康检查功能（healthcheck）网络

前文已讲过，Keepalived能够经过在自身的Keepalived.conf文件里配置LVS的节点IP和相关参数实现对LVS的直接管理；除此以外，当LVS集群中的某一个甚至是几个节点服务器同时发生故障没法提供服务时，Keepalived服务会自动将失效的节点服务器从LVS的正常转发队列中清除出去，并将请求调度到别的正常节点服务器上，从而保证最终用户的访问不受影响；当故障的节点服务器被修复之后，Keepalived服务又会自动地把它们加入到正常转发队列中，对客户提供服务。负载均衡

（3）做为系统网络服务的高可用功能（failover）运维

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

Keepalived高可用功能实现的简单原理为，两台主机同时安装好Keepalived软件并启动服务，开始正常工做时，由角色为Master的主机得到全部资源并对用户提供服务，角色为Backup的主机做为Master主机的热备；当角色为Master的主机失效或出现故障时，角色为Backup的主机将自动接管Master主机的全部工做，包括接管VIP资源及相应资源服务；而当角色为Master的主机故障修复后，又会自动接管回它原来处理的工做，角色为Backup的主机则同时释放Master主机失效时它接管的工做，此时，两台主机将恢复到最初启动时各自的原始角色及工做状态。

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

Keepalived高可用服务之间的故障切换转移，是经过VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议）来实现的。

在Keepalived服务正常工做时，主Master节点会不断地向备节点发送（多播的方式）心跳消息，用以告诉备Backup节点本身还活着，当主Master节点发生故障时，就没法发送心跳消息，备节点也就所以没法继续检测到来自主Master节点的心跳了，因而调用自身的接管程序，接管主Master节点的IP资源及服务。而当主Master节点恢复时，备Backup节点又会释放主节点故障时自身接管的IP资源及服务，恢复到原来的备用角色。

那么，什么是VRRP呢？
VRRP，全称Virtual Router Redundancy Protocol，中文名为虚拟路由冗余协议，VRRP的出现就是为了解决静态路由的单点故障问题，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）形式发送的。虚拟路由器由VRID（范围0-225）和一组IP地址组成，对外表现为一个周知的MAC地址：00-00-5E-00-01-{VRID}。因此，在一个虚拟路由器中，无论谁是Master，对外都是相同的MAC和IP（称之为VIP）。客户端主机并不须要因Master的改变而修改本身的路由配置。对他们来讲，这种切换是透明的。

在一组虚拟路由器中，只有做为Master的VRRP路由器会一直发送VRRP广播包（VRRP Advertisement messages），此时Backup不会抢占Master。当Master不可用时，Backup就收不到来自Master的广播包了，此时多台Backup中优先级最高的路由器会抢占为Master。这种抢占是很是快速的（可能只有1秒甚至更少），以保证服务的连续性。出于安全性考虑，VRRP数据包使用了加密协议进行了加密。

4、VRRP通讯原理

1.VRRP也就是虚拟路由冗余协议，它的出现就是为了解决静态路由的单点故障。

2.VRRP是经过一种竞选协议机制来将路由任务交给某台VRRP路由器的。

3.VRRP用IP多播的方式（默认多播地址（224.0.0.18））实现高可用之间通讯。

4.工做时主节点发包，备节点接包，当备节点接收不到主节点发的数据包的时候，就启动接管程序接管主节点的资源。备节点能够有多个，经过优先级竞选，但通常Keepalived系统运维工做中都是一对。

5.VRRP使用了加密协议加密数据，但Keepalived官方目前仍是推荐用明文的方式配置认证类型和密码。

5、Keepalived服务的工做原理

Keepalived高可用之间是经过VRRP进行通讯的，VRRP是经过竞选机制来肯定主备的，主的优先级高于备，所以，工做时主会优先得到全部的资源，备节点处于等待状态，当主挂了的时候，备节点就会接管主节点的资源，而后顶替主节点对外提供服务。

在Keepalived服务之间，只有做为主的服务器会一直发送VRRP广播包，告诉备它还活着，此时备不会抢占主，当主不可用时，即备监听不到主发送的广播包时，就会启动相关服务接管资源，保证业务的连续性。接管速度最快能够小于1秒。

6、Keepalived高可用单实例服务搭建

虚拟机主从服务器各添加一块网卡并开机配置网卡

cd /etc/sysconfig/network-scripts/

cp ifcfg-eth0 ifcfg-eth1

vim ifcfg-eth1 --->把网卡名换成eth1便可

硬件环境准备

准备4台VM虚拟机，两台用来作Keepalived服务，两台作测试的Web节点

Nginx-Master IP：192.168.200.67 --->Keepalived主服务器（Nginx主负载均衡）

Nginx-Slave IP：192.168.200.71 --->Keepalived从服务器（Nginx从负载均衡）

Nginx-WEB1 IP：192.168.200.72 --->WEBA节点

Nginx-WEB2 IP：192.168.200.73 --->WEBB节点

安装keepalived软件

yum -y install keepalived

启动Keepalived服务并检查

启动后有3个Keepalived进程表示安装正确

打开keepalived主配置文件

vim /etc/keepalived/keepalived.conf

! Configuration File for keepalived
global_defs {
notification_email {
1123400300@qq.com
}
notification_email_from Alexandre.Cassen@firewall.loc
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id lb01
}
vrrp_instance VI_1 {
state MASTER
interface eth1
virtual_router_id 66
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.200.166/24 dev eth0 label eth0:1
}
}

主配置文件详解

1123400300@qq.com --->邮箱随便写
smtp_server 127.0.0.1 --->邮件服务器IP
router_id lb01 --->lb表明负载均衡,不能和其余Keepalived节点相同（全局惟一）
vrrp_instance VI_1 { --->实例名字为VI_1,相同实例的备节点名字要和这个相同
state MASTER --->状态为MASTER，备节点状态须要为BACKUP
interface eth1 --->通讯（心跳）接口为eth1，此参数备节点设置和主节点相同
virtual_router_id 66 --->实例ID为66，要和备节点相同
priority 150 --->优先级为150，备节点的优先级必须比此数字低,通常为100
advert_int 1 --->通讯检查间隔时间1秒,不须要改动
auth_type PASS --->PASS认证类型，此参数备节点设置和主节点相同,用默认的就能够
auth_pass 1111 --->密码1111，此参数备节点设置和主节点相同,用默认的就能够
192.168.200.166/24 dev eth0 label eth0:1
--->VIP地址,dev绑定的意思,label别名为eth0:1,此参数备节点设置和主节点相同

打开keepalived从配置文件

! Configuration File for keepalived
global_defs {
notification_email {
1123400300@qq.com
}
notification_email_from Alexandre.Cassen@firewall.loc
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id lb02
}
vrrp_instance VI_1 {
state BACKUP
interface eth1
virtual_router_id 66
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.200.166/24 dev eth0 label eth0:1
}
}

从配置文件基本改动

router_id lb02 --->此参数和lb01 MASTER不一样
vrrp_instance VI_1 { --->lb01 MASTER相同
state BACKUP --->此参数和lb01 MASTER不一样
interface eth1 --->和lb01 MASTER相同
virtual_router_id 66 --->和lb01 MASTER相同
priority 100 --->此参数和lb01 MASTER不一样

配置文件参数详解

第1行是注释，！开头和#号开发同样，都是注释。
第2行是空行。
第3~8行是定义服务故障报警的Email地址。做用是当服务发生切换或RS节点等有故障时，发报警邮件。这几行是可选配置，notification_email指定在Keepalived发生事件时，须要发送的Email地址，能够有多个，每行一个。
第9行是指定发送邮件的发送人，即发件人地址，也是可选的配置。
第10行smtp_server指定发送邮件的smtp服务器，若是本机开启了sendmail或postfix，就可使用上面默认配置实现邮件发送，也是可选配置。
第11行smtp_connect_timeout是链接smtp的超时时间，也是可选配置。
注意：
第4~11行全部和邮件报警相关的参数都可以不配，在实际工做中会将监控的任务交给更加擅长监控报警的Nagios或Zabbix软件。
第12行是Keepalived服务器的路由标识（router_id）.在一个局域网内，这个标识（router_id）应该是惟一的。
大括号“{}”。用来分隔区块，要成对出现。若是漏写了半个大括号，Keepalived运行时，不会报错，但也不会获得预期的结果。另外，因为区块间存在多层嵌套关系，所以很容易遗漏区块结尾处的大括号，要特别注意。
第15行表示定义一个vrrp_instance实例，名字是VI_1,每一个vrrp_instance实例能够认为是Keepalived服务的一个实例或者做为一个业务服务，在Keepalived服务配置中，这样的vrrp_instance实例能够有多个。注意，存在于主节点中的vrrp_instance实例在备节点中也要存在，这样才能实现故障切换接管。
第16行state MASTER表示当前实例VI_1的角色状态，当前角色为MASTER，这个状态只能有MASTER和BACKUP两种状态，而且须要大写这些字符。其中MASTER为正式工做的状态，BACKUP为备用的状态。当MASTER所在的服务器故障或失效时，BACKUP所在的服务器会接管故障的MASTER继续提供服务。
第17行interface为网络通讯接口。为对外提供服务的网络接口，如eth0,eth1。当前主流的服务器都有2~4个网络接口，在选择服务接口时，要搞清楚了。
第18行virtual_router_id为虚拟路由ID标识，这个标识最好是一个数字，而且要在一个keepalived.conf配置中是惟一的。可是MASTER和BACKUP配置中相同实例的virtual_router_id又必须是一致的，不然将出现脑裂问题。
第19行priority为优先级，其后面的数值也是一个数字，数字越大，表示实例优先级越高。在同一个vrrp_instance实例里，MASTER的优先级配置要高于BACKUP的。若MASTER的priority值为150，那么BACKUP的priority必须小于150，通常建议间隔50以上为佳，例如：设置BACKUP的priority为100或更小的数值。
第20行advert_int为同步通知间隔。MASTER与BACKUP之间通讯检查的时间间隔，单位为秒，默认为1.
第21~24行authentication为权限认证配置。包含认证类型（auth_type）和认证密码（auth_pass）。认证类型有PASS（Simple Passwd（suggested）），AH（IPSEC（not recommended））两种，官方推荐使用的类型为PASS。验证密码为明文方式，最好长度不要超过8个字符，建议用4位数字，同一vrrp实例的MASTER与BACKUP使用相同的密码才能正常通讯。
第25 ~ 29 行virtual_ipaddress为虚拟IP地址。能够配置多个IP地址，每一个地址占一行，配置时最好明确指定子网掩码以及虚拟IP绑定的网络接口。不然，子网掩码默认是32位，绑定的接口和前面的interface参数配置的一致。注意，这里的虚拟IP就是在工做中须要和域名绑定的IP，即和配置的高可用服务监听的IP要保持一致！

单实例主备模式Keepalived配置文件对比

配置完成后，启动Keepalived服务

/etc/init.d/keepalived start

这时候发现主服务器有eth0:1而从没有,这就表明成功了

用主漂的IP进行wdinows页面测试

用从漂的IP进行wdinows页面测试

7、Keepalived高可用多实例服务搭建

原先的备配置文件(如今的主)

! Configuration File for keepalived
global_defs {
notification_email {
1123400300@qq.com
}
notification_email_from Alexandre.Cassen@firewall.loc
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id lb02
}
vrrp_instance VI_1 {
state BACKUP
interface eth1
virtual_router_id 66
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.200.166/24 dev eth0 label eth0:1
}
}
vrrp_instance VI_2 {
state MASTER
interface eth1
virtual_router_id 68
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.200.188/24 dev eth0 label eth0:2
}
}

原先的主配置文件(如今的备)

! Configuration File for keepalived
global_defs {
notification_email {
1123400300@qq.com
}
notification_email_from Alexandre.Cassen@firewall.loc
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id lb01
}
vrrp_instance VI_1 {
state MASTER
interface eth1
virtual_router_id 66
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.200.166/24 dev eth0 label eth0:1
}
}
vrrp_instance VI_2 {
state BACKUP
interface eth1
virtual_router_id 68
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.200.188/24 dev eth0 label eth0:2
}
}

多实例主测试阶段

多实例备测试阶段

8、Keepalived高可用服务器的“裂脑”问题

什么是裂脑

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

致使裂脑发生的缘由

高可用服务器对之间心跳线链路发生故障，致使没法正常通讯。

心跳线坏了（包括断了,老化）

网卡及相关驱动坏了，IP配置及冲突问题（网卡直连）。

心跳线间链接的设备故障（网卡及交换机）

仲裁的机器出问题（采用仲裁的方案）

高可用服务器上开启了iptables防火墙阻挡了心跳消息传输

高可用服务器上心跳网卡地址等信息配置不正确，致使发送心跳失败。

其余服务配置不当等缘由，如心跳方式不一样，心跳广播冲突，软件BUG等

重点提示

Keepalived配置里同一VRRP实例若是virtual_router_id两端参数配置不一致，也会致使裂脑问题发生。

解决裂脑的常见方案

同时使用串行电缆和以太网电缆链接，同时用两条心跳线路，这样一条线路坏了，另外一个仍是好的，依然能传送心跳消息。

当检测到裂脑时强行关闭一个心跳节点（这个功能需特殊设备支持，如Stonith，fence）。至关于备节点接收不到心跳消息，经过单独的线路发送关机命令关闭主节点的电源。

作好对裂脑的监控报警（如邮件及手机短信等或值班），在问题发生时人为第一时间介入仲裁，下降损失。例如，百度的监控报警短信就有上行和下行的区别。报警信息发送到管理员手机上，管理员能够经过手机回复对应数字或简单的字符串操做返回给服务器，让服务器根据指令自动处理相应故障，这样解决故障的时间更短。

固然，在实施高可用方案时，要根据业务实际需求肯定是否能容忍这样的损失。对于通常的网站常规业务，这个损失是可容忍的。

做为互联网应用服务器的高可用，特别是前端Web负载均衡器的高可用，裂脑的问题对普通业务的影响是能够忍受的，若是是数据库或者存储的业务，通常出现裂脑问题就很是严重了。所以，能够经过增长冗余心跳线路来避免裂脑问题的发生，同时增强对系统的监控，以便裂脑发生时人为快速介入解决问题。

若是开启防火墙，必定要让心跳消息经过，通常经过容许IP段的形式解决。

能够拉一条以太网网线或者串口线做为主被节点心跳线路的冗余。

开发检测程序经过监控软件（例如Nagios）检测裂脑。

生产场景检测裂脑故障的一些思路

1)简单判断的思想：只要备节点出现VIP就报警，这个报警有两种状况，一是主机宕机了备机接管了；二是主机没宕，裂脑了。无论属于哪一个状况，都进行报警，而后由人工查看判断及解决。

2）比较严谨的判断：备节点出现对应VIP，而且主节点及对应服务（若是能远程链接主节点看是否有VIP就更好了）还活着，就说明发生裂脑了。