VMware NIC Teaming技术探讨

文章转自Live空间( http://delxu.spaces.live.com/blog/cns!D04F87F9ED029F69!2583.entry )和51cto技术博客( http://delxu.blog.51cto.com )首发。转发时务必表明出处，顺便给博主做个广告，文章写的真的很好，深入浅出，期待看到更好的博文，再次表示对博主的感谢！！！
2/14/2010

VMware NIC Teaming技术探讨

delxu原创文档，如需转帖请务必说明出处： http://delxu.spaces.live.com/blog/cns!D04F87F9ED029F69!2616.entry

首先，说明几个知识要点：

(1) 所有3种类型的VMware网络都支持NIC Teaming （复习提问：哪3种类型？答：VMkernel, Service Console和VM port group）
(2) uplink连接到那些物理交换机的端口都必须在同一个Broadcast domain中。（也就是必须在同一个VLAN中，不能跨路由）
(3) 如果uplink要配置VLAN，则每个uplink必须都配置成VLAN Trunk并且具有相同的VLAN配置。
(4) VMware的负载均衡(Load Balancing)只是出站(Outbound)的负载均衡。（概念类似于HP术语中的TLB。关于HP负载均衡的术语详见拙文《 HP NIC Teaming技术探讨》，但是它和TLB其实不同，关于这一点，请看后文解释）
(参考：p192. Scott Lowe, 《Mastering VMware vSphere 4.0》)
(5) NIC Teaming的Load Balancing和一些高级路由算法的Load Balancing不同，它不是按照Teaming中网卡上通过的数据流量来负载均衡，而是根据网卡上的连接(connection)来进行负载均衡。

【VMware的3种负载均衡】

VMware的NIC Teaming Load Balancing策略有3种。
(1) 基于端口的负载均衡(默认)
(2) 基于源MAC的负载均衡
(3) 基于IP hash的负载均衡

基于端口的负载均衡 (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。(还记得创建一个vSwitch时候，默认的port数是56吗？你可以设置一个vSwitch的Port数为8，24，56，120，248，504或1016，看出什么规律来了没？对的，是2的某次方减8。这是因为VMKernel需要保留8个port的缘故)



对于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产生的

基于源MAC地址的负载均衡 Route based on source MAC hash

这种方式下，负载均衡的实现是基于源MAC地址的。因为每个vNIC总是具有一个固定的MAC地址，因此这种方式的负载均衡同基于端口的负载均衡具有同样的缺点。同样是要求vPort数量大于pNIC的时候才会有效。同样是vNIC的速率不会大于单个pNIC的速率。

基于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的算法。否则这种方式的负载均衡将无法实现。

比如Cisco 3560上的默认Etherchannel的算法是源MAC，因此需要将其修改成源和目的IP。 首先查看交换机的负载均衡的算法： show etherchannel load-balance 然后用修改负载均衡算法为src-dst-ip port-channel load-balance src-dst-ip

要点：配置IP Hash方式pNIC对端的物理交换机端口，要记得关闭802.3ad LACP和PAgP以减少这些动态协议带来的不必要网络开销，加快链路在failover时的转换速度。

这种方式的缺点是，因为pNIC是连接到同一台物理交换机的，因此存在交换机的单点失败问题。（这和HP SLB的缺点一样，详见拙文《 HP NIC Teaming技术探讨》）。此外，在点对点的链路中（比如VMotion），2端地址总是固定的，所以基于IP Hash的链路选择算法就失去了意义。

不管采用以上哪一种方法的Load Balancing，它会增加总聚合带宽，但不会提升某单个连接所获的带宽。为啥会这样？同一个Session中的数据包为啥不能做到Load Balancing？这是因为网络的7层模型中，一个Session在传输过程中会被拆分成多个数据包，并且到目的之后再重组，他们必须具有一定的顺序，如果这个顺序弄乱了，那么到达目的重组出来的信息就是一堆无意义的乱码。这就要求同一个session的数据包必须在同一个物理链路中按照顺序传输过去。所以，10条1Gb链路组成的10Gb的聚合链路，一定不如单条10Gb链路来的高速和有效。（详见Fraizer: IEEE 802.3ad Link Aggregation (LAG) - What it is, and what it is not)

【选择】
那么应该选择哪种NIC Teaming方式呢？大拿Scott Lowe建议：

• 如果使用链路聚合，必须设为“Route based on IP hash”
• 如果不是使用链路聚合，可以设为任何其它设置。大多数情况下，接受默认设置“Route based on originating virtual port ID”是最好的。

【更好的选择及其缺陷】
还有没有更好选择？答案是有。Cross-Stack Link Aggregation，跨堆叠交换机的链路聚合。

堆叠交换机通过堆叠线连接在一起，组成一个交换机堆叠栈。堆叠栈中的交换机共享同一个Forwarding Table。
堆叠交换机组在逻辑上被视作1台交换机，但是在物理上则是2台或多台不同的设备。
这和NIC Teaming是不是很像？
Teamport 在逻辑上是一个端口，但是在物理上却是2个或多个端口。
(突然想到，在一切都套上“虚拟化”的帽子的今日，不知道以后交换机堆叠技术会不会改名为交换机虚拟化？就像存在了多少年的RAID突然被套上了磁盘虚拟化的帽子一样，笑~~)

如图，SLB中的2条链路就可以不局限在同一台物理交换机上了，而可以分别连接到2台堆叠在一起的物理交换机上(切记，交换机堆叠必须连成环以保证冗余性)。此时，SLB的最大缺陷——交换机的单点失败就被克服了。这样，就可以既达到容错又达到双向负载均衡的目的了。
 

但是，这种方式的缺点是要求物理交换机具有堆叠能力。很遗憾的是，HP支持工程师告诉我，到目前为止，HP用于c-class刀片服务器机箱的所有以太网交换机都不支持堆叠。(信息获取时间2010年1月，不排除以后HP会提供支持堆叠的刀片交换机)

【参考文档】

本文的主要参考的文档如下：
(1) Scott Lowe, 《Mastering VMware vSphere 4.0》
(2) VMware Infrastructure 3环境下的物理网络设计 (Scott Lowe)
http://www.searchsv.com.cn/showcontent_14740.htm?lg=t
(3)如何在VMware ESX上实现网卡聚合？
http://www.searchsv.com.cn/showcontent_24716.htm 
(4) ESX Server, NIC Teaming, and VLAN Trunking （Scott Lowe)
http://blog.scottlowe.org/2006/12/04/esx-server-nic-teaming-and-vlan-trunking/
(5) IEEE 802.3ad Link Aggregation (LAG) - What it is, and what it is not
http://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf

7:35 PM  | Add a comment  | Read comments (1)  | Permalink  | Blog it  | 虚拟化技术

2/6/2010

HP NIC Teaming技术探讨

原创文档，转载请注明出处 http://delxu.spaces.live.com

NIC Teaming技术将2个或更多个网卡(HP NIC Teaming最多可达8个)捆绑在一起使用，以达到增加总的带宽(Load Balance，负载均衡)或者线路容错(Fault Tolerance)的目的。由2个或多个网卡组成一个逻辑网络端口Teamport，IP地址和网络设置绑定在这个逻辑的Teamport上，这样，无论哪一个物理网卡或者其相连的链路单独出现故障，Teamport还是能正常工作，服务器对外的网络连接不会中断。

为了方便说明，除非特别说明，本文以下部分的例子中将2个或多个网卡一律写成2个网卡，示意图也只画2个网卡。

HP服务器的NIC Teaming分三大类共7个选项，这三大类是指NFT、TLB和SLB。（7个选项后文会说明）

【NFT】
NFT 就是Network Fault Tolerant的缩写，这种模式下一个网卡处于活动(Active)状态，而另外一个网卡处于待机(standby)状态，平时只有一个网卡在用。NFT模式下，组成Teamport的2个1Gb的网卡分别连到2个不同的交换机，Teamport总带宽只有1Gb，这种模式具有容错能力，但是不具有增加带宽和负载均衡的能力。



【TLB】
TLB就是Transmit Load Balance，从字面上理解，就是传出(Tx)的负载均衡，也就是说，从服务器向外部发送的数据包，根据一定的规则，分别从Teamport中的2个网卡传出去，但是这种方式，不能保证接受(Rx)的数据包也同样能够负载均衡。简单的说，TLB可以做到网络容错，Teamport的Tx是2Gb带宽，Rx还是只有1Gb（除非有另外的方法来做负载均衡）
 

【SLB】
SLB是Switch-assist Load Balance，顾名思义，交换机协助的负载均衡，就是需要在交换机上进行相应的配置以后才能实现。SLB Team中的2个网卡必须连接到同一个交换机，这2个网卡到同一交换机的2个端口之间的链路就合并组成一个通道，这个通道Cisco交换机术语叫Etherchannel，其他厂商的交换机则常称这个为Port Trunk。这种组成联合通道的方式也称之为静态的链路聚合(SLA, Static Link Aggregation)。SLB方式的Teamport是双向2Gb，Tx和Rx的数据流都可以做到负载均衡，但是它只能保证网卡的容错，做不到交换机的容错。


注意(1)：应用SLB时还要特别注意SLB的负载均衡实现方式和对端交换机的限制。一般而言，很多厂商的交换机，都要求同一个聚合链路中的每个端口都必须是一致的，例如千兆端口不能和百兆端口聚合，百兆全双工的端口不能和百兆半双工的端口聚合。
注意(2): 不同厂商的负载均衡的算法有所不同，比如某些型号的Cisco交换机的Etherchannel是Layer 2的，有3种Load Balancing方式：基于源MAC，基于目的MAC和XOR方式；而其他一些型号或其他厂商的交换机还可以根据源IP，IP Hash或者TCP Session等的方式。如要继续深入研究并理解这些算法的优劣，请参考相关交换机厂商的文档。
(关于不同型号思科交换机的Etherchannel的异同和负载均衡的算法，请参考：http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a0080094714.shtml)

【NFT/TLB/SLB比较】
这三种方式的比较如下：

	NFT	TLB	SLB
网卡容错	支持	支持	支持
交换机容错	支持	支持	不支持
Tx负载均衡	不支持	支持	支持
Rx负载均衡	不支持	不支持	支持

【HP的NIC Teaming】
HP Proliant系列服务器的NIC Teaming是通过其PSP(Proliant Support Pack)中的NCU (Network Configuration Utility)来实现的。双击右下Systray中的HP网络工具的小图标，就能打开NCU配置界面。

从下面的截图我们可以看见，HP Network Team #1是一个Teamport，它由2个HP NC7782千兆端口组成。Teamport左边的绿×××标说明它目前工作正常。端口1是实线，说明其处于Active状态，端口2有一部分虚灰的颜色，表明这个链路是Standby的。

点击Teamport，然后点Property按钮，就可以打开Teamport的属性配置界面，在这里，我们可以选择HP NIC Teaming的类型。



从图中我们可以看到，HP的Team类型有7个选择，分别是

• Automatic (Recommended)
• 802.3ad Dynamic with Fault Tolerance
• Switch-assisted Load Balancing with Fault Tolerance (SLB)
• Transmit Load Balancing with Fault Tolerance (TLB)
• Transmit Load Balancing with Fault Tolerance and Preference Order
• Network Fault Tolerance Only (NFT)
• Network Fault Tolerance with Preference Order

我们发现上面这些选择中毫无例外的都注明了Fault Tolerance，这恰恰说明了NIC Teaming的最重要的目的： 容错。

这其中的SLB, TLB, NFT前文已经介绍过了。这里再解释下其他几个。

【NFT with PO和TLB with PO】
Preference Order就是指一种优先顺序，这种顺序往往是根据链路类型、速率等方式决定的。

NFT with Preference Order就是带有优先顺序的NFT。举例说明，比如一台NFT的Teamport是由一个千兆的Port A和一个百兆的Port B组成的，则Port A由于传输速率快，优于Port B，所以Port A会成为Active，而Port B则为Standby。 TLB with Preference Order同理，通常用于将不同速率端口绑定在一起的情况下。

【802.3ad Dynamic】
和SLB类似，802.3ad Dynamic 方式也是到同一台交换机的链路聚合，只不过不是手工配置(静态)的，而是自动协商(动态构成)的。它是通过一种智能的链路协商协议LACP (Link Aggregation Control Protocol)来实现的。LACP原本用于交换机和交换机之间的链路聚合，启用了LACP协议的2台交换机会相互发送LACP的协商报文，当发现2者之间有多条可用的链路的时候，自动将这些链路组合成一条带宽更大的逻辑链路，从而利用负载均衡来实现加宽交换机间链路带宽的目的。HP的NIC Teaming也支持动态链路聚合，可以实现在HP服务器和支持802.3ad 动态LACP的交换机之间自动创建聚合链路。

【Automatic】
Automatic (Recommended) 其实不是一种单独的模式，当选择Automatic的时候，会判断Team中的这些port是不是连接到同一个支持802.3ad Dynamic LACP协议的交换机，如果是，则选择802.3ad Dynamic方式；如果不是，则使用TLB方式。

如想继续深入HP的NIC Teaming技术，比如研究Load Balancing算法、检测链路失败的方法和链路恢复等，请阅读 HP NIC Teaming White Paper (英文) 。

【参考文档】
(1) HP NIC Teaming White Paper (英文)
http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01415139/c01415139.pdf