简介:

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的负载均衡WMware ESX Server网络负载均衡配置_ESX

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。

WMware ESX Server网络负载均衡配置_VMware_02

对于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”是最好的。