NIC Teaming是指将服务器上的几个网络端口组合在一起，无论是基于Windows的服务器，Linux服务器，还是VMware vSphere ESXi主机，做网卡绑定的主要目都是为了增加链路带宽、实现冗余以及实现负载均衡。在VMware vSphere环境中，通过NIC Teaming可以在所有成员之间实现共享物理和虚拟网络之间的流量负载，并可在发生硬件故障或网络中断时提供被动故障转移。要使用网卡绑定，必须将两个或多个网络适配器上行链接到虚拟交换机。

NIC Teaming的主要优点包括：

● 为托管的虚拟交换机提高网络容量。

● 网络冗余。当Teaming中的某个适配器发生故障时，可进行被动故障切换。服务器将能够幸免于网卡故障或链接故障，并继续通过流量。

● 负载平衡。服务器将能够通过多个网卡传输流量。不会因为某个服务器繁忙或者某个网络接口流量拥堵而影响虚拟机运行。

　　vSphere中所有三种类型的网络都支持NIC Teaming，包括VMKernel、Service Console和Port Group。Uplink连接到物理交换机的端口必须在同一个广播域中，也就是必须在同一个VLAN中，不能跨路由。如果Uplink要配置VLAN，则每个Uplink必须都配置成VLAN Trunk并且具有相同的VLAN配置。另外，VMware的负载均衡只是出站方向的负载均衡（Outbound Load Balancing）。VMware NIC Teaming的Load Balancing和路由算法中的Load Balancing不同，它不是按照Teaming中网卡通过的数据流量来做负载均衡的，而是根据网卡上的连接来进行负载均衡。

负载均衡的分类：

VMWare NIC Teaming的负载均衡有以下几种：

●  基于IP哈希的路由
●  基于源MAC哈希的路由
●  基于源虚拟端口ID的路由  默认选项
●  使用明确故障切换顺序
●  基于物理NIC负载的路由，采用分布式虚拟交换机时的选项

使用明确故障切换顺序

　　首先，我们来看一下：使用明确故障切换顺序，这个是在标准虚拟交换机（Standard vSwitch）中最简单的一个故障转移选项，即使用明确的故障转移顺序。使用此选项，不执行任何负载平衡，vSphere将首先使用活动列表中的第一个适配器（VMNIC）进行流量传输，如果此适配器失败，则将流量切换到备用的适配器上。这种方法配置最简单，但同时也不会提供任何的高级功能，也不支持负载均衡。通这这种故障切换的方法可以实现Port Group的冗余，比如对于管理网络的Potr Group，可以使用vmnic1作为活动端口，vmnic2作为备用端口。而对于vMotion端口组，则可以使用vmnic2作为活动端口，vmnic1作为备用端口。这样，如果一个NIC或link失败，仍然可以在ESXi主机上同时运行管理和vMotion流量。

基于源虚拟端口ID的路由

　　默认的负载平衡算法称为“基于源虚拟端口ID的路由”，这种模式下VMware vSphere将把虚拟机的虚拟端口按顺序分配给每一个上行链路，如下图所示，VM A连接到上行链路1,VM B连接到上行链路2，VM C再次连接到上行链路1，VM D再次连接到上行链路2，如此循环，如果新创建一个VM E，它就会连接到上行链路1。使用这种模式可以将虚拟机平均的分配到上行链路上。

基于IP哈希的路由

　　基于IP哈希负载均衡算法的路由是最复杂的。需要在VMware vSphere环境之外进行额外的配置。在这种模式下，负载均衡的实现是根据源IP地址和目的地IP地址的，因此同一台VM（源IP地址是固定的）到不同目的地的数据流量就会因为目的地IP地址的不同，而走不同的上行链路，也只有在这种模式下，虚拟机对外的流量的负载均衡才能够真正的实现。注意，VMware是不关心对端物理交换机的配置的，VMware的负载均衡只负责从ESXi主机出站的流量，因此要做到Inbound的负载均衡，必须在物理交换机上做同样的IP Hash配置，此时，上行链路必须连接到同一个物理交换机上。需要注意的是，VMware不支持动态链路聚合协议(例如802.3ad LACP或者Cisco的PAgP)，因此只能实现静态的链路聚合。不仅如此，对端的交换机设置静态链路聚合的时候也要设置成IP Hash的算法。否则这种方式的负载均衡将无法实现。 比如Cisco交换机上的默认Etherchannel的算法是源MAC，因此需要将其修改成源和目的IP。IP哈希通过源IP和目标IP的最后八位完成，这个运作法则叫作XOR。在执行完XOR之后，在XOR的运作结果和Teaming的网卡数量之间执行另一个称为modulo或mod的计算。由于Teaming中的NIC从0开始，所以最终结果总是介于0和N-1之间。

　　VMware KB: ESXi和交换机的EtherChannel/链路聚合控制协议 (LACP) 的配置示例 (自行查找)

 基于源MAC哈希的路由

　　这种方式下，负载均衡的实现是基于源MAC地址的。因为每个vNIC总是具有一个固定的MAC地址，因此这种方式的负载均衡同基于端口的负载均衡具有同样的缺点。同样是要求vPort数量大于pNIC的时候才会有效。同样是vNIC的速率不会大于单个pNIC的速率。与基于IP哈希的路由类似，基于源MAC哈希的路由计算每个包的上行链路。 与基于IP哈希的路由不同的是，基于源MAC哈希的路由不需要VMware vSphere环境之外的任何额外配置。 同样，基于源MAC的哈希算法使用虚拟机的MAC地址和NIC Teaming中的上行链路数量之间执行mod来计算应该使用哪个上行链路。

　　基于源MAC哈希的路由与基于IP哈希的路由具有相似的优点。由于我们在vSwitch中使用的是MAC地址和上行链路的数量，因此从这些负载平衡算法的使用中获益最多的虚拟机是那些具有多个虚拟nic的虚拟机。由于只需要进行一个数学运算来确定要使用的vSwitch上行链路，因此它的开销确实比基于IP哈希的路由要小，但比其他负载平衡机制要大。

基于物理NIC负载的路由

　　正如我们前面提到的，在使用分布式虚拟交换机时有一个额外的负载平衡算法，称为“基于物理NIC负载的路由”，通常称为LBT。使用分布式虚拟交换机时，可以使用基于负载的Teaming。它也非常简单，因为它采用和默认负载平衡算法相同的方式开始工作。如果一个上行端口在30秒内达到75%的利用率，繁忙的VM将被移动到另一个上行端口。虽然使用基于负载的Teaming确实需要在虚拟交换机上进行最少的配置(只需选择“基于phyiscal NIC负载的路由”)，但它仍然非常简单，因为它提供了负载平衡，不需要配置任何上游组件。一旦它被选中，虚拟机将在上行端口之间均衡，如果它们很忙，VM将被移动到另一个上行端口。基于负载的Teaming以及基于源虚拟端口的路由是VMware中最简单的NIC Teaming方法，因为它们不需要任何额外的配置。流量将在NIC之间得到平衡。