面向可扩展服务集群的 LVS 负载均衡原理与实践

最新推荐文章于 2025-05-26 15:48:48 发布

汪子熙

最新推荐文章于 2025-05-26 15:48:48 发布

阅读量774

点赞数 21

分类专栏：计算机基础知识文章标签： lvs 负载均衡运维

本文链接：https://blog.csdn.net/i042416/article/details/148176766

版权

计算机基础知识专栏收录该内容

1000 篇文章

订阅专栏

在现代分布式系统中，LVS Linux Virtual Server 通过内核级 IPVS 框架把四层转发逻辑嵌入 Linux 内核，使负载均衡不再受用户态代理瓶颈约束。这项技术以 Director / Real Server 架构为核心，提供 NAT DR TUN 三种转发模式，以及 rr wrr lc wlc dh sh mh 等多种调度算法；借助 Keepalived + VRRP 可以实现高可用双活 Director，并通过 /proc/net/ip_vs 暴露精细化指标。文章将从诞生背景、体系结构、包转发路径、算法实现、配置示例到云原生场景全面展开，并给出可直接运行的 ipvsadm 与 keepalived 配置示例，以帮助读者掌握 LVS 的设计哲学与落地细节。

LVS 的历史背景与目标

负载均衡技术起源于对横向扩容和高可用的需求；1998 年 Zhang Wensong 发起 Linux Virtual Server 项目，目标是用开源内核构建高性能 / 高可用集群，避免昂贵的专有硬件负载均衡器(linuxvirtualserver.org)。当前代码进入主线内核 net/netfilter/ipvs，并持续以 Subversion → Git 形式迭代(linuxvirtualserver.org)。

内核态实现意味着数据包只需一次上下文切换即可完成转发，而用户态代理(Nginx / HAProxy)往往需要多次拷贝，造成不必要的缓存污染；IPVS 采用独立连接跟踪，避免和 netfilter conntrack 双重开销，从而提升百万 QPS 场景下的吞吐率(kb.linuxvirtualserver.org)。

体系结构视角

Director、VIP 与 Real Server

Director 节点拥有对外 VIP Virtual IP；Real Server 保留私网 RIP。所有进入 VIP 的会话首先抵达 Director，由 IPVS 决策后重新封包并送往 Real Server；返回流量是否回经 Director 取决于所选转发模式(Red Hat Documentation)。

双机热备常以 Keepalived 运行 VRRP 实例，R1 为 Active、R2 为 Backup；当健康检查失败，VIP 会在 3 * 广告周期内漂移到 Backup，从而完成秒级故障切换(Keepalived, Pen Test Partners)。

三种数据包转发模式

模式	报文改写	回包路径	典型用途
`NAT`	Director 改写源/目标地址，Real Server 回包经 Director	所有方向两跳	内网多端口、多协议，配置简单但瓶颈在 Director 带宽(Loadbalancer)
`DR`	仅修改目标 MAC，将 IP 仍指向 VIP	请求经 Director，响应直接回客户端	局域网大并发 Web，吞吐最高但需同一二层广播域(Alibaba Cloud)
`TUN`	把报文包裹在 IPIP 隧道，再发往 Real Server	响应直达客户端	跨网段集群，路由可达即可部署(Loadbalancer)

三种模式共享同一 IPVS 连接哈希表，差异仅在 skb 重写与转发函数指针。

调度算法与连接一致性

IPVS 以内核 O(1) 哈希查表决定已有连接，再通过调度算法挑选新连接目标。核心算法包括：

rr 简单轮询，适用于同配置节点(keepalived-pqa.readthedocs.io)；
wrr 加权轮询，可在 Real Server 性能差异时按比例分流；
lc / wlc 把请求发给连接数最少或加权最少节点，缓解热点集聚(Server Fault)；
dh 基于源 IP ⟶ Real Server IP 一致性哈希，维持粘性会话；
sh 使用源 IP + 端口哈希；
mh 多层哈希，专为万级 Real Server 设计(Server Fault)。

Keepalived 通过 virtual_server → sorry_server → real_server 配置块调用 ipvs_set syscall，把调度算法与权重同步进内核(keepalived.readthedocs.io)。

可运行配置示例

使用 ipvsadm 直接下发规则

# Director 上执行
ipvsadm -A -t 203.0.113.10:80 -s wrr              # 建立虚拟服务VIP
ipvsadm -a -t 203.0.113.10:80 -r 10.0.0.11:80 -g -w 3
ipvsadm -a -t 203.0.113.10:80 -r 10.0.0.12:80 -g -w 1
ipvsadm -ln                                        # 查看统计

示例把 10.0.0.11 与 10.0.0.12 以权重 3:1 接入 DR 集群；-g 表示 gatewaying 即 DR 模式(Ubuntu Manpages)。

Keepalived 配置片段

vrrp_instance VI_1 {
  state        MASTER
  interface    eth0
  virtual_router_id 51
  priority     150
  advert_int   1
  virtual_ipaddress {
     203.0.113.10/24
  }
}

virtual_server 203.0.113.10 80 {
  delay_loop 2
  lb_algo wrr
  lb_kind DR
  protocol TCP

  real_server 10.0.0.11 80 {
    weight 3
    TCP_CHECK {
      connect_timeout 3
    }
  }
  real_server 10.0.0.12 80 {
    weight 1
    TCP_CHECK {
      connect_timeout 3
    }
  }
}

保存至 /etc/keepalived/keepalived.conf 后启动服务即可；Keepalived 利用 SOCKRAW 在用户态构造 VRRP 报文，并通过 netlink 将 VIP / IPVS 规则写入内核(keepalived.readthedocs.io, Keepalived)。

性能调优与监控

/proc/net/ip_vs_stats 暴露总连接、重定向、超时等指标，可结合 Prometheus node exporter 抓取。
/proc/sys/net/ipv4/ip_vs_sync 参数可启用多 Director 连接同步，满足 Active-Active 架构(VA Linux Systems Japan株式会社)。
在 NAT 模式避免加载 nf_conntrack_* 模块，以减少双重跟踪开销(kb.linuxvirtualserver.org)。
rmem_default wmem_default 系统缓冲调整帮助消除 DR 大吞吐时的丢包。

LVS 与云原生

Kubernetes kube-proxy 在 v1.11 引入 --mode=ipvs，通过 netlink 批量注入数万条 VIP → Endpoint 映射，解决 iptables O(n) 匹配延迟；EKS / GKE 指南建议在千服务级场景使用 IPVS 模式(Medium, AWS Documentation, DEV Community)。

相比用户态 Sidecar / Envoy，LVS 专注四层转发，不支持 TLS 终止与七层路由，但资源消耗极低，常作为内部微服务入口的第一道均衡层，中间再叠加 Nginx / Envoy 进行七层处理。

场景与最佳实践

互联网门户：淘宝在 2010 年代使用百万连接的 LVS DR 处理新闻首页流量，高峰 CPU 占用低于 20 %(Alibaba Cloud)。
数据库 VIP：MySQL 主从自动切换后，仅需 Keepalived 漂移 VIP 即可让客户端无感知重连。
裸金属 IDC：DR 模式在 10G LAN 可单机转发 14 Mpps，而 NAT 受限于回包路径，多用于出口带宽较小的后台服务。

结语

LVS 把负载均衡下沉到操作系统最底层，借助灵活的调度算法、三种转发模式与 Keepalived VRRP 机制，在高并发低延迟场景展示了内核态方案的极致性能。它与 HAProxy / Nginx / Envoy 属于互补关系：前者提供轻量快速的四层转发，后者在更高协议栈层面赋能流量治理。理解 LVS 的工作模式与配置要点，能够帮助架构师在不同规模与网络条件下挑选最合适的负载均衡组合，构建稳定、可伸缩的服务集群。