Eth-Trunk 负载分担在通信类设备上的应用*

罗 健，易 欣，谢永春，夏安祥

（1.中国电子科技集团公司第三十研究所，四川 成都 610041；2.北京航天飞行控制中心，北京 100094）

0 引 言

某通信类设备工作于IP 层，其基本功能是对特征IP 数据报文进行处理。设备根据IP 数据报文中的四元组对数据流进行分类，针对每一个不同的数据流，采用不同的硬件通道进行处理。由于设备硬件性能限制，最多只能承载8 个硬件通道，这就必须要求分配给单台设备处理的数据流个数不能超过8。在设备实际使用场景中，数据流由某终端群发出，其数量远大于8，因此必须采用负载均衡技术将众多数据流分担到多台设备上进行处理。

根据数据报文特征进行的负载分担主要有逐流分担和逐包分担，逐流分担一般是按照IP 数据报文的五元组将IP 报文分成不同的数据流，同一条流的报文固定在一条链路上传输，但缺点是逐流分担的负载均衡不会很理想，均匀程度一般与流量特征和负载分担策略相关。逐包分担不对数据流进行区分，而是以数据报文为单位，根据报文到来的顺序，将报文均匀地分担到参与负载均衡的各条链路上，缺点是可能造成报文乱序。逐流分担可以保证数据报文有序到达，由于某通信类设备对报文达到顺序非常敏感，因此选用了华为S5700 系列交换机的Eth-Trunk 功能实现逐流分担。

Eth-Trunk 是华为交换机的链路聚合功能，将多条物理链路捆绑为一个逻辑聚合组链路[1]。聚合组内的各成员链路可以互相热备，当某一条成员链路发生故障时，故障链路流自动分配到其他正常成员链路上。为了解决热备的实时性问题，本文选取了合适的LACP Timeout 对跨接设备进行故障判断，当交换机超过一定时间没有收到互发的LACP 报文时，立即启动热备机制。

负载分担实现机制是将进入交换机Eth-Trunk口的众多数据流通过HASH 策略随机从当前活跃的聚合组成员端口送出[2]，负载分担固有的HASH 策略引入了分担结果不均匀的问题。为了解决该问题，本文提出了一系列配置方法，能够保证负载分担结果相对均匀。

1 Eth-Trunk 负载分担

1.1 Eth-Trunk 技术

Eth-Trunk 是以太网链路聚合的简称，它通过将两台交换机之间的多条以太网物理链路捆绑成为一条逻辑链路，如图1 所示，各成员链路之间可以实现相互动态备份，提高了链路的可靠性。Eth-Trunk 属于TCP/IP 网络体系的数据链路层，如图2所示，位于MAC 与LLC 子层之间[3]。

图1 Eth-Trunk 示意图

图2 Eth-Trunk 在网络体系中的位置

Eth-Trunk 技术主要有以下三个优势：第一，可以增加带宽，Eth-Trunk 接口的最大带宽可以达到各成员接口带宽之和。第二，可以提高链路设备的可靠性，当某条链路出现故障时，流量可以自动切换到其他活跃的成员链路上。第三，可以实现负载分担，在同一聚合组内，流量可以分担到各成员链路上[4]。

1.2 负载分担策略

Eth-Trunk 模块内部维护了一张转发表，该表由OFFSET 值和接口号两项构成。OFFSET 值是由HASH-KEY 转化而来，不同的OFFSET 值对应不同的出接口，相同的OFFSET 值就对应相同的出接口。由于HASH 计算的结果具有随机特性，在没有手段干预的情况下，Eth-Trunk 负载分担结果不会很均匀。

负载分担策略、数据流特征和个数都固定之后，其分担结果也就固定，从Eth-Trunk 的HASH 计算原理可以看出，依次减少或增加既有的数据流，不会改变当前已接入数据流的出接口。

1.3 LACP 协议

LACP 协议是一种实现动态链路聚合的控制协议，该协议基于 IEEE802.3ad 标准[5]。运行该协议的交换机之间通过互相发送 LACPDU（Link Aggregation Control Protocol Data Unit）报文进行信息交互，报文包含了聚合组端口的信息和状态，交换机通过解析对端的LACPDU 报文并结合自身的端口状态进行端口的选择以及故障的判断[6]。

通过解析LACPDU 报文可以判断对端端口是否正常，如果异常则双方会协商出其他活跃端口接管故障端口流量。当超过一定时间没有收到对端发出的报文时，交换机也会判定该端口发生故障，将流量自动分配到其他活跃端口上。华为交换机可以选择互发LACPDU 报文的周期，最小可以设置为1 秒，超时时间为设置周期的3 倍。

2 系统应用场景

应用场景分为两种，场景1 的目的IP 地址都是组播地址。场景2 的目的IP 地址都为单播地址，且与源IP 地址不属于同一广播域，需要网关进行数据转发。

2.1 场景1

场景1 如图3 所示，采用3 台设备对终端群发往服务器的一共12 路数据流进行负载分担。交换机1 和2 配置了相同Id 的Eth-Trunk 口，聚合组成员接口统一为两交换机的第18、19、20 号物理端口，分别对应设备1、设备2 和设备3。

图3 场景1

12 条数据流的具体特征见表1，为了描述方便，后文以数据流编号表示该条数据流。场景1 中数据流1～12对应接入交换机2的第1～12号物理端口。

表1 场景1 所有数据流

2.2 场景2

场景2 如图4 所示，采用2 台设备对终端群发往服务器的一共6 路数据流进行负载分担。交换机1 和2 配置了相同Id 的Eth-Trunk 口，聚合组成员接口统一为两交换机的第17、18 号物理端口，分别对应设备1 和设备2。

1056 高分辨率磁共振成像分析基底节区孤立性缺血性脑卒中病因 王 诺，张首龙，秦鲁平，朱 宣，张敏敏，邓本强，吴 涛

图4 场景2

6 条数据流的具体特征见表2，为了描述方便，后文以数据流编号表示该条数据流。场景2 中数据流1 ～6 对应接入交换机2 的第1 ～6 号物理端口。

表2 场景2 所有数据流

2.3 LACP 配置

为了保证设备故障时，故障链路数据流自动切换到其他正常链路上，Eth-Trunk 配置了LACP 功能。以场景1 为例，场景2 同理，3 台设备都能正确透传LACPDU 报文，其中交换机2 配置为主设备，其LACP 配置了更高的系统优先级，并对其第18/19/20 三个Eth-Trunk 成员物理端口配置了更高的端口优先级。交换机1 不需要配置LACP 系统优先级和端口优先级，仅作为从设备。两交换机的LACP Timeout 都设置成最短的1 秒。两个交换机之间通过设备1、设备2、设备3 所在链路以固定1秒间隔发送LACPDU 报文。某个设备出现故障时，故障设备将阻断所在链路LACPDU 报文的互传，如果两端交换机超过3 秒没有收到互发的LACPDU 报文，则判定故障，故障链路流量会自动切换到其他活跃的链路上。由于设备数量限制，LACP 的最大活跃通道数设置为3，3 台设备都参与了负载分担。

2.4 分担策略配置

为了保证通过Eth-Trunk 的众数据流相对平均地分配到各成员链路上，需要在Eth-Trunk 出方向的交换机上配置负载分担策略。策略提取数据流的相关特征值做HASH 运算，根据计算结果选择与之对应的成员口作为数据流的出口。为了使得分配结果更平均，理论上要求参与HASH 计算的数据流特征值变化越繁复越好。华为交换机S5700 的负载分担策略不能单独配置为四层端口号，两场景中数据流的源IP 地址变化相对较大，因此负载分担策略都设置为Source-IP。由于场景1 目的IP 地址都为组播地址，场景1 负载分担策略在Source-IP 的基础上还另外添加了基于源MAC 地址的Unknown-Unicast Load-Balance Smac 策略。

3 试验结果及分析

3.1 场景1 结果

场景1 中，一共有3 条成员链路，由于设备的性能限制，通过任一台设备的数据流不能超过8 路。HASH 计算具有散列性，场景1 中12 条数据流的目的地址为组播，其HASH 计算的输入为12 条数据流中的二层源MAC 地址。由于不同的MAC 地址计算出来的HASH 结果可能相同，会导致多个数据流从固定的成员链路上经过，可能超过该链路上设备的处理极限。

场景1 配置完之后首次运行时，分配给设备1、设备2、设备3 的数据流个数分别为7/1/4，分担结果不是很均匀，特别是设备1，其分担结果已经接近其处理极限，这样的分担结果显然不会令人满意，如果后期终端群中某终端发生故障，另换一台新的终端上线，则负载分担结果可能发生改变，造成分配给单台设备的数据流个数超限的情况。

为了解决负载分担结果不均匀的问题，可以手动调整交换机2 上各数据流流入的物理端口。初始时，数据流1 ～12 对应接入交换机2 的第1 ～12号物理端口，手动调整数据流流入交换机2 的物理端口，将数据流2 从原来的端口2 接入端口3，数据流3 从原来的端口3 接入端口4，以此类推。调整的同时，密切关注负载分担结果，当负载分担结果相对均匀时，停止调整，此时数据流1 ～12 对应接入交换机2 的第1,3,4,6,7,9,11,12,14,15,16,17 号端口。分担结果如表3 所示，设备1、设备2、设备3 都正常工作时，分担结果是4/5/3，详细结果为设备1 分担了数据流中的1,4,5,10，设备2 分担了3,7,8,9,12，设备3 分担了2,6,11。

为了验证热备功能，拔掉设备3 与交换机Eth-Trunk 成员口之间的网线模拟设备3 发生故障，经过3 秒超时后，设备3 上的流量都分配到了设备1和设备2 上。分担结果如表3 所示，设备1 和设备2 负载分担结果为7/5，其中，设备1 分担了数据流中的第1,2,4,5,6,8,11，设备2 分担了数据流中的3,7,9,10,12。设备2 或设备1 发生故障后，其他两台正常设备的负载分担结果也是5/7，因此可以保证任一设备发生故障时，分配给其他任何设备的数据流个数不会超过其处理极限。

保持交换机中相关参数、HASH 策略、所有数据流特征值以及各数据流流入的交换机物理端口不变，对系统整体多次关电重启。每次运行，无论是三台还是两台设备正常工作的情况下，其分担结果都与表3 中描述的一致，不会发生改变。

表3 场景1 不同工作状况下负载分担结果

3.2 场景2 结果

场景2 中，一共有2 条成员链路，其HASH 计算的输入为6 条数据流中的源IP 地址。由于不同的IP 地址计算出来的HASH 结果可能相同，会导致多个数据流从固定的成员链路上经过，造成分担不均的现象。

场景2 配置完之后首次运行时，分配给设备1、设备2 的数据流个数分别为6/0，分担结果不均匀，虽然没有造成单台设备性能超限的问题，但也违背了负载均衡的初衷。

采用如场景1 中相同的方法，初始时，数据流1 ～6 对应接入交换机2 的第1 ～6 号物理端口，手动调整数据流流入交换机2 的物理端口，将数据流2 从原来的端口2 接入端口3，数据流3 从原来的端口3 接入端口6，以此类推，调整完毕之后，数据流1 ～6 对应接入交换机2 的第1,3,6,7,9,10 号端口。其分担结果如表4 所示，设备1、设备2 都正常工作时，分担结果是3/3，其中，设备1 分担了数据流中的1,2,3，设备2 分担了4,5,6。

拔掉设备1 或设备2 与交换机Eth-Trunk 成员口之间的网线模拟设备发生故障，经过3 秒超时后，故障设备上的流量都分配到了正常运行的设备上，其详细分配结果见表4。

保持交换机中相关参数、HASH 策略、所有数据流特征值以及各数据流流入的交换机物理端口不变，对系统整体多次关电重启。每次运行，无论是两台还是单台设备正常工作的情况下，其分担结果都与表4 中描述的一致，不会发生改变。

表4 场景2 不同工作状况下负载分担结果

3.3 试验总结

多次试验之后可以得出以下结论：交换机中相关参数和策略配置完毕之后，只要保持交换机各个物理接口、终端群的硬件MAC 地址以及应用场景中的所有数据流特征值不发生改变。系统每次运行其负载分担结果都不会发生改变，不会出现分配给单台设备的数据流个数超过其处理极限的情况。

如果使用场景需要改变数据流的特征值、终端群的配置参数或者硬件MAC。改动完成之后，为了不给负载分担带来负面影响，可以手动调整数据流流入方向上交换机的非聚合口，直到分配给聚合组各成员端口的数据流个数相对平均为止，最后再固化配置状态即可。

4 结 语

本文提出了使用华为交换机Eth-Trunk 功能进行负载分担的方法，给出了LACP 以及负载分担策略的详细配置情况，并成功应用于某通信类设备。通过手动调整数据流流入方向上交换机的非聚合口，解决了负载分担效果不理想的情况。经验证，该方法的负载均衡效果较好，能够保证分配给单台设备的数据流个数不超过其处理极限。