文章目录

• 概述
• Keepalived基础HA功能演示
• • 配置Keepalived
  • keepalived-master节点的keepalived.conf文件
  • keepalived-backup节点的keepalived.conf文件
• Keepalived启动过程分析
• • Master节点
  • backup节点
• Keepalived的故障切换过程分析
• 故障恢复切换分析

---

概述

作为一个高可用集群软件，Keepalived提供了vrrp_script、notify_master、notify_backup等多个功能模块，通过这些模块也可以实现对集群资源的托管以及集群服务的监控。

Keepalived基础HA功能演示

在默认情况下，Keepalived可以实现对系统死机、网络异常及Keepalived本身进行监控。也就是说，当系统出现死机、网络出现故障或Keepalived进程异常时，Keepalived会进行主备节点的切换。

但这些还是不够的，因为集群中运行的服务也随时可能出现问题，所以，还需要对集群中运行服务的状态进行监控，当服务出现问题时也进行主备切换。作为一个优秀的高可用集群软件，Keepalived提供了一个vrrp_script模块专门用来对集群中服务资源进行监控。

---

配置Keepalived

这里我们要部署一套基于HTTPD的高可用集群系统。

---

keepalived-master节点的keepalived.conf文件

# 全局配置
global_defs {
  # 邮件通知信息
  notification_email {
　　 acassen@firewall.loc
　　 failover@firewall.loc
　　 sysadmin@firewall.loc
　 }
　 # 定义发件人
　 notification_email_from Alexandre.Cassen@firewall.loc
　 # SMTP服务器地址
　 smtp_server 192.168.200.1
　 smtp_connect_timeout 30
　 # 路由器标识，一般不用改，也可以写成每个主机自己的主机名
　 router_id LVS_DEVEL
　 # VRRP的ipv4和ipv6的广播地址，配置了VIP的网卡向这个地址广播来宣告自己的配置信息，下面是默认值
   vrrp_mcast_group4 224.0.0.18
   vrrp_mcast_group6 ff02::12
}

# 定义用于实例执行的脚本内容，比如可以在线降低优先级，用于强制切换  名称自定义
vrrp_script check_httpd {
　　script "killall -0 httpd"
　　interval 2
　　}

# 一个vrrp_instance就是定义一个虚拟路由器的，实例名称
vrrp_instance HA_1 {
   # 定义初始状态，可以是MASTER或者BACKUP
　　state MASTER
　　# 工作接口，通告选举使用哪个接口进行
　　interface eth0
　　# 虚拟路由ID，如果是一组虚拟路由就定义一个ID，如果是多组就要定义多个，而且这个虚拟
    # ID还是虚拟MAC最后一段地址的信息，取值范围0-255
　　virtual_router_id 80
　　# 使用哪个虚拟MAC地址
    use_vmac XX:XX:XX:XX:XX
    # 监控本机上的哪个网卡，网卡一旦故障则需要把VIP转移出去
    track_interface {
        eth0
        ens33
    }
   # 如果你上面定义了MASTER,这里的优先级就需要定义的比其他的高
　　priority 100
　　# 通告频率，单位为秒
　　advert_int 2
　　# 通信认证机制，这里是明文认证还有一种是加密认证
　　authentication {
　　　　auth_type PASS
　　　　auth_pass qwaszx
　　}

	# 设置虚拟VIP地址，一般就设置一个，在LVS中这个就是为LVS主机设置VIP的，这样你就不用自己手动设置了
	virtual_ipaddress {
		# IP/掩码 dev 配置在哪个网卡
        192.168.66.80/24 dev eth0 
　　}

	# 工作模式，nopreempt表示工作在非抢占模式，默认是抢占模式 preempt
    nopreempt|preempt
    # 如果是抢占默认则可以设置等多久再抢占，默认5分钟
    preempt delay 300
    # 追踪脚本，通常用于去执行上面的vrrp_script定义的脚本内容
　　track_script {
　	　check_httpd
　　}


	# 三个指令，如果主机状态变成Master|Backup|Fault之后会去执行的通知脚本，脚本要自己写
　　notify_master "/etc/keepalived/master.sh "
　　notify_backup "/etc/keepalived/backup.sh"
　　notify_fault "/etc/keepalived/fault.sh"

　　
}

---

其中，master.sh文件的内容如下。

#!/bin/bash
LOGFILE=/var/log/keepalived-mysql-state.log
echo "[Master]" >> $LOGFILE

backup.sh文件的内容如下。

#!/bin/bash
LOGFILE=/var/log/keepalived-mysql-state.log
echo "[Backup]" >> $LOGFILE

fault.sh文件的内容如下。

#!/bin/bash
LOGFILE=/var/log/keepalived-mysql-state.log
echo "[Fault]" >> $LOGFILE

这三个脚本的作用是监控Keepalived角色的切换过程，进一步理解notify参数的执行过程。

---

keepalived-backup节点的keepalived.conf文件

keepalived-backup节点上的keepalived.conf配置文件内容与keepalived-master节点上的基本相同，需要修改的地方有两个。

• 将“state MASTER”更改为“state BACKUP”。
• 将priority 100更改为一个较小的值，这里改为“priority 80”。

---

Keepalived启动过程分析

将配置好的keepalived.conf文件及master.sh、backup.sh、fault.sh三个文件一起复制到keepalived-backup备用节点对应的路径下，然后在两个节点启动http服务，最后启动Keepalived服务。

Master节点

首先在keepalived-master节点启动keepalived服务，执行如下操作。

[root@keepalived-master keepalived]# chkconfig --level 35 httpd on
[root@keepalived-master keepalived]# /etc/init.d/httpd　start
[root@keepalived-master keepalived]# /etc/init.d/keepalived　start

Keepalived正常运行后共启动了3个进程，其中一个进程是父进程，它负责监控其余两个子进程（分别是vrrp子进程和healthcheckers子进程）。然后观察keepalived-master上Keepalived的运行日志

【keepalived-master上Keepalived的启动日志】

从日志可以看出

• 在keepalived-master主节点启动后，VRRP_Script模块首先运行了check_httpd的检查，发现httpd服务运行正常，
• 然后进入Master角色，如果检查httpd服务异常，将进入Fault状态，
• 最后将虚拟IP地址添加到系统中，完成Keepalived在主节点的启动。此时在主节点通过命令“ip add”就能查看到已经添加到系统中的虚拟IP地址。

再查看/var/log/keepalived-mysql-state.log日志文件

tail -f /var/log/keepalived-mysql-state.log
[Master]

---

通过上面给出的三个脚本的内容可知，Keepalived在切换到Master角色后，执行了/etc/keepalived/master.sh这个脚本，从这里也可以看出notify_master的作用。

backup节点

接着在备用节点keepalived-backup上也启动keepalived服务，执行如下操作。

[root@keepalived-backup keepalived]# chkconfig --level 35 httpd on
[root@keepalived-backup keepalived]# /etc/init.d/httpd　start
[root@keepalived-backup keepalived]# /etc/init.d/keepalived　start

然后观察keepalived-backup上Keepalived的运行日志。

【keepalived-backup上Keepalived的启动日志】

从日志输出可以看出，

• keepalived-backup备用节点在启动Keepalived服务后，因为自身角色为Backup，所以会首先进入Backup状态，
• 接着也会运行VRRP_Script模块检查httpd服务的运行状态，如果httpd服务正常，将输出“succeeded”。

在备用节点查看/var/log/keepalived-mysql-state.log日志文件

tail -f /var/log/keepalived-mysql-state.log
[Backup]

由此可知，备用节点在切换到Backup状态后，执行了/etc/keepalived/backup.sh这个脚本。

---

Keepalived的故障切换过程分析

下面开始测试Keepalived的故障切换（failover）功能。

• 首先在keepalived-master节点关闭httpd服务，然后看看Keepalived是如何实现故障切换的。

• 在keepalived-master节点关闭httpd服务后，紧接着查看Keepalived的运行日志

【keepalived-master节点在httpd服务故障后的日志状态】

从日志可以看出，

• 在keepalived-master节点的httpd服务被关闭后，VRRP_Script模块很快就能检测到
• 然后进入Fault状态，最后将虚拟IP地址从eth0上移除。

紧接着查看keepalived-backup节点上Keepalived的运行日志

从日志可以看出，

• 在keepalived-master节点出现故障后，备用节点keepalived-backup立刻检测到，此时备用机变为Master角色，并且接管了keepalived-master主机的虚拟IP资源，
• 最后将虚拟IP绑定在eth0设备上。

Keepalived在发生故障时进行切换的速度是非常快的，只有几秒钟的时间，如果在切换过程中，持续ping虚拟IP地址，几乎没有延时等待时间。

---

故障恢复切换分析

由于设置了集群中的主、备节点角色，因此，主节点在恢复正常后会自动再次从备用节点夺取集群资源，这是常见高可用集群系统的运行原理。

下面继续演示故障恢复后Keepalived的切换过程。

首先在keepalived-master节点上启动httpd服务。

[root@keepalived-master ～]# /etc/init.d/httpd　start

紧接着查看Keepalived运行日志

【keepalived-master节点httpd服务恢复后Keepalived的运行日志】

从日志可知，

• keepalived-master节点通过vrrp_script模块检测到httpd服务已经恢复正常，
• 然后自动切换到Master状态，同时也夺回了集群资源，将虚拟IP地址再次绑定在eth0设备上。

继续查看keepalived-backup节点Keepalived的运行日志信息

【keepalived-backup节点在keepalived-master节点故障恢复后的日志信息】

可以看出，

• keepalived-backup节点在发现主节点恢复正常后，释放了集群资源，重新进入了Backup状态，于是整个集群系统恢复了正常的主、备运行状态。

Keepalived的整个运行过程和切换过程，看似合理，但事实上并非如此。在一个高负载、高并发、追求稳定的业务系统中，执行一次主、备切换对业务系统的影响很大，因此，不到万不得已，尽量不要进行主、备角色的切换。

也就是说，在主节点发生故障后，必须要切换到备用节点，而在主节点恢复后，不希望再次切回主节点，直到备用节点发生故障时才进行切换，这就是不抢占功能，可以通过Keepalived的“nopreempt”选项来实现。