企业官网建设流程全解析

华为CloudEngine交换机的堆叠，是我这几年在数据中心网络项目里用得最多的可靠性手段，没有之一。堆叠的核心思想不复杂：把两台甚至更多台 CloudEngine 物理交换机用高速链路互联，整机对外呈现为一台逻辑交换机，一个管理 IP、一套配置文件、跨设备的 Eth-Trunk，控制面和转发面统一调度。华为在这个能力上分了两条路线：盒式 CE 走 iStack，框式 CE 走 CSS，两者理念一致，但硬件、命令和限制完全不同。这篇就把我从选型、规划、配置、验证到排障的完整过程写出来，适合正在做数据中心接入汇聚改造的工程师，也适合刚把 CE 设备拿到手、想一次性搞懂堆叠原理和坑的同行。

1. 堆叠方案选型：iStack 与 CSS 怎么选

1.1 两种技术的基本定位

很多人第一次接触华为堆叠时，会被 iStack、CSS、集群、堆叠这些词绕晕。其实按产品线区分就清楚了。

iStack（Intelligent Stack，智能堆叠）用在 CE6800、CE7800、CE8800 这类盒式交换机上。它最大的特点是不需要额外堆叠硬件，直接拿设备上的高速业务口当堆叠口用，常见的是 25GE、40GE、100GE 口。成本低、部署灵活，适合接入层和中小规模汇聚。

CSS（Cluster Switch System，集群交换系统）用在 CE12800、CE16800 这类框式核心交换机上。它通过主控板上的专用集群口或者独立的集群卡互联，提供更高的带宽容忍度和更强的转发能力，适合核心层和数据中心骨干。

两者对外表现完全一致：一台逻辑设备、一个管理面。区别主要在物理形态、转发能力上限和硬件依赖。用一张表看得更清楚：

选型第一件事，就是看手里设备的定位和手册里给的成员上限，别指望拿两台盒式设备硬顶核心业务，也别在接入层杀鸡用牛刀上 CSS。

1.2 从业务场景反推选型

我一般不会先问“这个设备能不能堆叠”，而是先问“这个位置需要什么样的故障域和扩展方式”。

服务器接入场景，最典型的做法是两台 CE6800 做 iStack，下联口跨框做 Eth-Trunk 接服务器双网卡，上联到汇聚交换机。一台设备宕机，服务器流量全部走另一台，业务无感知。这种场景对堆叠带宽要求不高，iStack 完全够用。

汇聚和中小规模核心场景，可以考虑多台 CE7800 或 CE8800 做 iStack。但要注意，堆叠成员越多，控制面合并带来的风险也越大，升级窗口和排障复杂度都会上升。一般超过四台我就会重新评估，是不是应该拆成两层或者换 CSS。

核心层场景，CE12800 / CE16800 的 CSS 是更稳的选择。框式设备本身交换容量大，专用集群口保障跨框转发不成为瓶颈，适合流量大、对可靠性要求极高的位置。

还有一类场景我不建议堆叠：两台设备要跨机房、跨楼宇部署。堆叠链路距离有限，而且一旦堆叠分裂，故障域会同时覆盖两个位置，反而把问题放大。这种场景更适合用跨设备链路聚合组（MLAG 类技术）或 EVPN 网关来解耦控制面。

1.3 硬件约束与可扩展上限

选型阶段最容易踩的坑是只看型号不看版本。同一个 CE 系列，不同软件版本支持的堆叠成员数、堆叠口类型可能都不一样。我每次做方案前都会做三件事：

• 查手册确认成员数量上限，并预留至少 1 台的扩容空间；
• 确认堆叠口支持的光模块型号和速率，避免配到一半发现模块不支持；
• 确认所有将要堆叠的设备软件版本一致，跨版本堆叠大概率协商不成功。

堆叠线缆长度也必须在规划里考虑。盒式设备 iStack 一般要求堆叠口之间用光纤或专用堆叠线，距离通常在同一个机柜或相邻机柜内。如果两台设备物理位置隔了三个机柜，中间还得绕走线槽，光纤长度和衰减就会成为隐患。

2. 动手前的规划：比敲命令更重要的事

2.1 成员编号、优先级与堆叠域

配置之前，先把三张牌定下来：成员编号（Member ID）、优先级（Priority）、堆叠域（Domain）。

成员编号就是设备在堆叠里的“座位号”。堆叠成立后，所有接口的编号都会带上成员编号，比如主设备的 100GE1/0/1，从设备的 100GE2/0/1 ，“1”和“2”就是成员编号。这个编号不能冲突，后续扩容也要预留好。

优先级决定谁是主设备（Master）。华为的选举规则我记了这么多年，核心就一句话：优先级数值大的当选；相同则 MAC 地址小的当选；再相同则成员编号小的当选。注意，这里比的是优先级，不是谁先开机。所以规划时要明确哪台设备承载关键业务、后续由谁主导管理，给它更高的优先级。

堆叠域是为了隔离网络中多套堆叠系统。如果同一个二层网络里有两套独立堆叠，它们之间不能互相干扰，就必须配置不同的 Domain ID。这跟 VLAN 隔离的逻辑有点像，Domain 错了会把两个本不该合并的系统硬凑到一起。

我给一个实际项目的规划表模板，你直接照着填：

2.2 堆叠拓扑与链路带宽设计

华为 iStack 支持链形和环形两种连接方式，我强烈建议你上环形，除非实在没有多余光纤。

链形拓扑所有设备排成一条线，任何一根堆叠线断开，堆叠就分裂成两段，两段各自为政，直接触发双主风险。环形拓扑相当于在链形首尾再加一条线，单根堆叠线断掉后，所有设备仍然通过另一条路径保持连通，堆叠不会分裂。两台设备组环形，就是两台之间拉两条线，逻辑上分别对应两台设备的 stack-port 1 和 stack-port 2。

链路带宽设计是很多人忽视的点。堆叠成立后，某台成员收到的下联流量如果要出上联口，而上联口不在本机，流量就要跨堆叠链路转发。如果堆叠链路带宽小于实际跨框流量，就会丢包。粗算方法很简单：先估计跨框流量峰值，再让堆叠链路总带宽留出至少 1.5 倍余量。比如每台设备下联有四条 100GE 满负荷，上联两条 100GE，那跨框流量可能到 1~2 条 100GE，堆叠链路至少做两条 100GE 才稳妥。

2.3 双主检测与故障域划分

堆叠不是银弹，它有一个必须面对的先天风险：堆叠分裂。

当堆叠链路完全断开，一个堆叠会变成两个独立的堆叠系统，两边都可能认为自己还是主设备，同时持有相同的业务 IP、相同的 VLAN 报文转发，这就是“双主”故障，网络瞬间乱套。所以华为 CE 提供了多主检测机制，常见叫法有 MAD、DAD（Dual Active Detection），作用是在堆叠分裂后，让低优先级一侧检测到对端仍然存活，然后主动把自己的业务口关闭，进入 Recovery 状态，避免两边同时转发。

很多人在规划时把这一环漏掉，等故障发生才追悔莫及。我的建议是：在堆叠规划阶段就预留一对空闲高速口做检测探测口，并保证探测链路和堆叠链路、业务链路三层隔离。检测方式一般分为直连和通过中间设备代理两种，直连只适合两台设备，代理适合多成员场景。选哪种，取决于你的拓扑和手头还有没有富余端口。

3. 核心配置实操：iStack 配置全流程

3.1 配置前准备与成员参数修改

命令可以抄，但准备工作不能省。我在现场的操作顺序是这样：

第一步，把所有要参与堆叠的设备软件版本对齐。版本不一致，堆叠协商阶段就会失败。

第二步，备份主设备的配置，同时清理从设备上不相关的业务配置。这里有个关键知识：堆叠成立后，系统保留的是主设备的配置，从设备原本的本地配置会被覆盖。所以不要把还要用的配置放在从设备上，否则堆叠完成那一刻就相当于被人清库了。

第三步，修改从设备的成员编号。默认情况下，每台独立设备都把自己当作成员 1。要把一台设备变成成员 2，需要在它的系统视图下进入 stack 视图执行成员重编号：

system-view stack stack member 1 renumber 2 quit save

重编号后设备会要求重启生效。注意不同软件版本命令格式可能有细微差异，执行前先打问号看提示，但思路是固定的。

重启完成后，这台设备就已经是成员 2。接着给它配置成员参数：

system-view sysname CE-Standby stack stack member 2 domain 100 stack member 2 priority 100 quit save

主设备的配置类似，方向相反：

system-view sysname CE-Master stack stack member 1 priority 200 stack member 1 domain 100 quit save

这里把主设备优先级设为 200，从设备保持默认 100，确保堆叠协商后由主设备当选 Master。

3.2 堆叠口绑定与链路协商

成员参数配好后，接下来绑定堆叠口。堆叠口是逻辑概念，每个成员最多两个逻辑堆叠口，命名方式就是“成员编号/堆叠口号”，比如 1/1、2/2。我们要把物理接口“塞”进逻辑堆叠口里。

主设备上，我习惯把 100GE1/0/1 和 100GE1/0/2 分别绑到 stack-port 1/1 和 1/2：

system-view stack stack-port 1/1 port interface 100GE1/0/1 enable stack-port 1/2 port interface 100GE1/0/2 enable quit save

从设备上，对应绑定 100GE2/0/1 和 100GE2/0/2：

system-view stack stack-port 2/1 port interface 100GE2/0/1 enable stack-port 2/2 port interface 100GE2/0/2 enable quit save

注意，物理口一旦被绑定为堆叠口，它原有的业务配置全部失效，不能再当普通业务口用。绑定前确认这些口上没有在跑的 VLAN、Trunk 或 IP 配置。

线缆连接也有讲究。两台设备做环形堆叠时，要交叉连接：主设备的 stack-port 1/1 连从设备的 stack-port 2/2，主设备的 stack-port 1/2 连从设备的 stack-port 2/1。别两根线都直连同一个逻辑口，那样形不成环，冗余效果大打折扣。

连接完成后，先给从设备上电，再给主设备上电，或者两台同时上电让优先级高的自动当选。堆叠协商成功后，从设备会重启加入堆叠，整个系统变成一个可管理的逻辑设备。

3.3 堆叠成立后的状态校验

第一次配置堆叠，心里没底太正常了，关键是会用校验命令确认状态。我常用的三个命令：

• display stack：查看成员列表、角色、堆叠拓扑和运行状态；
• display device：确认所有成员设备是否在位、状态是否 Normal；
• display interface brief：确认堆叠口和业务口是否都正常 Up。

看到所有成员都已经出现在display stack输出里，并且角色符合预期（一台 Master、一台 Standby），堆叠才算真正成立。

这时你还会发现一个明显变化：原来从设备上的接口编号变成了以 2 开头。这就是成员编号直接体现在接口命名上的效果，后续配置业务口、看日志、看告警，都要习惯这个编号规则。

3.4 跨框聚合与业务配置

堆叠最爽的地方，就是可以配置跨成员 Eth-Trunk。服务器双网卡接到两台不同成员上，逻辑上做成一个聚合口，任何一台成员故障，流量自动引流到另一台，业务零感知。

配置方式和单台设备没太大区别：

system-view interface eth-trunk 10 mode lacp-static trunkport 100GE1/0/3 trunkport 100GE2/0/3 quit

注意跨框 Eth-Trunk 要求成员接口速率一致，否则 LACP 协商会有问题。服务器侧配合 bond 双网卡，把负载均衡模式选好。这里建议优先用静态 LACP 而不是静态手工聚合，因为 LACP 可以感知链路状态变化，故障切换更快。

堆叠也简化了二层设计。整个堆叠逻辑上就是一台交换机，内部天然无环，常规 STP 配置可以大幅简化。但堆叠上联到另一个独立的二层设备时，环路风险仍然存在，上联口该做聚合做聚合，该开 STP 开 STP，别因为堆叠了就掉以轻心。

3.5 多主检测的落地

多主检测这块，我见过太多人抄网上老文档抄翻车，因为 CloudEngine 不同版本、不同系列的命令差异真的很大。我的建议很直接：不要背命令，上设备进 stack 视图，打一个问号，把本版本支持的多主检测相关关键字拉出来，再对照配置指南填参数。

但思路是通用的，你可以照着这个流程走：

1. 在规划阶段每台设备预留一个空闲高速口做检测口，例如 100GE1/0/4 和 100GE2/0/4，两台设备之间点对点直连；
2. 在 stack 视图下使能多主检测功能，并把检测口关联进去；
3. 根据两台设备的角色，把检测口的两端角色设置正确，通常是主设备侧和从设备侧各有一个方向；
4. 保存配置后，做一次手工分裂测试验证效果。

分裂测试的方法后面会讲。这里先记住判断标准：堆叠分裂后，低优先级一侧的成员应该检测到对端存活，把自己的业务口全部关闭，进入 Recovery 状态，而不是继续正常转发。能做到这一点，双主防护才算真正生效。

4. 验证、切换演练与日常维护

4.1 交付验收检查清单

堆叠配置完，别急着说“上线了”。我每次交付都会过一遍验收清单，不放过任何一个环节：

其中业务连通性测试，我建议在堆叠口 Down 的情况下也做一遍，别只测正常态。正常态全通说明不了可靠性，故障态不丢包才是堆叠的价值所在。

4.2 主动故障演练：拔线测试

堆叠这种高可用架构，一定要在可控环境里先“炸”一次。我最常做的演练分两级：

第一级，拔一根堆叠线。环形拓扑下，所有成员仍然连通，堆叠不会分裂，业务应该不受影响。观察 5 分钟，确认日志没有双主告警，再把线插回去，确认堆叠链路恢复。

第二级，拔掉全部堆叠线，模拟彻底分裂。这时两套系统同时独立运行，多主检测应该触发，低优先级设备业务口全关。这种演练必须挑维护窗口，因为恢复合并时设备可能要重启，会造成短暂中断。演练完后，恢复堆叠链路，让两套系统重新合并，观察角色还原、业务恢复。

演练记录一定要写清楚：拔哪根线、出现什么告警、恢复用了多久。这些数据后续排查故障时是救命稻草。

4.3 版本升级与扩容

堆叠升级比单台设备要谨慎得多。核心原则是：所有成员必须在同一个维护窗口内完成升级，不能长期混版本运行。因为堆叠成员之间版本不一致时轻则告警，重则影响跨框转发。

我的升级流程是：

1. 上传新版本文件到主设备，并配置为所有成员的指定下次启动版本；
2. 检查配置文件备份，确认关键配置可以回退；
3. 在维护窗口内重启整个堆叠或逐台重启；
4. 重启完成后验证display stack成员状态和业务连通性。

扩容相对简单。新设备先离线把成员编号、Domain、版本都配好，然后断电、连堆叠线、上电，让它自动加入堆叠。加入后立刻检查角色是否按规划生效，如果新设备意外当选 Master，马上检查优先级是不是忘了配。

5. 常见故障与排查技巧

5.1 堆叠协商失败的典型原因

堆叠协商不成功的现象很典型：display stack里永远只看到本机，或者新设备反复重启。排查顺序我建议从物理层往上走，别一上来就怀疑配置。

先看光纤和光模块。堆叠口两端必须使用同一类型的光模块，速率必须一致。25GE 口插了 10GE 模块，或者 100GE 口两端的模块速率不同，链路都可能起不来。其次是光纤收发接反或者插错口，尤其是环形连接时，两端的逻辑口对应关系错了，对端收不到预期的堆叠报文。

再看配置。确认堆叠域、成员编号、优先级都已保存生效。很多工程师配置完忘了save，设备一重启全回到解放前，这是最低级也最常见的翻车现场。

最后看版本。成员之间软件版本不一致，协商必然失败。这个在规划阶段就要杜绝，排查时也别忽略。

5.2 主备切换后业务闪断或丢包

堆叠平时跑得好好的，一主备切换就丢包。遇到这种情况，优先查三个地方。

第一，堆叠带宽。主备切换瞬间，所有跨框流量全部压在堆叠链路上，如果堆叠口带宽不够，直接丢包。用display interface看堆叠口的流量统计，确认峰值没超过带宽的 70%。

第二，跨框聚合配置。确认下联和上联的 Eth-Trunk 是否都正确跨了两个成员，如果聚合口只在单台成员上，那另一台宕机时这个聚合口就直接断了，业务自然受损。

第三，多主检测误判。如果原本不该分裂的堆叠触发了 Recovery，低优先级设备业务口全部关闭，整个设备就像“宕机”了一样。这种情况要回头看 DAD 链路和堆叠链路是否同时发生了问题。

5.3 多主检测误触发与恢复流程

我自己就踩过一次：某次割接，操作人员不小心把 DAD 探测口的线拔了，又恰好堆叠链路因为光模块故障抖动，结果 DAD 误判对端存活，低优先级设备直接进入 Recovery，业务口全关，整个汇聚节点下联全断。

恢复流程其实不复杂，但顺序不能乱：

1. 恢复 DAD 探测链路，确保两端口 Up；
2. 恢复物理堆叠链路；
3. 等待两套系统重新合并，Recovery 侧设备会在合并时重启或需要手动重启；
4. 重启完成后，用display stack确认成员重新加入、角色还原；
5. 逐步打开业务口，验证业务恢复。

注意，Recovery 侧设备业务口全关是正常保护行为，千万别以为设备坏了就盲目重启。先恢复链路，再让软件自己完成合并，才是正确路径。

5.4 常见问题速查表

这两年开始，我每次给新项目做堆叠方案，都会在交付文档里单独留一节“故障演练记录”，把拔线测试、分裂测试的时间、现象、恢复时间全部写进去。运营团队后期遇到问题，翻记录比翻手册有用得多。最后分享一个我的习惯：堆叠虽然对外像一台设备，但运维心态上千万别把它当一台设备。告警监控要覆盖每个成员、日志要按成员区分、巡检要逐台看状态，把每台成员的“健康档案”记清楚。只有这样，堆叠才能从纸面上的高可用变成实际业务里真正扛得住的高可用。