简介： 
1) 3种类型的VMware网络都支持NIC Teaming ，详细请参考《VMWare ESX Server中的网络设置》(VMkernel, Service Console和VM port group）
2) uplink连接到那些物理交换机的端口都必须在同一个广播域中。（也就是必须在同一个VLAN中，不能跨路由）
3) 如果uplink要配置VLAN，则每个uplink必须都配置成VLAN Trunk并且具有相同的VLAN配置。
4) VMware的负载均衡(Load Balancing)只是出站(Outbound)的负载均衡，因此要做到Inbound的负载均衡，必须在物理交换机上做同样IP Hash方式的配置。
5）NIC Teaming的Load Balancing和一些高级路由算法的Load Balancing不同，它不是按照Teaming中网卡上通过的数据流量来负载均衡，而是根据网卡上的连接(connection)来进行负载均衡。
VMware的3种负载均衡 
VMware的NIC Teaming Load Balancing策略有3种。
(1) 基于端口的负载均衡(默认)
(2) 基于源MAC的负载均衡
(3) 基于IP hash的负载均衡 

1. 基于端口的负载均衡 (Route based on the originating virtual port ID) 
这种方式下，负载均衡是基于vPort ID的。一个vPort和Host上的一个pNIC(从vSwitch角度看就是某个uplink)捆绑在一起，只有当这个pNIC失效的时候，才切到另外的pNIC链路上。这种方式的负载均衡只有在vPort数量大于pNIC的数量时才生效。
什么是vport？一个VM上的vNIC或者某一个VMKernel或者Service Console的某个vswif。用一个图来直观的表述，vPort在下图中显示为vSwitch上左侧的那些绿点。而pNIC在图中显示为右边的vmnicX。

对于VM来说，因为某台VM的vNIC是捆绑在某一个pNIC上的，也就是说这台VM(如果只有一个vNIC的话)对外的数据流量将固定在某一个pNIC上。这种负载均衡是在VM之间的均衡，对于某一台VM而言，其uplink的速率不可能大于单个pNIC的速率。此外，只有当VM的数量足够多，并且这些VM之间的数据流量基本一致的情况下，Host上的NIC Teaming的Load Balancing才较为有效。对于以下这些极端情况，基于端口方式的负载均衡根本不起作用或者效果很差，充其量只能说是一种端口冗余。
(1)Host上只有一台只具有单vNIC的VM (此时完全没有Load balancing)
(2)Host上的VM数量比pNIC少(比如有4台VM但是Teaming中有5块pNIC，此时有一块pNIC完全没用上，其他每个vNIC各自使用一块pNIC，此时也没有任何负载均衡实现)
(3)Host上虽然有多台VM，但是99%的网络流量都是某一台VM产生的
这里还可以参考VMware esx5i负载均衡分析：
最近对esx5i负载均衡策略中的默认“基于源虚拟端口ID的路由”做了一些分析，非常有意思分享给大家。
先描述一下场景：
一台ESX5i服务器有6台VM（姑且用VM1、VM2、VM3、VM4、VM5、VM6来称呼），两块物理网卡做负载均衡（依次显示vmnic0和vmnic1）—默认的做法，两网卡分别依次对应到对端Cisco 2950上的fa0/1和fa0/2口上，通过分析cisco2950上MAC表来分析vmnic0或vmnic1承载VM的数量。
1：依次启动VM虚拟机，VM1走vmnic0，VM2走vmnic1，VM3走vmnic1，VM4走vmnic0，VM5走vmnic0，VM6走vmnic1。
VM1、VM4、VM5走的是vmnic0网口
VM2、VM3、VM6走的是vmnic1网口
2：shutdown vmnic1对应的网口后，VM2、VM3、VM6自动转移到vmnic0上承载。后重新开启vmnic1后，VM2、VM3、VM6自动又转移回vmnic1上
3：人为关闭VM2、VM3、VM6虚拟机，VM1、VM4、VM5并没有自动转移到vmnic1上，哪怕是一个VM，关闭VM1后又重启，发现VM1走到了vmnic1上了。
总结：
1：在默认的“基于源虚拟端口ID的路由”策略下，每一个VM的数据流（上下行）实际上跑的是一个网口（vmnic1或vmnic0）,也就是说任何一个VM虚拟机的数据流并没有被这两个网口分担。
2：初始开启的VM虚拟机使用哪一个网口来负载的判断原则是网口上承载VM的数量，而不是网口自身资源的负载压力，这样的判断原则有可能会出现有的网口压力非常大，而有的网口非常闲置。
3：系统正常运行中（上述1），添加网口vmnic2，则虚拟机会重新分配负载平衡，数量是2—2—2模式(三网卡模式下)。
4：添加和删除网口，对极个别VM会造成一个包的丢失。
5：建议大家根据VM的要承载数据量的大小，使用vmnetwork端口组中负载均衡设置，人为的指定承载网口和待定网口，最优化使用网口资源。
其实这个基于端口和mac地址准确的说应该不是叫负载均衡，理解为冗余更好点，这个均衡应该理解为按端口或者mac平均哼配，测试过就算一张卡的吞吐率到达50%，也不会切换的，所以准确地说这前两个应该理解为连接数平均，最后个IP Hash才是真的负载均衡，这个时候交换机设置为两层的EthernetChannel，配置负载模式为Src xor des ip。
2. 基于源MAC地址的负载均衡 Route based on source MAC hash 
这种方式下，负载均衡的实现是基于源MAC地址的。因为每个vNIC总是具有一个固定的MAC地址，因此这种方式的负载均衡同基于端口的负载均衡具有同样的缺点。同样是要求vPort数量大于pNIC的时候才会有效。同样是vNIC的速率不会大于单个pNIC的速率。
3. 基于IP Hash的负载均衡 Route based on IP hash 
这种方式下，负载均衡的实现是根据源IP地址和目的IP地址的。因此同一台VM(源IP地址总是固定的)到不同目的的数据流，就会因为目的IP的不同，走不同的pNIC。只有这种方式下，VM对外的流量的负载均衡才能真正实现。
不要忘记，VMware是不关心对端物理交换机的配置的，VMware的负载均衡只负责从Host出站的流量(outbound)，因此要做到Inbound的负载均衡，必须在物理交换机上做同样IP Hash方式的配置。此时，pNIC必须连接到同一个物理交换机上。
需要注意的是，VMware不支持动态链路聚合协议(例如802.3ad LACP或者Cisco的PAgP)，因此只能实现静态的链路聚合。(类似于HP的SLB)。不仅如此，对端的交换机设置静态链路聚合的时候也要设置成IP Hash的算法。否则这种方式的负载均衡将无法实现。
这种方式的缺点是，因为pNIC是连接到同一台物理交换机的，因此存在交换机的单点失败问题。此外，在点对点的链路中（比如VMotion），2端地址总是固定的，所以基于IP Hash的链路选择算法就失去了意义。
4. 总结 
不管采用以上哪一种方法的Load Balancing，它会增加总聚合带宽，但不会提升某单个连接所获的带宽。为啥会这样？同一个Session中的数据包为啥不能做到Load Balancing？这是因为网络的7层模型中，一个Session在传输过程中会被拆分成多个数据包，并且到目的之后再重组，他们必须具有一定的顺序，如果这个顺序弄乱了，那么到达目的重组出来的信息就是一堆无意义的乱码。这就要求同一个session的数据包必须在同一个物理链路中按照顺序传输过去。所以，10条1Gb链路组成的10Gb的聚合链路，一定不如单条10Gb链路来的高速和有效。
【选择】
那么应该选择哪种NIC Teaming方式呢？大拿Scott Lowe建议：
如果使用链路聚合，必须设为“Route based on IP hash” 
如果不是使用链路聚合，可以设为任何其它设置。大多数情况下，接受默认设置“Route based on originating virtual port ID”是最好的。

源链接：http://bbs.vmsky.com/forum.php?mod=viewthread&tid=36574&highlight=%E7%BD%91%E7%BB%9C%E8%B4%9F%E8%BD%BD


 

------------------------------------------------------------------------------------------------------------------------------------------------

In the ESX case, the vSwitch fully supports VLAN tagging. How does this help you? Instead of having to provide a separate network card for every VLAN you’re connecting into your ESX server, you can trunk them all onto the same physical NIC. Doing so can signi?  cantly reduce TCO for your infrastructure from day one and in the long run. Providing redundancy for the vSwitch is also extremely simple. There are four options:


   Route based on the originating virtual port ID


   Route based on an IP hash


   Route based on the source MAC hash


   Explicit failover order


The most commonly used option is the ?  rst (it’s the default for all vSwitches). A number of VMs are connected to a vSwitch that uses two or more physical NICs (pNICs). You use all of these pNICs in an active-active con?  guration. If you lose a pNIC, traf?  c automatically travels over one of the other pNICs in the vSwitch. Each time a VM is powered on, it’s assigned to a pNIC and continues to operate from that NIC until it’s power-cycled or until the pNIC fails and network traf?  c is passed to the other pNICs in the vSwitch. This setup doesn’t provide ef?  cient load balancing over all the pNICs in the vSwitch and can become unbalanced in certain cases; but in the majority of scenarios, it’s suitable because it’s the default con?  guration of an ESX host.