企业官网建设流程全解析

做网络运维这些年，凡是涉及业务断网的改造，我都习惯先问一句：有没有办法让设备自己扛住故障？华为交换机堆叠（iStack）就是我最常用来回答这个问题的技术。简单说，它把两台或更多物理交换机在逻辑上合并成一台设备，统一管理、统一配置，控制面由主交换机负责，转发面则由所有成员共同承担。这个技术我最早是为了解决一个数百人办公网的汇聚层单点故障，后来在数据中心接入层、园区万兆组网里也反复用到。这篇文章不讲那些特别冷僻的理论，主要分享我实际部署 iStack 时的选型思路、配置过程、验证手段，以及后面维护中踩过的几个必须提醒新手的坑。无论你是刚接触堆叠的网络新人，还是打算给现有网络做高可用改造的运维同学，应该都能省下不少摸索时间。

1. 为什么堆叠——一台设备顶不住，两台又怕维护累

1.1 一个典型场景：百人规模办公网的单点故障

我第一次认真考虑堆叠，是因为一个特别常见的破事。某公司办公网的汇聚交换机用了三年多，板卡上某个端口开始频繁闪断。网络维护的人都知道，这种隐藏故障最折磨人——白天业务看着正常，一到晚上流量稍大就出问题。当时全网就靠这一台汇聚设备撑着，交换机后面挂着十几个接入交换机的千兆上联，所有员工的办公流量、打印、文件共享全走它。要换设备就得断网，断网就意味着整个办公室瘫痪。

后来我和同事商量，干脆在这个位置部署一套 iStack 堆叠，用两台物理设备组成逻辑单台。这个方案最打动我们的点不是“技术先进”，而是它把两个问题一起解决了：单点故障没了，上联带宽也翻倍了。当时网上关于堆叠的教程不多，我们边查文档边测试，前后折腾了两个晚上才把整套拓扑稳定跑起来。现在回头看，那些时间花得非常值。

1.2 堆叠到底解决了什么：冗余、带宽和管理

堆叠带来的收益，我会用三个词概括：冗余、带宽、省心。

冗余这块最好理解。一台成员设备故障，另一台继续转发业务，只要不是整堆叠都挂掉，业务基本不受影响。实际维护中，我遇到过某台成员设备的电源模块损坏，堆叠系统自动把转发压力全部切到另一台，现场业务没有任何感知。

带宽这块，重点是跨设备链路聚合。普通链路聚合只能把同一台设备上的多个端口捆在一起，堆叠之后可以把两台设备上的端口捆成一个逻辑口，吞吐能力直接叠加。比如两台设备各出一个万兆口组成 Eth-Trunk，逻辑上就是一个 20G 的链路。

管理这块，原本要分别登录两台设备，现在一个管理 IP、一份配置，配置自动同步到所有成员。这个“一台设备”的感觉，在做接入层改造的时候尤其重要，因为运维人手往往不多，设备越多越难管。

1.3 “多台变一台”背后的隐藏成本

堆叠不是没有代价。多台设备当成一台设备，意味着成员之间必须软件版本一致、堆叠 ID 唯一、域编号一致，维护方式跟单机完全不同。这也是为什么网上总有人质疑“堆叠不好用”，然后举例时往往是把线拔了、或者堆叠 ID 配置冲突导致起不来。

所以我不建议把一个还没想清楚物理连接和业务拓扑的堆叠直接上线。堆叠的配置命令本身不多，真正的难点在于设计：哪两台设备配对、用哪些端口做堆叠口、业务口怎么规划、跨设备聚合怎么接。这些想明白了，后面操作就是照方抓药。

2. iStack 底层机制：角色选举、堆叠 ID 与“一台设备”的真相

2.1 主备从角色如何产生

很多人以为堆叠的主备关系和传统双机热备差不多——主设备干活，备设备在旁边等着。这是误解。在华为 iStack 体系里，主交换机、备用交换机、从交换机这三个角色，真正区别主要在于控制面管理，而不是转发。

主交换机负责整个堆叠系统的管理面：配置同步、版本管理、协议状态维护等，相当于这个逻辑设备的“大脑”。备用交换机是主交换机的影子，平时也参与业务转发，只是随时准备在主交换机故障时接替控制面。从交换机则更多承担转发任务。

选举规则说穿了很简单：先比优先级，数字越大越优先；优先级相同比 MAC 地址，越小越优先；再相同就看堆叠 ID。这有点像几个同事同时开会，谁职位高谁牵头，职位相同就看谁先到。设备刚上电时，会有一个启动协商过程，正常情况下几秒到十几秒就能选出主交换机。

2.2 堆叠 ID 决定了什么：槽位号和接口命名

堆叠 ID 是我见过的坑里最容易被忽略的一个。每个成员必须有一个唯一的堆叠 ID，范围通常是从 0 到 9。这个 ID 一旦确定，会直接体现在接口编号上：假设某台成员设备的堆叠 ID 是 1，那它的业务口编号就是 10GE1/0/1、10GE1/0/2 这种格式；堆叠 ID 是 2 的设备，接口就是 10GE2/0/1、10GE2/0/2。

也就是说，堆叠 ID 本质上充当了设备在堆叠系统里的“槽位号”。好多新手第一次配置堆叠，登录第二台设备后按照单机习惯找接口，结果发现原来的 10GE0/0/1 变成了 10GE2/0/1，直接懵了。这不是设备坏了，是堆叠 ID 生效后的正常变化。

配置堆叠 ID 也要小心。设备默认堆叠 ID 是 0，如果两台设备都不改，它们就都是 0，逻辑上根本分不清谁是哪个成员。正确的做法是先通过stack slot 0 renumber 1这种命令把设备重新编号，保存并重启后再加入堆叠系统。

2.3 域编号、优先级、系统 MAC 和 MAD 的关系

堆叠里还有一个容易踩雷的参数叫域编号。域编号用来区分同一网络中的不同堆叠系统，默认是 0。如果同一个二层网络里有两套以上堆叠，域编号必须配成不同值，否则邻居发现机制会串味。

优先级的作用前面说过，范围一般是 1 到 255，默认 100。想让哪台设备当主，就把它的优先级调大。主设备确定后，整个堆叠系统会对外表现一个虚拟的系统 MAC，二层邻居看到的是一个统一设备。

这里必须提到 MAD（Multi-Active Detection，多主检测）。堆叠如果发生分裂但没有检测机制，两台设备会各自认为自己是主，出现“双主”状态，网络里就会出现 MAC 地址漂移、ARP 表抖动、网关冲突等一堆怪问题。MAD 就是用来防止这种情况的机制，它依赖域编号来识别对端是否属于同一个堆叠系统。所以生产环境配堆叠，域编号和 MAD 是配套动作，不能只配一半。

3. 组网和端口规划：环形还是链形、跨设备聚合怎么接

3.1 环形连接的冗余逻辑

华为盒式交换机的堆叠，物理连接方式主要有环形和链形两种。我的建议一直很明确：生产环境只做环形，不做链形。

环形连接的意思是，成员设备之间通过堆叠口首尾相连，形成一个环路。比如两台设备，A 的 1/1 口连 B 的 2/1 口，A 的 1/2 口连 B 的 2/2 口，两条线形成一个环。正常工作时，系统内部的流量既可以从 A 到 B，也可以从 B 到 A，任何一条堆叠链路断开，系统仍然可以经由另一条链路通信。

链形连接就危险得多。比如三台设备串成一条线，中间任何一根堆叠线缆断开，整个堆叠系统就会从断点处分裂成两个独立系统。这等于把你精心设计的高可用直接打回单点故障。我见过不止一次，运维图省事只拉了一根堆叠线，结果某次光纤被老鼠咬断，网络直接瘫痪。

3.2 堆叠口的本质与接线要点

华为盒式设备的堆叠口，本质上是由业务口转换而来的逻辑接口。你可以把 10GE 口、40GE 口绑定到逻辑堆叠口上，让它专门承担堆叠互联流量。这意味着一个 10GE 口一旦被绑定到堆叠口，就不能再当普通业务口用了。

规划端口时，我习惯先数清楚这台设备的业务口需求，再决定哪几个口划给堆叠。比如一台设备有 4 个万兆上联口，我会选其中两个做堆叠口，剩下两个做跨设备聚合上联到核心。不要贪心把所有高速口都做堆叠口，否则业务侧反而没有足够的接入能力。

物理连线这块有个容易忽略的点：请使用原厂堆叠线缆或对应规格的光模块，不要随便找个网线或者低速率光模块凑合。堆叠口之间承载的是系统内部的跨设备转发流量，带宽和稳定性要求都很高。另外，堆叠线缆建议单独走线，做好标签，不要让它在机柜里和其他网线缠在一起。后面排错时，标签清楚能省很多时间。

3.3 跨设备 Eth-Trunk 怎么设计

堆叠真正的价值，在很大程度上要靠跨设备 Eth-Trunk 来体现。普通链路聚合只在单台设备内做，跨设备聚合则把两台成员设备上的端口放入同一个 Eth-Trunk，对外表现为一条逻辑链路。

举个例子：某台接入交换机需要双上联到汇聚层，汇聚层由两台设备做堆叠。我可以把 10GE1/0/21 和 10GE2/0/21 都加入 Eth-Trunk 1，一根线上联到接入交换机的 A 口，另一根上联到 B 口。当堆叠中某一台成员设备故障时，Eth-Trunk 仍然能够通过另一台成员继续转发，整个链路不中断。

配置跨设备 Eth-Trunk 时，需要注意两端聚合模式必须一致，成员端口速率保持一致，建议采用 LACP 动态聚合模式，这样协商更可靠。另外，Eth-Trunk 的成员端口千万不要包含已经绑定为堆叠口的物理端口，否则配置会冲突。

4. 配置实操：两台 S 系列交换机完成 iStack

4.1 硬件准备、连线方式和初始登录

以两台华为 S 系列盒式交换机为例，比如常见的 S5720 或 S5730 系列。部署前先准备好两台设备、两根堆叠线缆（或对应光模块）、一根 console 线。把两台设备放到可以同时操作的位置，先把版检查一遍：登录每台设备执行display version，确认两台设备的软件版本一致。如果版本不一致，先统一版本再继续，不要带着差异做堆叠。

接下来是清空旧配置。如果设备是二手或者测试留下的，建议执行reset saved-configuration并重启，让设备回到出厂状态。不要嫌麻烦，残留配置往往是堆叠建立失败的隐形原因。

物理连线建议采用环形方式：设备 A 的 10GE 口连接设备 B 的 10GE 口，设备 A 的另一个 10GE 口连接设备 B 的另一个 10GE 口，形成两条堆叠链路。先不要着急把所有业务口都接上，等堆叠建立验证通过后再恢复业务连线。

4.2 命令行：从堆叠 ID 到堆叠口绑定

下面是两台设备的大致配置流程。不同版本命令可能有细微差异，以你设备实际使用的版本为准，但整体思路是一样的。

第一台设备（计划作为成员 1，优先级调高让它当主）：

system-view stack slot 0 renumber 1 stack member 1 priority 200 stack domain 100 quit save reboot

第一台重启后，继续配置堆叠口并绑定物理端口：

system-view interface stack-port 1/1 port member-group interface 10GE1/0/49 interface stack-port 1/2 port member-group interface 10GE1/0/50 quit save reboot

第二台设备（计划作为成员 2）：

system-view stack slot 0 renumber 2 stack member 2 priority 100 stack domain 100 quit save reboot

第二台重启后，配置自己的堆叠口：

system-view interface stack-port 2/1 port member-group interface 10GE2/0/49 interface stack-port 2/2 port member-group interface 10GE2/0/50 quit save reboot

这里要特别提醒：堆叠口编号里的“1/1”“2/1”，前面的数字就是堆叠 ID。也就是说interface stack-port 1/1是在为堆叠 ID 为 1 的成员配置第一个堆叠口，interface stack-port 2/1是在为堆叠 ID 为 2 的成员配置第一个堆叠口。绑定物理端口时，接口编号也要带着相应的堆叠 ID 前缀。

配置完成后，两台设备再重启一次，正常情况下就能在物理线缆连通的状态下自动建立堆叠。

4.3 重启后如何验证

堆叠建立后，不要急着接业务，先用验证命令确认系统状态正常。我常用的验证命令就四个：

实际操作中，我的验证清单大概是这样：

• display stack中能看到两台设备的堆叠 ID、优先级、角色，状态为稳定；
• display device中所有成员状态为 Normal；
• 通过一个管理 IP 登录，能同时管理两台设备；
• 在业务口上做连通性测试，跨成员转发正常。

如果条件允许，最好再做一次主备切换测试：手动重启主交换机，观察备用交换机是否顺利接管控制面，业务中断时间是否在可接受范围内。这个测试看起来麻烦，但能提前暴露很多潜在问题。

5. 排错实录：分裂、配错、换备件时我怎么处理

5.1 堆叠分裂的典型症状

堆叠分裂是我在运维中最不愿意看到的情况之一，但很多人第一次遇到时根本不知道是分裂。典型症状是：原本正常的网络突然大量丢包、设备管理地址时而通时而不通、交换机日志里出现一堆 MAC 地址漂移告警。

用display stack查看时，如果发现原本应该在一起的成员变成了独立状态，或者出现了两个 Master，基本可以断定堆叠已经分裂。此时如果没配 MAD，两台设备会各自按照自己的独立配置转发业务，同一个广播域里出现两台设备同时工作，结果就是二层环路和地址冲突。

5.2 一次误拔堆叠线缆的根因定位

我跟同事处理过一起典型事故。某次机房调整，值班同事本来只是理顺上联光纤，结果手一抖，把堆叠线缆从设备上拔下来了。由于当时这套堆叠没有配置 MAD，设备立刻分裂成两个独立系统，同一个管理 IP 在两台设备上都能登录，核心交换机上 ARP 表疯狂抖动，整个楼栋的网络直接“抽风”。

当时排查思路是这样的：先看物理链路，发现堆叠口 Down；再看display stack，只能看到本机，且角色变成了 Master；登录另一台设备，发现它也认为自己是 Master。到这里基本确认是堆叠线缆被误拔导致的“双主”。我们把线缆插回去后，事情还没完——两台设备不会自动恢复成一个统一的堆叠系统，需要手动重启其中一台，让它重新以备用成员身份加入。

这个案例给我最大的教训不是“拔线不对”，而是“没配 MAD 的堆叠，根本不是高可用”。从那以后，我的所有堆叠配置都强制加上 MAD。

5.3 恢复流程与 MAD 的作用

MAD 的核心逻辑是：堆叠分裂后，让其中一侧自动进入禁用状态，主动关闭业务口，从而避免双主。华为盒式设备常见的有直连检测和中间设备检测两种方式。直连检测需要在成员设备之间额外拉一条检测链路；中间设备检测则借助二层交换机转发检测报文。

配置 MAD 前，必须先配置堆叠域编号。直连检测的命令大致是：

system-view stack mad detect mode direct

使用中间设备检测的命令大致是：

system-view stack mad detect mode relay

MAD 生效后，如果堆叠因为线缆断开而分裂，其中一侧会检测到多主，随即关闭自己的业务口，只保留堆叠口和检测链路。这样就不会出现两边同时转发业务的情况。

恢复时，先把堆叠线缆重新插好，然后在处于备用状态的那台设备上手动恢复业务口，或者直接重启备用设备让它重新加入堆叠。注意：插回线缆不等于系统自动恢复，一定要再执行一遍display stack确认角色和成员状态已恢复正常。

5.4 配置错误导致的堆叠建立失败

还有一种常见问题，是配置错误导致堆叠根本建不起来。我见过最多的是堆叠 ID 冲突和域编号不一致。两台设备都保持默认堆叠 ID 0，系统无法区分；或者两台设备域编号不同，互相不认。

处理方式不复杂：把其中一台设备下线，登录后重新执行stack slot 0 renumber 1或renumber 2设置唯一 ID；再确认两台设备的域编号一致，保存后重启。如果设备已经加入过其他堆叠，建议先清空配置再去设置新的堆叠参数。

排查这类问题，建议按顺序检查：先看物理连接是否 Up，再看堆叠 ID 是否唯一，接着看域编号和优先级，最后看软件版本是否一致。把这几项过一遍，大多数堆叠建立失败的问题都能找到根因。

6. 运维向：升级、备件更换与长期稳定心得

6.1 升级顺序：先备后主、回退准备

堆叠环境的版本升级，顺序非常重要。常规思路是先升级备用成员，观察备用成员正常加入堆叠后再升级主成员。这样做的好处是，即使升级备用成员时出现问题，主成员还能继续转发业务，不至于全网断联。

我在一次升级中吃过亏。当时图省事，把所有升级文件一次性传到设备 flash 里，结果文件名写错，设备重启后一直找不到启动文件，进不了系统。最后靠着 console 线进入引导菜单，手动指定正确的启动文件才算恢复。从那以后，我升级前必做三件事：备份当前配置、核对升级包文件名、准备好回退用的旧版本文件。

升级最好选择业务低谷窗口执行，不要在工作时间搞。即使准备工作再充分，也要预留至少半小时的应急时间。

6.2 备件更换的标准化动作

堆叠环境里换备件，最忌讳的是把新设备直接插上堆叠线就上电。新设备如果没有清空配置、堆叠 ID 和域编号不一致，很可能把整个堆叠系统搞乱。

我的标准流程是：新设备先单机登录，确认软件版本与现行堆叠一致；执行reset saved-configuration清空配置并重启；设置好堆叠 ID、优先级和域编号；然后关机，按预定方案连接堆叠线缆，最后上电观察display stack输出。整个过程不要急，每一步都验证后再继续。

如果维护的堆叠数量比较多，建议做一张台账，记录每套堆叠的成员信息：成员序号、堆叠 ID、优先级、MAC 地址、机房位置、堆叠口占用情况。时间久了你会发现，这张表比一堆零散的命令行记录管用得多。

6.3 我个人坚持的两条习惯

最后分享两条不算技术、但很影响稳定性的习惯。第一，堆叠线缆一定要用不同颜色标签区分，贴上“堆叠线，勿拔”的警示标识，并且把所有堆叠口在端口描述里写清楚。运维现场人多手杂，物理层面的标识是最有效的保护。

第二，每次动设备之前，先执行一次display stack和display device，确认成员状态正常。这个动作只需要几秒钟，但能让你在动手前就发现那些“看起来没事、其实已经异常”的隐患。

堆叠设备上线后，我很少再为单台交换机故障半夜爬起来。设备稳定不是靠运气，是每一次操作前多想一步换来的。希望这篇分享能让你在部署华为交换机堆叠时少走一段弯路。