Linux如何搭建高可用Web服务器集群？_LinuxNginx与Keepalived配置

2025-07-24 电脑数码

高可用web服务器集群通过消除单点故障确保服务连续性，主要依赖nginx和keepalived实现。1. nginx作为反向代理和负载均衡器，将流量按算法（如轮询、ip哈希、最少连接）分发至多台后端服务器，并转发请求头以保留客户端信息；2. keepalived利用vrrp协议管理虚拟ip（vip），通过健康检查脚本监控nginx状态，主节点故障时自动切换至备用节点，保障服务不中断。该架构有效提升了用户体验、业务连续性，并支持无停机维护升级。

搭建高可用Web服务器集群，核心思路就是消除单点故障，确保服务不间断。在Linux环境下，我们通常会利用Nginx作为反向代理和负载均衡器，将流量分发到多台后端Web服务器上；而Keepalived则负责管理一个虚拟IP（VIP），并在Nginx服务器之间进行故障转移，一旦主Nginx宕机，备用Nginx能立即接管VIP，对外提供服务。说白了，就是Nginx负责“干活”，Keepalived负责“看家”，谁倒下了另一个就顶上。

解决方案

要实现一个高可用的Web服务器集群，我们主要需要配置两部分：Nginx和Keepalived。

1. Nginx配置（在所有Nginx节点上）

Nginx作为负载均衡器，负责将请求转发给后端的实际Web服务器（如Apache、PHP-FPM、Tomcat等）。

# /etc/nginx/nginx.conf 或包含在 conf.d/default.conf 中
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
    worker_connections 1024;
}

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

    access_log /var/log/nginx/access.log main;

    sendfile on;
    #tcp_nopush on;

    keepalive_timeout 65;

    # gzip on;

    # 定义后端服务器集群
    upstream backend_web_servers {
        # 负载均衡算法，可选的有 round_robin（默认）、ip_hash、least_conn、url_hash等
        # server_weights 权重，fail_timeout 故障判断时间，max_fails 失败次数
        server 192.168.1.101:80 weight=5 max_fails=3 fail_timeout=30s;
        server 192.168.1.102:80 weight=5 max_fails=3 fail_timeout=30s;
        # server 192.168.1.103:80 backup; # 备份服务器，只有当其他服务器都不可用时才使用
        # server 192.168.1.104:80 down;   # 标记为不参与负载均衡
    }

    server {
        listen 80;
        server_name your_domain.com; # 或直接使用_匹配所有

        location / {
            proxy_pass http://backend_web_servers; # 转发请求到后端集群
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            # 启用会话保持，如果你的应用需要
            # sticky learn
            #   create=$upstream_cookie_sessionid
            #   lookup=$cookie_sessionid
            #   zone=client_sessions:1m;
        }

        # 可以添加SSL配置
        # listen 443 ssl;
        # ssl_certificate /etc/nginx/ssl/your_domain.crt;
        # ssl_certificate_key /etc/nginx/ssl/your_domain.key;
    }
}

2. Keepalived配置（在所有Nginx节点上）

Keepalived利用VRRP协议实现高可用。我们需要至少两台Nginx服务器，一台作为Master，另一台作为Backup。

Master节点配置示例 (/etc/keepalived/keepalived.conf)：

! Configuration File for keepalived

global_defs {
    router_id LVS_DEVEL # 路由器ID，每个节点唯一
    # script_security strict # 脚本执行安全模式，推荐开启
}

vrrp_script chk_nginx {
    script "/etc/keepalived/check_nginx.sh" # 检查Nginx状态的脚本
    interval 2 # 每2秒执行一次
    weight 20 # 如果脚本执行失败，优先级会降低20
    fall 2 # 连续失败2次后认为服务失效
    rise 1 # 连续成功1次后认为服务恢复
}

vrrp_instance VI_1 {
    state MASTER # 定义为Master节点
    interface eth0 # 绑定VIP的网络接口，根据实际情况修改
    virtual_router_id 51 # 虚拟路由ID，Master和Backup必须一致
    priority 100 # 优先级，Master的优先级要高于Backup
    advert_int 1 # 通告间隔，每1秒发送一次VRRP包

    authentication {
        auth_type PASS
        auth_pass 1111 # 认证密码，Master和Backup必须一致
    }

    virtual_ipaddress {
        192.168.1.100/24 # 虚拟IP地址，对外提供服务的IP
    }

    track_script {
        chk_nginx # 关联Nginx检查脚本
    }

    # notify_master "/etc/keepalived/notify.sh master"
    # notify_backup "/etc/keepalived/notify.sh backup"
    # notify_fault "/etc/keepalived/notify.sh fault"
    # notify_stop "/etc/keepalived/notify.sh stop"
}

Backup节点配置示例 (/etc/keepalived/keepalived.conf)：

与Master节点类似，但state改为BACKUP，priority要低于Master（例如90）。

! Configuration File for keepalived

global_defs {
    router_id LVS_BACKUP # 路由器ID，与Master不同
    # script_security strict
}

vrrp_script chk_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 2
    weight 20
    fall 2
    rise 1
}

vrrp_instance VI_1 {
    state BACKUP # 定义为Backup节点
    interface eth0
    virtual_router_id 51
    priority 90 # 优先级低于Master
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass 1111
    }

    virtual_ipaddress {
        192.168.1.100/24
    }

    track_script {
        chk_nginx
    }
}

Nginx检查脚本 (/etc/keepalived/check_nginx.sh)：

#!/bin/bash
# 检查Nginx进程是否存在
A=`ps -C nginx --no-header |wc -l`
# 如果Nginx进程不存在
if [ $A -eq 0 ];then
    # 尝试启动Nginx
    /usr/sbin/nginx # 根据实际Nginx路径修改
    # 等待几秒钟，再次检查
    sleep 2
    B=`ps -C nginx --no-header |wc -l`
    # 如果Nginx依然没有启动，则杀死Keepalived进程，触发故障转移
    if [ $B -eq 0 ];then
        killall keepalived
    fi
fi

给脚本添加执行权限：chmod +x /etc/keepalived/check_nginx.sh

部署完成后，启动Nginx和Keepalived服务。

Web服务器集群为什么需要高可用？

说实话，这年头，哪个线上业务敢说自己不需要高可用？单点故障就像悬在头顶的达摩克利斯之剑，不知道什么时候就掉下来了。想象一下，你的网站突然访问不了了，用户刷不出来，业务停摆，这损失可不是闹着玩的。所以，高可用，在我看来，不是“锦上添花”，而是“雪中送炭”，是现代互联网服务的基础设施。

具体来说，Web服务器集群实现高可用，主要解决以下几个痛点：

消除单点故障（SPOF）：这是最直接也最重要的原因。如果只有一个Web服务器，一旦它因为硬件故障、软件崩溃、网络中断或者维护升级而停机，整个服务就中断了。高可用集群通过冗余设计，确保即使某个节点失效，服务也能迅速切换到其他正常节点，用户几乎无感知。
提升用户体验：服务中断或者响应缓慢，都会让用户感到沮丧。高可用不仅保证服务“在线”，还能通过负载均衡优化请求分配，避免某个服务器过载，从而提高响应速度和整体性能，让用户始终感受到流畅的访问体验。
保障业务连续性：对于电商、金融、新闻等对实时性要求高的业务来说，哪怕是几分钟的服务中断都可能造成巨大的经济损失和品牌信誉损害。高可用集群能最大限度地减少服务中断时间，保障业务的持续运行。
简化维护升级：有了高可用集群，你可以进行“滚动升级”或“蓝绿部署”。比如，先将一台服务器从集群中移除进行升级，升级完成后再加回集群，然后对下一台进行同样操作。这样，整个升级过程中，服务始终保持在线，无需停机维护。这在实际运维中，简直是救命稻草。

Nginx在集群中扮演什么角色？Nginx负载均衡与反向代理配置

Nginx在这个高可用Web集群里，扮演的角色非常关键，它既是“门面”，又是“交通指挥官”。

反向代理（Reverse Proxy）：
Nginx作为反向代理，就像一个公司的前台。所有外部的请求首先到达Nginx，Nginx再根据请求的类型、路径等规则，将请求转发给后端的真正处理业务的服务器。这样做的好处是：

隐藏后端服务器：外部用户只知道Nginx的IP，不知道后端服务器的真实IP和结构，增加了安全性。
统一入口：所有的请求都从Nginx进来，便于集中管理、日志记录和安全策略的实施。
SSL卸载：Nginx可以处理SSL/TLS加密解密，减轻后端服务器的负担，提高后端效率。

负载均衡（Load Balancer）：
这是Nginx的另一个核心功能。当Nginx接收到请求后，它会根据预设的负载均衡算法，将请求分发给后端多台Web服务器中的一台。这样可以：

分散流量：避免单台后端服务器压力过大，导致响应变慢甚至崩溃。
提高吞吐量：多台服务器并行处理请求，大大提升了整个集群的处理能力。
故障隔离：如果某台后端服务器出现故障，Nginx可以自动将其从负载均衡池中移除，不再将请求转发给它，直到它恢复正常。

Nginx负载均衡配置的常见姿势：
在nginx.conf中，我们通过upstream模块来定义后端服务器组，并选择负载均衡算法。

http {
    upstream backend_web_servers {
        # 默认是轮询（round-robin），请求依次分发给后端服务器
        server 192.168.1.101:80;
        server 192.168.1.102:80;

        # ip_hash：根据客户端IP的哈希值来分发请求，保证同一IP的请求总是发送到同一台服务器，
        # 适用于需要会话保持的场景，但可能导致负载不均。
        # ip_hash;
        # server 192.168.1.101:80;
        # server 192.168.1.102:80;

        # least_conn：最少连接数，将请求分发给当前连接数最少的服务器，适合长连接服务。
        # least_conn;
        # server 192.168.1.101:80;
        # server 192.168.1.102:80;

        # fair：按后端响应时间来分配请求，响应时间短的优先（需要第三方模块）。

        # url_hash：按访问URL的哈希值来分配（需要第三方模块）。

        # weight：权重，数字越大，被分配到的请求越多。
        # server 192.168.1.101:80 weight=10;
        # server 192.168.1.102:80 weight=5;
    }

    server {
        listen 80;
        server_name your_domain.com;

        location / {
            proxy_pass http://backend_web_servers; # 转发到定义的后端集群
            # 重要的请求头转发，确保后端能获取到客户端真实IP等信息
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
}

通过这些配置，Nginx就能像个老练的交通警察，合理地将流量引导到健康的后端服务器，确保整个系统的稳定运行。

Keepalived如何实现Web集群的自动故障转移？Keepalived虚拟IP与健康检查

Keepalived在整个高可用架构中，扮演的是“守护者”的角色，它的核心任务就是确保那个对外服务的虚拟IP（VIP）始终在线，并且能自动在不同的Nginx服务器之间漂移。这事儿听起来有点玄乎，但原理其实是基于VRRP（Virtual Router Redundancy Protocol）协议。

虚拟IP（VIP）的魔力：
想象一下，你的Web服务对外只有一个IP地址，这个IP就是VIP。用户永远只访问这个VIP。而这个VIP，在任何时刻，只会绑定在集群中的一台Nginx服务器上（通常是Master）。当Master Nginx服务器出现故障时，Keepalived会检测到，然后迅速将这个VIP“转移”到Backup Nginx服务器上。这个过程对用户来说是透明的，他们甚至不知道背后的服务器已经换了一台。

VRRP协议的工作机制：

Master/Backup模式：集群中，一台Keepalived节点被选举为Master，负责持有VIP并周期性地发送VRRP通告（Advertisements）包。其他节点是Backup，它们监听Master的通告。
优先级（Priority）：每个节点都有一个优先级值。优先级最高的节点会成为Master。如果Master宕机，优先级次高的Backup节点会接管VIP，成为新的Master。
抢占（Preemption）：默认情况下，如果一个优先级更高的节点从故障中恢复，它会“抢占”VIP，重新成为Master。你也可以配置nopreempt来禁用抢占，让当前的Master继续服务，直到它自己宕机。

健康检查（Health Check）：
这是Keepalived实现故障转移的关键。光靠VRRP通告不足以判断服务是否真的可用。例如，Nginx进程挂了，但服务器本身还在运行，VRRP通告可能还在发。这时就需要健康检查脚本。

# /etc/keepalived/check_nginx.sh
#!/bin/bash
# 检查Nginx是否在运行，以及它是否能正常响应请求
# 比如，可以尝试访问Nginx的本地状态页或一个简单的健康检查URL
# curl -s http://127.0.0.1/nginx_status > /dev/null 2>&1
# if [ $? -ne 0 ]; then
#    # 如果Nginx不健康，尝试重启
#    systemctl restart nginx
#    sleep 5 # 给Nginx一些时间启动
#    curl -s http://127.0.0.1/nginx_status > /dev/null 2>&1
#    if [ $? -ne 0 ]; then
#        exit 1 # 再次检查失败，退出码为1，Keepalived会降低优先级
#    fi
# fi

# 更简单粗暴但有效的：检查Nginx进程是否存在
A=`ps -C nginx --no-header |wc -l`
if [ $A -eq 0 ];then
    # Nginx进程没了，尝试拉起来
    systemctl start nginx # 或者 /usr/sbin/nginx
    sleep 2
    B=`ps -C nginx --no-header |wc -l`
    if [ $B -eq 0 ];then
        # 还是没起来，说明Nginx真的挂了，或者系统有问题
        # 这时候就得让Keepalived知道，然后它会触发故障转移
        killall keepalived # 直接杀死Keepalived，让VIP漂移
        exit 1 # 退出码非0，表示检查失败
    fi
fi
exit 0 # 检查成功，退出码为0

在keepalived.conf中，我们通过vrrp_script定义这个检查脚本，并用track_script将其与vrrp_instance关联起来。当chk_nginx脚本返回非零退出码时，Keepalived会根据配置降低本节点的优先级（weight参数），导致它失去Master地位，从而触发VIP的转移。

整个流程就是：用户访问VIP -> VIP绑定在Master Nginx上 -> Master Nginx宕机或服务不健康 -> Keepalived的健康检查脚本发现问题 -> Master Nginx的Keepalived降低优先级或直接退出 -> Backup Nginx的Keepalived发现Master失联 -> Backup Nginx接管VIP，成为新的Master -> 服务继续对外提供。这个切换过程通常在几秒内完成，极大地减少了服务中断时间。

以上就是Linux如何搭建高可用Web服务器集群？_LinuxNginx与Keepalived配置的详细内容，更多请关注深圳推广【www.sztg.com.cn】。

本文地址：https://www.sztg.com.cn/article/357149.html

如非特殊说明，本站内容均来自于网友自主分享，如有任何问题均请联系我们进行处理！