很多刚接触华为数通设备的朋友第一次听到“集群CSS”都会愣一下这不是前端写样式表的东西吗在数通领域CSS是Cluster Switch System的缩写中文叫集群交换机系统。它是华为框式交换机上实现“多虚一”的关键技术把两台物理交换机通过集群链路绑在一起对外呈现为一台逻辑交换机。这几年我在做数据中心和园区核心网络时CSS出现的频率越来越高尤其是对可靠性要求高、链路带宽又需要横向扩展的场景。这篇东西把我实际部署和运维CSS的经验理一遍适合刚接手华为框式交换机、准备上集群或者已经在跑集群但心里没底的朋友。1. 为什么要把两台交换机“虚拟”成一台1.1 单台设备的瓶颈很多刚开始接触数据中心网络的朋友都会有一个疑问一台框式交换机的主控板可以做11备份业务板可以插满电源风扇也都是冗余的为什么还要搞CSS单台设备再怎么堆硬件终究有一个绕不开的坎控制面是单一的。主控板坏了倒是有备份但主备切换那段时间里设备要重新学习路由、重新收敛转发表业务多多少少会抖一下。而且很多框式设备在做软件升级、补丁加载的时候需要整机重启这个窗口对核心业务来说非常致命。另一个问题是端口规模和带宽扩展。单台设备的槽位是固定的业务板插满了就是满了端口密度不够就只能换更大的框子换设备的过程又是一次业务割接。如果换成两台设备做VRRP主备之间又只有主设备在转发备设备闲着带宽利用率上不去。CSS的思路就是把两台设备的资源合并成一台来调度控制面主备冗余转发面两张业务板同时工作端口数量接近翻倍升级的时候也有机会做整体维护窗口规划。1.2 集群要解决的两个核心问题从业务角度看CSS真正解决的就两件事第一是缩短故障切换时间第二是扩大转发带宽。先说切换时间。传统VRRP主备切换依赖心跳超时一般要几秒加上路由收敛业务中断时间可能到十几秒。CSS不一样主备主控板之间通过专门的集群链路同步状态主用主控故障后备用主控可以在亚秒级接管对下端设备来说网关MAC和接口状态几乎没有变化。再说带宽。CSS建立后两台交换机的业务板都在工作流量可以跨设备做负载分担。比如两台设备各插两块40GE业务板汇聚起来就是160GE的转发能力。更重要的是CSS支持跨设备Eth-Trunk一根聚合链路可以同时连接到两台物理交换机上下端设备不再需要分别对接两台设备做两套冗余组网变得干净很多。注意CSS不是简单的“两台设备拼在一起”它牵扯到主控板状态同步、业务板跨框转发、集群分裂检测等一系列机制。我见过不少朋友把它当成“增强版堆叠”来用结果出了问题无从下手所以下面对原理和部署细节多花点篇幅。2. CSS和iStack堆叠、VRRP的本质区别2.1 控制面、转发面、交换网板的关系华为数通设备里有两类多虚一技术盒式交换机叫iStack智能堆叠框式交换机叫CSS集群交换机系统。很多人容易混淆但两者底层差异很大。盒式设备的控制芯片和转发芯片在同一块板上堆叠之后通过堆叠口转发跨设备流量框式设备的主控板、业务板、交换网板是分离的CSS的跨框转发走的是集群链路由集群卡或者业务口承载。从控制面看CSS的两台设备只有一台主控板处于激活状态另一台热备。主备之间通过集群链路实时同步配置、路由表、ARP表等关键状态。从转发面看两台设备的业务板各自独立转发本板流量如果流量需要从一台设备的端口进、另一台设备的端口出就会经过集群链路走到交换网板再送到目的端口。这里有个容易忽略的点即使CSS建立成功也不是所有流量都走集群链路。本机内部的流量进和出在同一台物理设备上直接由本机交换网板转发只有跨设备的流量才需要经过集群链路。所以集群链路的带宽规划非常关键不能随便拿两根10GE线凑数。2.2 集群链路与集群IDCSS建立的基础参数CSS要正常工作有几项基础参数必须规划好成员设备编号、集群ID、集群链路。成员设备编号相当于给每台物理设备起名CSS建立后设备编号不能冲突。集群ID则是用来区分同一组集群和外界交互时用的标识两台设备必须配置相同的集群ID才能组成一个集群。集群链路的作用前面说过既传控制面同步报文又传跨框数据流量断了任何一条轻则集群分裂重则业务中断。我在实际配置中习惯先在图纸上把两台设备的设备编号、集群ID、集群链路端口全部标好再上设备操作。很多人一上来就敲命令结果设备编号配重了、集群链路交叉接错折腾半天。集群链路要特别强调连接方式必须交叉连接即A设备的集群口连B设备的集群口不能两台设备各接各的。2.3 为什么VRRP“双主”会害死人CSS最大的诱惑在于两台设备同时在转发但这也带来了一个传统方案没有的风险脑裂。VRRP方案里主备角色是竞选的备设备正常情况下不转发业务流量即使主备之间的心跳断了备设备也不会贸然抢占。CSS不一样两台设备都是活跃的如果集群链路断了两台设备之间的控制面同步失效它们可能同时认为自己是主设备这就叫“双主”。双主状态非常危险两台设备用相同的虚拟MAC和IP地址同时转发流量下端交换机的MAC表会在两台设备之间反复漂移整个二三层网络立刻变得不稳定比单纯的链路中断严重得多。所以CSS必须搭配双主检测机制DADDual Active Detect专门对付这种场景我后面会细讲。3. 部署前必须要做的组网判断3.1 什么场景适合上CSS什么场景不该上CSS不是万金油盲目上集群反而给自己挖坑。我一般这样判断适合上CSS的场景典型的有三类。一是数据中心Spine节点东西向流量大端口密度要求高跨设备链路聚合可以简化接入层组网。二是园区核心网关集中在这里需要快速切换和统一管理CSS可以把两台核心虚拟成一台下面的汇聚交换机只需要一组聚合链路对接。三是对升级窗口要求苛刻的场景整体规划好维护窗口后CSS可以配合流量迁移做平滑操作。不适合上CSS的场景也很明确。首先是两台设备物理距离太远的场景集群链路是有限制的跨机房、跨楼层拉长距离既不安全也不合规。其次是两台设备代际差异太大的场景比如一台老款框式、一台新款框式主控板性能、版本支持能力都不同硬凑在一起反而拖累整体性能。最后是管理域需要隔离的场景如果两台设备要给不同的业务部门使用那还是各管各的别用CSS强行绑在一起。3.2 组网连接方式与集群带宽规划CSS组网连接方式要遵循交叉原则。两台设备的集群链路建议至少两条独立路径比如两个集群卡分别承载或者业务口集群方式下把不同单板上的端口都纳进集群链路避免单板故障导致集群链路全断。连线方式一般是A设备的口1连B设备的口1A设备的口2连B设备的口2做成一个“十字”结构。集群带宽的规划有一个经验值集群链路的总带宽建议不要低于跨设备流量峰值的20%。为什么是20%而不是50%因为正常情况下大部分流量是本地进本地出真正需要跨框转发的流量比例没有想象中那么高但万一下端链路聚合的Hashing不均匀某个方向的流量集中到某一台设备集群链路就会成为瓶颈。留足余量宁多勿少。3.3 光模块与线缆选型这个环节最容易埋雷CSS组网里最不起眼但最容易出问题的就是光模块和线缆。我踩过最典型的一个坑集群链路的端口和业务端口的端口在同一个业务板上结果业务侧跑了一个大流量业务光模块温度飙高集群链路开始出现误码主备同步报文反复重传设备状态变得很不稳定。后来我总结了几条硬规矩集群链路最好使用专用的集群卡或者独立的集群口不要和业务口共用同一块板卡的同一组光模块资源光模块的收发光功率在部署前必须逐一测试尤其是旧模块和新模块混用时不同代际的光模块在链路协商上可能会有兼容性差异线缆标签必须两端都贴写清楚“A1-B1”、“A2-B2”否则后期维护时根本不知道哪根线对应哪条集群链路。注意集群链路的抖动比业务链路的抖动危害大得多。业务链路抖动最多丢几个包集群链路抖动会引发控制面同步异常甚至触发主备切换或集群分裂。所以光模块的选型和质量一定不能省。4. CSS部署配置实战从命名到双主检测4.1 配置前的硬件检查与版本确认动手配置前先做一轮硬件和版本检查这几步省不得。先看设备型号和单板类型确认设备支持CSS。一般来说华为框式交换机如S系列、CE系列的高端框式产品支持CSS盒式交换机走的是iStack堆叠两者配置方式不同。其次是主控板配置建议主控板11备份并且两台设备的主控板型号保持一致。然后是版本检查两台设备的软件版本、补丁版本必须完全一致包括特性License的加载情况不一致会导致集群建立失败或行为异常。下面是检查项汇总检查项检查内容备注设备型号确认框式产品支持CSS盒式设备走iStack主控板型号一致、11冗余跨设备也要一致业务板槽位规划、端口用途集群口与业务口分离软件版本版本号、补丁号完全一致不一致禁止合并集群链路光模块质量、收发光功率部署前逐端口测试4.2 修改设备编号与集群参数检查做完就可以上设备配置了。这里以我常用的框式设备命令习惯为例不同型号和版本在命令细节上会有些差异关键思路是一致的实际操作时以设备的display命令和操作手册为准。先把两台设备的设备编号规划好比如A设备为1B设备为2。进入系统视图后执行设备编号修改SwitchA system-view [SwitchA] set device id 1设备编号修改后通常需要保存配置并重启才能生效。这里要注意修改设备编号前先把设备上的业务配置导出备份避免重启后配置被重置。B设备同样处理设置成设备编号2。接下来配置集群ID。集群ID的作用是让两台设备识别彼此属于同一个集群必须一致。命令思路类似[SwitchA] set system css-id 10 [SwitchB] set system css-id 10集群ID的取值要结合现网规划来定如果同一个管理域里有多组CSS每组的集群ID要错开。4.3 配置集群链路与业务口加入集群链路配置是整个部署的核心。以业务口集群方式为例我一般会预留一组高速端口做集群口比如每个设备预留四个10GE端口。A设备上这样配置[SwitchA] interface css-port 1/1 [SwitchA-css-port-1/1] port interface 10GE1/0/1 to 10GE1/0/4 [SwitchA-css-port-1/1] quit [SwitchA] saveB设备的配置方式类似把1/1集群口的成员端口也指向自己对应的四个10GE口。这里有一件很重要的事集群口两端必须交叉连接也就是A设备的10GE1/0/1要连到B设备的10GE1/0/1A设备的10GE1/0/2连B设备的10GE1/0/2不能连错。配置完成后两台设备都保存配置并重启。重启完成后在任意一台设备上执行display css status能看到两台成员设备、各自的设备编号、主备角色、集群链路状态就说明CSS已经建立成功。如果一直显示“Cluster is not established”先别急按这个顺序排查两端设备编号是否冲突、集群ID是否一致、集群链路端口是否up、光模块是否正常。八成问题都出在这四个地方。4.4 配置双主检测DAD与业务验证CSS建立成功只是第一步防脑裂的双主检测DAD必须同步配置。以增强检测方式为例在两台设备上分别指定用于双主检测的接口[SwitchA] dual-active detect [SwitchA-dual-active-1] interface 10GE2/0/1 [SwitchA-dual-active-1] quitB设备同样配置一个检测接口。双主检测链路上的端口不要并进业务聚合口也不要配置常规业务VLAN它专门用来在集群链路断开时探活。两台设备通过DAD检测链路互相发送探测报文如果一台设备发现集群链路断了、但还能通过DAD链路探测到对端活着就知道自己不是“唯一的主”于是自动把自己这边的业务口置为DOWN避免双主转发。DAD配置完成后做一轮业务验证SwitchA display css status SwitchA display device SwitchA display dual-active detect确认主备状态、设备编号、检测链路状态都正常后再在业务侧测试跨设备Eth-Trunk、终端网关连通性、路由表是否能正常同步。我习惯把这轮验证结果整理成一份文档后续每次变更前后都对照检查。5. 分裂、主备倒换与线上故障排查5.1 集群分裂时发生的四件事集群分裂是最让人头大的故障没有之一。当集群链路完全中断时会发生四件事第一两台设备之间的控制面同步失效备用主控无法继续接收主用主控的状态报文。第二两台设备都会尝试重新竞选主设备如果双方都认为自己还活着并且信号正常就可能竞选出两个主设备形成双主。第三双主状态下两台设备用相同的MAC地址和IP网关同时转发流量下端设备的MAC表项会不断漂移二层环路、三层访问异常全部冒出来。第四原本跨集群的聚合链路因为分裂变成跨设备的普通链路流量路径变得不可控丢包和时延抖动一起出现。整个过程从集群链路断掉到业务异常往往只有几秒钟。如果现场没有告警运维人员通常还没反应过来业务侧就已经炸了。5.2 双主检测DAD为什么能兜底DAD就是为上面这个场景设计的兜底机制。它通过独立的探活链路确认“对端到底还活没活着”。集群链路断了之后如果DAD链路还能探测到对端设备说明两台设备都在运行只是集群链路出了问题那其中一台就会主动把自己的业务口全部shutdown也就是进入“禁用状态”把流量全部交给另一台设备处理。这个机制的巧妙之处在于它不依赖集群链路用独立的物理链路做判断依据。同理如果DAD链路也断了设备无法确认对端状态出于安全考虑也会主动关闭业务口宁可让业务中断也不能让双主状态下的流量冲突毁掉整个网络。恢复过程也简单把集群链路恢复了两台设备重新建立集群完成状态同步后自动从禁用状态恢复。这个过程不需要人工干预但前提是DAD检测链路本身要稳定可靠不能出现误报。所以我一般建议DAD链路用单独的端口和光模块别跟业务口挤在一起。5.3 一次典型的CSS故障排查链路复盘我按经验抽象一个常见场景出来模拟一下完整排查链路方便大家参考。某数据中心核心交换机突然弹出告警提示CSS分裂。值班同事第一反应是直接看业务发现部分服务器之间链路时通时断。我赶到现场后没有直接动业务配置而是按这条链路排查第一步登录任意一台设备执行display css status确认当前CSS状态、主备角色、集群链路是否down。第二步检查集群链路端口状态执行display interface brief查看集群口物理状态和协议状态。第三步检查光模块收发光功率发现其中一根集群光纤接收光功率异常偏低只有正常值的四分之一说明接线或者光纤本身有问题。第四步顺着光纤链路排查最后在ODF机柜里发现那根光纤由于标签脱落维护人员误以为是备用纤芯插到了其他设备的端口上。拔插过程中光纤端面也磕碰到了导致接收光功率下降。重新整理纤芯、清洁端面后集群链路恢复up两台设备自动完成状态同步CSS恢复正常业务侧时通时断的现象消失。这里面的经验是别一上来就怀疑设备硬件先把物理链路层、光模块收发光全都检查一遍再往上层看。集群链路故障里面物理光路问题占了一大半。6. 版本、升级与日常运维的“隐藏坑”6.1 版本配套关系最容易被忽视的“隐患”CSS对版本的要求非常苛刻两台设备的软件版本、补丁版本必须完全一致否则集群建立时会报版本不匹配错误甚至可能在运行过程中出现行为不一致。我见过一个案例两台设备都是同一个大版本但一台打了某个补丁另一台没打结果集群状态显示正常但某些协议报文的主备协商总是异常花了两天才定位到是补丁不一致导致的。所以日常运维里要建立一个习惯任何版本变更前先确认两台设备的版本、补丁、特性License都完全一致。变更时建议把两台设备的版本文件包、补丁文件包放到一个统一的版本目录里由专人核对校验值后再操作。6.2 升级流程与回退预案CSS有一个和其他高可用方案不太一样的特性它不支持两台设备逐台滚动升级。因为两台设备作为一个逻辑设备整体运行如果一台升级完成、另一台还是老版本集群链路恢复时会发生版本不匹配无法合并。所以CSS升级需要整体规划维护窗口两台设备一起离线升级。升级流程我一般这样安排先备份两台设备的配置和版本文件再导出日志然后在维护窗口内把流量切到备用路径或者提前通知业务方之后两台设备一起重启进入升级程序加载新版本升级完成后检查display css status、display device、display version再验证业务。回退预案同样重要。如果升级过程中发现新版本有问题要在窗口时间内把两台设备一起回退到旧版本。这里最忌讳的是只回退一台另外一台还停留在新版本两台设备无法建立集群业务反而更糟。回退命令同样要提前验证过不要在现场临场查文档。6.3 日常巡检该看哪些关键指标CSS部署完成只是开始日常巡检是保证它长期稳定运行的关键。我总结了一个巡检清单每次巡检基本按照这个表来过一遍巡检项检查目标异常处置CSS主备状态确认主备角色、成员设备在线主备反复切换需排查链路质量集群链路状态确认所有集群口updown口立即排查光路光模块收发光功率功率在正常范围波动不大异常时清洁端面或更换光纤主控板CPU/内存峰值不超过阈值异常时检查是否有异常协议报文集群链路误码率长期为0或极低误码持续增长要更换光模块日志中CSS关键字无“CSS split”“DAD”等告警有告警立即定位处理说实话CSS这个东西配置本身并不复杂真正考验人的是对机制的理解和运维习惯。我见过很多故障不是设备不行而是版本不一致、链路质量差、DAD没配好这些看起来很小的问题。把物理层、版本层、检测机制这三样管住了CSS还是非常好用的高可用方案。最后分享一个我个人的习惯每次做完变更我都会把display css status、display device、display dual-active detect的输出存成一份文件命名带上日期。这样下次变更后做对比一眼就能看出来主备角色、成员状态有没有变化。别小看这个习惯遇到问题查历史记录时它能帮你省下大把排障时间。