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之間得到平衡。
