在构建高可用的网络服务架构时,确保服务的连续性和稳定性是至关重要的，任何单点故障都可能导致业务中断，造成不可估量的损失，为了解决这一问题，业界普遍采用冗余备份和故障自动切换的方案，Keepalived正是实现这一目标的核心工具之一，它基于VRRP（虚拟路由冗余协议）协议，能够为服务器集群提供一个高可用的虚拟IP（VIP），并在主服务器发生故障时，将虚拟IP自动漂移到备用服务器上，从而实现服务的不间断运行，本文将以经典的CentOS 6.5系统为例，深入探讨Keepalived的工作原理、安装配置及其实际应用，尽管CentOS 6.5已进入生命周期末期，但其上承载的配置逻辑和原理对于理解Keepalived依然具有极高的学习价值。
Keepalived核心原理剖析
要理解Keepalived,首先必须掌握其三大核心功能模块，它们协同工作，构成了强大的高可用性与负载均衡能力。
VRRP Stack（VRRP堆栈）：这是Keepalived的基础，VRRP协议旨在解决局域网中默认网关单点故障的问题，在Keepalived中，它被扩展用于服务的高可用，多台服务器可以组成一个VRRP组，共同对外提供一个虚拟IP（VIP），组内有一台主服务器和多台备用服务器，主服务器会定期向备用服务器发送心跳报文（通告），如果备用服务器在设定时间内未收到主服务器的心跳，就认为主服务器宕机，并根据优先级选举出新的主服务器，接管VIP，这个过程对客户端是透明的，客户端始终通过VIP访问服务。
Checkers（健康检查）：这是Keepalived实现智能故障切换的关键，它不仅仅检查服务器本身是否存活（通过VRRP心跳），更重要的是能检查服务器上运行的具体服务（如Nginx、MySQL、PHP-FPM等）是否正常工作，管理员可以配置多种检查方式，例如TCP端口检查、HTTP GET检查、脚本检查等，如果Checkers检测到某个服务异常，Keepalived可以主动降低本服务器的优先级，从而触发一次平滑的VIP切换，即使服务器本身还在线，这确保了只有真正能提供服务的节点才持有VIP。
IPVS Wrapper（IPVS包装器）：这个模块与Linux内核的IPVS（IP Virtual Server）紧密集成，当Keepalived与IPVS配合使用时，它不仅能实现高可用，还能构建一个高性能的负载均衡集群，Keepalived负责管理IPVS的规则，并根据后端真实服务器的健康状态（由Checkers监控）动态地添加或移除节点，这种架构常用于构建四层（TCP/UDP）负载均衡器。
下表小编总结了这三个核心组件的功能：
| 组件名称 | 主要功能 | 在高可用架构中的角色 |
|---|---|---|
| VRRP Stack | 基于VRRP协议，实现VIP的故障转移 | 提供统一的访问入口，并在节点故障时自动切换 |
| Checkers | 对服务或应用进行多层健康检查 | 实现精细化的故障检测，确保服务可用性，而不仅仅是节点存活 |
| IPVS Wrapper | 管理内核IPVS规则，实现负载均衡 | 在高可用的基础上，扩展出流量分发能力，构建LVS集群 |
在CentOS 6.5上安装Keepalived
由于CentOS 6.5的官方源已停止维护，直接使用yum install会失败，我们需要将其源地址指向CentOS的归档仓库。
修改yum源配置文件：
sed -i "s/mirrorlist/#mirrorlist/g" /etc/yum.repos.d/CentOS-Base.repo sed -i "s|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g" /etc/yum.repos.d/CentOS-Base.repo
修改完成后,清理并重建缓存：
yum clean all yum makecache
就可以顺利安装Keepalived了：
yum install keepalived -y
安装完成后,其主配置文件位于/etc/keepalived/keepalived.conf。
配置高可用实例：主备模式
我们以最常见的主备模式为例,配置一个基于Nginx服务的高可用集群，假设有两台服务器：
- 主节点（MASTER）：IP地址为
168.1.10 - 备节点（BACKUP）：IP地址为
168.1.11 - 虚拟IP（VIP）：
168.1.100
主节点（192.168.1.10）配置
编辑/etc/keepalived/keepalived.conf如下：
! Configuration File for keepalived
global_defs {
router_id LVS_DEVEL_01 # 节点标识，需唯一
}
vrrp_script chk_nginx {
script "/usr/local/bin/check_nginx.sh" # 检查Nginx状态的脚本路径
interval 2 # 每2秒检查一次
weight -20 # 如果检查失败，优先级降低20
}
vrrp_instance VI_1 {
state MASTER # 状态为主节点
interface eth0 # 网卡名称，根据实际情况修改
virtual_router_id 51 # 虚拟路由ID，主备必须一致
priority 100 # 优先级，主节点应高于备节点
advert_int 1 # 心跳间隔，单位为秒
authentication {
auth_type PASS
auth_pass 1111 # 认证密码，主备必须一致
}
virtual_ipaddress {
192.168.1.100 # 虚拟IP地址
}
track_script {
chk_nginx # 调用上面定义的检查脚本
}
} 需要创建健康检查脚本/usr/local/bin/check_nginx.sh：
#!/bin/bash
A=`ps -C nginx --no-header | wc -l`
if [ $A -eq 0 ]; then
# 如果Nginx进程数为0，尝试重启
/usr/local/nginx/sbin/nginx
sleep 3
if [ `ps -C nginx --no-header | wc -l` -eq 0 ]; then
# 重启失败，则退出脚本，Keepalived会降低优先级
exit 1
else
exit 0
fi
else
exit 0
fi 赋予脚本执行权限：chmod +x /usr/local/bin/check_nginx.sh。
备节点（192.168.1.11）配置
备节点的配置与主节点高度相似,只需修改state和priority即可：
! Configuration File for keepalived
global_defs {
router_id LVS_DEVEL_02 # 修改节点标识
}
vrrp_script chk_nginx {
script "/usr/local/bin/check_nginx.sh"
interval 2
weight -20
}
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 {
192.168.1.100 # 与主节点保持一致
}
track_script {
chk_nginx
}
} 备节点同样需要配置并赋予check_nginx.sh脚本执行权限。
启动服务与状态验证
在两台服务器上分别启动Keepalived并设置开机自启：
service keepalived start chkconfig keepalived on
在主节点上,使用ip addr命令查看网卡信息，可以看到eth0网卡已经绑定了VIP 168.1.100。
模拟故障：在主节点上停止Keepalived服务或Nginx服务。
service keepalived stop # 或者 service nginx stop
稍等片刻后,再到备节点上执行ip addr命令，会发现VIP已经成功漂移到了备节点上，通过查看/var/log/messages日志，可以详细观察到VRRP状态切换的整个过程，至此，一个简单而强大的高可用服务就搭建完成了。
相关问答FAQs
Q1: Keepalived和Heartbeat有什么区别？我应该选择哪个？
A: Keepalived和Heartbeat都是实现高可用的经典软件，但它们的设计哲学和侧重点不同。
- 协议与核心：Keepalived基于VRRP协议，专为IP故障切换设计，配置相对简单直接，尤其适合与LVS、Nginx等负载均衡器配合，实现负载均衡器本身的高可用，Heartbeat则使用自己的心跳协议，功能更通用，不仅可以管理IP，还能管理复杂的资源（如文件系统、数据库服务等），适合构建更复杂、更全面的高可用集群。
- 易用性：对于实现简单的VIP漂移，Keepalived的配置通常被认为比Heartbeat更简洁、更容易上手。
- 选择建议：如果你的主要需求是为Nginx或LVS等前端代理做高可用，Keepalived是首选，它轻量且高效，如果你需要构建一个包含多种资源（如数据库、应用服务、共享存储）的复杂高可用系统，Heartbeat（或其现代替代品如Pacemaker）提供了更强大的资源管理能力。
Q2: 什么是“脑裂”问题？Keepalived如何避免或处理它？
A: “脑裂”是指在高可用集群中，由于网络分区等原因，主备节点之间无法通信，导致备节点认为主节点已宕机，从而接管VIP，但此时主节点实际上仍在正常运行，也持有VIP，这就造成了“两个主节点”同时存在的局面，它们都响应客户端请求，可能导致数据不一致或服务混乱。
Keepalived通过其VRRP机制在一定程度上缓解了脑裂：
- 多播/单播心跳：VRRP通过定期发送心跳报文来维持节点间的“联系”，如果网络是单向中断（如主能发备不能收），备节点收不到心跳会接管，但主节点因能收到自己的报文而不会主动放弃VIP，此时仍会发生脑裂。
- 优先级机制：在脑裂发生时，优先级最高的节点（通常是原始主节点）会继续持有VIP，但这并不能完全解决问题。
为了更彻底地解决脑裂，通常需要引入“仲裁”机制，增加一个第三方的仲裁节点，或者使用共享存储，当主备节点通信中断时，它们会去询问仲裁节点或尝试锁定共享存储文件，只有成功的一方才能成为主节点，Keepalived本身不内置复杂的仲裁功能，但可以通过自定义脚本（vrrp_script）来实现简单的仲裁逻辑，例如检查一个在公网上可访问的地址，只有能访问到的节点才允许提升为主。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
发表回复