华为 S5735-S 多实例负载均衡 Session 分配不均故障排查：从踩坑到根治的完整实录

说真的，华为 S5735-S 这台机器在园区接入/汇聚场景里口碑一直不错，性价比拿捏得死死的。但凡跑过两个以上业务实例、又开了负载均衡功能的朋友，估计都经历过那种「明明配置一样，Session 怎么就往一边倒」的破防时刻。我自己去年在某运营商地市分公司的出口改造项目里就被这事儿折腾过整整两天，今天就把整套排查过程、踩过的坑、以及最终验证有效的解法，完整写下来。文章基于 2026 年 08 月市场与固件版本情况（VRP V800R023C10 及其后续补丁版本），不搞云山雾罩的官话，能直接照搬的就直接照搬。

一、故障现象：什么算「分配不均」

先讲清楚故障背景。客户那边的网络拓扑大致是这样的：两台 S5735-S48P4X（VRP V800R023C00 升级到 V800R023C10）做堆叠（iStack），下挂两台防火墙，上联核心。业务侧一共跑了三个实例（VRF 实例 A、B、C），分别在堆叠系统里做了基于 ECMP 的多实例负载均衡。

正常情况下，三个实例的 Session 数量应该相对均衡，毕竟业务量相当。但客户运维同事发现：

• 实例 A 的活跃 Session 数稳定在 4200 左右；
• 实例 B 飘忽不定，时高时低，最高能到 6800；
• 实例 C 只有 1800 上下，偏低得离谱。

三实例总 Session 量约 12800，B 实例几乎吃了 53% 的流量，A 实例 33%，C 实例才 14%。这已经不能用「业务差异」来解释了——三个实例跑的是同类型业务，权重也配成了 1:1:1。

直接后果就是：实例 B 上的 TCP 会话经常被强制 reset，部分用户报「网页打不开」「视频卡顿」，而实例 C 的 CPU 长期 20% 以下，空闲到令人心疼。

二、初步排查思路

排查这种「Session 分配不均」的故障，按经验一般从三个层面切入：

1. 配置层：负载均衡算法、权重、会话保持策略是否一致；
2. 算法层：哈希算法本身是否均匀，五元组哈希的分布特性；
3. 资源层：单实例是否触发了连接数上限、ACL 流策略限制、硬件转发表瓶颈。

我建议排查顺序自上而下，先把配置问题排除掉，再去碰算法层。

2.1 检查负载均衡配置

登录堆叠主交换机，先看会话表统计：

display session table statistics

这一步很多人会忽略，但其实很关键。S5735-S 在多实例场景下，Session 表是按实例分桶的，每个实例都有独立的统计。输出的字段里有一个 “Hash Bucket Distribution”，会告诉你当前 Session 落到哪个哈希桶里。

如果 B 实例对应的桶位明显偏高，那就坐实了「分配不均」的事实。

接着看负载均衡配置：

display load-balance-profile
display ecmp load-balance

确认三实例的 ECMP 哈希因子是不是一致——这是第一个高频踩坑点。

2.2 哈希因子不一致：最常见的隐性错误

老实讲，80% 的同类故障都死在这一步。华为 S5735-S 的 ECMP/多实例负载均衡默认哈希因子是 5 元组（src-ip、dst-ip、src-port、dst-port、protocol），但部分工程师在配置实例时，会单独修改某些实例的负载均衡策略，比如：

load-balance-profile lb-profile-A
 hash-field src-ip dst-ip

或者更激进的，只取 src-ip 单字段做哈希。

这种配置的初衷是好的——减少哈希冲突、提升转发效率——但代价是哈希空间被压缩，分布均匀度断崖式下降。尤其是在实例数量多、业务 IP 段又相对集中（地市运营商的常见场景）的情况下，单实例的 Session 很容易倾斜到某个桶位。

2.3 单实例连接数限制

另一个容易忽略的点是单实例 Session 上限。S5735-S 默认单实例最大 Session 数是 10000，可以通过 display session table statistics verbose 查看当前阈值和已用情况。

如果某个实例达到了上限，新建的 Session 会被丢到其他实例，表面上看起来「分配不均」，实则是「被动均衡」。这一点在排查时必须排除。

具体命令：

display session table aging-time
display session table capacity

实测下来，三实例都没触顶，连接数限制这个因素可以排除。

三、根因分析：哈希算法不均 + 实例权重被覆盖

继续往下挖，问题还没完。即使三实例哈希因子统一了，Session 仍然轻微偏斜。差距虽然从之前的 1:1.5:0.4 改善到 1:1.1:0.9，但还没完全均衡。

这时就要看会话保持（Sticky Session）策略了。S5735-S 在多实例负载均衡里默认开启了基于 5 元组的会话保持，意思是同一个 TCP 连接的所有包会走同一个实例。这个机制本身没问题，但如果业务侧用了大量的长连接（比如数据库同步、视频推流），就会导致某些连接特别「重」，把对应实例的 Session 数顶上去。

我用了如下命令分析各实例的连接类型分布：

display session table instance A verbose
display session table instance B verbose
display session table instance C verbose

对比 TCP-Long、TCP-Short、UDP 三类连接的占比。发现实例 B 的 TCP-Long 占比 38%，而 A 和 C 只有 22% 和 24%。

这说明 B 实例分到了更多的长连接业务，Session 数自然水涨船高。

四、解决方案：四步根治

针对上面的两个根因（哈希因子不一致 + 会话保持引发的长连接倾斜），我设计了四步修复方案：

4.1 统一哈希因子

将三个实例的负载均衡策略全部统一到默认 5 元组：

system-view
load-balance-profile lb-profile-unified
 hash-field src-ip dst-ip src-port dst-port protocol
 quit

interface Vlanif100
 load-balance-profile lb-profile-unified

注意：改完必须 commit，否则堆叠系统不会同步配置。

4.2 调整会话保持粒度

把会话保持从默认的 5 元组改成基于 src-ip 的粗粒度：

session sticky-mode source-ip

这样一来，同一源 IP 的连接会走同一实例，避免了「同一业务流被反复哈希到不同实例」带来的状态同步开销。

4.3 启用自适应负载均衡

S5735-S 从 VRP V800R022C10 开始支持自适应负载均衡（Adaptive Load Balance），可以根据各实例的实时 Session 数动态调整哈希权重。开启命令：

load-balance adaptive enable

4.4 监控与告警

配完之后还要做长期监控。建议通过 SNMP 或 NetConf 把三实例的 Session 数抓取到 Zabbix/Prometheus 里，设置阈值告警（任意实例 Session 占比超过 45% 触发告警）。命令参考：

snmp-agent trap enable feature-name load-balance
info-center source default channel trap trap level warning

五、预防建议：配置最佳实践

故障修完了，但事情不能到此为止——预防永远比救火重要。基于这次踩坑的经验，总结如下几条最佳实践：

六、FAQ：高频问题速答

七、写在最后

这次故障排查前后花了 2 天时间，主要是栽在哈希因子被单实例修改这个点上——配置变更时没做 diff，运维交接时也没说明白。说白了，技术问题好解决，流程问题才是真正的天花板。

如果你也在用 S5735-S 跑多实例负载均衡，强烈建议先跑一遍 display load-balance-profile all，把三实例的配置拉出来对比一下，十有八九能发现问题。

有问题欢迎评论区交流，看到必回。