CentOS 6.5如何搭建Nginx集群实现高可用负载均衡？

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

核心架构与原理

一个典型的 Nginx 集群架构主要包含两个层面：负载均衡和高可用。

1. 负载均衡：这是 Nginx 的核心功能，通过配置 upstream 模块，Nginx 可以将来自客户端的请求根据预设策略（如轮询、IP哈希、最少连接等）分发到后端的多个真实 Web 服务器上，这不仅有效分摊了单台服务器的压力，还提升了整体处理能力和响应速度。

2. 高可用：如果仅使用一台 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 漂移。

服务启动与验证

1. 在所有服务器上启动 Web 服务。
2. 在两台负载均衡器上启动 Nginx 和 Keepalived：

   service nginx start
   service keepalived start

3. 在 lb-master 上执行 ip addr，可以看到 eth0 网卡绑定了 VIP 168.1.100。
4. 在客户端浏览器或使用 curl 访问 http://192.168.1.100，可以正常获取到后端 Web 服务器的页面，并且多次刷新会看到内容在 web-01 和 web-02 之间切换。
5. 模拟故障：停止 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，但为了构建一个真正健壮、无单点故障的系统，将两者结合是业界标准且最佳实践。