http://www.poppingclouds.com/2012/12/20/to-lacp-or-not-to-lacp-on-a-5-1-vds-2/

I have been recently mulling over the potential benefit of LACP in some of our environments. I want to discuss how LACP is implemented in vSphere, its limitations, and the potential benefits that I see in its use. I will also go over the process for enabling LACP from the vSphere side of things.

Beginning with vSphere 5.1, VMware supports Link Aggregation Control Protocol (LACP) on distributed switches (vDSs). LACP, as I am sure you are already aware, allows the bundling together of multiple physical links to form a single logical channel. The purpose here is to provide more efficient network redundancy and failover (as well as increased available bandwidth, which I will get to in a moment).

LACP works by simultaneously sending frames down each interface that has been enabled for LACP. If the device on the other end of the connection is configured for LACP, it will also start sending frames along those same links thereby enabling both systems to detect multiple connections between themselves and combine them into a single logical link.

So this all sounds great, the immediate question becomes, “Do I enable this in my vSphere 5.1 environment?” And as any architect would tell you (really it’s always the same answer for any design question) the answer is, “It depends.”

First we need to look closely at the limits of the current implementation of LACP in 5.1. According to the 5.1 networking guide published by VMware, these are the limitations as they exist today:

Limitations:

  • LACP is only available on vSphere Distributed Switches.
    • This means you need Enterprise Plus (or better) licensing.
  • LACP only works with IP Hash load balancing and Link Status Network failover detection.
  • LACP is not compatible with iSCSI software multipathing.
  • vSphere only supports one LACP group per distributed switch, and only one LACP group per host.
  • LACP settings do not exist in host profiles.
  • LACP between two nested ESXi hosts is not possible.
  • LACP does not work with port mirroring.

Now, depending on your environment’s functional and non-functional requirements, one or more of these may be a show stopper. For instance, if you have a budgetary constraint preventing you from purchasing Enterprise Plus licensing, that would undoubtedly rule this out. Or perhaps you are (like many environments today) aggregating all of your traffic from the host up through a pair of 10G interfaces into a stacked switch pair on a single vDS. If you are using ISCSI storage with software-based multipathing, you are probably going to run into a complication here.

You also need to be aware that the IP Hash load balancing method is not going to pay attention to the NIC utilization. Imagine a situation where a VM is accessing a backup server, it is quite possible that that VM is already saturating that link. It will never choose another uplink as long as the IP hash for it’s destination remains the same.

Okay, but don’t I get more bandwidth with the aggregated links?

Well yes and no. If you look at things from the point of view of a VM sitting in a port group, using IP Hash load balancing will let that single source IP use a single physical interface to any given destination IP. So for that one connection, no, you only have the bandwidth that is available on that single physical interface. But if we take a step back and look at a VM that is connecting to “many” destination IP addresses (for instance a web server), then yes, as a whole, that VM will have access to the total aggregate bandwidth available in the LACP group (even though each individual connection only has the total amount of bandwidth present in a single uplink). Likewise, inbound traffic will be subject to the load balancing policy that is in place on the access layer switches.

You also need to take into account the additional overhead of IP Hash, and determine if it is worth it for  your use case. For instance, the VMkernel will need to select the appropriate uplink for each connection while using IP Hash. Now imagine you have a VM that is accessing a backup server or a backend database for 90%+ of its traffic. The IP Hash calculation is useless in that scenario since it will ALWAYS choose the same physical interface (unless the IP on the remote host changes and alters the hash value).  Yet the VMkernel will still be making that calculation for every connection from that VM, even though it is always going to result in the same hash.

Lets take a look at a logical diagram of this (click to enlarge):

As you can see here, the LACP “magic” occurs pretty far up in the stack. The port groups are still subjected to the load balancing algorithm, and will be assigned one of the available physical uplinks based on that algorithm (IP hash) for that individual connection.

Bottom line: LACP can give you some pretty nice benefits in regards to failover and network failure detection. However, (in my opinion) it is not going to be better at balancing traffic, or route traffic any more efficiently than a properly configured set of static uplinks using “Route based on physical NIC Load.” Please keep in mind that I am basing that off of my research here, not on any real-world testing of LACP vs Nic Load. However it would have to be my recommendation that when using a vDS, you should stick with load-based teaming (Route based on physical NIC Load) rather than IP Hash for most use cases. It is load-aware, less complex to set up, places less overhead on the VMkernel (load calculations are made only every 30 seconds), and will route traffic just as efficiently (in my opinion) as IP Hash.

So, all that aside, there are still some notable advantages to running LACP within your vSphere environment.

Advantages:

  • It is literally “Plug and play.”
  • Link failures are detected nearly instantaneously and failover is immediate.
  • Can detect cabling mistakes and reconfigure the links automatically.

So, lets assume that you have made the decision to use LACP. You have confirmed that your upstream switches support the protocol, the limitations of LACP in a 5.1 VDS are not an issue for your environment, and you have a valid use case that warrants it. How do you go about enabling it?

It’s actually fairly simple. I will go through the steps below.

How to configure LACP on a vSphere 5.1 vDS:

First thing is first, you must use the vCenter Web client for this.

In order to use the dynamic link aggregation configuration, you must be working on a v5.1.0 switch or later:

It is also a good idea to enable the LLDP (Link Layer Discovery Protocol) since this makes the configuration on the physical switch a bit simpler:

With LLDP enabled, it is very easy to confirm which exact ports on the physical switch is connected to which individual hosts in the cluster.

Now go over to the uplink port group on your VDS. You will see the new LACP option:

You will notice, that you can also set the mode to either active or passive. This is the mode in which the vDS decides to initiate the LACP negotiation. In Passive mode, it will remain silent and not transmit any LACP BPDU frames unless the switch on the other side initiates the session. In active mode, the vDS will start transmitting the frames to start the session with the switch. Passive is the default option.

The last thing we need to do from a vDS standpoint is configure all the other port groups on this switch to use the “Route based on IP hash” load balancing method. Note that you also need to make sure that “Network failure detection” is set to “Link Status only.” Beacon probing is not supported with IP Hash load balancing. Also make sure all uplinks are active. Standby and unused uplinks are also not supported with IP Hash load balancing.

From this point you simply need to configure the LACP port grouping on the physical switch, (or switches if stacked). Again, having LLDP enabled makes this task a bit easier, especially if we are dealing with a ton of switchports here.

To LACP or not to LACP (on a 5.1 vDS)的更多相关文章

  1. Using LACP with a vSphere Distributed Switch 5.1

    Using LACP with a vSphere Distributed Switch 5.1 by Chris Wahl on Oct 15th, 2012 | 6,347 views One o ...

  2. HCNA配置静态LACP模式链路聚合

    1.静态LACP模式 静态LACP模式是一种利用LACP协议进行聚合参数协商.确定活动接口和非活动接口的链路聚合方式.该模式下,需手工创建Eth-Trunk,手工加入Eth-Trunk成员接口,由LA ...

  3. LACP学习笔记

    LACP学习笔记 来源: https://blog.csdn.net/zhengmx100/article/details/53893902 参考文档:download.h3c.com.cn/down ...

  4. LACP链路聚合控制协议

    LACP链路聚合控制协议 来源: https://www.cnblogs.com/taosim/articles/4378691.html http://storage.chinabyte.com/6 ...

  5. 配置交换机之间直连链路聚合-LACP模式

    组网图形 LACP模式链路聚合简介 以太网链路聚合是指将多条以太网物理链路捆绑在一起成为一条逻辑链路,从而实现增加链路带宽的目的.链路聚合分为手工模式和LACP模式. LACP模式需要有链路聚合控制协 ...

  6. 专题:『Channel Bonding/team』——EXPERIMANTAL!!!

    Linux内核支持的多网卡聚合方法——bond.team bond 优点:经过长时间的实践检验,具有较高的稳定性:kernel-2.4及以上内核均广泛支持 缺点:需要通过sysfs或发行版定制的网卡配 ...

  7. port-channel和channel-group

    cisco交换机上的链路聚合 2层 ethernet channel (interface)#channel-group number mode {on | auto [no-silent]|desi ...

  8. H3C Comware V3 端口聚合

    通常链路聚合有三种模式:手工汇聚.静态LACP汇聚和动态LACP汇聚. 但是V3版本下只提供了 手工聚合模式 manual 和 静态LACP聚合模式 static 两种 V3版本配置链路聚合 1,创建 ...

  9. 原创:vsphere概念深入系列四:Nic Teaming若干问题

    参考文档:http://www.hyper-v.nu/archives/marcve/2013/01/lbfo-hyper-v-switch-qos-and-actual-performance-pa ...

随机推荐

  1. Android 数据存储02之文件读写

    Android文件读写 版本 修改内容 日期 修改人 V1.0 原始版本 2013/2/25 skywang Android文件读写的有两种方式.一种,是通过标准的JavaIO库去读写.另一种,是通过 ...

  2. 在后台运行rtorrent

    本来一直是用transmission做PT的客户端的,但是transmission的功能实在是太弱了,web-gui显示的信息也实在是太有限.在别人的推荐下,总算下定决心换rtorrent+wtorr ...

  3. 整理:iOS 短信与电话事件的获取

    整理:iOS 短信与电话事件的获取   background information: Core Telephony iOS 4.0 的官方 API 裡頭,多了一個叫做 Core Telephony  ...

  4. 神盾局特工第四季/全集Agents Of SHIELD迅雷下载

    英文全名Agents Of SHIELD,第4季(2016)ABC. 本季看点:<神盾局特工>(Agents Of SHIELD)第三季季终集里,我们终于知道谁死了……但死的不是一个,而是 ...

  5. Nvidia驱动正确安装过程

    找到适合的正确的驱动 去nvidia驱动官网下载 卸载掉原有驱动 sudo apt-get remove –purge nvidia* 安装驱动 进入命令行界面 Ctrl-Alt+F1 给驱动run文 ...

  6. Universal-Image-Loader解析(一)——ImageLoaderConfiguration的详细配置

    Universal-Image-Loader这个开源框架又来给我们造福了,它是一个图片加载框架,主要强大在于可以用于网络等图片源的加载,并且有多重缓存机制.先给出其项目地址:https://githu ...

  7. Asp.Net 拦截请求自定义处理

    需求: 在Aps.Net 应用中,对于浏览器请求的部分url的地址自定义处理,不交给路由系统或页面. 解决方案: 在全局文件Global.asax中 ,提供Application_BeginReque ...

  8. git如何删除远端不存在的本地分支?

    问题:远端分支删除后,如何删除之前拉取的本地分支? 答案: git fetch -p git remote show origin 可以查看remote地址,远程分支,还有本地分支与之相对应关系等信息 ...

  9. CSS 强制换行和禁止换行强制换行 和禁止换行样式

    强制换行 1.word-break: break-all;       只对英文起作用,以字母作为换行依据. 2.word-wrap: break-word;   只对英文起作用,以单词作为换行依据. ...

  10. [leetcode]Word Ladder II @ Python

    [leetcode]Word Ladder II @ Python 原题地址:http://oj.leetcode.com/problems/word-ladder-ii/ 参考文献:http://b ...