首先,说明几个知识要点:

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

【VMware的3种负载均衡】

VMware的NICTeamingLoadBalancing策略有3种。
(1)基于端口的负载均衡(默认)
(2)基于源MAC的负载均衡
(3)基于IPhash的负载均衡


基于端口的负载均衡(RoutebasedontheoriginatingvirtualportID)

这种方式下,负载均衡是基于vPortID的。一个vPort和Host上的一个pNIC(从vSwitch角度看就是某个uplink)捆绑在一起,只有当这个pNIC失效的时候,才切到另外的pNIC链路上。这种方式的负载均衡只有在vPort数量大于pNIC的数量时才生效。

什么是vport?一个VM上的vNIC或者某一个VMKernel或者ServiceConsole的某个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上的NICTeaming的LoadBalancing才较为有效。对于以下这些极端情况,基于端口方式的负载均衡根本不起作用或者效果很差,充其量只能说是一种端口冗余。

(1)Host上只有一台只具有单vNIC的VM(此时完全没有Loadbalancing)
(2)Host上的VM数量比pNIC少(比如有4台VM但是Teaming中有5块pNIC,此时有一块pNIC完全没用上,其他每个vNIC各自使用一块pNIC,此时也没有任何负载均衡实现)
(3)Host上虽然有多台VM,但是99%的网络流量都是某一台VM产生的

基于源MAC地址的负载均衡RoutebasedonsourceMAChash

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

基于IPHash的负载均衡RoutebasedonIPhash

这种方式下,负载均衡的实现是根据源IP地址和目的IP地址的。因此同一台VM(源IP地址总是固定的)到不同目的的数据流,就会因为目的IP的不同,走不同的pNIC。只有这种方式下,VM对外的流量的负载均衡才能真正实现。

不要忘记,VMware是不关心对端物理交换机的配置的,VMware的负载均衡只负责从Host出站的流量(outbound),因此要做到Inbound的负载均衡,必须在物理交换机上做同样IPHash方式的配置。此时,pNIC必须连接到同一个物理交换机上。

需要注意的是,VMware不支持动态链路聚合协议(例如802.3adLACP或者Cisco的PAgP),因此只能实现静态的链路聚合。(类似于HP的SLB)。不仅如此,对端的交换机设置静态链路聚合的时候也要设置成IPHash的算法。否则这种方式的负载均衡将无法实现。

比如Cisco3560上的默认Etherchannel的算法是源MAC,因此需要将其修改成源和目的IP。

首先查看交换机的负载均衡的算法:
show etherchannel load-balance

然后用修改负载均衡算法为src-dst-ip
port-channel load-balance src-dst-ip


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

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

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

【选择】
那么应该选择哪种NICTeaming方式呢?大拿ScottLowe建议:
  • 如果使用链路聚合,必须设为“RoutebasedonIPhash”

  • 如果不是使用链路聚合,可以设为任何其它设置。大多数情况下,接受默认设置“RoutebasedonoriginatingvirtualportID”是最好的。


【更好的选择及其缺陷】
还有没有更好选择?答案是有。Cross-StackLinkAggregation,跨堆叠交换机的链路聚合。

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

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



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

【参考文档】
本文的主要参考的文档如下:
(1)ScottLowe,《MasteringVMwarevSphere4.0》
(2)VMwareInfrastructure3环境下的物理网络设计(ScottLowe)
http://www.searchsv.com.cn/showcontent_14740.htm?lg=t
(3)如何在VMwareESX上实现网卡聚合?
http://www.searchsv.com.cn/showcontent_24716.htm
(4)ESXServer,NICTeaming,andVLANTrunking(ScottLowe)
http://blog.scottlowe.org/2006/12/04/esx-server-nic-teaming-and-vlan-trunking/
(5) IEEE802.3adLinkAggregation(LAG)-Whatitis,andwhatitisnot
http://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf

本文出自“delxuTechNotebook”博客,请务必保留此出处http://delxu.blog.51cto.com/975660/276642