LVS-Keepalived高可用群集

LVS (Linux Virtual Server) 结合 Keepalived 是实现高可用、高性能网络服务（如 Web、数据库、邮件等）的经典解决方案。它利用 LVS 提供强大的四层（传输层，TCP/UDP）负载均衡能力，并通过 Keepalived 实现负载均衡器本身的高可用性（HA），避免单点故障。

核心组件与工作原理

1. LVS (IPVS):

   • 角色 ：核心负载均衡器。工作在内核空间 (ip_vs 模块)，效率极高。

   • 功能 ：接收客户端请求，根据配置的调度算法 (如轮询 rr、加权轮询 wrr、最少连接 lc、加权最少连接 wlc、源地址哈希 sh 等)，将请求转发 给后端真实服务器集群 (Real Servers, RS)。

   • 工作模式 (关键选择)：

     • NAT (Network Address Translation):

       • LVS 修改请求和响应的 IP 地址/端口。

       • 进出流量都经过 LVS，易成为瓶颈。RS 网关需指向 LVS。

     • DR (Direct Routing):

       • 最常用、高性能模式。

       • LVS 只修改请求帧的 MAC 地址，将其直接路由给选中的 RS。

       • RS 处理请求并直接将响应发送回客户端 (不经过 LVS)。

       • 要求 LVS 和所有 RS 在同一物理网络/VLAN (不能跨路由器)。RS 需要配置 VIP (Virtual IP) 在 loopback 接口上并抑制 ARP 响应 (arp_ignore=1, arp_announce=2)。

     • TUN (IP Tunneling):

       • 在 LVS 和 RS 之间建立 IP 隧道。

       • LVS 将请求封装在 IP 隧道包中发送给 RS。

       • RS 解封装后处理请求，并将响应直接发送回客户端。

       • 允许 LVS 和 RS 在不同网络，但配置复杂，性能开销略高于 DR。

2. Keepalived:

   • 角色 ：实现 LVS 负载均衡器本身的高可用性 + 管理 LVS 配置 + 监控后端 RS 健康状态。

   • 核心机制 ：VRRP (Virtual Router Redundancy Protocol)。

     • 多个 LVS 节点（通常是两个：Master 和 Backup）组成一个 VRRP 组。

     • 组内所有节点都配置一个相同的虚拟路由器 ID (VRID)。

     • 组内选举出一个 Master 节点。Master 节点持有虚拟 IP 地址 (VIP)，这个 VIP 就是客户端访问服务的地址。

     • Master 节点定期发送 VRRP 通告 (advert) 给组内其他节点，宣告自己存活。

     • Backup 节点监听通告。如果 Backup 在指定时间内 (advert_int + n * priority delay) 没有收到 Master 的通告，它会发起选举，成为新的 Master 并接管 VIP。

     • 优先级 (priority) 决定选举结果（值高的优先）。

   • 功能：

     • LVS 高可用 (VRRP)：自动进行故障转移（Failover），确保 VIP 始终可用。

     • 管理 LVS 规则 ：Keepalived 根据其配置文件 (keepalived.conf) 自动在活动节点 (Master) 上配置 LVS 的虚拟服务器 (virtual_server) 和后端 RS (real_server)。

     • 健康检查 (Health Checking)：

       • 对后端 RS ：Keepalived (Master) 定期检查配置的每个 real_server 的健康状态（如 TCP 连接检查、HTTP GET 检查、自定义脚本检查等）。如果检测到 RS 故障，它会将其从 LVS 转发池中移除。当 RS 恢复后，再将其重新加入。

       • 对 LVS 节点自身服务 ：可配置脚本检查本机上的关键服务（如 ipvsadm 服务本身、或依赖的进程），如果检查失败，Keepalived 可以主动降低自身优先级 (priority)，触发主备切换，让更健康的节点接管。这有助于处理"僵死"节点（网络通但服务挂的情况）。

典型架构 (以 DR 模式为例)

  +-----------------------+
  |      Client           |
  +----------+------------+
             | (请求目标: VIP)
             |
  +----------v------------+        +-----------------------+
  |                       | VRRP  |                       |
  |   LVS/Keepalived      <-------->   LVS/Keepalived      |
  |      (Master)         |        |      (Backup)         |
  |     [VIP:eth0]        |        |     [VIP:未激活]      |
  +----------+------------+        +-----------------------+
             | (DR 模式: 转发请求到 RS, 目标 MAC 是选中的 RS)
             |
  +----------v---------------------------+
  |          Switch / VLAN               |
  +-----+--------------+-----------------+
        |              |
+-------v----+   +------v-------+
| Real Server|   | Real Server  |
| (RS1)      |   | (RS2)        |
| [VIP:lo:0] |   | [VIP:lo:0]   |  <-- VIP 配置在 loopback 接口，抑制 ARP
+------------+   +--------------+
        |              |
        | (响应直接发送给客户端，源IP是VIP)
        |
  +-----v----------------------+
  |      Client                |
  +----------------------------+

关键配置文件 (keepalived.conf) 主要部分

global_defs {
    notification_email { ... } # 报警邮件设置 (可选)
    router_id LVS_DEVEL         # 标识本节点
}

# VRRP 实例配置 - 实现 LVS 节点 HA
vrrp_instance VI_1 {
    state MASTER                # 初始状态 MASTER 或 BACKUP
    interface eth0              # 绑定 VRRP 的物理接口
    virtual_router_id 51        # VRRP 组 ID (必须相同)
    priority 100                # 选举优先级 (MASTER 通常更高)
    advert_int 1                # VRRP 通告间隔 (秒)

    authentication {            # VRRP 认证 (可选，简单密码)
        auth_type PASS
        auth_pass 1111
    }

    virtual_ipaddress {         # 要管理的 VIP (可以有多个)
        192.168.1.100/24 dev eth0 label eth0:0 # VIP 配置在 eth0:0
    }

    # 可选的脚本跟踪接口/脚本检查
    track_script {
        chk_haproxy  # 引用下面定义的脚本检查 (可选)
    }
}

# 定义一个 LVS 虚拟服务器 (Virtual Server)
virtual_server 192.168.1.100 80 { # VIP 和端口
    delay_loop 6                 # 健康检查间隔 (秒)
    lb_algo wrr                  # 调度算法 (加权轮询)
    lb_kind DR                   # 工作模式 (DR)
    persistence_timeout 50       # 会话保持时间 (秒，可选)
    protocol TCP                 # 协议

    # 真实服务器 1 (Real Server)
    real_server 192.168.1.11 80 {
        weight 1                 # 权重 (用于 wrr, wlc 等算法)
        # TCP 健康检查
        TCP_CHECK {
            connect_timeout 3    # 连接超时
            nb_get_retry 3       # 重试次数
            delay_before_retry 3 # 重试间隔
            connect_port 80      # 检查端口
        }
        # 或者 HTTP_GET 健康检查
        # HTTP_GET {
        #   url { path /healthz }
        #   connect_timeout 3
        #   nb_get_retry 3
        #   delay_before_retry 3
        # }
    }

    # 真实服务器 2 (Real Server)
    real_server 192.168.1.12 80 {
        weight 2
        TCP_CHECK { ... } # 同上
    }
}

# 可选的额外脚本检查 (用于 track_script)
vrrp_script chk_haproxy {
    script "/usr/bin/killall -0 haproxy" # 检查 haproxy 进程是否存在 (示例)
    interval 2                          # 检查间隔
    weight 2                            # 检查失败时优先级变化值 (可负)
}

优点

1. 高性能：LVS 内核转发，效率极高，尤其 DR/TUN 模式避免响应瓶颈。

2. 高可用：Keepalived 实现 LVS 节点故障自动转移，服务不中断。

3. 可扩展性：后端 RS 可以水平扩展以应对增长流量。

4. 透明性：客户端只感知 VIP，后端服务器变化对客户端透明。

5. 灵活性：支持多种负载均衡算法和健康检查方式。

6. 成熟稳定：技术成熟，在大型互联网公司广泛使用多年。

缺点/注意事项

1. 配置复杂性：尤其 DR 模式下的 ARP 抑制和网络拓扑要求。

2. 单点配置：Keepalived 主节点负责 LVS 配置管理，需确保配置同步（通常靠同步配置文件解决，Keepalived 自身不负责配置同步）。

3. 脑裂 (Split-Brain) 风险：如果 VRRP 通告因网络分区无法传递，可能导致两个节点都认为自己是 Master 并持有 VIP。需要合理设置优先级、通告间隔，并在网络设计上尽量避免分区。有时需依赖额外的监控和仲裁机制。

4. 模式限制：

   • DR/TUN：要求后端应用不能依赖源 IP（因为客户端 IP 直达 RS，RS 看到的源 IP 是真实客户端 IP，但 LVS 可能修改了 TCP 选项如时间戳，某些应用需注意）。

   • NAT：LVS 可能成为带宽和连接数瓶颈，且需要 RS 网关指向 LVS。

5. 功能层级：LVS 是四层负载均衡，不感知应用层内容（如 HTTP URL、Cookie）。如需七层负载均衡（更智能的路由），需要在 RS 上部署 Nginx/Haproxy 或使用专门的七层负载均衡器。

部署步骤概要

1. 规划：确定 VIP、真实服务器 IP、网络拓扑（推荐同一 VLAN DR 模式）、调度算法、健康检查方式。

2. 配置后端 RS：

   • 安装并配置应用服务 (Nginx, Apache, Tomcat 等)。

   • 配置 VIP 在 loopback 接口 (仅 DR/TUN 模式需要)。

   • 配置 ARP 抑制 (arp_ignore=1, arp_announce=2)。

   • 确保 RS 防火墙允许 VIP 和健康检查流量。

3. 配置 LVS/Keepalived 节点 (所有节点)：

   • 安装 ipvsadm (管理工具) 和 keepalived。

   • 编辑 /etc/keepalived/keepalived.conf (如上示例)。

   • 确保配置文件在节点间一致（主备的 state 和 priority 不同）。

   • 开启内核转发 (net.ipv4.ip_forward=1 for NAT)。

   • 确保 VRRP 通告端口 (通常是 112) 和健康检查端口在防火墙允许。

4. 启动服务：

   • 在所有 LVS 节点启动 keepalived 服务：systemctl start keepalived && systemctl enable keepalived

   • 检查日志 (journalctl -u keepalived -f)，确认 Master 选举成功，VIP 绑定正确。

   • 在 Master 节点使用 ipvsadm -Ln 检查 LVS 规则和后端 RS 状态。

5. 测试：

   • 访问 VIP 测试服务是否正常。

   • 模拟故障测试：

     • 关闭 Master 的 keepalived：观察 Backup 是否接管 VIP 和 LVS 规则。

     • 关闭一个后端 RS：观察 LVS Master 是否将其从池中移除 (ipvsadm -Ln 查看状态)。

     • 恢复 RS：观察是否重新加入池。

     • (可选) 模拟网络分区测试脑裂处理。

总结

LVS + Keepalived 是一个强大、高效且成熟的四层高可用负载均衡解决方案。它特别适合处理高流量、对性能要求苛刻且需要高可用性的场景（如 Web 前端、API 网关、缓存层等）。虽然配置（尤其是 DR 模式）相对复杂并需要注意网络拓扑和 ARP 问题，但其卓越的性能和稳定性使其在基础设施领域占据重要地位。理解其工作原理和不同模式的特点对于成功部署和维护至关重要。