1. 集群CSS到底是什么一台交换机干不了的活两台一起干做数通维护这么多年只要涉及到核心交换机或者数据中心网关的部署几乎绕不开华为的CSS集群。不少刚接触的朋友一听集群两个字就以为是什么复杂的分布式框架其实它做的事情非常朴素把两台物理交换机通过专门的接口和线缆连起来让它们从控制平面到转发平面都像一台交换机一样工作。我当年第一次在现网碰CSS是某公司机房要上两台框式交换机做核心业务又要跑VRRP虚拟路由冗余协议做网关冗余。领导觉得VRRP两台设备总有一台在闲置带宽利用率太低就让我研究一下能不能把两台设备当成一台用。这就是CSS最典型的场景两台物理设备虚拟成一台逻辑设备网络里其他设备只看到一个邻居、一条链路而转发面却拥有两台设备的全部端口和带宽。CSS的全称是Cluster Switch System翻译成中文叫集群交换系统是华为在园区网和数据中心网络里的核心竞争力之一。它与传统的堆叠技术相比不只是把两台设备用堆叠线缆绑在一起那么简单。CSS要求参与集群的成员设备必须同型号、同版本通过专用的集群接口连接后设备会选举出主设备和备设备。整个系统对外呈现为一个管理IP、一个MAC地址所有端口资源统一管理每个端口都可以配置VLAN、路由、策略无需区分它究竟属于哪台物理成员。对网络设计人员来说这种虚拟成一台的能力意味着网络拓扑可以大大简化。原先双核心跑VRRP时下联交换机要起两个VLAN接口做网关主备还要调优先级、占位计时器麻烦不说主备切换时总有一定延迟。而CSS把两台物理设备变成一台逻辑设备后下联设备只需要起一个三层网关链路聚合跨两台物理成员的端口绑定在一起任何一台成员故障流量无缝地切到另一台不需要协议重新收敛。所以CSS适合谁来用我认为是最适合两类需求一类是核心网络要求高可用、但不愿意承担传统双机方案配置复杂度的场景另一类是业务增长快、需要横向扩展转发容量和端口密度的场景。前者是省心后者是省钱——毕竟两台旧设备通过CSS组合出来的能力往往比直接换一台更高端的新设备更划算。2. 核心机制拆解CSS是怎么把两台设备焊在一起的2.1 集群连接的物理基础堆叠口和业务口CSS的物理连接主要有两种方式一种是用专用的堆叠口比如华为框式设备上的主控板自带堆叠口通过堆叠线缆直连另一种是利用高速业务口比如10GE、40GE、100GE接口做集群连接。不同的产品形态支持的连接方式有区别早期S9700、S12700这类框式交换机通常有专门的CSS接口而盒式设备如S5731-H、S6730-H则更常用业务口堆叠。用堆叠口做集群的优势是控制信道和数据信道物理隔离稳定性高不占用业务端口资源。缺点是你得先有相应的堆叠线缆和可用的堆叠口而且堆叠口的带宽一般固定比如40GE或100GE一旦设备型号只支持某个速率你没法灵活调整。用业务口做集群则灵活得多可以把任意高速端口划为堆叠物理成员端口但需要注意的是业务口在做堆叠时会占用端口并且端口上的业务配置会清空必须提前规划好哪些口承担集群互联哪些口留给业务。我在实操中见过不少人把集群接口和业务接口混在一起结果设备一重启端口角色变了配置全乱。记住一个原则集群连接端口一旦创建它就不属于任何业务只属于集群系统端口上的所有配置都会失效。2.2 主备角色与系统选举机制CSS集群由两台设备组成后系统会自动选举一台作为主设备Master另一台作为备设备Standby。主设备负责整个集群的控制管理运行协议栈管理成员设备的状态备设备则同步主设备的配置和状态转发平面同时工作数据流量不会因为主备关系而阻塞。选举的优先级比较规则朴素优先比较集群优先级数值越大越优先如果优先级一样比较MAC地址越小越优先如果还一样比较设备ID越小越优先。这和STP根桥选举很像很多擅长二层交换的朋友就能迅速理解。最容易被忽略的是主备角色是全局概念但不同业务板卡在主备设备上的角色可以不一样。比如主设备上有一块板卡故障可能引发整机主备切换但备设备上的板卡故障则更多的是本板卡的业务受影响。所以CSS虽然把两台设备变成一台逻辑设备内部的冗余逻辑依然遵循主控备份、转发分布的原则。2.3 跨设备链路聚合CSS最核心的价值点如果只是把两台设备堆成一个逻辑设备那意义不大。CSS真正的杀手锏是跨设备链路聚合Eth-Trunk跨成员绑定。下联交换机可以创建一条Eth-Trunk把两个物理成员端口分别接到CSS集群的两台物理设备上然后在Eth-Trunk上配置二层、三层接口以及网关。这样从下联设备看它连接的是一个逻辑设备链路聚合的主备和负载分担都交给Eth-Trunk处理从CSS集群看它用两台设备的端口共同承载业务任何一台设备故障聚合链路自动把流量迁移到另一台设备端口上几乎不中断业务。这条跨设备的聚合链路天然解决了传统VRRP方案中主设备在用、备设备在睡的浪费问题。在CSS方案里两台设备的转发芯片都处于Active状态流量可以hash到两端整体吞吐量接近两台设备之和。2.4 双主检测防的是脑裂而不是分裂CSS在正常工作时只有一个主设备。但如果集群链路发生故障两台设备都认为对方不可达就会各自独立启动争夺主角色导致集群形成两个主设备也就是俗称的双主或脑裂。这会产生灾难性后果两台设备都接入了同一个二层网络以相同的MAC地址对外发送报文造成MAC地址表震荡、广播风暴、业务流量来回翻转。为了防止双主华为CSS用了一套双主检测机制最常见的是直连检测和业务口检测。直连检测是主备设备之间单独拉一根检测线专门用来探测集群链路状态。业务口检测是复用业务口的链路与对端设备形成检测通道常见做法是把两台CSS成员分别与上联或下联的汇聚交换机连接通过这些业务口发送检测报文一旦超过超时时间没有收到对端的检测报文就判定集群链路中断备设备会关闭自己的所有业务端口进入备机拒发状态避免双主冲突。我调试的时候特别爱看双主检测是否正常因为这是CSS可靠性里最容易被忽视的环节。有些现场图省事没有配置双主检测或者检测通道配置了错误的接口结果集群链路一断网络直接瘫痪。3. 实操解析从零配置一套华为CSS集群3.1 配置前检查清单用一句话总结CSS配置前的准备物理一致、软件一致、拓扑清晰。成员设备的型号必须一致主控板、业务板型号及版本一致最好连固件补丁都一致。设备软件版本必须相同如果版本不同建议先升级到相同版本再做集群否则可能因为版本差异导致CSS组建失败或功能异常。规划好集群连接端口建议使用两个或以上的集群链路做冗余如果条件允许用独立的堆叠口最佳。所有配置操作建议在设备未接入业务网络前进行避免组网过程中产生环路。备份每台设备的独立配置。组建CSS后两台设备原来的配置会合并如果有冲突项可能覆盖或者报错。3.2 配置核心步骤演示我以常见的框式交换机为例假设两台设备分别叫A和B我准备用设备A的10GE1/0/1和10GE1/0/2集群口与设备B的10GE1/0/1和10GE1/0/2集群口相连同时配置双主直连检测。整个过程分几步第一步在A设备上配置集群连接端口并启用集群。sysname CS_A interface Eth-Trunk 1 trunkport 10GE1/0/1 trunkport 10GE1/0/2 quit css css enable css id 1 css priority 100系统会提示需要重启生效重启后A设备就进入了CSS模式等待与B建立集群。第二步在B设备上做同样的配置但设备ID和优先级与A不同。sysname CS_B interface Eth-Trunk 1 trunkport 10GE1/0/1 trunkport 10GE1/0/2 quit css css enable css id 2 css priority 50也需要重启。重启后两台设备如果集群线缆连接正常应该能协商成功通过display css status可以看到集群状态正常。这里有个关键点CSS模式下配置是合并而不是覆盖。A和B设备如果原来有管理IP在合并时可能出现IP冲突所以建议一开始给每台设备的管理IP设置不同地址待到集群建立后再统一重新规划。这点坑我踩过两台设备明明配置正常但一重启后管理地址互相冲突登录不上去最后只能接console口紧急处理。第三步进入CSS视图配置主设备的全局管理接口和业务逻辑。interface VLANIF 4001 ip address 10.10.10.1 255.255.255.252CSS集群建立后主备设备的全局配置是同步的只需要在主设备上配置即可。集群内部会自动把配置同步到备设备。3.3 双主检测配置为了保证集群链路故障时的安全我建议立即配置双主检测。直连检测方式最简单在主备设备之间找一根专用的检测线比如用Eth-Trunk中的一对独立端口做直连检测。css dual-active detection direct这个命令配置后系统会默认使用指定的用于直连检测的接口。也可以用业务口检测方式需要通过eth-trunk和对端设备配合复杂一些但不需要单独拉线。小型组网用直连检测就够了。3.4 验证集群状态配置完使用这几个display命令是每天必看的display css status查整体集群状态主备角色、成员数、集群连接状态。display css device查成员设备的详情包括设备ID、优先级、MAC地址。display css channel查集群链路的状态和带宽这里能看到集群口是否UP。display eth-trunk 1查看跨设备聚合链路是否正常。如果看到集群状态显示为Running成员设备都正常就说明组建成功。我还会进一步用display css binding查看主备设备上的板卡绑定关系确保各板卡都在正常工作。4. 常见故障与排查技巧实录4.1 集群链路协商失败场景两台设备配置完成后display css status显示成员设备离线或协商失败。排查思路先用display css channel查看集群链路的物理状态如果显示Down大概率是线缆问题或光模块问题。如果是光模块看一下收发光功率CSS链路对光模块质量要求高模块参数劣化就会导致协商不稳定。还有一种常见原因是端口类型配置成了普通业务口没有重新加载为集群口这在业务口做集群时很常见确认起来很简单在接口视图下查看端口属性如果显示为Stack或CSS端口就对了。4.2 双主检测误判导致端口被强制关闭有一次现网故障让我印象很深集群物理链路断开后双主检测端口仍然UP备设备没有及时关闭业务端口结果两台设备同时转发流量下联交换机MAC表疯狂跳动。后来查原因是双主检测线接到了中间一台傻瓜交换机上检测报文经过交换机后备设备能收到主设备的检测报文但检测通道的物理可靠性很差问题发生后没有第一时间触发拒发。这个教训是检测通道一定要可靠、独立尽量点对点直连不要让检测报文经过第三方设备。如果是业务口检测也要确保检测链路和集群链路是不同路径这才是真正的冗余。4.3 跨设备链路聚合流量不均配置好CSS后发现跨设备Eth-Trunk的负载不均衡一条物理链路流量高一条低。排查思路是看哈希因子是否合理。Eth-Trunk默认按报文的源MAC目的MAC、源IP目的IP做哈希如果业务报文格式比较单一比如全是同一种源IP到目的IP的流量哈希结果就会集中到一个成员口上。解决办法是修改Eth-Trunk的负载分担方式改为根据VLAN或二层信息进行hash或者改变hash算法。实际操作中可以在Eth-Trunk视图下使用load-balance命令调整最好配合不同业务的流量特征来定不能盲改。4.4 版本升级与平滑迁移CSS集群升级比较方便通常只需要将备用设备先升级然后主动执行主备倒换再升级新的备用设备。核心点在于升级前确认集群的配置一致性、备份配置文件并确保升级期间业务端口不会全挂。我习惯用issuIn-Service Software Upgrade方式在框式设备上做它能做到不中断业务的平滑升级。如果你的设备版本比较老不支持issu那就老老实实按传统方式做但一定要在业务低峰期操作做好回退预案。5. 关于CSS我的几条个人经验CSS技术本身不复杂但真正考验功力的是实施细节。我给想做或已经做了CSS的朋友几条基于经验的心得第一不要为了省线缆省端口而使用单条集群链路。任何情况下集群链路必须冗余否则一次光口松动就是全网故障。第二双主检测不能少一定要配置。即使你的组网觉得不会发生集群链路故障也要考虑模块老化、灰尘污染等不可控因素。双主检测是最后一道保险别省。第三每次变更前先备份配置CSS的配置合并逻辑和单台设备不同改坏了容易牵连两台设备。另外CSS设备上使用SNMP、NetStream等网管功能时网管地址和业务地址要分清楚。主设备故障切换后备设备接管管理角色网管平台需要能自动识别否则会误报设备离线。CSS还有一个容易被忽略的白皮书细节集群系统只是两台设备虚拟成一台但在故障切换时转发面上仍存在一定切换时间只是比传统协议收敛快得多。所以如果你的业务对毫秒级无缝切换有极致要求还是需要叠加硬件级冗余方案。CSS适合的是高可用、高性能的核心场景但不是所有网络问题的万能药。做技术的都知道纸上谈兵不如现场练手。有条件的朋友可以找两台支持CSS的设备做测试普通盒式设备做堆叠也行原理与CSS一致。自己把配置、断线、倒换完整跑一遍比看十篇文档都管用。等你能不看文档把双主检测、跨设备聚合、升级回退一次做对才算真正吃透了集群CSS。