构建高可用Web服务,基于Keepalived的三台服务器集群实战
作者：admin
分类：默认分类
阅读：6 W
评论：99+
在当今互联网时代,Web服务的稳定性和可用性直接关系到用户体验和业务连续性，任何单点故障都可能导致服务中断，造成不可估量的损失，为了消除单点故障，构建高可用（High Availability, HA）集群成为企业级应用的标配，本文将详细介绍如何利用Keepalived软件，结合三台Web服务器，搭建一个高性能、高可用的Web服务集群方案。
为什么需要Keepalived与三台服务器集群？
传统的单台Web服务器面临着诸多风险,如硬件故障、系统崩溃、网络中断等，虽然双机热备（如主备模式）能提供一定的高可用性，但存在资源利用率低（备用服务器通常处于空闲状态）和单点隐患（主备切换时仍可能出现短暂服务中断）等问题。
引入三台服务器并结合Keepalived,可以构建更优的解决方案：
- 高可用性：三台服务器互为备份，当其中一台发生故障时，其他服务器能迅速接管服务，确保服务不中断或中断时间极短。
- 负载均衡：结合Nginx等反向代理软件，Keepalived可以实现流量的负载均衡，将用户请求分发到多台后端Web服务器，提高整体处理能力和响应速度。
- 可扩展性：集群架构便于后续增加更多服务器节点，以应对不断增长的业务需求。
- 故障自动转移：Keepalived通过VRRP（Virtual Router Redundancy Protocol）协议，能够自动检测服务器状态，并在主节点故障时，快速将虚拟IP（VIP）切换到备用节点，实现服务的无缝切换。
核心组件：Keepalived简介
Keepalived最初是为LVS（Linux Virtual Server）负载均衡器设计的，主要用来监控集群系统中各个服务节点的状态，后来，它逐渐演变成一个更通用的高可用解决方案，支持对任意TCP服务进行健康检查和故障转移。
其核心功能包括：
- VRRP：通过虚拟路由器冗余协议，实现虚拟IP的动态管理和故障转移。
- 健康检查：定期检查后端服务器的服务状态（如HTTP端口、特定URL等），确保只有健康的节点才能接收流量。
- 故障通知：当节点故障时，可以通过邮件等方式发送通知。
- 脚本支持：允许用户自定义脚本来执行复杂的健康检查和故障恢复操作。
三台服务器集群架构设计
我们采用“一主两备”（Master-Backup-Backup）或“主主备”（Master-Master-Backup，需结合负载均衡软件）的常见架构，这里我们以更典型的“一主两备”结合负载均衡为例进行阐述。
假设我们有以下三台Web服务器：
- Server 1 (192.168.1.10)：主节点（Master），默认处理流量。
>
Server 2 (192.168.1.11)：备用节点1（Backup1），当主节点故障时接管服务。
Server 3 (192.168.1.12)：备用节点2（Backup2），进一步增强可用性，或在Backup1也故障时接管。
核心组件部署：
- 虚拟IP（VIP）：
168.1.100，对外提供服务的统一入口。
- Keepalived：在三台服务器上均安装。
- Web服务（如Nginx/Apache）：在三台服务器上均安装并配置相同的应用程序。
- （可选）负载均衡软件：如Nginx，可以部署在VIP指向的位置，或者直接利用Keepalived的转发功能（如果后端服务器直接提供服务，则VIP直接指向主节点，通过Keepalived做健康检查和故障转移；如果后端服务器需要Nginx做负载均衡，则Keepalived负责Nginx负载均衡器本身的高可用）。
为了简化,我们假设三台服务器都部署了相同的Web服务（如Nginx），VIP 168.1.100 由Keepalived动态分配给当前的主节点，用户请求访问VIP，实际由主节点上的Web服务处理，当主节点故障，VIP自动切换到Backup1，若Backup1也故障，则切换到Backup2。
配置步骤（以Nginx + Keepalived为例）
-
环境准备：
- 三台服务器安装相同的Linux操作系统（如CentOS 7/8）。
- 三台服务器安装Nginx,并配置相同的测试页面，确保Web服务能正常启动。
- 三台服务器安装Keepalived：
yum install -y keepalived (CentOS) 或 apt-get install -y keepalived (Ubuntu)。
-
Keepalived配置：
-
主节点（Server 1, 192.168.1.10）：
编辑 /etc/keepalived/keepalived.conf 文件：
! Configuration File for keepalived
global_defs {
router_id LVS_DEVEL_MASTER # 路由器ID，主备节点不同
vrrp_skip_check_adv_addr
vrrp_strict
vrrp_garp_interval 0
vrrp_gna_interval 0
}
vrrp_script check_nginx {
script "/usr/local/sbin/check_nginx.sh" # 自定义检查Nginx状态的脚本
interval 2
weight -20
fall 3
rise 2
}
vrrp_instance VI_1 {
state MASTER # 主节点状态为MASTER
interface eth0 # 本地网卡名称，根据实际情况修改
virtual_router_id 51
priority 100 # 主节点优先级较高
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.1.100/24 dev eth0 label eth0:0 # 虚拟IP
}
track_script {
check_nginx # 调用自定义脚本检查Nginx
}
}
check_nginx.sh 脚本内容示例（用于检查Nginx进程是否存活）：
#!/bin/bash
if ! pgrep nginx > /dev/null; then
exit 1
else
exit 0
fi
给脚本执行权限：chmod +x /usr/local/sbin/check_nginx.sh
-
备用节点1（Server 2, 192.168.1.11）：
编辑 /etc/keepalived/keepalived.conf 文件，主要修改以下部分：
global_defs {
router_id LVS_DEVEL_BACKUP1
# ... 其他全局配置同主节点 ...
}
vrrp_script check_nginx {
script "/usr/local/sbin/check_nginx.sh"
interval 2
weight -20
fall 3
rise 2
}
vrrp_instance VI_1 {
state BACKUP # 备用节点状态为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/24 dev eth0 label eth0:0
}
track_script {
check_nginx
}
# nopreempt # 如果需要非抢占模式，取消注释（主节点恢复后不抢占）
}
-
备用节点2（Server 3, 192.168.1.12）：
配置与备用节点1类似，只需修改 router_id（如 LVS_DEVEL_BACKUP2）和 priority（如 80，低于备用节点1）。
-
启动与测试：
- 在三台服务器上启动Nginx服务：
systemctl start nginx，并设置为开机自启：systemctl enable nginx。
- 在三台服务器上启动Keepalived服务：
systemctl start keepalived，并设置为开机自启：systemctl enable keepalived。
- 在主节点上执行
ip addr 命令，应能看到虚拟IP 168.1.100 已经绑定到 eth0:0。
- 在客户端浏览器访问
http://192.168.1.100，应能看到Nginx的欢迎页面或测试页面。
- 故障转移测试：
- 停止主节点的Nginx服务或关闭主节点服务器,观察备用节点1是否接管VIP（在备用节点1上执行
ip addr 查看）。
- 如果停止备用节点1,备用节点
