很多工程师第一次接触华为框式交换机集群都是从S7706开始的。原因很简单S7706是不少数据中心汇聚和园区核心机房里经常见到的一台设备而CSS集群配置又是把两台设备变成一台逻辑设备最典型的做法。前段时间我帮客户做了一次S7706的CSS改造走的就是集群卡路线整体过程里既有顺利的地方也踩了不少坑。这篇文章不打算堆概念就从硬件规划、参数设计、命令行操作、事后验证到常见故障恢复把整套流程完整捋一遍。如果你手头正好有两台S7706要在线成堆或者还在纠结用集群卡还是业务口堆叠这篇可以直接拿来当参考。1. 为什么建议优先考虑集群卡CSS方案的取舍逻辑1.1 从两台设备到一台逻辑设备核心收益在哪CSS全称是Cluster Switch System翻译过来叫集群交换系统。S7706做CSS之后两台物理设备在逻辑上就成为了一台设备管理面只有一个IP配置同步由系统自动完成转发面共享一套规则。这不是传统意义上的备机热备而是两台设备真正作为一个整体在工作——主用主控负责控制面备用主控实时同步表项成员设备之间的业务流量可以通过集群链路直接转发。这个机制带来的收益很直观。第一是拓扑简化原来两台独立设备需要跑STP来阻塞冗余链路做了CSS之后可以直接把成员端口聚合到一个Eth-Trunk里跨设备链路不再有环路问题。第二是切换更快传统的主备网关方式依赖协议协商CSS里备用主控本来就掌握了所有转发表项主用主控异常后备用主控能直接接管业务中断时间会缩短很多。第三是运维成本下降不用再维护两套配置、两套网管IP临时改配置也只要在主设备上改一次命令会自动同步过去。1.2 集群卡和业务口堆叠怎么选别拍脑袋决定S7706做CSS业界常见就是两条路一条是通过集群卡另一条是用业务口做堆叠链路。很多人在选型阶段纠结得比较多我直接给个对比表看起来更清楚。对比项集群卡方案业务口堆叠方案占用资源占主控板预留的集群卡槽位不占业务口占用10GE/40GE等高速业务口链路能力专用集群通道带宽高可多链路互联带宽受限于端口速率可多口聚合扩展排障复杂度链路独立问题和业务流量互不干扰需要确认业务流量是否占满堆叠带宽成本投入需要采购集群卡、配套线缆和光模块不需要额外硬件现有业务口即可推荐场景核心、汇聚层的高可靠性组网接入层或成本敏感的小规模场景我个人的倾向是S7706这类框式交换机既然出现在核心、汇聚的位置业务端口本身就紧张再加上这类设备承载的往往是关键业务优先选集群卡是更稳的做法。业务口堆叠也不是不能用但你要额外管理好堆叠链路的带宽水位——万一业务流量已经接近端口速率上限堆叠链路本身成了瓶颈后面再排查起来会很痛苦。1.3 哪些场景不建议硬上CSSCSS不是万能的有些现场条件其实不适合做。最常见的判断标准就是两条物理距离和业务窗口。如果两台S7706不在同一个机柜甚至跨楼层、跨机房我建议慎重。CSS的集群链路距离有限正常情况下都是机框相邻、走线短距离互联。两台设备隔得太远集群链路一旦不稳定分裂的风险会明显上升。另一个关键条件是业务窗口。首次做成CSS两台设备都处于单机运行模式必须通过重启才能进入集群模式这意味着你至少要有一个允许设备重启的维护窗口。如果客户那边业务7x24小时不允许中断也没有备机可以临时顶替那就不该在这个阶段强行做CSS不如先把结构和硬件准备做完等窗口再操作。2. 开工前的硬件盘点与参数规划2.1 需要备齐的材料清单缺一不可CSS配置别看命令行就那么几条真正的功夫在进场前。我这几次做下来发现最容易出问题的环节是硬件准备不齐。先列一份清单两台S7706机框和各自的主控板检查主控板型号是否一致并确认有预留的集群卡槽位集群卡及配套线缆、光模块型号要和主控板、集群卡接口匹配一条Console线最好是USB转串口线带笔记本现场调试用管理网线用于后续DAD双主检测和网管接入还有用于跨设备链路聚合的业务跳线数量要根据实际需要接入Eth-Trunk的端口来定。集群卡插入的位置要注意看面板丝印每台S7706主控板预留的卡槽位置可能不完全一样别想当然插错。插卡操作前建议先做好防静电措施手头没有防静电手环的话至少先用手触碰一下机柜金属部分放电这是我一贯的习惯。2.2 集群ID、优先级、域参数先写进规划表再动手很多人拿到设备就直接登录敲命令配置得差不多才发现两台设备ID重复、优先级没拉开只能推倒重来。我的习惯是进场前先做一张参数规划表把每台设备的信息定死。设备角色定位CSS ID优先级CSS域管理IP设备A主用设备11501规划值设备B备用设备21201规划值CSS ID相当于设备在集群里的身份标识集群内唯一建议固定用1和2不轻易改。优先级用来决定主用主控落在哪台设备上数值越大优先级越高主设备设150、备设备设120是比较常见的做法留出一定差值可以避免协商时边界情况。CSS域参数用于区分不同组的集群系统如果机房里有不止一组CSS域规划更要提前想清楚防止错连。这里的排序逻辑很关键主用主控上的配置是标准配置备机通过集群链路同步。将来你改配置也好、升级也好都以主用主控为准。所以主用设备选哪一台应该优先考虑硬件状态更好、业务接入更关键的那一台而不是随便指定。2.3 物理接线的三条纪律一是标签一定要做。集群链路、管理口、跨设备聚合业务线根根贴标签写上CSS-A-1、CSS-B-2这种格式后期运维省大量时间。二是集群链路如果可以支持双链路互联两条链路尽量分走不同线槽不要捆在同一束里避免一次物理损坏把两条链路同时打掉。三是两台设备的电源尽量取自不同回路避免出现一个空开跳闸把整组集群全拉黑的情况。这里额外提醒一句DAD双主检测用的管理口链路不要放在最后补。很多人觉得DAD是可选功能其实在集群链路中断场景下DAD是避免双主冲突的关键保护。管理口的物理链路建议在接线阶段就完成不要等到设备上线后才想起。3. 命令行配置全程从单机模式到CSS统一视图3.1 第一步不是敲命令而是单机自检正式配置之前先通过Console线登录每一台设备做一遍状态确认。不要为了省事直接复用现网网管IP来操作因为CSS建立后管理面会重构当前会话很可能在配置过程中断掉到时候上不去设备反而麻烦。登录后逐项检查display version对比两台设备的软件版本和补丁信息必须一致否则成堆后很容易出现备机反复重启。display device确认主控板、集群卡、业务板在位且状态正常。display css status确认当前两台设备都处于单机运行模式而不是已经意外使能了CSS。版本不一致这个问题务必在单机模式下先解决别着急配CSS。我在项目中见过不止一次两台设备版本差了一个小版本直接配CSS后怎么都不成功最后还是要退回单机模式升级来回折腾了一整晚。3.2 两台设备分别写入CSS参数自检没问题后开始配置第一台设备。规划表里设备A是主用设备按照下面的顺序操作HUAWEI system-view [HUAWEI] set css id 1 [HUAWEI] set css priority 150 [HUAWEI] css domain 1 [HUAWEI] css enable Warning: This operation will change the system mode to CSS mode. Continue? [Y/N]: y [HUAWEI] quit HUAWEI save设备B按照备用角色配置注意ID和优先级不同HUAWEI system-view [HUAWEI] set css id 2 [HUAWEI] set css priority 120 [HUAWEI] css domain 1 [HUAWEI] css enable Warning: This operation will change the system mode to CSS mode. Continue? [Y/N]: y [HUAWEI] quit HUAWEI save需要留意的是css domain这个命令在部分版本中可能存在差异执行前可以在系统视图下先敲css ?查看当前版本的命令提示以实际支持为准。整体配置顺序就是先定身份再定优先级最后使能CSS。css enable一旦执行系统会提示运行模式即将切换这时还没有真正成堆只是把标志写入了配置。保存配置这一步一定不要省。有些人习惯配完直接重启结果配置没保存设备重启后又回到单机状态所有参数全部丢失只能重来一遍。3.3 保存重启后的成堆判读与配置同步第一次成堆必须重启而且两台设备尽量在同一个维护窗口内完成重启。如果条件限制只能逐台重启建议先重启优先级较低的备用设备让它进入等待集群成员的状态再尽快重启主用设备。注意不要在主设备已经重启之后备机还在单机模式下运行很久那样业务其实还处于未受保护状态窗口会被无谓拉长。重启完成后用Console或管理IP登录设备执行display css status检查集群状态。输出中重点看三个点CSS功能是否Enable、成员设备列表是否包含1和2、Master Device显示的是不是规划中的主设备。如果全部符合说明这两台S7706已经成功组成了一个逻辑设备。成堆成功后配置同步机制就开始工作了。此时所有配置修改都必须在主用主控上操作系统会自动同步到备用主控。千万不要在备机上做配置因为备机的配置文件随时可能被主设备覆盖改动不但不生效还会在下次同步时被还原纯属浪费时间。4. 验证不能只看display css status4.1 基础状态检查清单成堆成功只是第一步不代表业务链路已经没问题。我习惯做一轮完整的基础状态检查把下面这几条命令过一遍确认每个环节都处于健康状态。检查项建议命令判断标准CSS总状态display css statusCSS Enable为Yes成员包含1和2设备成员状态display device主控、集群卡、业务板均为Normal集群链路通道display css channel或对应链路检查链路Up无错包、丢包跨设备聚合链路display eth-trunk成员端口全部Up且均在聚合组内日志告警display logbuffer无CSS反复切换、链路闪断、DAD告警4.2 跨设备链路聚合的实测方法CSS最核心的业务价值是跨设备链路聚合。配置时把Eth-Trunk的成员口分别放在两台成员设备上比如interface Eth-Trunk1 trunkport XGE1/0/1 trunkport XGE2/0/1 port link-type trunk port trunk allow-pass vlan 10 20注意这里XGE1/0/1和XGE2/0/1只是示意写法设备成堆后接口编号会按CSS成员ID重新编排真实端口名要以设备实际显示为准。配置完成后最有效的验证方式就是断开其中一条成员链路观察业务流量是否不中断或仅在聚合收敛时间内短暂抖动。再进一步可以在维护窗口内把其中一台成员设备下电确认业务能通过另一台设备继续转发。这类测试做过一次你对CSS的业务保障能力才算真正有底。4.3 主备倒换与日常巡检的关注点主备倒换测试要选在业务低峰期做。方法比较直接在主用主控上执行主备倒换或直接重启主用主控观察备用主控是否在预期时间内完成接管。切换过程中已有转发表项都在备用主控上同步过正常情况下业务中断时间会维持在很低的水平。日常巡检不要只盯着CSS状态看还要关注集群链路的接收光功率、误码计数主备主控的CPU和内存占用以及配置文件是否持续同步正常。日志定期刷一遍重点搜索CSS、DAD、Reconfiguration这类关键字很多隐患在日志里出现时现场业务往往还没表现出明显异常这时候处理成本最低。5. 常见故障场景与恢复操作实录5.1 两台设备CSS ID配成了同号这个场景我遇到过的频率比想象中高尤其是两台设备都保持出厂默认值、配置前没做规划表的项目。典型特征是配置完成后两台设备始终无法正常组成集群其中一台提示成员冲突另一台则一直在等待状态。排查思路很简单分别用Console线登录两台设备执行display current-configuration | include css确认两台设备的CSS ID是否相同。如果相同把其中一台改成不同的ID保存后重启。问题修复本身不难真正难的是现场人员容易陷入反复重启、反复看状态的循环而不愿意回到配置本身去检查最基础的参数。提前规划好参数表这类问题基本不会发生。5.2 版本不一致导致备机反复重启还有一类常见故障是备机加入集群后反复重启日志里出现版本协商失败的记录。这种往往发生在两台设备软件版本不一致的场景。你可能觉得差一个小版本无所谓但在CSS协商机制里版本差异可能导致控制面协议报文互相不认可表现就是备机反复重启。处理方法是回到单机模式按照官方升级流程把两台设备的版本和补丁升到完全一致再重新配置CSS。升级时建议先在备用设备上升级验证确认版本文件稳定之后再处理主用设备。升级过程中要保留原有版本文件至少保留一份可用配置万一新版本启动失败还能快速回退。5.3 集群链路中断引发的双主风险集群链路如果因为光模块故障、线缆松动或者集群卡接触不良而中断两台设备之间无法感知对方状态就可能各自认为自己是唯一的主设备这就是所谓的双主场景。双主一旦出现两台设备可能同时承担网关角色、同时转发流量造成MAC漂移、环路甚至业务瘫痪。如果当时已经配置了DAD双主检测非接管一侧的设备会主动关闭业务口把网络角色让出来问题影响面会小很多。如果没配DAD就需要人工介入。处理步骤我按顺序整理一遍先用Console登录两台设备执行display css status确认当前主用主控到底在哪一台不要盲目操作。检查物理层集群线缆是否松动、光模块是否发光、集群卡是否紧固用日志信息辅助判断。如果已经双主先把非接管一侧的业务口手动shutdown断开争议链路保住现网业务稳定。恢复物理链路观察两台设备重新完成CSS协商合并再逐条恢复之前手动关闭的业务口并确认Eth-Trunk成员口状态。DAD配置这件事我一直坚持一个原则在建集群的时候就配不要等出了问题再补。DAD的检测链路可以用管理口、专用检测口具体命令不同版本有差异配置前查阅对应版本手册就行但物理链路一定提前布好。5.4 升级维护时最容易忽略的节奏做CSS之后设备升级不再是单机操作那么简单。每次升级前先在主设备上备份当前配置和系统软件包同时记录当前版本信息确保有回退路径。升级顺序一般建议先备用再主用或者严格按照官方文档的节奏执行千万不要自行改顺序。还有一点容易被忽略在集群环境下每一次配置变更都会被实时同步到另一台设备。也就是说你在主设备上敲的每一条命令影响的不是单台设备而是整个集群。所以临时调试性质的命令尽量少在主设备上直接敲改动前先在文本里写好、评审再一次性贴入这样可以有效降低误操作风险。最后说点个人体会。我做过好几组S7706的CSS集群最深的感受是成堆本身不难难的是你的规划是不是覆盖了异常场景。ID重复、版本不一致、链路中断这些我都遇到过而且现场一旦开始乱试命令恢复时间就会被拉长一倍。所以如果你正准备做这组集群先花半小时写一张参数表设备、ID、优先级、管理IP、DAD链路然后按顺序执行再把上面提到的验证清单过一遍基本不会出大问题。对了还有一个容易被忽略的小细节成堆过程中Console线一定要留在手边线的一头最好能直接插到笔记本上随时待命别等到设备起不来才到处翻线。