在vSphere的设计案中，实质上，有大量的关键都在vSwitch和Load Balancing Policy这边，可以这样说：针对这个部分的设计，关系到整个虚拟数据中心的性能问题，经验来看，很多设计的败笔都在这边，也很少设计详细解读这个。所以，这里我们针对这个部分做一个简单的解读，以作抛砖引玉之举；
根据猫猫作为讲师多年的接触来看，绝大多数的人在选择Load Balancing Policy的时候，都会选择IP Hash，当然，不是说这个不好，相反，在vSS结构下，这是唯一一个具备真正意义上负载均衡能力的策略，有了它，就可以较大程度增强整体网路性能。当使用vDS时，很多人依然延续了这个习惯，还是选用IP Hash这个选项作为负载均衡策略，而Route based on physical NIC load这个选项，基本上是被忽略掉的，而且，由于VMware的ICM教材设计中，拿掉了vDS部分，结果，几乎很少人知道这个Route based on physical NIC load的策略。
下面，猫猫就这两个部分分别做一个阐述；
IP Hash
选择IP Hash作为Load Balancing Policy的一个最核心的理由就是：它可以聚合多条上行链路来增加带宽，不过，遗憾的是，即使增加再多的Uplinks，一样很难增加虚拟机的可用带宽比例；
IP Hash是如何工作的？
很多人都知道IP Hash的大体情况，但是，在通过一个设定了IP Hash这个Load Balancing Policy的Portgroup执行流量传输时，到底是如何工作的呢？
基于源和目标IP地址的聚合在VMkernel里执行计算，再将负载通过vSwitch分发到所有可用pNICs上。关于Outbound NIC的选择的计算方式，可以参考 NIC Teaming中Load Balancing策略里IP Hash的计算方式讲解，IP Hash在源和目标IP地址之间的计算会被转换成16进制的值，然后通过所有可用的Uplinks去进行传输，例如：
本里种，虚拟机开启2个对外连接，1个连接到备份服务器，1个连接到应用程序服务器，vSwitch配置了2个Uplinks，如下图：
游客，如果您要查看本帖隐藏内容请回复
如下图所示：
IP Hash会对每个外出的连接在源和目标IP地址之间进行路由、Hash计算，然后，vSwitch负责将不同的连接分发到所有的可用Uplinks。然而，由于pNIC和vNIC之间的关联，任何连接都是一个基于基础流量 的连接。任何的连接的流量都不可能跨Ulinks。这就意味着，单一连接绝对受制于单一物理网路卡的带宽。
关于IP Hash的配置，在网路层需要执行下列配置：
- EtherChannel - IP Hash的配置是在vSwitch上完成的，但是，还要求在pSwitch上配置EtherChannel。利用EtherChannel，才可以确保在多端口之间执行Load Balancing。如果不用IP Hash，则VMkernel这边只会接收来自vNIC指定MAC地址的单一连接信息。结果就是，当Session存在时，则其它 的Sessions就会被drop掉。当IP Hash选中之后，则VMkernel将会在所有处于活动状态的NICs上接收Inbound MAC地址；
- EtherChannel配置 - 以前的vSphere不支持动态的Link Aggregation Channel Protocol（LACP），所以，在5.0以前只能设置静态绑定，5.1以后就可以通过vSphere Web Client进行配置LACP了；
- 交换机配置 - vSphere支持从1台pSwitch到vSwitch的EtherChannel。pSwitch可以是单独的pSwitch，也可以多台pSwitch执行堆叠之后逻辑上的1台pSwitch，不支持没堆叠的多台pSwitchs的EtherChannel；
正常情况下，每个Connection都会在VMkernel上做一个合适的Uplink选择，因此，在VMkernel上会产生额外的计算开销。如果1台VM是一个前段应用，且大部分时间都在和后端数据库通讯，则IP Hash的计算就毫无意义，因为VMkernel会对95%里每个连接选择相同的Uplink，因为Hash计算后，会得到同一个Hash值，因此，就不会调整物理链路，这样看来，负载均衡效果就几近于无。
下面的例子就是一个比较有代表性的例子，多了1台VM3，需要去到Backup Server，此时，就会出现某张物理网路卡的负载多1个连接，下面的2张图就清晰的阐述了这个事情：
游客，如果您要查看本帖隐藏内容请回复
备注：在IP Hash结构下，关于Network failover detection Beacon Probing的配置，是没用的，因为当使用EtherChannel时，Beacon Probing时无法正常工作的。默认亲故扛下，ESXi会广播beacon包到NIC Teaming里所有的Uplinks，pSwitch会转发所有的包到其它端口上，在EtherChannel模式下，pSwitch不会发送封包，因为在它眼中，眼下只有1条通道，此时，没有beacon包会，网路就会异常；
Route based on physical NIC load
介绍完IP Hash之后，就轮到介绍LBT了，这个选项第一次出现在vSphere 4.1版本，只能结合vDS使用。Route based on physical NIC load，通常被简称为LBT（Load Based Teaming），LBT会根据虚拟机的网路I/O负载，结合NIC Teaming里的pNICs，来将对应的流量分配到对应的pNIC上；
LBT是如何工作的？
Load Based Teaming会将vNICs映射到pNICs，然后，当某条Uplink上的负载达到指定阀值时，会再重新建立vNIC > pNIC的映射关系。LBT使用类似Originating port id的Load Balancing Policy来执行初始化端口分配，初始状态下，第一张vNIC会被关联到第一张pNIC，第2张vNIC会被关联到第二张pNIC，完成初始化分配之后，LBT会在NIC Teaming的每条上行链路监测Ingress和Egress的流量，然后如果上行链路拥塞，则LBT就会重新调整vNIC到pNIC的映射关系。NIC Teaming里LBT的检测会在Uplink的使用率超过75%，且峰值持续时间超过30s时，就会触发LBT的调整；
LBT会要求对端的pSwitch的对应接口配置为Access或者Trunk模式。LBT不支持EtherChannels，因为它的工作原理就是在接入到vDS上的所有Uplinks之间进行Floating流量处理。即使LBT带来的流量重分配不一定会经常发生，但是，依然在这种模式下，依然建议在对端pSwitch上激活PortFast或TrunkFast模式；
VMkernel也会在不停的监测通道拥堵状况，因此，对于VMkernel也会有额外负载产生，不过，它的开销和originating port-id差不多；
看看下面的2张示意图：
看看上图中左边和右边的差异，当左边VM1和VM2的流量都通过NIC1传输时，会导致NIC1的负载超过75%打到Total的80%左右，而NIC2的负载较小，因此，当30s后依然是这个状况，LBT就会激活重新建立vNIC > pNIC之间的映射关系，重新Map之后，就可以看到上图中右边部分，负载均衡在了NIC1和NIC2，均衡传输；
尽管LBT没有整合到DRS里面，但是，实质上当DRS切换VM时，VM到新的ESXi Host上后，会根据vNIC的负载，来重新构建vNIC到pNIC的映射关系，因此，变相实现了DRS的某种能力。