机房里的核心设备最怕的不是某一块业务板卡悄悄亮红灯而是两台核心交换机在关键时刻没人能顶上。传统主备方案里备机常年空转切换时间按秒算业务部门早就开始打电话了。我第一次接触华为的集群CSS就是在一次核心网改造项目里两台框式交换机用一组集群线缆把控制面拉起来重启之后变成一台逻辑设备对外只看到一个管理IP、一套配置转发面却是两台一起扛。这个思路解决的不只是“备机浪费”而是把主备切换从“秒级”压到了“毫秒级”。这篇文章不打算讲太多PPT层面的概念重点放在CSS到底是什么、为什么值得用、实施前怎么规划、配置命令怎么敲、双主检测怎么配以及我在实际项目里踩过的坑。想给核心网络做双机冗余又不想让备机闲着的人可以参考着看。后面所有命令基于华为较为普及的VRP平台具体型号和版本有差异我会在关键地方标注。1. 先搞清楚CSS到底是什么1.1 集群系统的本质CSS全称Cluster Switch System是华为在企业网核心和数据中心场景里主推的交换机虚拟化技术。通俗讲就是把两台物理交换机通过专门的集群链路连接起来在逻辑上合并成一台交换机使用。网络里的其他设备不会感知到背后有两台设备它们看到的只是一台交换机、一个管理地址、一套配置。用生活里的例子类比两个独立的售票窗口一个在左边一个在右边排队的人要猜哪个窗口人少。CSS的做法是把两个窗口打通改成一个大厅、一个入口里面两个售票员一个主一个备外面的人永远只面对一个入口。主售票员出问题备售票员无缝顶上排队的人甚至没感觉到停顿。但要注意CSS不是简单的“设备主备”。传统主备方案中两台设备各自独立运行、互相同步配置切换时存在状态不一致的风险而CSS在控制平面上就是一台设备只是硬件上分布在两个机框里。1.2 它真正解决了什么问题老牌的主备方案存在三个让运维很头疼的问题主备切换时间长健康检测、状态迁移、路由收敛一套流程走完几秒钟过去了对敏感业务来说已经算故障。备机利用率低备机整年不转发业务流量投资回报率很低。管理成本高两台设备两套配置升级、审计、变更都要双倍工作量。CSS把这几点都改掉了。控制平面一主一备主设备挂掉时备设备直接接管切换时间大幅缩短转发平面两台设备一起工作带宽资源不被浪费管理上只有一套配置登录任何一个成员都能管理整个集群系统配置统一下发自动同步到对端。另一个很实用的价值是跨设备Eth-Trunk。下联交换机可以用一个Eth-Trunk同时连接两台集群成员把两根物理链路聚合成一根逻辑链路。这样既增加了带宽又实现了链路冗余不再需要跑STP去阻塞端口网络拓扑变得干净许多。1.3 哪些场景不适合用CSSCSS不是万能药我的态度一直是一开始就别神化它。如果你的核心交换机单框容量已经足够可靠性压力也不大强上CSS反而引入新的风险点。比如集群链路本身就是一个故障点。两台设备之间的控制面同步依赖集群链路虽然有双主检测兜底但多一个环节就多一套运维工作。再比如真正的物理隔离要求高的场景比如等保三级里某些业务要求主备物理独立CSS把两台设备变成一个逻辑设备审计上可能说不清楚。所以我的建议是流量规模大、业务连续性要求高、希望简化运维的场景CSS非常合适单台设备性能富余、维护力量薄弱的小型网络用传统主备或者干脆单机更实在。2. CSS的系统架构与关键原理2.1 控制平面的一主一备机制集群建立后两台成员会通过协商选举出一个主交换机和一个备交换机。主交换机的控制平面处理所有协议报文包括STP、OSPF、BGP、LACP等等并把协议运行的结果通过集群链路同步到备机。备机的控制平面在线但处于待命状态不参与协议计算却始终保持着和主设备一致的协议状态。这里有个容易混淆的点CSS不是传统意义上的两台设备各自跑协议再互相同步而是一个逻辑设备内部有两个“半脑”一个在工作一个在热备份。所以从外部看协议邻居会话只有一个MAC地址表只有一份ARP表只有一份。这种架构带来的好处是切换时外部网络几乎感知不到协议变化因为协议邻居关系本来就不存在断裂。出故障的时候备机的控制平面接管协议计算转发平面本来就在工作所以业务中断窗口很小。这也是为什么很多核心网络改造愿意上CSS它不只是冗余而是一种更高级的一体化设计。2.2 转发平面的跨框协同数据转发这块CSS采用分布式架构。流量从成员1进来如果目的端口恰好落在成员2上那么报文会通过集群链路传给成员2再由成员2完成转发。集群链路因此承担两类流量控制面的同步报文以及跨成员的转发流量。所以集群链路的带宽规划不能拍脑袋。如果你的网络东西向流量大比如服务器之间的备份、虚拟机迁移这流量跑到对端成员的概率非常高。集群链路带宽不足时跨框转发就会出现拥塞和丢包业务口看起来全正常但流量一大就掉链子。我习惯在方案设计阶段就把东西向流量测算进集群链路的带宽需求里而不是把集群链路单纯当成一根“同步线”。框式交换机如果支持多条集群链路尽量用满既提升带宽又增加冗余。2.3 集群链路的设计与布线集群链路可以是专用的集群线缆也可以是普通光纤端口配置成的逻辑集群端口。不同产品系列差异很大框式交换机往往有专门的集群口盒式交换机则常常占用业务口来复用。布线形态有两种常见方式环形连接成员1的两个集群口分别连接成员2的两个集群口形成一个环。任何一条链路断了另一条还能兜住控制面同步可靠性高。链形连接成员1的一个集群口连接成员2的一个集群口单条链路简单但存在单点风险。华为的官方建议基本都推荐环形。我实际操作时还有个习惯两条集群链路走不同的物理路径最好分布在不同板卡上。避免出现机柜同一侧的光纤被一起拉断或者同一块板卡故障导致两条链路同时失效的尴尬。2.4 双主检测机制防止脑裂的最后一道防线这是CSS里我最看重的设计。假设集群链路彻底断开两台设备之间控制面失去联系此时如果它们各自都还认为自己是主设备就会同时处理业务。于是同一个IP地址出现两台交换机都在响应MAC地址漂移、环路、ARP冲突会全部涌上来。这就是俗称的“脑裂”。华为的应对机制是双主检测英文缩写DAD。集群建立后两台成员之间除了集群链路还会额外建立一条检测链路。当集群链路断开时检测链路仍然能把两台设备连在一起让双方发现彼此都还活着于是其中一台自动进入禁用状态整机业务接口全部关闭避免对网络造成二次冲击。检测链路有两种形态直连方式拿一个专用的业务口或管理口把两台设备直接连起来简单可靠。中继方式通过中间交换机转发检测报文适合两台设备物理距离较远、无法直接拉线的场景。直连方式配置少、故障点少但占用一个接口中继方式灵活但依赖中间链路的健康状态需要额外规划和监控。这个机制不能省生产环境里我从来不开玩笑说“集群链路够稳不用配DAD”一旦缆线松动或者光模块劣化没DAD就是全网事故。3. 实施前需要完成的准备3.1 硬件形态与集群口规划以华为中高端框式交换机为例CSS有两种实现路径一种是专用的集群主控板配合专用集群线缆另一种是在业务板上用高速接口做逻辑集群口。选型阶段要翻设备手册确认自己的主控板、业务板是否支持集群以及最多支持几条集群链路。我的经验是预算允许的情况下优先选带专门集群口的框式交换机。专用集群口不占业务接口线缆是定制的信号质量有保障。盒式交换机也能做CSS但会吃掉两到四个业务口在接口本来就紧张的网络里这个代价有点肉痛。3.2 业务口与集群口的冲突处理这是实施前最容易被忽略的一步。同一个物理端口不是你想让它做业务口就做业务口、想做集群口就做集群口。把业务口改成集群口原端口上的业务配置会全部失效。而且不同版本的软件对端口类型的切换要求还不一样有的直接报错有的静默覆盖。所以规划要分两步走第一步确定哪些端口作为集群口优先选在设备两侧、不同板卡上的端口保证冗余第二步把这些端口原本的业务配置提前梳理出来并清理干净。不要等配置做到一半系统提示“端口已被业务占用无法创建集群口”那时候再回头处理就很被动。3.3 版本、License与兼容性核对两台设备做集群有一个硬性前提软件版本一致。如果两台设备的版本不同集群协商很可能失败或者即使协商成功某些特性表现也不正常。我见过某次维护一台设备在V200R003、另一台在V200R005组集群后配置能同步但新版本的特性在老设备上直接不生效排查了整整半天才定位到版本差异。建议实施之前把两台设备都升级到同一基线版本再开始组集群。License方面也要提前确认特别是双主检测的中继方式、M-LAG这类高级特性部分功能需要额外授权。现场发现功能被锁是很尴尬的。3.4 规划设计表我每次做CSS项目都会先拉一张规划表把关键参数写清楚后面实施时照着执行就行。项目成员1成员2说明成员ID12决定逻辑槽位号业务上线前定死集群优先级高低高者当选主设备集群链路端口所在板卡/端口号所在板卡/端口号两侧要对称集群链路数量22环形连接双主检测方式直连直连占用专用端口双主检测端口端口号端口号可以复用管理口业务上联口规划好规划好集群化后编号会变化这张表填完网络的逻辑结构已经清楚了后面只是把规划翻译成命令行。4. 一步步完成CSS配置4.1 物理连线先接线路再配软件接线之前确认设备已经断电或者端口没有承载业务。专用集群线缆一头接成员1的集群口另一头接成员2的集群口。如果做环形连接就再用一根线把两边第二组集群口也连起来。连接时注意线缆型号和端口区块的对应关系别插错。我习惯在两端贴上标签边接边记录在规划表上。集群链路不像业务口那样有明确的指示灯可以一眼看出是否正常线缆接错了往往要等配置完成、重启之后才能发现那时候排查起来很费劲。4.2 配置成员ID与优先级设备处于单机状态下登录设备A设置成员ID为1优先级调高。设备B设置成员ID为2优先级调低。以华为较新版本的VRP为例system-view set css id 1 set css priority 200另一台设备执行system-view set css id 2 set css priority 100成员ID的作用非常关键它决定集群建立后这台设备在逻辑架构中的“槽位号”。比如成员1的10GE接口集群化后会显示为10GE1/0/1成员2的接口就会显示为10GE2/0/1。如果ID规划不当调整之后所有端口编号都会变化涉及这些端口的配置、策略、网管监控全要跟着改一遍。优先级的作用是选举主设备。数值越高越有可能在集群协商时成为主交换机。原则上应该把硬件性能更稳、后续方便维护的那台设成高优先级。4.3 配置集群链路框式交换机上需要把物理端口配置为集群端口。命令大致如下system-view interface css-port 1/0/1 port link-type css quit interface css-port 1/0/2 port link-type css quit成员2上执行同样的配置注意端口编号里要使用自己的成员ID。盒式交换机的命令形态可能会不同比如部分型号使用下面的形式system-view interface stack-port 1/1 port link-type css quit不同产品系列的命令差异比较大以设备配套的手册为准。配置完成后立即保存配置接下来要重启设备如果配置没有保存后面的操作等于白做。4.4 切换到集群模式并重启集群链路配置好后还需要把设备运行模式从“单机模式”切换为“集群模式”system-view set css mode css系统会提示该操作需要重启设备生效。保存配置后分别重启两台成员。重启顺序没有硬性要求但我习惯让优先级高的主设备先启动。设备起来之后集群链路会进行协商两台设备开始交换CSS报文选举主备角色。重启完成后需要通过命令确认集群是否建立成功display css status display css configuration display device输出信息里能看到成员ID、角色、集群链路状态。如果看到一台设备角色是Master、另一台是Standby集群链路状态是UP就说明集群已经成功建立。4.5 集群状态验证与端口编号确认集群建立后再看看业务端口这时端口编号已经带上了成员ID前缀。比如原来是10GE1/0/1集群化之后可能变成10GE1/0/1但成员2上的端口就变成10GE2/0/1。所有涉及成员2端口配置的命令都要用新的编号。这个阶段我会做几个快速测试登录集群的管理IP确认能正常访问从上联口ping下联设备确认转发正常查看MAC地址表确认是集群统一维护的一份表。确认没问题之后集群的搭建就算完成了。5. 双主检测的配置与验证5.1 直连方式DAD配置如果两台设备物理位置靠在一起直连方式是最简单的。直接拿一根网线把两台设备的管理口连起来然后分别在两台设备上配置system-view dual-active detection direct这里有个容易忽略的点管理口被占用之后设备的管理通道就没了需要通过业务口或者带外网络去管理。所以配置之前先想好后续管理走哪条路别把设备管到“失联”。5.2 中继方式DAD配置如果两台设备距离远或者不想占用额外接口可以选择中继方式。中继方式的原理是让检测报文穿过中间的交换机网络两台集群成员之间通过一个逻辑链路Eth-Trunk来传送检测报文。配置如下system-view interface eth-trunk 10 trunkport interface 10ge 1/0/24 quit成员2也要创建编号相同的Eth-Trunk并把对应的业务口加入。然后开启中继检测system-view dual-active detection eth-trunk 10中继链路必须保证有独立的物理路径不要让检测链路和集群链路走在同一根光缆或同一个中间设备上。如果集群链路和检测链路同时断掉双主检测就失去了意义。5.3 模拟故障验证配置完DAD不能光看状态一定要在变更窗口做一次演练。演练方法很简单在保证业务低峰期且做好回退预案的前提下拔掉集群链路中的一根线。观察的现象有两个第一两台设备是否都检测到了集群链路故障第二双主检测是否把备用设备自动置为禁用状态。正常情况下备机会将所有业务口关闭整个系统仍然保持单主运行。之后把线接回去观察两台设备是否自动恢复集群关系。我在实际操作中测试过多次这套机制的恢复速度相当不错前提是检测链路本身健康。如果检测链路经常丢包建议多做一条冗余检测路径一条挂掉另一条顶上。6. 实施与维护中容易踩的坑6.1 集群模式切换命令找不到有些型号在普通系统视图下根本没有set css mode css这条命令需要进入专门的集群配置视图。不同产品系列的命令路径不一样敲不出来的时候别怀疑设备坏了先确认设备型号和软件版本再翻对应的集群配置手册。这个坑我踩过一次。一台盒式设备在系统视图下敲set css mode css直接提示未知命令当时一度以为版本不支持集群。后来才发现这个系列的设备切换到集群模式是通过专门的命令进入集群视图来完成的。多花了大半天查手册做项目时时间是很贵的。6.2 集群化之后端口编号全变了前面反复强调过成员ID的规划这里讲一个真实教训。某次项目里实施人员没有提前规划好ID两台设备默认都是1集群协商直接失败。临时把其中一台改成2之后原来写好的下联配置全部失效VLAN放行、ACL策略、端口描述全要跟着改。处理办法是在正式割接之前把端口映射表完整做出来把旧的端口号和集群化之后的新端口号一一对应。割接完成后拿着映射表逐条核对配置不能靠脑子去记。6.3 集群链路带宽不足导致转发丢包有一个典型症状业务口全部正常没有告警但流量一大网络延迟明显升高甚至出现丢包。排查时注意看集群链路的光口计数如果发现丢包和CRC错误持续增长大概率是集群链路带宽被跨框流量打满了。解决方案有几个增加集群链路数量把带宽提上去或者调整业务部署把流量尽量控制在成员本地减少跨框概率。如果是虚拟化环境下的大流量迁移场景集群链路规划一定要做得更充足。6.4 集群模式下的软甲升级顺序集群模式下升级版本不能两台设备同时重启否则集群链路断开业务彻底中断。我的标准流程是先把备机的业务流量切走或者使用命令行将备机置为隔离状态。升级备机的软件版本并重启。备机起来之后执行主备倒换让升级后的设备接管主角色。升级原主设备的软件版本并重启。两台设备版本一致之后集群重新协商业务恢复正常。如果设备支持ISSU在线升级这个流程会简化很多但ISSU也不是所有特性都支持操作之前同样要仔细看文档。升级时间选在维护窗口提前备份配置文件这是最基本的习惯。6.5 双主检测误报导致业务被切断双主检测误报是很少见但后果很严重的故障。检测链路物理端口是UP但中间交换机的VLAN配置错误导致检测报文被丢弃。此时集群链路正常业务也都正常但设备之间已经失去了DAD通信。一旦集群链路出现短暂抖动两台设备就可能同时认为自己是主然后备机自动关闭业务口造成大面积业务中断。所以在日常巡检里不能只看检测端口状态还要检查检测报文的收发计数。定期执行一下display dual-active detect state确认两边都在正常收发这样才能保证这道防线随时可用。7. 生产环境中的运维实践7.1 与M-LAG配合使用CSS之上最常叠加的就是M-LAG也就是跨设备链路聚合。两台集群成员各出一条物理链路组合成一个跨设备的Eth-Trunk和下联交换机对接。下联交换机看到的只是一个普通Eth-Trunk不知道背后连的是两台设备。这个组合的优势在于带宽翻倍、链路冗余、无STP阻塞。配置时注意两台成员上要使用相同的Eth-Trunk编号和成员端口接口参数也要保持一致否则跨设备的聚合会话可能协商失败。我习惯在配置完成后在下联交换机上检查Eth-Trunk的成员端口状态确认两边的LACP协商都正常。7.2 日常巡检建议组了集群之后巡检重点会比单机多一些。我自己的巡检清单大致是这几个命令display css status display device display dual-active detect state display eth-trunk 10 display alarm all每季度至少做一次全量巡检额外看一下集群链路光模块的收发光功率。光模块劣化是集群断链的隐形杀手等它真正断了再处理业务已经被影响了。光功率低于告警阈值时及时更换光模块成本不高收益很大。7.3 变更操作的原则做网络时间久了越来越觉得最重要的不是多聪明而是多守规矩。我给自己定了几个死规矩任何变更前先保存配置操作完无论成败都保留现场截图涉及集群链路的操作一定安排在维护窗口内拔插线缆必须戴防静电手环所有命令先在测试环境敲一遍再到生产环境执行。有一次一个小操作只是给集群链路加一条线结果因为没先在测试环境验证端口类型切换的细节配置报错后又反复调整硬是把一个半小时的窗口用完了。从那以后再简单的变更我也不敢跳过提前验证的环节。CSS这个技术从第一次接触到现在我一直觉得它是一个思路非常清晰的设计。它把两台物理设备的复杂性封装成一个逻辑设备让网络管理员从繁琐的备机维护里解放出来。但它毕竟也是由物理线路、光模块、软件版本这些环节构成的系统哪个环节都可能出问题。真正懂得用CSS的人不是只会把它配起来而是知道它的边界在哪里、风险在哪里、怎么去验证它是否健康。网络这行当让业务睡得着觉比什么都重要。