前阵子一个老客户半夜打电话过来，说办公室网络突然卡得没法用。我远程一看，拓扑里核心交换机后面挂着两台接入交换机，其中一台离线了，业务流量全挤到剩下那一台上面，广播域又大，环路检测又没做好，整个局域网直接半瘫痪。这事其实挺典型的，单台交换机跑关键业务，不出事怎么都好说，一出事就是全网陪葬。后来我过去帮他们把两台接入交换机做了堆叠，又顺手整理了上联链路，问题才算彻底解决。今天没别的，就着这个场景，认真聊聊交换机的堆叠与集群。

1. 为什么说堆叠和集群是网络运维的“双保险”

很多人第一次接触堆叠和集群，都是在被领导批评之后：核心设备单点故障、链路带宽不够、管理地址太多太乱、配置同步麻烦。堆叠和集群这个名字一听就觉得高端，其实本质思路特别朴素：把多台交换机变成一台来用。

1.1 一个“拿走交换机就卡死”的经典故障

热搜里有个问题我一直印象很深：为什么从局域网中拿走一个交换机后很卡？这个问题如果放在没有堆叠、没有集群的环境里，答案基本就一句话——拿走的那台交换机承担了部分网关或汇聚功能，或者干脆就是环路被破坏了之后STP重新收敛，导致全网广播风暴。但更深层的原因是，你的网络设计里压根没考虑设备冗余和链路冗余，单台设备死掉，流量只能绕路，绕路之后带宽或者路径又不对，于是卡。

我自己踩过的坑是：公司有四个部门，原来规划是每层楼一台24口接入交换机，分别上联到一台核心，核心没做双机，接入更没做堆叠。结果有一次一台接入交换机因为电源模块老化直接断电，整个楼层办公全部断网。修好之后我做了两件事：一是把接入交换机全部换成支持堆叠的型号并两两堆叠，二是把上联改成双链路到两台核心。从那以后，再遇到单台硬件故障，用户基本无感知，顶多丢一两个包。

1.2 我理解的堆叠和集群到底解决什么问题

如果非要用一句话概括，堆叠解决的是横向扩展和简化管理的问题，集群解决的是高可用和负载分担的问题。堆叠把多台物理设备虚拟成一台逻辑设备，管理IP只有一个，配置可以统一下发，跨设备的链路可以捆绑成Eth-Trunk，环路被天然消除。集群则更偏重控制层面的协同，多台设备之间通过心跳互相备份状态，一台挂了另一台立刻接管业务。

我举个生活化的例子：堆叠就像你雇了好几个员工，但他们坐在一起，对外只留一个接待窗口，客户觉得你是一个人；集群呢，是开了好几个分店，每家店都有人值班，一家店出了问题，客户走到另一家店照样办事。前者优化的是内部效率和资源利用率，后者保障的是服务的连续性。

这里我得强调一点：堆叠和集群不是替代关系。很多场景下它们会配合使用——接入层用堆叠扩展端口密度和上联带宽，核心层用集群或双机热备保障整网稳定。如果你在规划设计阶段把这两件事分开想，后面很多麻烦其实都可以避免。

2. 堆叠与集群的底层逻辑拆解

光知道概念不顶用，咱得把原理吃透。交换机的堆叠和集群，核心都是虚拟化技术，但虚拟化的层面不同。

2.1 堆叠是怎么“变一台”的

堆叠的底层实现，简单说就是把多台交换机的控制平面和转发平面合并成一个。每台参与堆叠的设备叫成员交换机，按角色分为主交换机、备交换机和从交换机。主交换机负责整个堆叠系统的管理和协议计算，备交换机是主交换机的备份，从交换机只做业务转发。三者的角色不是固定的，系统运行中会根据角色选举规则动态调整，比如主交换机挂了，备交换机会自动顶上。

堆叠系统的控制平面是合并的，对外表现就是一台设备。你登录堆叠系统之后看到的接口，会带一个成员编号前缀，比如GigabitEthernet 1/0/1和GigabitEthernet 2/0/1，分别表示第一台成员和第二台成员上的接口。配置的时候一条命令就能下发到所有成员，VLAN、ACL、路由协议这些配置全部全局生效。

这里面最关键的是堆叠口。堆叠口是专门用来连接成员设备之间高速链路的口，业务数据和控制报文都会走这个口。华为的设备上，堆叠口可以是一个物理口，也可以把多个物理口捆绑成一个逻辑堆叠口来用，目的就是提高堆叠链路的带宽和可靠性。

2.2 集群/高可用和堆叠的差异

集群这个词在网络里用得挺泛，思科叫StackWise和VSS，华为叫集群交换机系统（Cluster Switch System，CSS），H3C叫IRF（Intelligent Resilient Framework），锐捷有自己的VSU（Virtual Switching Unit）。不同厂商的命名不同，但核心思想都差不多：把两台或多台设备组合成一台逻辑设备，统一管理、统一转发。

集群和堆叠的区别，最容易让人晕的地方在于：厂商有时会把这两种技术混着叫。以我实际使用经验来看，判断标准很简单——看它对控制平面的处理方式。堆叠通常是把多台设备的控制平面合并成一个逻辑控制平面，参与堆叠的设备之间通过堆叠口传输大量的协议报文和表项同步信息；集群则更强调独立设备的协同，每台设备仍然有自己的控制平面，但通过集群协议同步关键状态，对外虚拟成一个整体。

用华为的iStack（Intelligent Stack）和CSS来对比更直观：iStack一般用于中低端框式或盒式交换机，最多支持9台堆叠，适合接入层和汇聚层；CSS一般用于核心交换机，本质是把两台框式交换机虚拟成一台，适合数据中心核心或园区网核心。CSS对硬件的要求更高，需要专门的集群接口板或集群线缆，稳定性也更强。

2.3 各厂商堆叠技术命名与定位

我在实际项目中接触过不少厂商设备，各家堆叠技术能力参差，但总体上都挺成熟，这里按我自己的经验给个定位参考：

表格里这些数字是常规值，具体还要看软件版本，不要拿老版本的限制套新版本设备。另外我得提醒一句：跨厂商堆叠是行不通的，堆叠协议是私有的，不用想着华为和思科混堆，选型的时候就得把品牌统一。

3. 华为堆叠配置实战：从零到一落地

前面聊了原理，下面拿华为设备走一遍真实配置。我这边用的示例是两台S5720-52X-SI，版本是V200R019C10，做的是业务口堆叠。为什么选业务口堆叠而不是专门的堆叠口？因为S5720这种盒式交换机大多数没有专门堆叠口，直接拿万兆光口或者千兆光口当堆叠口就能用，灵活又省钱。

3.1 开工前必须确认的硬件条件

做堆叠前，先检查三样东西，缺一样都别开工：

第一，软件版本必须一致。我用华为设备比较多，在系统视图下执行display version就能看到版本号，参与堆叠的设备版本不一致时，系统会提示可能堆叠失败。哪怕小版本号不同，也建议先升级再组堆叠，不然有的功能会异常。

第二，堆叠口之间的连线必须做对。华为的堆叠口是有编号的，业务口堆叠的时候需要先创建逻辑堆叠口，再把物理口加进去。两台设备组堆叠时，通常要两根线交叉连接：1号设备的堆叠口1连2号设备的堆叠口2，1号设备的堆叠口2连2号设备的堆叠口1。如果接成直连，堆叠会起不来。

第三，设备启动方式要是堆叠模式。华为很多盒式交换机出厂默认就是堆叠模式，不用额外切换；但有些型号需要在BIOS里改启动模式。我遇到过一次，设备是独立模式，怎么配堆叠都不生效，后来查文档才发现要改启动方式并重启。

3.2 华为堆叠配置：从规划到命令行

我规划的是两台设备组成一个堆叠系统，成员编号分别是1和2，堆叠域编号固定为10，堆叠优先级1号设为200（让它成为主），2号保留默认100。这样设计是防止设备同时启动时角色竞争不稳定。

先配置1号设备。进入系统视图，修改成员编号和优先级，再创建堆叠端口：

system-view sysname SW_Building_A stack stack member 1 priority 200 stack member 1 domain 10 stack-port 1/1 port interface GigabitEthernet0/0/27 stack-port 2/1 port interface GigabitEthernet0/0/28

注意这里的stack-port写法，第一个数字是成员编号，第二个数字是堆叠口编号。比如stack-port 1/1表示给1号成员创建堆叠口1，再把物理口27加进去。2号设备同样操作，但成员编号改成2，优先级保持默认：

system-view sysname SW_Building_A stack stack member 2 domain 10 stack-port 1/2 port interface GigabitEthernet0/0/27 stack-port 2/2 port interface GigabitEthernet0/0/28

然后把两台设备断电，用堆叠线缆交叉连接：1号设备的物理口27连2号设备的物理口28，1号设备的物理口28连2号设备的物理口27。接好后先给1号设备上电，等它完全启动后再给2号设备上电。这样做的目的是让1号先完成初始化，大概率稳坐主角色。

两台设备都启动后，在1号设备上执行display stack查看堆叠状态。如果显示堆叠成员有2台，角色一个是Master一个是Standby，那就说明堆叠建立成功。如果只显示1台或者成员角色不对，优先检查连线顺序和堆叠口配置。

3.3 业务口堆叠的雷区和注意事项

业务口堆叠虽然方便，坑也不少。

第一，物理口加入堆叠口之后，这个物理口就不能再当普通业务口用了。我见过有人配完堆叠后怎么都ping不通某些业务地址，排查半天发现是在堆叠口里加了业务物理口，导致那根线被堆叠系统占用了。所以在规划的时候，端口预留一定要够，别把堆叠口和业务口混在一起。

第二，堆叠链路的带宽会影响整机转发性能。两台设备之间的流量，如果走堆叠口，带宽不够就会拥塞。我的建议是堆叠口至少用万兆，如果只有千兆口，堆叠内跨设备流量大的时候会明显掉速。S5720-SI这种型号自带4个万兆光口，优先拿万兆口做堆叠，千兆口留给业务。

第三，跨设备链路聚合很重要。堆叠做完之后，一定要把上联口或下联口跨设备捆绑成Eth-Trunk，不然堆叠就失去了一半意义。我处理过一个现场：堆叠做完了，但下联服务器的两根网线分别插在不同成员交换机上，没有做链路聚合，结果一台成员设备挂了，服务器依然断网。跨设备聚合才能让流量在成员间自动切换，才能真正利用堆叠的冗余能力。

4. 堆叠核心机制：选举、分裂与MAD

配置做完只是第一步，能把堆叠运行机制搞明白，后面出问题才能快速定位。堆叠系统里最核心的三个机制：角色选举、成员加入、堆叠分裂。这三个机制决定了一旦拓扑变化，堆叠表现如何。

4.1 堆叠系统的角色选举规则

堆叠建立或拓扑变化的时候，会触发角色选举。选举规则按顺序比较：运行状态（已经运行的优先）、堆叠优先级（数值大的优先）、MAC地址（小的优先）。我前面配置里把1号设备的优先级设成200，就是为了保证它稳定当主设备。

角色确定后，主交换机会负责收集所有成员的拓扑信息，计算转发表项，然后同步给备机和从机。这里有个细节：如果后来新加入一台设备，它的配置会和主设备冲突，新设备会自动清空自己的配置，跟随主设备重新下发配置。所以给堆叠系统加新成员时，千万别接上就完事，要等它自动同步，着急开业务可能会因为配置不一致产生奇怪问题。

4.2 堆叠分裂为什么很危险

堆叠分裂是运行中最危险的事件，没有之一。人为原因最常见：有人拔了堆叠线缆，或者某台设备的堆叠口光模块坏了。一旦堆叠链路断开，原本的一个堆叠系统会变成两个独立的系统，而且是两个系统还在转发同一个网段的流量，IP地址、VLAN配置完全一样，这就形成了事实上的双主冲突。

双主冲突之后，原来走堆叠口的跨设备流量全部断掉，网络广播报文还会在两个系统之间反复横跳，严重时直接广播风暴。这时候如果没做MAD检测，整个网络会变得极其不稳定，想远程登录设备处理都困难。

4.3 MAD检测配置与建议

MAD（Multi-Active Detection，多主检测）就是专门用来解决这个问题的。它通过一条独立于堆叠口的链路检测对方是否存活。常用的MAD方式有直连检测和代理检测。直连检测适合两台成员设备的场景，用一根普通网线把两台设备的检测口互连；代理检测适合多成员设备，通过中间设备进行检测。

华为设备配置直连MAD的典型命令：

system-view interface GigabitEthernet0/0/29 mad detect mode direct

我在实际项目中习惯把所有空闲端口也开启mad检测，并把堆叠域编号统一规划。要注意，MAD检测口不能用来跑业务，必须独立占用一个物理口，最好是千兆以上端口，专门留给堆叠自愈用的。

还有一个容易忽略的坑：MAD检测配置在成员设备上要写一样的命令。如果只在一台设备上配了，另一台没配，分裂后检测机制形同虚设。

5. 从交换机堆叠看向服务器集群

聊了这么多交换机堆叠，肯定有不少朋友是搞服务器集群的。其实这两个方向在工程实践中往往是绑定的：服务器集群要稳定，网络侧必须给力。

5.1 服务器集群对网络的新要求

我自己搭过Hadoop、Kafka和K8s集群，也帮人排查过因为网络问题导致集群不稳定的案例。服务器集群的流量模式和传统办公网差别很大：东西向流量占比极高，节点之间要频繁通信，数据副本同步、任务调度、心跳检测全都在局域网内完成。

比如Kafka集群，broker之间要复制消息，节点一多，内网带宽很容易被刷满。这时候如果接入交换机的带宽不够、单台设备转发能力弱，就会出现消费者拉取消息延迟、rebalance频繁触发。Hadoop集群跑shuffle的时候，多个节点同时拉取中间结果，对网络时延非常敏感，交换机缓存太小都会拖慢整个任务进度。

所以有条件的情况下，服务器接入交换机最好也是双机上联+堆叠或集群，服务器网卡做bond，交换机之间做跨设备链路聚合。这样即使一台交换机故障，集群通信也不会中断，不会因为网络抖动触发节点间心跳超时。

5.2 网络侧给集群做保障的几个习惯

第一，把服务器区域单独划VLAN，隔离广播域。办公网的广播报文本来就多，如果服务器和办公电脑混在一起，集群通信会被击穿。我的习惯是把服务器单独划一个VLAN，并关闭不必要组播，减少无谓的协议报文干扰。

第二，给集群业务流量打上高优先级。现在很多交换机支持简单的QoS，可以通过简化优先级的配置，让集群的心跳、存储同步这些关键流量优先转发。我用华为设备时，会做流策略，把服务器网段的流量映射到EF队列，保证集群流量在网络拥塞时不被丢弃。

第三，监控交换机的CPU和内存。集群跑大任务的时候，交换机如果处理不过来，会出现CPU占用率飙升，表现为管理面卡顿、协议邻居频繁震荡。遇到这种情况，优先检查是不是交换机型号选得小了，其次检查有没有被异常广播报文打满。我一般会开启SNMP，配合Prometheus或Zabbix监控交换机端口流量、CPU、内存，提前发现问题。

6. 常见问题与排查技巧实录

写了这么多，最后来点实践沉淀。我整理了一张速查表，全是在现场遇到过的真实问题，照着排查能省很多时间。

6.1 我整理的一份常见故障速查表

6.2 华为6720堆叠配置踩坑笔记

热搜里也有华为6720堆叠，我顺手说一下。S6720系列本身是数据中心接入交换机，做堆叠和普通S5720思路类似，但要注意它的40GE端口用得比较多，配置堆叠口的时候需要指定端口类型。

配置示例：

interface Stack-Port 1/1 port interface 40GE1/0/27 interface Stack-Port 2/1 port interface 40GE1/0/28

我遇到过一次诡异问题：S6720堆叠建好之后，display stack显示正常，但两台设备之间的三层转发一直不通。后来抓包发现是堆叠系统的虚拟MAC地址在跨设备学习的时候出了岔子，最后把MAC地址老化时间调短、同时清空动态表项，才恢复正常。这种底层表项问题不好复现，真遇到了别慌，先从表项查。

6.3 锐捷、H3C堆叠的配置习惯

锐捷交换机做VSU，我习惯先确认设备是否支持，因为不是所有型号都支持VSU。VSU配置需要在特定视图下进行，先给设备配置域编号，再指定成员ID，然后创建VSL端口并把物理口加进去。锐捷的VSL端口绑定和华为的逻辑堆叠口类似，但它更强调物理口要成对绑定，不推荐一根线堆叠。

H3C的IRF配置逻辑和华为很像，核心命令是irf member、irf-port、port group interface。H3C的坑在于，如果设备之前配置过业务，重新组IRF时经常出现配置冲突，最好的办法是清空设备配置再组。H3C的IRF分裂之后也有irf mad检测，包括链路级检测和扩展LACP检测，合理使用都能快速感知双主问题。

7. 最后分享几个我自己的使用体会

写到这里，差不多把我的经验和理解都铺开了，最后收个尾，说几句真心话。

堆叠和集群，说到底只是网络高可用方案的前半段，设备级冗余解决了，后面还要考虑链路级、网关级、甚至机房级的冗余。我在实际规划时，一般遵循一个原则：能成对就成对，能聚合就聚合，能检测就检测。堆叠解决了设备层面的虚拟化，Eth-Trunk解决链路层面的冗余，MAD解决分裂后的脑裂问题，三者配合，才能真正把网络做稳。

我个人最深的体会是，堆叠和集群不是配完就完事。我见过太多项目，堆叠配好了，但MAD没开、跨设备聚合没做、堆叠线缆质量差、堆叠口带宽不够，整个堆叠系统的价值大打折扣。技术没有银弹，关键还是看落地细节。后面如果你也准备给自己的网络加堆叠，建议先在小范围测试环境里把配置和故障演练做一遍，再上生产，这样会踏实很多。