LVS 节点从千兆升到万兆时，性能并不会线性增长。某业务把双口万兆网卡插上、交换机换成万兆后，发现转发 PPS 只提高了三到四成，甚至软中断分布不均导致延迟抖动。核心原因通常不是 LVS 调度算法不够快，而是网卡队列、CPU 绑核方式、交换机缓存和链路聚合策略没有同步调整。本文从网卡硬件能力和交换机转发模型出发，梳理 LVS 高并发场景下的选型与优化思路。
一、先看清楚 LVS 转发的性能模型
LVS 的 ip_vs 模块工作在内核协议栈中，数据包从网卡 DMA 到内存、触发硬中断、唤醒软中断处理、进入网络层和传输层，再根据调度结果转发。单个队列只能由一个 CPU 处理软中断，所以当网卡只有 4 个队列而服务器有 32 核时，真正用于收包的核至多 4 个，小包一多就把这几核打满，而其他核空闲。这种队列与 CPU 的错配是万兆性能上不去的第一类原因。
万兆网络下线速每秒钟约有 1488 万个小包，Linux 内核协议栈不做任何优化时，单核通常只能处理 100 万到 300 万 PPS，取决于 CPU 主频、cache 和网卡驱动。多队列 RSS 的作用就是把不同五元组哈希到不同队列，让多个 CPU 并行处理软中断。哈希冲突、irqbalance 乱绑核、NUMA 远端内存访问都会直接吞噬性能。实际调优时，往往先确认网卡队列是否足够多，再确认队列中断是否被均匀绑到目标 CPU。
检查队列和哈希配置的命令如下：
# 查看当前队列数量和最大支持 ethtool -l eth0 # 查看 RSS 哈希配置 ethtool -x eth0 # 调整合并队列数，重启后可能失效 ethtool -L eth0 combined 16
如果 RSS 哈希只使用源 IP，大量客户端来自同一网段或经过 NAT 后源 IP 很少，队列会极度不均。建议对 TCP/UDP 四元组做哈希，使 LVS NAT 和 DR 模式下的连接都能散开。调完队列后还要关闭 irqbalance 或手动设置中断亲和性，否则系统可能会在运行时重新分配网卡中断，破坏绑核效果。
二、高性能网卡选型要注意哪些硬件指标
LVS 网卡选型不能只看端口速率。万兆网卡必须配合足够的 PCIe 通道，否则总线成为瓶颈。PCIe 2.0 x8 单向大约 32Gbps，双向勉强跑满两个万兆口；PCIe 3.0 x8 单向约 64Gbps，更适合双口万兆。注意插槽与 CPU 的 NUMA 关系，网卡应与处理软中断的 CPU 在同一个 NUMA 节点，避免跨节点访问描述符和报文缓存。很多转发性能问题最终追到 NUMA 远端内存后才暴露。
硬件卸载能力同样重要。TCP 分段卸载、通用接收卸载、校验和卸载等可以降低 CPU 开销，但在 LVS 转发中通用接收卸载会聚合小包，对转发延迟敏感的业务需要评估。多队列数和 SR-IOV 能力决定虚拟化或容器化部署的上限。用 DPDK 开发的 DPVS 可以绕过内核协议栈，网卡需要支持 DPDK PMD 驱动，Mellanox ConnectX-5、Intel X710 等都是常见选择。
常见网卡型号对比如下：
| 网卡型号 | 端口与速率 | 队列/SR-IOV | 适用场景 |
|---|---|---|---|
| Intel X710-DA4 | 4×10G SFP+ | 多队列，支持 SR-IOV | LVS 内核态转发，物理机 |
| Mellanox ConnectX-5 | 2×25G/10G | 多队列，支持 DPDK/ASAP2 | 高 PPS、DPVS 或混合云 |
| Broadcom BCM57414 | 2×10G/25G | 多队列，支持 SR-IOV | 标准 Linux 集群 |
实际采购时还要看驱动在目标内核版本上的稳定性。Intel 的 i40e 驱动和 Mellanox 的 mlx5 驱动更新较快，但部分旧内核需要升级。可以用 ethtool -i eth0 查看驱动、固件和总线信息；用 lspci -vvv -s 网卡地址 确认链路宽度，例如 LnkSta: Speed 8GT/s, Width x8 表示 PCIe 3.0 x8。如果发现网卡插在 PCIe 2.0 x4 上，那么即使端口是万兆，实际吞吐也远达不到预期。
三、万兆交换机选型不能忽略缓存与转发延迟
交换机的职责不是把端口插满就行。LVS 集群常见的流量不对称：北向入口可能是 10G，南向真实服务器如果是千兆，多个真实服务器同时响应会形成瞬时突发。交换机芯片如果没有足够的共享缓存，会直接丢弃报文，TCP 重传导致后端性能急剧下降。因此选型时优先选择数据中心级芯片，关注动态共享 buffer，通常 9MB 到 16MB 可应对大部分微突发，低于 4MB 的园区交换机不建议用于高并发 LVS 场景。
转发延迟方面，万兆交换机的直通转发模式可以做到几百纳秒，存储转发模式则在 1 到 3 微秒。对 LVS 四层转发来说，交换机延迟影响不如缓存丢包明显，但如果集群跨机柜、路径多跳，选低延迟交换机可以减少长连接抖动。同时要确认交换机对 VLAN、LACP、ARP 和未知单播的处理能力。LVS DR 模式中 VIP 会配置在真实服务器的 lo 接口上，交换机的 MAC 地址学习会看到同一 VIP 对应多个端口，如果开启过于严格的端口安全或 ARP 检测，会误判为欺骗而断流。
链路聚合配置推荐使用 LACP 动态聚合，负载分担算法选择三层加四层哈希。不要使用基于 MAC 的哈希，否则 LVS 出口流量都使用同一 VIP 的 MAC，可能全落到一条链路上。Linux 侧的 bonding 或 team 需要匹配交换机的 LACP 模式：
# 设置 802.3ad 聚合，按三层和四层信息做哈希 ip link add bond0 type bond mode 802.3ad xmit_hash_policy layer3+4 ip link set eth0 master bond0 ip link set eth1 master bond0
VLAN 隔离和监控也是选型考量。管理网、真实服务器网、外部服务网尽量划分独立 VLAN，避免广播风暴影响 LVS 软中断。选择支持 sFlow 或硬件计数器的交换机可以快速定位丢包发生在物理层还是队列。预算允许时，把监控流量镜像到独立端口，比在生产交换机上抓包更安全。
四、推荐组合与实际压测方法
如果从零搭建一套 LVS 高并发入口，预算允许的情况下推荐使用双路 Xeon 多核 CPU、Intel X710-DA4 四口万兆或 Mellanox ConnectX-5 双口万兆，接入数据中心级万兆交换机。LVS 节点采用 DR 模式，VIP 通过 keepalived 做主备，真实服务器配置 lo 上的 VIP 并抑制 ARP 响应。关闭 irqbalance，按队列数手动绑定网卡中断到固定 CPU，避免跨 NUMA 节点处理软中断。
压测时先用小包测试转发上限，不要直接用大包跑带宽。可以使用 pktgen、trafgen 或专业测试仪，观察 /proc/softirqs 中 NET_RX 和 NET_TX 的增长是否集中在少数 CPU。如果某几列数值暴涨，说明队列没有均匀分散。再来用 ipvsadm -L -n --stats 看每秒连接和报文数，使用 sar -n DEV 1 看网卡收发速率。将小包转发能力压到接近网卡理论值时，才能真正验证网卡和交换机的组合是否合格。
收集网卡计数器定位丢包点：
# 查看所有队列的丢包与缓存状态 ethtool -S eth0 | grep -E 'rx_missed|rx_no_buffer|tx_errors|rx_dropped'
如果 rx_no_buffer_count 或类似计数持续增加，说明内核或网卡队列的 buffer 不足，需要增大内核网络参数 net.core.netdev_max_backlog、net.core.rmem_max，或调整网卡队列长度。如果是交换机端口计数器出现 output drop，则需要扩大交换机缓存或调整后端速率收敛比。两者对应的优化位置完全不同，区分清楚才能避免盲目改参数。
最后形成一个检查清单：确认网卡 PCIe 插槽带宽充足、队列数等于 CPU 核数、RSS 哈希为四元组、网卡和交换机 LACP 哈希一致、VLAN 隔离无环路、交换机动态缓存不低于 9MB。满足这些条件后，LVS 节点才有机会把万兆带宽和调度能力同时发挥出来，避免出现网卡换了、交换机也换了，性能却没达到预期的尴尬。