在现代互联网架构中,为了应对日益增长的用户访问量和保障服务的持续可用性,集群技术已成为不可或缺的一环,本文将详细介绍如何在经典的 CentOS 6.5 系统上,构建一个基于 Nginx 的高可用负载均衡集群,这个方案的核心在于利用 Nginx 实现请求分发,同时借助 Keepalived 解决 Nginx 自身的单点故障问题,从而实现整个前端接入层的高可用性。

核心架构与原理
一个典型的 Nginx 集群架构主要包含两个层面:负载均衡和高可用。
-
负载均衡:这是 Nginx 的核心功能,通过配置
upstream模块,Nginx 可以将来自客户端的请求根据预设策略(如轮询、IP哈希、最少连接等)分发到后端的多个真实 Web 服务器上,这不仅有效分摊了单台服务器的压力,还提升了整体处理能力和响应速度。 -
高可用:如果仅使用一台 Nginx 作为负载均衡器,那么这台 Nginx 服务器本身就成为了整个系统的单点故障,一旦它宕机,所有后端服务都将无法访问,为了解决这个问题,我们引入 Keepalived,Keepalived 基于 VRRP(虚拟路由冗余协议)协议,可以虚拟出一个统一的 IP 地址(VIP),这个 VIP 在同一时刻只由主 Nginx 服务器持有,当主服务器发生故障时,备服务器会通过心跳检测发现异常,并立即接管 VIP,确保服务不会中断。
环境准备
在开始部署前,我们需要规划好服务器角色和网络环境,以下是一个基础的示例:
| 服务器角色 | 主机名 | IP地址 | 安装软件 |
|---|---|---|---|
| 主负载均衡器 (MASTER) | lb-master | 168.1.10 | Nginx, Keepalived |
| 备负载均衡器 (BACKUP) | lb-backup | 168.1.11 | Nginx, Keepalived |
| Web服务器 1 | web-01 | 168.1.20 | Nginx/Apache |
| Web服务器 2 | web-02 | 168.1.21 | Nginx/Apache |
虚拟IP (VIP):192.168.1.100
所有服务器均安装 CentOS 6.5,并确保网络互通,在两台负载均衡器上安装 EPEL 源,然后安装 Nginx 和 Keepalived:

rpm -ivh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm yum install nginx keepalived -y
Nginx 负载均衡配置
在两台负载均衡器(lb-master 和 lb-backup)上,我们需要配置相同的 Nginx 负载均衡规则,编辑 /etc/nginx/nginx.conf 文件,在 http 块中添加如下配置:
http {
# 定义后端服务器池
upstream web_pool {
server 192.168.1.20:80 weight=1 max_fails=2 fail_timeout=30s;
server 192.168.1.21:80 weight=1 max_fails=2 fail_timeout=30s;
}
server {
listen 80;
server_name _;
location / {
proxy_pass http://web_pool;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
}
此配置定义了一个名为 web_pool 的服务器组,包含两台 Web 服务器。weight 用于设置权重,max_fails 和 fail_timeout 用于被动健康检查。
Keepalived 高可用配置
这是实现故障自动切换的关键,配置文件位于 /etc/keepalived/keepalived.conf。
主服务器 (lb-master) 配置:
! Configuration File for keepalived
global_defs {
router_id lb-master
}
vrrp_script chk_nginx {
script "/usr/local/bin/check_nginx.sh" # 检查Nginx是否运行的脚本
interval 2
weight -20
}
vrrp_instance VI_1 {
state 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 # 虚拟IP
}
track_script {
chk_nginx
}
}
备服务器 (lb-backup) 配置:
! Configuration File for keepalived
global_defs {
router_id lb-backup
}
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
}
}
需要创建一个 Nginx 检测脚本 /usr/local/bin/check_nginx.sh如下:

#!/bin/bash
if [ -z `ps -C nginx --no-header | wc -l` ]; then
systemctl stop keepalived
fi
赋予执行权限 chmod +x /usr/local/bin/check_nginx.sh,这个脚本的作用是,Nginx 进程不存在,就主动停止本机的 Keepalived,从而触发 VIP 漂移。
服务启动与验证
- 在所有服务器上启动 Web 服务。
- 在两台负载均衡器上启动 Nginx 和 Keepalived:
service nginx start service keepalived start
- 在
lb-master上执行ip addr,可以看到eth0网卡绑定了 VIP168.1.100。 - 在客户端浏览器或使用
curl访问http://192.168.1.100,可以正常获取到后端 Web 服务器的页面,并且多次刷新会看到内容在web-01和web-02之间切换。 - 模拟故障:停止
lb-master的 Nginx 或 Keepalived 服务,稍等片刻后,在lb-backup上执行ip addr,会发现 VIP 已经漂移到了这台服务器上,此时再次访问 VIP,服务依然可用,证明高可用集群配置成功。
相关问答FAQs
Q1:如果后端的某台 Web 服务器宕机,Nginx 会自动将请求转发到其他服务器吗?
A1: 是的,Nginx 具备被动健康检查机制,在 upstream 配置中,max_fails 参数设置了在 fail_timeout 时间内允许的失败次数,Nginx 向某台后端服务器转发请求失败次数达到上限,它会在接下来的 fail_timeout 时间内暂时标记该服务器为不可用,并不再将请求发往该节点,时间窗口过后,Nginx 会再次尝试连接,如果成功则恢复使用,这确保了即使后端有节点故障,用户请求也能被自动转发到健康的节点上。
Q2:Keepalived 和 Nginx 在集群中分别扮演什么角色?它们是必须一起使用的吗? A2: 它们在集群中扮演互补但不同的角色,Nginx 的核心角色是“负载均衡器”,负责将流量智能地分发到后端服务器集群,以提升性能和可扩展性,Keepalived 的核心角色是“高可用性管理者”,负责监控主服务器的状态,并在其发生故障时,通过 VIP 漂移机制,快速将服务切换到备用服务器上,从而消除单点故障,它们并非必须一起使用,如果只追求负载均衡而不关心前端接入层的高可用,可以单独使用 Nginx,但为了构建一个真正健壮、无单点故障的系统,将两者结合是业界标准且最佳实践。