nginx高可用keepalived配置

1.高可用的基本介绍

在使用 Nginx 做反向代理或者负载均衡的时候，都是以 Nginx 为入口，如果 Nginx 宕机了，那么所有的服务都无法正常提供，影响非常严重。所有我们需要保证 nginx 高可用，就是配置备份机，前一个挂了，还有后一个。

为了避免负载均衡服务器宕机造成严重影响，就需要建立一个备份机。主服务器和备份机上都运行高可用（High Availability）监控程序，通过传送诸如“I am alive”这样的信息来监控对方的运行状况。当备份机不能在一定的时间内收到这样的信息时，它就接管主服务器的服务IP并继续提供负载均衡服务；当备份管理器又从主管理器收到“I am alive”这样的信息时，它就释放服务IP地址，这样的主服务器就开始再次提供负载均衡服务。

高可用（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。如果一个系统能够一直提供服务，那么这个可用性则是百分之百，但是我们不能保证一个系统能永远不出问题，所以我们只能通过设计来尽可能的去减少由于系统的故障所造成的影响。

2.keepalived原理

我们可以通过 keepalived 来实现 Nginx 的高可用，keepalived 是集群管理中保证集群高可用的一个服务软件，用来防止单点故障。Keepalived的作用是检测 web 服务器的状态，如果有一台 web 服务器死机或工作出现故障，Keepalived 将能检测到，并将有故障的 web 服务器从系统中剔除，当web服务器工作正常后 Keepalived 会自动将该 web 服务器加入到服务器群中。这些工作全部都会自动完成，不需要人工干涉，需要人工做的只是修复故障的web服务器。keepalived 可以理解为一个健康检查的软件。

高可用至少需要 2 台服务器，主备都得装上keepalived，当请求访问主服务器时，备份服务器会一直检查主服务器的状态。

keepalived 需要绑定一个虚拟地址 vip ( Virtual IP Address ) ，这个虚拟 ip 地址绑定在哪台服务器上请求就会发送到哪台服务器，一开始会绑定在主服务器上。

3.keepalived配置文件/etc/keepalived/keepalived.conf

主服务器 Keepalived 配置 (/etc/keepalived/keepalived.conf)

global_defs {
    router_id u1adfslng01 # 可自定义，同一集群需唯一
    script_user root
    enable_script_security
}

# 定义 Nginx 健康检查脚本
vrrp_script chk_http {
    script "/usr/local/src/nginx_check.sh"
    interval 5      # 每5秒检查一次
    fall 2          # 连续2次失败（10秒）才判定故障
    rise 3          # 连续3次成功（15秒）才恢复（防抖动）
    timeout 10      # 脚本超时时间（避免卡死，可选但推荐）
    weight -50
}

vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass 1111
    }

    virtual_ipaddress {
        10.26.211.48/24  # 建议加上子网掩码（更规范）
    }

    # 关键！关联健康检查脚本
    track_script {
        chk_http
    }

    # 可选：恢复后延迟抢占（配合 rise 使用，避免频繁切换）
    preempt_delay 30
}

备服务器 Keepalived 配置 (/etc/keepalived/keepalived.conf)

global_defs {
    router_id u1adfslng02  # 可自定义，同一集群需唯一
    script_user root
    enable_script_security
}

# 定义 Nginx 健康检查脚本
vrrp_script chk_http {
    script "/usr/local/src/nginx_check.sh"
    interval 5      # 每5秒检查一次
    fall 2          # 连续2次失败（10秒）才判定故障
    rise 3          # 连续3次成功（15秒）才恢复（防抖动）
    timeout 10      # 脚本超时时间（避免卡死，可选但推荐）
    weight -50
}

vrrp_instance VI_1 {
    state BACKUP
    interface ens33
    virtual_router_id 51
    priority 90
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass 1111
    }

    virtual_ipaddress {
        10.26.211.48/24  # 建议加上子网掩码（更规范）
    }

    # 关键！关联健康检查脚本
    track_script {
        chk_http
    }

}

4.上面的配置文件中我们配置了检测脚本的名称和位置，即 /usr/local/src/nginx_check.sh，根据配置我们需要往主备服务器的 /usr/local/src 目录下分别创建一个 nginx_check.sh 脚本文件，文件内容如下：

#!/bin/bash
# Nginx健康检查脚本（适用于 systemd 托管的 Nginx）
# 用于 Keepalived 的 vrrp_script，返回 0 表示健康，非 0 表示故障

# 检查 nginx.service 是否处于 active (running) 状态
if systemctl is-active --quiet nginx; then
    # Nginx 正常运行，返回健康状态
    exit 0
fi

# 如果未运行，尝试重启服务
echo "$(date): Nginx is not running. Attempting to restart via systemctl..." >&2

if ! systemctl restart nginx; then
    echo "$(date): ERROR: Failed to restart nginx service." >&2
    # 重启失败，触发 VIP 转移
    if systemctl is-active --quiet keepalived; then
        echo "$(date): Stopping keepalived to trigger VIP failover..." >&2
        systemctl stop keepalived
    fi
    exit 1
fi

# 等待服务稳定（给予足够时间启动）
sleep 5

# 再次验证是否真正运行成功
if systemctl is-active --quiet nginx; then
    echo "$(date): Nginx restarted successfully." >&2
    exit 0
else
    echo "$(date): CRITICAL: Nginx still not active after restart." >&2
    if systemctl is-active --quiet keepalived; then
        systemctl stop keepalived
    fi
    exit 1
fi

上面的检测脚本的作用是，当检测到 nginx 挂掉但如果此时 keepalived 没挂掉，该脚本会主动尝试重启nginx服务，如果实在重启不了nginx，该脚本会主动关闭 keepalived 好让备份服务器的 nginx 替代上来。

最后分别启动主备服务器的 Nginx 和 keepalived

扩展，若改动了keepalived细微的配置，可以执行下述命令进行检测配置文件并重载，无需重启

keepalived -t -f /etc/keepalived/keepalived.conf && systemctl reload keepalived

⚠️ 什么情况下必须 restart？

表格

修改类型	必须 restart？	原因
新增/删除 **vrrp_instance**	❌ 否	支持热加载
修改 **virtual_router_id**	✅ 是	VRRP 组变更需重建会话
修改网卡 **interface**	✅ 是	需重新绑定网络接口
首次配置健康检查	❌ 否	您的情况属于此类，可重载

您的修改 不涉及以上必须重启的场景。

🔧 为什么推荐 reload 而不是 restart？

表格

对比项	**reload**	**restart**
VIP 中断	❌ 无中断	✅ 可能短暂丢失 VIP（1-3秒）
连接影响	0 影响	活跃 TCP 连接可能被重置
服务连续性	保持高可用	临时降级为单点
适用场景	配置优化/新增检查	核心参数变更（如 router_id）

在生产环境中，任何能避免 VIP 中断的操作都应优先选择 **reload**。