ESXi与物理交换机静态链路聚合配置过程中的小陷阱

内容简介：ESXi与物理交换机之间配置静态链路聚合时，因为静态链路聚合的特点，在进行down网卡和从虚拟交换机移除网卡的操作时，可能会无法完成故障流量切换，影响到虚拟机的运行。本文对其中的原理进行了分析。

链路聚合（link aggregation）是将多个物理端口绑定为单一逻辑组的行为。在日常应用中，链路聚合的配置模式有两种：静态模式和动态模式。动态聚合的链路聚合，即大名鼎鼎的LACP，不再多做介绍，这里我们主要聊聊静态模式的链路聚合。静态模式，顾名思义，配置即生效，没有协商，聚合组创建之后立刻显示为“启动”状态，即使线路另一端的对应端口没有正确配置，也依然为“启动状态”，就是这么任性。
当我们配置vSphere ESXi主机虚拟标准交换机（VSS）时，如果采用了双网卡绑定，并想使用“基于IP HASH 哈希的路由”这一负载平衡策略，必要条件是——与ESXi主机上行链路相连的物理交换机必须配置静态模式的链路聚合。只有物理交换机配置了链路聚合，ESXi主机VSS网卡绑定使用的“基于IP HASH哈希的路由”负载平衡策略才能够将网络流量均衡的分配到两块物理网卡，实现上行链路网络流量均衡和上行物理链路冗余。如果要问为什么不配置动态模式的链路聚合，原因很简单，虚拟标准交换机（VSS）不支持LACP协商，我们的选择只有一个——静态模式的链路聚合。

图1.基于IP哈希的路由负载均衡策略

图2. ESXi与物理交换机静态链路聚合配置示例

一切配置就绪，总得测试一把，按照正常情况，链路聚合组中的一个端口失效后，网络流量应该会发生故障切换，那么从ESXi这边看，怎样才能使链路聚合组中的一个端口失效呢，我们很快会想到如下办法：down网卡（使用命令esxcli network nic down –n vmnicX）、从虚拟交换机移除网卡。当我们进行上述两个操作时，会发现物理交换机上与被down掉或被移除网卡对应的端口并没有失效，端口状态依然为UP，流量也没有发生故障切换，这是怎么回事？

图3.从虚拟交换机移除网卡

原来，一切就源于“静态模式”链路聚合。在配置静态模式链路聚合后，物理交换机端检测聚合端口是否生效，是通过链路的物理状态，即电信号，只要链路的电信号存在，端口即被认为是UP状态，而不管对端有没有正确配置。由此，我们可以得出如下分析：
（1）当down掉ESXi上的一块网卡时，如果网卡的驱动程序不能切断网卡的电信号，那么上联物理交换机并不会感知到相连对端虚拟交换机聚合组中有成员被down掉，还是继续从被down掉网卡对应的端口发送数据，不会发生故障流量切换。
（2）当从虚拟交换机移除网卡时，该网卡只是不再被ESXi使用，但是其电信号依然存在，上联物理交换机并不会感知相连对端虚拟交换机聚合组中有成员被移除，还是继续从被移除网卡对应的端口发送数据，也不会发生故障流量切换。

通过以上的分析可以看出，在配置静态链路聚合后，如果要使聚合组中的成员失效，必须要切断其对应物理链路的电信号，否则物理交换机就会认为相应端口在聚合组中的状态为UP，不会发生故障流量切换。这就是我们发现的ESXi与物理交换机静态链路聚合配置过程中的小陷阱。
在发现以上“小陷阱”后，我们又在多种型号服务器和物理交换机组合上对拔网线、down网卡、从虚拟交换机移除网卡这三种操作进行了测试，得出了以下结论：
（1）拔网线，能够保证使物理交换机静态链路聚合组中的成员状态为Down，发生故障流量切换。
（2）down网卡，与服务器使用的网卡型号和驱动程序相关，如果网卡的驱动程序在执行down网卡操作时能够切断网卡的电信号，那么就可以使物理交换机静态链路聚合组中的成员状态为Down，发生故障流量切换；否则无法发生故障流量切换。
（3）从虚拟交换机移除网卡，物理交换机始终会认为相应的物理链路电信号正常，不会发生故障流量切换。

知道了以上小陷阱后，如果我们的环境中配置了静态链路聚合，在进行down网卡和从虚拟交换机移除网卡的操作时，就要小心了。如果有重要的虚拟机在运行，且上行链路配置了静态链路聚合，强烈建议您不要轻易进行down网卡和从虚拟交换机移除网卡的操作，以防发生不测。

打赏