一文详解Keepalived
1. 介绍
**单点故障:**单点故障是指一旦某一点出现故障就会导致整个系统架构的不可用。
Keepalived是Linux下一个轻量级别的高可用解决方案。高可用(High Avalilability,HA),其实两种不同的含义:广义来讲,是指整个系统的高可用行,狭义的来讲就是之主机的冗余和接管,
它与HeartBeat、RoseHA 实现相同类似的功能,都可以实现服务或者网络的高可用,但是又有差别,HeartBeat是一个专业的、功能完善的高可用软件,它提供了HA 软件所需的基本功能,比如:心跳检测、资源接管,检测集群中的服务,在集群节点转移共享IP地址的所有者等等。HeartBeat功能强大,但是部署和使用相对比较麻烦,与HeartBeat相比,Keepalived主要是通过虚拟路由冗余来实现高可用功能,虽然它没有HeartBeat功能强大,但是Keepalived部署和使用非常的简单,所有配置只需要一个配置文件即可以完成,
Keepalived是系统高可用最简单的方式,为以后理解系统架构打下基础。
2. 网络基础知识(IP网络层、TCP传输层、HTTP应用层)
- 首先主机A将自己的IP地址和路由表里的子网掩码作“与运算”; (route -a netstat -n)
- 如果找到,则将包发给下一跳(最长匹配) (无类域间路由(CIDR)编址方案、ABCD分类IP)
- 如果没找到,则将包发给默认路由。
- 继续1、2,直到知道HostB
- 发送ARP包,查找Mail Server IP -> MAC
- 如果发生错误,回传ICMP数据包:ping、tracert
3. VRRP简介
VRRP即虚拟路由冗余协议(Virtual Router Redundancy Protocol),它是为了避免路由器出现单点故障的一种容错协议。
如图1所示,我们把多个运行着VRRP协议的路由器抽象成一个虚拟路由器(从外边来看,就像只有一个真实的路由器在工作),组成虚拟路由器的一组路由器会有一个会成为Master路由器,其余的会成为Backup路由器。
正常情况下,会由Master完成该虚拟路由器的工作。Master一旦出现故障,从Backup中选出一个成为Master继续工作,从而避免路由器单点问题。
在详细介绍VRRP协议之前,先弄清楚几个概念。
3.1 相关术语
3.1.1 VIP
VIP(Virtual IP)即虚拟IP,是一个不与特定计算机或网络接口卡相连的IP地址。
3.1.2 VRRP路由器
运行VRRP协议的路由器(或设备)。它可能属于一个或多个虚拟路由器。
3.1.3 虚拟路由器
由一组VRRP路由器组成,抽象成一个虚拟的路由器。它拥有一个虚拟路由器标识符(VRID)和一个VIP。
3.1.4 虚拟MAC地址
即虚拟路由器根据VRID生成的MAC地址。
一个虚拟路由器拥有一个虚拟MAC地址,格式为:00-00-5E-00-01-{VRID}。
当虚拟路由器回应ARP请求时,使用虚拟MAC地址,而不是接口的真实MAC地址。
3.1.5 IP地址拥有者(IP Address Owner)
如果一个VRRP路由器将VIP作为 真实的接口地址,则该设备是IP地址拥有者。
当这台设备正常工作时,它会响应目的地址是VIP的报文,如ping、TCP连接等。
3.1.6 优先级(Priority)
用来标识虚拟路由器中各成员路由器的优先级。
虚拟路由器根据优先级选举出Master和Backup。
3.2 VRRP是如何工作的
当路由器配置了VRRP(VRID、VIP、优先级等信息)后,它就成了一台VRRP路由器,即组成某个虚拟路由器的一个成员路由器。
3.2.1 VRRP的工作流程
- Master选举:从VRRP组中选举一个Master,其余为Backup
- 各设备协调工作:Master负责虚拟路由器的工作,Backup负责监听Master的状态
- 故障转移:Master出现故障,回到步骤1
3.2.2 VRRP协议定义了3种状态机:
分别为初始状态(Initialize)、活动状态(Master)、备份状态(Backup)。
3种状态相互之间的转换:
- 初始状态(Initialize)
- 为VRRP不可用状态,在此状态下设备不会对VRRP报文做任何处理。通常刚配置VRRP时或设备检测到故障时会进入该状态。
- 收到接口startup(启动)的状态,如果设备的优先级为255**(表示该设备为虚拟路由器IP地址拥有者)**,则直接成为Master设备。如果设备的优先级小于255,则会先切换到Backup状态。
- 活动状态(Master)
处于该状态下的设备为Master设备,Master设备会做如下工作:
- 定时发送VRRP通告报文(时间间隔为Advertisement_Interval)
- 以虚拟MAC地址相应对虚拟IP地址的ARP请求
- 转发目的MAC地址为虚拟MAC地址的IP报文
- 抢占模式下,如果收到比自己优先级大的VRRP报文,或者跟自己优先级相等,且本地接口IP地址小于源端接口IP地址时,则转变为Backup状态。
- 收到Shutdown(关闭)消息后,则立即转变为Initialize状态。
- 备份状态(Backup)
处于该状态下的设备接收Master发送的VRRP通告报文,判断Master是否正常。如果一定时间间隔没有收到VRRP通告报文,即Master_Down_Interval(Master_Down_Interval = 3* Advertisement_Interval + Skew_time)超时,则判断为Master故障。
- 接收Master发送的VRRP通告报文,判断Master是否正常
- 对虚拟IP的ARP请求不做响应
- 丢弃目的MAC地址为虚拟路由器MAC地址的IP报文
- 丢弃目的IP地址为虚拟路由器IP地址的IP报文
- 如果收到优先级比自己高,或与自己相等的VRRP报文,则重置Master_Down_Interval定时器(不进一步比较IP地址)。
- 如果收到优先级比自己小的VPPR报文,且优先级为0时,(表示原Master设备声明不参与该VRRP组了),定时器时间设置为Skew_time(偏移时间,Skew_time= (256 - priority)/256)。
- 如果收到优先级比自己小的VPPR报文,且优先级不为0时,丢弃该报文,立即转变为Master状态。
- Master_Down_Interval定时器超时,立即转变为Master状态。
- 收到Shutdown(关闭)消息后,则立即转变为Initialize状态。
3.2.3 Master选举
VRRP根据优先级来确定虚拟路由器中每台设备的角色,Master设备或Backup设备。优先级越高,则越有可能成为Master设备。
Master选举过程如下:
- 初始创建的VRRP设备都工作在Initialize状态,当VRRP设备在收到VRRP接口Startup的消息后,如果此设备的优先级等于255(也就是所配置的虚拟路由器IP地址是本设备VRRP接口的真实IP地址),将会直接切换至Master状态,并且无需进行下面的Master选举。否则,会先切换到Backup状态,待Master_Down_Interval定时器超时后再切换至Master状态。(开始的时候并没有Master设备,则这个Master_Down_Interval定时器一定会超时)
- 首先切换至Master状态的VRRP设备通过VRRP通告报文的交互获知虚拟设备中其他成员的优先级,然后根据以下规则进行Master的选举。
1).如果收到的VRRP报文中的优先级高于或等于自己的优先级,则当前Backup设备保持Backup状态。
2).如果VRRP报文中Master设备的优先级低于自己的优先级,当采用抢占方式下(缺省为抢占方式),则当前Backup设备将切换至Master状态;当采用非抢占方式时,当前Backup设备仍保持Backup状态。 - 当有多个VRRP设备同时切换至Master状态,通过VRRP通告报文的交互进行协商后,优先级较低的VRRP设备将切换至Backup状态,优先级最高的VRRP设备成为最终的Master设备;优先级相同时,再根据VRRP设备上VRRP备份组所在接口主IP地址大小进行比较,IP地址较大的成为Master设备。
3.2.4 Master与Backup协调工作
Master设备会周期性的发送VRRP通告报文,在VRRP备份组中公布其配置信息(优先级等)和工作状态。Backup设备通过接收到Master设备发来的VRRP报文的情况来判断Master设备是否工作正常。
- 当Master设备主动放弃Master地位(如Master设备退出备份组)时,会发送优先级为0的VRRP通告报文,使Backup设备快速切换成Master设备(当有多台Backup设备时也要进行Master选举),而不用等到Master_Dwon_Interval定时器超时。这个切换的时间称为Skew_time,计算方式为:(256 -Backup设备的优先级)/256,单位为秒。
- 当Master设备发生网络故障而不能发送VRRP通告报文的时候,Backup设备并不能立即知道其工作状况,要等到Master_Down_Interval定时器超时后,才会认为Master设备无法正常工作,从而将状态切换为Master(同样,当有多台Backup设备时也要进行Master选举)。
在性能不稳定的网络中,网络堵塞可能导致Backup设备在Master_Down_Interval定时器超时后仍没有收到Master设备的报文后,使得Backup设备主动切换为Master。如果此时原Master设备的报文又到达了,新Master设备将再次切换回Backup。如此会出现VRRP设备组成员状态频繁切换的现象。为缓解这种现象,可以配置抢占时延,使得Backup设备在等待了Master_Down_Interval定时器后再等待抢占时延时间。
4. Keepalived的体系结构
- Scheduler I/O Multiplexer 是一个I/O复用分发调度器,它负载安排Keepalived所有内部的任务请求,
- Memory Mngt 是一个内存管理机制,这个框架提供了访问内存的一些通用方法
- Control Plane 是keepalived的控制版面,可以实现对配置文件编译和解析
- Core componets 这部分主要保护呢了5个部分
-
**Watchdog:**是计算机可靠领域中极为简单又非常有效的检测工具,Keepalived正是通过它监控Checkers和VRRP进程
-
Checkers: 这是Keepalived最基础的功能,也是最主要的功能,可以实现对服务器运行状态检测和故障隔离。
-
VRRP Stack: 这时keepalived后来引用VRRP功能,可以实现HA集群中失败切换功能。
-
IPVS wrapper: 这个是IPVS功能的一个实现,IPVS warrper模块将可以设置好的IPVS规则发送的内核空间并且提供给IPVS模块,最终实现IPVS模块的负载功能。
-
**Netlink Reflector:**用来实现高可用集群Failover时虚拟IP(VIP)的设置和切换 ,
-
IPVS:内核空间
-
NETLINK:内核空间
-
5. Keepalived安装及配置
5.1 安装指导
# 编译安装
$ yum install -y openssl-devel
$ cd /data/software
$ wget http://www.keepalived.org/software/keepalived-1.3.5.tar.gz
$ tar -zvxf keepalived-1.3.5.tar.gz
$ cd keepalived-1.3.5
$ ./configure --prefix=/usr/local/keepalived
$ make && make install
# 拷贝执行文件
cp /usr/local/keepalived/sbin/keepalived /usr/sbin/
# 将初始化脚本拷贝到系统初始化目录下
$ cp /data/software/keepalived-1.3.5/keepalived/etc/init.d/keepalived /etc/rc.d/init.d/
# 将keepalived配置文件拷贝到etc下
$ cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
# 创建keepalived文件夹
$ mkdir /etc/keepalived/
# 将keepalived配置文件拷贝到etc下
$ cp /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/
# 添加keepalived到开机启动
$ chkconfig --add keepalived
$ chkconfig keepalived on
$ echo "/etc/init.d/keepalived start" >> /etc/rc.local
# 启动、停止、重启、查看启动情况
$ service keepalived start #启动 sys
$ service keepalived stop #停止
$ service keepalived restart #重启
$ ps -aux |grep keepalived #查看启动情况
5.2 配置文件
Keepalived的所有配置都在一个配置文件keepalived.conf里面,主要分为三类:
- 全局配置
- VRRPD配置
- LVS 配置
配置文件是以配置块的形式存在,每个配置块都在一个闭合的{}范围内,所以编辑的时候需要注意大括号的闭合问题。#和!开头都是注释。
全局配置
全局配置是对整个 Keepalived 生效的配置,一个典型的配置如下:
global_defs {
notification_email { #设置 keepalived 在发生事件(比如切换)的时候,需要发送到的email地址,可以设置多个,每行一个。
acassen@firewall.loc
failover@firewall.loc
sysadmin@firewall.loc
}
notification_email_from Alexandre.Cassen@firewall.loc #设置通知邮件发送来自于哪里,如果本地开启了sendmail的话,可以使用上面的默认值。
smtp_server 192.168.200.1 #指定发送邮件的smtp服务器。
smtp_connect_timeout 30 #设置smtp连接超时时间,单位为秒。
router_id LVS_DEVEL #是运行keepalived的一个表示,多个集群设置不同。
}
VRRPD配置
VRRPD 的配置是 Keepalived 比较重要的配置,主要分为两个部分 VRRP 同步组和 VRRP实例,也就是想要使用 VRRP 进行高可用选举,那么就一定需要配置一个VRRP实例,在实例中来定义 VIP、服务器角色等。
VRRP Sync Groups
不使用Sync Group的话,如果机器(或者说router)有两个网段,一个内网一个外网,每个网段开启一个VRRP实例,假设VRRP配置为检查内网,那么当外网出现问题时,VRRPD认为自己仍然健康,那么不会发生Master和Backup的切换,从而导致了问题。Sync group就是为了解决这个问题,可以把两个实例都放进一个Sync Group,这样的话,group里面任何一个实例出现问题都会发生切换。
vrrp_sync_group VG_1{ #监控多个网段的实例
group {
VI_1 #实例名
VI_2
......
}
notify_master /path/xx.sh #指定当切换到master时,执行的脚本
netify_backup /path/xx.sh #指定当切换到backup时,执行的脚本
notify_fault "path/xx.sh VG_1" #故障时执行的脚本
notify /path/xx.sh
smtp_alert #使用global_defs中提供的邮件地址和smtp服务器发送邮件通知
}
VRRP实例(instance)配置
VRRP实例就表示在上面开启了VRRP协议,这个实例说明了VRRP的一些特征,比如主从,VRID等,可以在每个interface上开启一个实例。
vrrp_instance VI_1 {
state MASTER #指定实例初始状态,实际的MASTER和BACKUP是选举决定的。
interface eth0 #指定实例绑定的网卡
virtual_router_id 51 #设置VRID标记,多个集群不能重复(0..255)
priority 100 #设置优先级,优先级高的会被竞选为Master,Master要高于BACKUP至少50
advert_int 1 #检查的时间间隔,默认1s
nopreempt #设置为不抢占,说明:这个配置只能在BACKUP主机上面设置
preempt_delay #抢占延迟,默认5分钟
debug #debug级别
authentication { #设置认证
auth_type PASS #认证方式,支持PASS和AH,官方建议使用PASS
auth_pass 1111 #认证的密码
}
virtual_ipaddress { #设置VIP,可以设置多个,用于切换时的地址绑定。格式:#<IPADDR>/<MASK> brd <IPADDR> dev <STRING> scope <SCOPT> label <LABE
192.168.200.16/24 dev eth0 label eth0:1
192.168.200.17/24 dev eth1 label eth1:1
192.168.200.18
}
}
LVS 配置
虚拟服务器virtual_server定义块 ,虚拟服务器定义是keepalived框架最重要的项目了,是keepalived.conf必不可少的部分。 该部分是用来管理LVS的,是实现keepalive和LVS相结合的模块。ipvsadm命令可以实现的管理在这里都可以通过参数配置实现,注意:real_server是被包含在viyual_server模块中的,是子模块。
virtual_server 192.168.202.200 23 { //VIP地址,要和vrrp_instance模块中的virtual_ipaddress地址一致
delay_loop 6 #健康检查时间间隔
lb_algo rr #lvs调度算法rr|wrr|lc|wlc|lblc|sh|dh
lb_kind DR #负载均衡转发规则NAT|DR|RUN
persistence_timeout 5 #会话保持时间
protocol TCP #使用的协议
persistence_granularity <NETMASK> #lvs会话保持粒度
virtualhost <string> #检查的web服务器的虚拟主机(host:头)
sorry_server<IPADDR> <port> #备用机,所有realserver失效后启用
real_server 192.168.200.5 23 { //RS的真实IP地址
weight 1 #默认为1,0为失效
inhibit_on_failure #在服务器健康检查失效时,将其设为0,而不是直接从ipvs中删除
notify_up <string> | <quoted-string> #在检测到server up后执行脚本
notify_down <string> | <quoted-string> #在检测到server down后执行脚本
TCP_CHECK { //常用
connect_timeout 3 #连接超时时间
nb_get_retry 3 #重连次数
delay_before_retry 3 #重连间隔时间
connect_port 23 #健康检查的端口的端口
bindto <ip>
}
HTTP_GET | SSL_GET{ //不常用
url{ #检查url,可以指定多个
path /
digest <string> #检查后的摘要信息
status_code 200 #检查的返回状态码
}
connect_port <port>
bindto <IPADD>
connect_timeout 5
nb_get_retry 3
delay_before_retry 2
}
SMTP_CHECK{ //不常用
host{
connect_ip <IP ADDRESS>
connect_port <port> #默认检查25端口
bindto <IP ADDRESS>
}
connect_timeout 5
retry 3
delay_before_retry 2
helo_name <string> | <quoted-string> #smtp helo请求命令参数,可选
}
MISC_CHECK{ //不常用
misc_path <string> | <quoted-string> #外部脚本路径
misc_timeout #脚本执行超时时间
misc_dynamic #如设置该项,则退出状态码会用来动态调整服务器的权重,返回0 正常,不修改;返回1,
检查失败,权重改为0;返回2-255,正常,权重设置为:返回状态码-2
}
}
6. Keepalived案例分析
172.16.60.205 作为web-master主节点, 172.16.60.206 作为web-slave从节点, 两节点上都部署nginx。现在在两节点上部署keepalived,只做节点故障时vip转移功能, 不做负载均衡功能。VIP为: 172.16.60.129。
1) 主从两节点部署nginx,访问内容一致
yum安装的nginx, 启动命令: /etc/init.d/nginx start
http://172.16.60.205/ 和 http://172.16.60.205/ 均可以正常访问.
2) 主从两节点安装keepalived (两个节点都要安装)
3) keepalived配置
==========web-master 主节点的配置==========
$ vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
router_id LVS_Master
}
vrrp_instance VI_1 {
state MASTER #指定instance初始状态,实际根据优先级决定.backup节点不一样
interface eth0 #虚拟IP所在网
virtual_router_id 51 #VRID,相同VRID为一个组,决定多播MAC地址
priority 100 #优先级,另一台改为90.backup节点不一样
advert_int 1 #检查间隔
authentication {
auth_type PASS #认证方式,可以是pass或ha
auth_pass 1111 #认证密码
}
virtual_ipaddress {
172.16.60.129 #VIP地址
}
}
==========web-slave 从节点的配置==========
$ vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
router_id LVS_Backup
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
172.16.60.129
}
}
4) 分别启动主从节点的keepalived服务
启动主从节点keepalived服务
$ /etc/init.d/keepalived start
Starting keepalived: [ OK ]
查看vip资源情况 (默认vip是在主节点上的)
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:50:56:88:43:f8 brd ff:ff:ff:ff:ff:ff
inet 172.16.60.205/24 brd 172.16.60.255 scope global eth0
inet 172.16.60.129/32 scope global eth0
inet6 fe80::250:56ff:fe88:43f8/64 scope link
valid_lft forever preferred_lft forever
从节点没有vip资源
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:50:56:ac:50:9b brd ff:ff:ff:ff:ff:ff
inet 172.16.60.206/24 brd 172.16.60.255 scope global eth0
inet6 fe80::250:56ff:feac:509b/64 scope link
valid_lft forever preferred_lft forever
5) keepalived 实现故障转移 (转移vip资源)
假设主节点宕机或keepalived服务挂掉, 则vip资源就会自动转移到从节点
$ /etc/init.d/keepalived stop
Stopping keepalived: [ OK ]
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:50:56:88:43:f8 brd ff:ff:ff:ff:ff:ff
inet 172.16.60.205/24 brd 172.16.60.255 scope global eth0
inet6 fe80::250:56ff:fe88:43f8/64 scope link
valid_lft forever preferred_lft forever
则从节点这边就会接管 VIP
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:50:56:ac:50:9b brd ff:ff:ff:ff:ff:ff
inet 172.16.60.206/24 brd 172.16.60.255 scope global eth0
inet 172.16.60.129/32 scope global eth0
inet6 fe80::250:56ff:feac:509b/64 scope link
valid_lft forever preferred_lft forever
接着再重启主节点的keepalived服务, 即主节点故障恢复后, 就会重新抢回vip (根据配置里的优先级决定的)
[root@web-master keepalived]# /etc/init.d/keepalived start
Starting keepalived: [ OK ]
[root@web-master keepalived]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:50:56:88:43:f8 brd ff:ff:ff:ff:ff:ff
inet 172.16.60.205/24 brd 172.16.60.255 scope global eth0
inet 172.16.60.129/32 scope global eth0
inet6 fe80::250:56ff:fe88:43f8/64 scope link
valid_lft forever preferred_lft forever
这时候, 从节点的vip就消失了
[root@web-slave keepalived]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:50:56:ac:50:9b brd ff:ff:ff:ff:ff:ff
inet 172.16.60.206/24 brd 172.16.60.255 scope global eth0
inet6 fe80::250:56ff:feac:509b/64 scope link
valid_lft forever preferred_lft forever
以上操作, keepalived实现了两台机器的vip的故障转移功能, 即实现了双机热备, 避免了单点故障.
7. Keepalived常见问题解析
7.1 脑裂
脑裂(split-brain):指在一个高可用(HA)系统中,当联系着的两个节点断开联系时,本来为一个整体的系统,分裂为两个独立节点,这时两个节点开始争抢共享资源,结果会导致系统混乱,数据损坏。 对于无状态服务的HA,无所谓脑裂不脑裂;但对有状态服务(比如MySQL)的HA,必须要严格防止脑裂。
对付HA系统“裂脑”的对策,目前达成共识的的大概有以下几条:
1)添加冗余的心跳线,例如:双线条线(心跳线也HA),尽量减少“裂脑”发生几率;
2)启用磁盘锁。正在服务一方锁住共享磁盘,“裂脑”发生时,让对方完全“抢不走”共享磁盘资源。但使用锁磁盘也会有一个不小的问题,如果占用共享盘的一方不主动“解锁”,另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃,就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了“智能”锁。即:正在服务的一方只在发现心跳线全部断开(察觉不到对端)时才启用磁盘锁,平时就不上锁了。
3)设置仲裁机制。例如设置参考IP(如网关IP),当心跳线完全断开时,2个节点都各自ping一下参考IP,不通则表明断点就出在本端。不仅“心跳”、还兼对外“服务”的本端网络链路断了,即使启动(或继续)应用服务也没有用了,那就主动放弃竞争。
7.2 永远浪费一台服务器
两个VIP,其中一个坏掉,则使用另外一个。
7.3 仅当Keepalived故障时生效,不能监控服务
**解决问题:**编写脚本,判断本机服务是否正常,如果发现服务不正常,重启之。等待N秒再次校验,仍然失败则不再尝试,关闭Keepalived,其他主机此时会接管VIP。
crond crontab (0 * 23 * 1/1) 守护程序(fork 1.) watchdog watchdog watchdog