MLAG（Multi-Chassis Link Aggregation Group，跨设备链路聚合）是文件存储双活架构里绕不开的一项网络技术。简单来说，它能让两台物理上独立的交换机在逻辑上表现为一台设备，存储节点的多条链路可以分别接到这两台交换机上，再聚合成一个逻辑口。这样一来，任意一台交换机故障，存储的链路依然可用，同时日常流量还能在多条链路间分担，实现高可用与负载均衡的双重收益。这篇文章把配置方法、选型思路和常见的坑放在一起讲透，方便对照部署。
MLAG在文件存储中的工作原理
传统的链路聚合（LACP）要求一个聚合组的所有成员口必须在同一台交换机上，这天然形成了单点故障。MLAG的核心思路是打破这个限制：两台交换机通过一条专门的peer-link链路互相同步状态信息，包括MAC地址表、ARP表、聚合口成员状态等，对外则使用相同的虚拟MAC地址和系统ID应答LACP协商。对存储节点来说，它完全感知不到对端是两台设备，只认为自己连着一台普通交换机的一个聚合口。
在文件存储场景下，这个特性尤其有价值。分布式文件存储集群通常由多个存储节点组成，每个节点需要和接入交换机之间跑大量的业务流量，比如NFS、SMB、iSCSI或者对象存储的读写请求。如果每个节点只用单链路上联，带宽和可靠性都不够；如果做普通聚合，交换机侧又是单点。MLAG正好补上了这块短板：节点双上联到两台MLAG交换机，聚合组内的链路按哈希算法分流，故障时毫秒级切换。
需要特别理解的一点是，MLAG的负载均衡是“逐流”而不是“逐包”的。也就是说，一条TCP连接或者一个文件会话的流量始终走同一条成员链路，避免乱序问题。这意味着如果存储集群里存在一条超大流量的单连接，它是无法被拆分到多条链路上的，这也是后面选型部分要讨论的哈希因子选择问题的根源。
MLAG负载均衡的具体配置步骤
不同厂商的命令差异较大，但配置逻辑是一致的，这里以常见的通用命令风格为例说明整体流程。第一步是规划基础信息：两台交换机分别命名为SWA和SWB，分配keepalive地址，确定MLAG域编号、虚拟MAC等参数。这些参数在两台设备上必须严格对应，域编号不一致会导致MLAG协商失败。
第二步是配置peer-link和keepalive链路。peer-link建议使用至少两条万兆链路做聚合，用于同步MAC表和转发兜底流量；keepalive链路则是一条独立的心跳线，通常走管理网，专门用于双主检测。两条链路职能不同，不能省略任何一条，这点在避坑部分还会展开。
# SWA 上的关键配置 mlag domain 1 peer-link interface port-channel 10 peer-address 10.0.0.2 local-address 10.0.0.1 system-mac 0000.1111.2222 # peer-link 聚合口 interface port-channel 10 switchport mode trunk interface range Ethernet47-48 channel-group 10 mode active # keepalive 走管理口 interface Management1 ip address 192.168.100.11/24 # 面向存储节点的MLAG聚合口 interface port-channel 20 mlag 20 switchport mode trunk interface range Ethernet1-2 channel-group 20 mode active
第三步是存储节点侧的配置。以Linux为例，节点上用bonding或者team对接交换机侧的MLAG聚合口。推荐mode 4（802.3ad，即LACP）配合layer3+4的哈希策略，这样能兼顾TCP和UDP流量的均衡度。存储节点上两条网卡分别接SWA和SWB的Ethernet1口，交换机侧通过mlag 20这条命令把两台设备上的port-channel 20绑定成同一个逻辑聚合组，这是整个配置中最关键的一行。
# 存储节点侧的 bond 配置 nmcli con add type bond con-name bond0 ifname bond0 \ bond.options "mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4" nmcli con add type ethernet slave-type bond con-name bond0-port1 ifname eth0 master bond0 nmcli con add type ethernet slave-type bond con-name bond0-port2 ifname eth1 master bond0 # 配置业务IP nmcli con mod bond0 ipv4.addresses 172.16.10.5/24 ipv4.method manual nmcli con up bond0
验证环节不可跳过。在交换机上确认MLAG状态为active、双活一致性检查通过；在存储节点上用cat /proc/net/bonding/bond0查看两个成员口是否都处于active状态。如果有一个成员口显示down或者aggselect失败，多半是两端LACP系统ID不匹配或者Trunk放行的VLAN不一致导致的。
负载均衡算法怎么选
哈希算法的选择直接决定了链路利用率。常见的哈希因子组合有src-mac、dst-mac、src-dst-ip、src-dst-ip-port这几种。对文件存储来说，客户端数量多、目的IP集中在存储节点上的流量模型，决定了纯MAC哈希效果很差：多个客户端经过同一台网关或虚拟化宿主机后，源MAC可能高度重复，流量会全部压到一条链路上。
实际部署中建议直接启用基于IP加端口的哈希，即五元组级别分流。这样即使客户端全部来自同一个虚拟化集群，不同的TCP会话也能因为端口不同而分散到各成员链路。以下是一个典型的均衡策略配置：
port-channel load-balance src-dst-ip-port
选型时还要区分组网层级。如果文件存储是纯二层接入，MLAG聚合口跑Trunk即可；如果存储流量需要三层转发，则要考虑在MLAG交换机上部署网关冗余方案，比如用VRRP配合MLAG，或者在支持MLAG网关虚拟化的平台上直接用任播网关。任播网关的优势是两台交换机都能本地转发，避免流量绕行peer-link，这在高吞吐场景下性能差距非常明显。另外，如果存储集群规模较大，超过两台的接入交换机需求出现时，MLAG这种双设备模型就不够用了，需要评估堆叠、虚拟chassis或者EVPN多归属方案。
注意事项与避坑建议
第一坑是peer-link带宽不足。很多故障场景下，比如一侧交换机到存储的成员链路全部断开，流量会全部改道peer-link转发，如果peer-link只有一条万兆而业务口是两条40G，故障瞬间的拥塞会导致存储I/O超时，甚至触发集群脑裂判断。经验法则是peer-link带宽不低于所有MLAG成员口带宽总和的一半，条件允许直接对等配置。
第二坑是双主检测失效。当peer-link断掉但两台交换机都还活着时，如果没有独立的keepalive链路做仲裁，两台设备都会认为自己应该独占转发，同一个虚拟MAC出现在两个位置，导致MAC漂移和流量黑洞。所以keepalive必须走与peer-link物理隔离的路径，通常是管理网，且不要经过MLAG交换机自身。如果条件允许，keepalive可以接一台上游独立设备，可靠性更高。
第三坑是配置一致性漂移。MLAG要求两端聚合口的VLAN放行列表、生成树模式、MTU等参数完全一致，有些平台在配置不一致时不会阻断业务，只打印告警，时间久了就会积累隐患。建议在变更流程中加入双端配置diff检查，或者启用平台的一致性校验强制模式。MTU尤其要注意，文件存储网络经常启用巨型帧提升吞吐，peer-link和所有MLAG成员口都要统一调整，否则会出现难以定位的碎片丢包。
第四坑是监控盲区。MLAG的很多问题在链路正常时看不出来，建议常态化监控几个关键指标：MLAG协商状态、peer-link利用率、各成员口的流量分布均匀度。如果发现某条成员链路长期流量占比超过60%而其他链路空闲，通常是哈希因子没有覆盖到实际流量特征，比如存储复制流量恰好是固定IP对之间的单连接，此时可以考虑在存储软件层面把复制会话拆成多线程来改善均衡度。
最后一点，升级和变更要按顺序来。MLAG两台交换机升级固件时，应先升级一台，确认业务切换正常、存储集群I/O无中断后再处理第二台。切忌两台同时重启，那样等于亲手制造双主故障。变更前把keepalive和peer-link的状态快照留存下来，回退时对照检查，能省去不少排障时间。