企业官网建设流程全解析

前言

在vSphere分布式交换机DVS环境中，很多运维在端口组内一次性添加3条Uplink上行链路，期望虚拟机流量自动分摊到3块物理网卡，实现带宽叠加与链路冗余。部署完成后监控流量却发现：无论虚拟机业务负载高低，所有VM流量始终只跑在其中一条Uplink，剩余两条上行链路流量几乎为0，没有负载分担效果。

很多人第一时间怀疑物理交换机、网卡或者DVS故障，反复检查vSphere网络配置，却忽略DVS端口组Uplink链路角色与负载均衡算法的基础机制。

核心原因：检查端口组内Active/Standby Uplink角色配置，DVS默认负载均衡策略为基于源端口哈希（Source Port ID Hash），该策略下单台虚拟机流量只会固定走一条上行链路。本文拆解DVS上行链路角色、负载均衡原理，完整排查步骤，不同负载均衡适用场景，适合vSphere7/8 DVS网络运维排错。

前置说明：本文针对vSphere Distributed Switch（DVS分布式虚拟交换机），区别于标准vSwitch；DVS的负载均衡、故障切换策略在端口组级别独立生效，不同端口组可以使用不同策略。修改DVS网络配置建议在维护窗口操作，避免虚拟机网络短暂中断。

故障现象

DVS分布式交换机绑定3条物理Uplink网卡，端口组内已经添加全部3条上行链路。 虚拟机部署在该端口组，业务跑起来后，在ESXi主机或者物理交换机监控端口流量：

• 仅有一条Uplink存在业务流量，另外两条Uplink流量接近0
• 虚拟机迁移到另一台主机后，流量切换到另一根Uplink，但依旧是单链路跑流量
• 链路状态正常，无端口down、无丢包，链路故障切换功能正常，一旦在用Uplink断开，VM流量可以自动切换至剩余链路
• 管理员预期实现3条链路带宽叠加，实际只有单链路承载业务，无法利用其余上行带宽

DVS上行链路角色与负载均衡原理

DVS端口组内Uplink分为三类角色：Active uplink（活动链路）、Standby uplink（备用链路）、Unused uplink（未使用链路）。 只有标记为Active的链路，才会参与负载分担；Standby链路仅做故障冗余，Active链路故障时才启用；Unused链路全程不会被使用。

vSphere DVS默认负载均衡策略：基于源端口哈希（Source Port ID Hash）该算法的核心规则：

1. 单台虚拟机对应的虚拟网卡，只会映射到唯一一条Active Uplink。无论虚拟机带宽占用多高，这台VM所有进出流量都固定在同一条上行链路。
2. 多台不同虚拟机，会根据源端口哈希分配到不同Active上行链路，实现多VM之间的负载分担。
3. 此策略不能实现单台虚拟机跨多条上行链路带宽叠加，这是最容易产生误解的关键点。

举个例子：端口组3条Uplink全部设置为Active，使用默认源端口哈希策略。 三台虚拟机，可能VM1走Uplink1，VM2走Uplink2，VM3走Uplink3；但其中任意一台虚拟机，永远不会同时跑在两条Uplink上。如果只有一台业务虚拟机，那么永远只占用一条上行链路，其余两条空闲。

完整排查步骤（由简到繁）

第一步：查看DVS端口组Uplink角色（核心检查项）

登录vSphere Client，进入DVS分布式交换机，找到目标虚拟机端口组：

1. 编辑端口组设置，切换到【Teaming and Failover（绑定和故障切换）】页面。
2. 查看三条Uplink的角色：Active、Standby、Unused。

   高频问题：很多运维添加了3条Uplink，但其中两条被误配置为Standby，仅一条Active。此时无论负载均衡策略是什么，流量只会跑唯一一条Active链路，其余链路仅故障备用。 修正方案：如果希望三条链路参与负载分担，需要将全部3条Uplink设置为Active。

第二步：确认负载均衡策略，理解源端口Hash限制

在同一个【绑定和故障切换】页面，查看负载均衡类型：

• 默认选项：基于源端口ID哈希（Route based on source port ID），也就是Source Port Hash。

  该策略下，单VM流量只能走单条Uplink，不是故障，是算法本身设计。 如果业务场景需要单台虚拟机多链路带宽聚合，不能使用源端口哈希，需要更换策略。

DVS支持的负载均衡策略简要说明：

1. 基于源端口ID哈希（默认）：多VM负载分担，单VM固定单链路，不需要交换机特殊配置。
2. 基于源MAC哈希：按虚拟机网卡MAC分配上行链路，效果和源端口哈希接近。
3. 基于源和目的IP哈希：需要物理交换机端口开启静态LACP，支持跨链路分担同一虚拟机不同IP会话流量。
4. LACP（动态链路聚合）：物理交换机开启LACP，DVS启用LACP，实现真正链路聚合。

第三步：检查DVS上行链路绑定，确认物理网卡状态

1. 回到DVS主页，管理上行链路，确认ESXi主机上3块物理网卡都成功绑定为DVS的Uplink，网卡状态正常，无断开。
2. 确认物理网卡速率协商正常，没有协商成百兆，物理端口无CRC错误、丢包。

   若物理网卡存在硬件故障，网卡会被标记为down，不会参与流量转发。

第四步：物理交换机配置核查

如果准备使用IP哈希或LACP策略，物理交换机必须配套配置，否则负载分担失效。

• 源端口哈希策略：交换机无需任何聚合配置，普通access/trunk端口即可。
• IP哈希：交换机端口配置静态链路聚合组。
• LACP：交换机开启LACP动态聚合。

  仅修改DVS策略，交换机不配置聚合，会出现网络不通、丢包。

第五步：验证流量分配效果

修改完成后，可以通过两种方式验证链路分配：

1. vSphere性能图表：选中DVS上行链路，监控每个Uplink的网络吞吐量。
2. ESXi CLI查看虚拟机网卡对应的上行链路：

netstat -S -i vsish -e get /net/portsets/DvsPortset-0/ports

查看虚拟机虚拟端口对应的uplink，确认哈希分配结果。

高频误区总结

误区1：端口组添加多条Uplink，单台VM就可以叠加多条链路带宽

纠正：默认源端口哈希策略，单VM流量只会跑在一条Active上行链路，多条Active链路只能实现多台虚拟机之间的负载均衡，不能提升单VM带宽。想要单VM多链路聚合，需要LACP/IP哈希+交换机聚合配置。

误区2：Uplink添加到列表里，就自动参与负载分担

纠正：Uplink角色至关重要，Standby链路只做故障备份，平时不转发流量。需要负载分担，必须把链路设置为Active。

误区3：Active链路越多，性能一定越好

纠正：Active链路数量匹配业务规模即可。链路过多，哈希调度分散，一旦某条链路故障，会导致大量虚拟机重新哈希，产生流量震荡。

误区4：DVS和标准vSwitch负载均衡机制不一样

纠正：标准vSwitch与DVS的Teaming负载均衡算法逻辑完全一致，默认都是源端口哈希。

误区5：更换策略后立刻看到流量均分

纠正：哈希分配是基于虚拟机端口/会话，虚拟机已经运行时，端口哈希绑定关系不会实时刷新。必要时重启虚拟机，让哈希重新分配上行链路。

不同业务场景推荐配置方案

场景一：虚拟化基础业务，只需要链路冗余，多台虚拟机分担流量 推荐配置：多条Uplink全部Active，负载均衡保持默认【基于源端口ID哈希】，交换机无需聚合。 特点：配置最简单，稳定可靠，单虚拟机带宽上限等于单网卡速率，链路故障自动切换。

场景二：业务虚拟机需要单VM更高带宽，存储/大流量业务 推荐配置：DVS启用LACP，物理交换机配置LACP聚合组，Uplink全部Active。 特点：真正链路聚合，单台虚拟机流量可以跨多条上行链路分担，配置复杂度高，需要交换机配合。

场景三：南北向多IP业务，虚拟机多IP访问不同外部地址 推荐配置：负载均衡切换为【基于源和目的IP哈希】，交换机配置静态聚合。

生产环境最佳实践

1. 区分需求：优先确认需求是链路冗余，还是单虚拟机带宽叠加。大部分虚拟化业务仅需要冗余，默认源端口哈希完全够用，无需改动。
2. 规划Active/Standby：一般生产环境推荐N条Active + 1条Standby，保留专门冗余链路，避免全部Active下链路故障时大规模虚拟机重哈希。
3. LACP场景提前测试：LACP配置改动风险更高，上线前必须测试链路故障切换，确认无断流。
4. 端口组复用策略：DVS不同端口组可以独立配置Teaming策略，业务端口组和vMotion、存储端口组分开配置，不要混用同一端口组。
5. 监控上行链路流量：定期监控DVS各Uplink带宽，发现负载严重不均衡，可以评估调整哈希策略或调整Active链路数量。
6. 网络变更操作：修改端口组Teaming配置会短暂重置虚拟机网络，业务虚拟机尽量在维护窗口操作。

结语

DVS端口组添加3条Uplink，但虚拟机流量只走其中一条链路，优先检查端口组内Active和Standby Uplink角色配置；DVS默认负载均衡策略是基于源端口hash，该算法下单台虚拟机流量只会固定使用一条上行链路。 排查顺序优先确认Uplink角色，再确认负载均衡算法，区分业务是需要多VM负载分担，还是单虚拟机带宽叠加。理解源端口哈希的限制是解决该问题的核心；如果业务需要单VM跨链路带宽聚合，则需要搭配LACP或者IP哈希，并同步在物理交换机上配置链路聚合。