VMware ESXi6.7 Teaming 分析与故障一则

先说故障：

在一个VC内新建了一个虚拟端口组，VLAN 129，并未做其他任何配置。交换机与ESXi服务器之间有两个端口互联，交换机端口配置为聚合。之前该VC内其他VLAN运行正常。故障现象为新增的VLAN内的两台主机，向外访问正常，但客户端无法正常访问VLAN 129内的服务器，ping丢包严重，随便中断交换机与ESXi主机之间的任一端口，网络访问恢复正常。故确认该故障肯定与交换机上的端口聚合配置有关。

背景知识---ESXi交换机的Load Balancing机制

在ESXi6.7环境下，ESXi有5种负载均衡机制，其实这个机制从15年开始就几乎没有再发生变化了，所以这篇文档应该也适用于之前的ESXi版本。

Route Base on Originating Virtual Port，基于初始的虚拟端口

这个模式很好理解，这台虚拟机的第一个流量是从哪个uplink走的，那么这台虚拟机未来的所有流量都将通过这个uplink。

怎么确定第一个报文走哪个uplink呢？通过虚拟机的Port ID和NIC Teaming的uplink数量来进行计算。虚拟机的Port ID在以下情况下会发生改变，分别是关机，迁移和删除，也就是说只要虚拟机一直运行在一台ESXi上，使用这种负载均衡机制下，这台虚拟机的数据流将永远只跑在一个物理端口上。

优点：

如果虚拟网卡（口）数量多余物理网卡（口）数量，那么这种分配方式总是平均的。
资源消耗低，因为虚拟机只计算一次uplink端口即可，除非重启，迁移和删除。
不用修改物理交换机的配置。这点其实是最吸引人的，物理交换机的端口几乎只需要配置一个trunk和vlan修剪，关闭STP或者开启PortFast就好，配置风险非常低。

缺点：

负载不均衡。虚拟交换机不会感知流量，有可能出现ESXi的一个物理端口流量已经爆掉，但其他端口没流量的极端情况。
虚拟机的带宽被一个物理端口的速率限制了。

总结：懒人配置首选，不易出错，但性能也不高，不亏是ESXi的默认选项。

2. Route Base on Source MAC Hash，基于源MAC地址HASH

与上面一种方式类似，只是现在会对每一个数据包进行检查，检查数据包的源MAC，并确认uplink。

优点：

更均衡，因为每一个包都会被检查MAC地址。但我觉得这个理由很牵强，除非一个虚拟网卡有多个MAC地址，否则MAC和第一种方式里的Port ID一样，都是唯一标识一台虚拟机网卡的信息，不存在更均衡的现象。
流量固定。只要这台虚拟机还在这台ESXi上，那么即使它重启了，它的数据流量还是经过固定的uplink。
不用修改物理交换机的配置

缺点：

如果虚拟机只有一个MAC地址，那么它的带宽也被物理端口的速率所限制。
高资源占用，毕竟每个包的MAC地址都要看一遍。
虚拟交换机无法感知流量。

总结：不做推荐的一种方式，可能在某些特殊的情况下有用，但性能不高，损耗略大。

3. Route Base on IP Hash，基于IP HASH

基于源IP和目的IP的负载均衡。虚拟交换机检查每一个数据包的源IP和目的IP地址，并执行XOR运算，之后再与网卡数量进行以此计算，得出一个0至网卡数量-1之间的值，该值则是这个数据包将发送出去的网卡编号。对于非IP数据包则取其中32bit数据进行计算。

这个方式在IP地址较多的环境内，可以有效利用该ESXi上几乎所有的带宽资源。但在较小环境内，比方说一台web前端服务器和一台数据库服务器，由于它们的源和目的IP地址不会发生改变，它们之间的流量几乎只会跑在一个uplink上，并不能完全利用所有带宽。

配置要求：

ESXi主机只能与一台交换机或者堆叠的交换机之间进行IP Hash。堆叠包括虚拟堆叠。
ESXi主机只支持静态的802.3ad，标准虚拟交换机只支持静态的Etherchannel。这个说法很迷，我要去确认下，意思是分布式虚拟交换机只支持LACP，而静态虚拟交换机只支持Etherchannel么？

优点：

负载更加均衡。嗯，终于可以把一台虚拟机一块网卡的流量分配到不同的uplink上了。
与多IP地址进行通讯时，更高的吞吐。

缺点：

高负载，因为每个包都要拆开来看一眼。
虚拟交换机不感知uplink的实际负载。
需要修改交换机配置及更复杂的故障排错。这点是最伤的，尤其是对于做了虚拟堆叠的交换机，本来就已经有几百个接口了，现在每个ESXi主机还要再多出来一个端口，有些品牌的交换机还很难查聚合口对应的物理端口，简直了。

4. Route Based on Physical NIC Load，基于物理网卡负载

虚拟交换机先基于Originating Virtual Port来进行流量转发，然后每隔30秒检查一次所有物理网口的负载情况，如果流量负载高于75%，则尝试将IO最高的虚拟机迁移到其他uplink上。

这个模式仅在分布式虚拟交换机上支持。

优点：

低资源占用，第一做转发的时候只计算一次uplink，与方法1相同。
终于可以感知物理网卡的实际负载了。
不必修改物理交换机配置。

缺点：

与方法1和方法2相同，带宽也被物理端口的速率所限制。
流量震荡，如果被迁移走的虚拟机IO非常高，那么它无论在哪个uplink上都会导致每30秒一次的流量震荡，就这样不停的切来切去，虽然实际上每隔30秒让交换机刷新一次几个端口的mac表也没什么，但多少有点不好意思吧。

5. Use Explicit Failover Order，显式故障转移

没什么好说的，严格按照Failover里配置的网卡顺序进行uplink选择，没有所谓的负载均衡概念。

故障解释

回到故障本身，该故障是由于错误的配置虚拟交换机的Load Balancing模式导致的。交换机上配置了端口聚合，而ESXi的虚拟端口组则选择了默认的基于初始的虚拟端口的路由转发策略。但又是为什么导致了由服务器出去的报文正常，而客户端访问服务器的数据大量丢包的现象呢？

参考H3C交换机端口聚合的配置说明，对于未指定的聚合负载配置，默认的负载配置为”packet type-based sharing“，按照H3C的解释，这个模式是按照报文协议，二层和三层的
方式来对报文进行分类，然后进行负载均衡。可如果按照H3C的这个解释，我们之前的故障就不该发生，ping包就不该丢失这么多，因为同样的源/目的IP，源/目的MAC，源/目的端口，应该是会分配到同一个路径上的，应该要么全通，要么全丢，而不是通一半丢一半的情况。

所以说，H3C肯定对于 ”packet type-based sharing“的机制解释有错误。

故障规避方法

在这个案例中，我们无法规避这个故障。端口聚合在设计之初也的确考虑过这个问题，因而可以将聚合端口配置为edge-port，避免因为我们这样的错误配置而导致问题。但edge-port只支持LACP模式，也就是动态模式下才能配置edge-port，而ESXi主机只能支持静态的端口聚合。所以在这样的场景下，我们无法规避这样的故障，只能配置时自己小心谨慎。

打赏