Keepalived高可用集群

Keepalived高可用集群

 

Keepalived介绍

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

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

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

 

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反向代理这样的服务器。

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

 

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数据包使用了加密协议进行了加密。

 

VRRP通信原理

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

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

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

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

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

 

Keepalived服务的工作原理

Keepalived高可用之间是通过VRRP进行通信的，VRRP是通过竞选机制来确定主备的，主的优先级高于备，因此，工作时主会优先获得所有的资源，备节点处于等待状态，当主挂了的时候，备节点就会接管主节点的资源，然后顶替主节点对外提供服务。

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

 

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软件

主从Nginx负载均衡都需要安装Keepalived软件

 

启动Keepalived服务并检查

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

默认情况会启动三个VIP地址,这里从Nginx就不测试了

 

Keepalived主配置文件

 

1. ! Configuration File for keepalived
3. global_defs {
4. notification_email {
5. 1123400300@qq.com
6. }
7. notification_email_from Alexandre.Cassen@firewall.loc
8. smtp_server 127.0.0.1
9. smtp_connect_timeout 30
10. router_id lb01
11. }
13. vrrp_instance VI_1 {
14. state MASTER
15. interface eth1
16. virtual_router_id 66
17. priority 150
18. advert_int 1
19. authentication {
20. auth_type PASS
21. auth_pass 1111
22. }
23. virtual_ipaddress {
24. 192.168.200.166/24 dev eth0 label eth0:1
25. }
26. }

 

主配置文件基本改动

 

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

 

Keepalived从配置文件

 

1. ! Configuration File for keepalived
3. global_defs {
4. notification_email {
5. 1123400300@qq.com
6. }
7. notification_email_from Alexandre.Cassen@firewall.loc
8. smtp_server 127.0.0.1
9. smtp_connect_timeout 30
10. router_id lb02
11. }
13. vrrp_instance VI_1 {
14. state BACKUP
15. interface eth1
16. virtual_router_id 66
17. priority 100
18. advert_int 1
19. authentication {
20. auth_type PASS
21. auth_pass 1111
22. }
23. virtual_ipaddress {
24. 192.168.200.166/24 dev eth0 label eth0:1
25. }
26. }

 

从配置文件基本改动

 

1. router_id lb02 --->此参数和lb01 MASTER不同
3. vrrp_instance VI_1 { --->lb01 MASTER相同
5. state BACKUP --->此参数和lb01 MASTER不同
7. interface eth1 --->和lb01 MASTER相同
9. virtual_router_id 66 --->和lb01 MASTER相同
11. priority 100 --->此参数和lb01 MASTER不同

 

配置文件参数详解

 

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

 

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

 

配置完成后，启动Keepalived服务

/etc/init.d/keepalived start

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

---

 

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

192.168.200.166

---

---

 

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

192.168.200.166

---

---

---

 

Keepalived高可用多实例服务搭建

多实例就是把原先的主变成备,原先的备变成主,配置详解请看上文

 

原先的备配置文件(现在的主)

 

1. ! Configuration File for keepalived
3. global_defs {
4. notification_email {
5. 1123400300@qq.com
6. }
7. notification_email_from Alexandre.Cassen@firewall.loc
8. smtp_server 127.0.0.1
9. smtp_connect_timeout 30
10. router_id lb02
11. }
13. vrrp_instance VI_1 {
14. state BACKUP
15. interface eth1
16. virtual_router_id 66
17. priority 100
18. advert_int 1
19. authentication {
20. auth_type PASS
21. auth_pass 1111
22. }
23. virtual_ipaddress {
24. 192.168.200.166/24 dev eth0 label eth0:1
25. }
26. }
27. vrrp_instance VI_2 {
28. state MASTER
29. interface eth1
30. virtual_router_id 68
31. priority 150
32. advert_int 1
33. authentication {
34. auth_type PASS
35. auth_pass 1111
36. }
37. virtual_ipaddress {
38. 192.168.200.188/24 dev eth0 label eth0:2
39. }
40. }

 

原先的主配置文件(现在的备)

 

1. ! Configuration File for keepalived
3. global_defs {
4. notification_email {
5. 1123400300@qq.com
6. }
7. notification_email_from Alexandre.Cassen@firewall.loc
8. smtp_server 127.0.0.1
9. smtp_connect_timeout 30
10. router_id lb01
11. }
13. vrrp_instance VI_1 {
14. state MASTER
15. interface eth1
16. virtual_router_id 66
17. priority 150
18. advert_int 1
19. authentication {
20. auth_type PASS
21. auth_pass 1111
22. }
23. virtual_ipaddress {
24. 192.168.200.166/24 dev eth0 label eth0:1
25. }
26. }
27. vrrp_instance VI_2 {
28. state BACKUP
29. interface eth1
30. virtual_router_id 68
31. priority 100
32. advert_int 1
33. authentication {
34. auth_type PASS
35. auth_pass 1111
36. }
37. virtual_ipaddress {
38. 192.168.200.188/24 dev eth0 label eth0:2
39. }
40. }

 

多实例主测试阶段

---

---

 

多实例备测试阶段

---

---

---

 

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

 

什么是裂脑

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

 

导致裂脑发生的原因

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

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

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

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

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

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

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

其他服务配置不当等原因，如心跳方式不同，心跳广播冲突，软件BUG等

 

重点提示

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

 

解决裂脑的常见方案

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

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

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

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

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

如果开启防火墙，一定要让心跳消息通过，一般通过允许IP段的形式解决。

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

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

 

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

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

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

来源：oschina

链接：https://my.oschina.net/u/4370598/blog/3757463