最近帮一个核心机房的网络做改造两台汇聚交换机要做双机冗余传统的VRRPSTP方案配置麻烦链路利用率还低倒换也要等好几秒。后来直接把这两台设备做成了VSC也就是中兴交换机的虚拟交换集群把两台物理交换机虚拟化成一台逻辑设备来管理。这个方案实操下来效果很明显配置量少了一大半故障切换基本无感知。这篇就完整记录一下VSC从规划到落地的全过程包括配置命令、验证方法和我踩过的坑给同样准备做双机虚拟化的朋友一个参考。1. 为什么用VSC双机热备的老问题与虚拟集群的价值先说清楚VSC到底解决了什么。以前做链路冗余最常规的思路是两台交换机跑VRRP作为网关冗余下联交换机或者服务器做双归接入靠STP阻塞一个端口来防环。这套方案能用但问题也很明显。1.1 传统方案的三个痛点配置量大。一台接入交换机要上联到两台汇聚两台汇聚要各自配VRRP、MSTP实例、ACL、QoS策略任何一条策略都要在两边重复操作漏改一处就容易出故障。如果还有多VLAN网关VRRP的配置量会成倍上涨。链路利用率低。STP阻塞掉的那条链路平时是闲置的你为它付了光模块、光纤和端口的成本换来的只是备份能力。服务器双网卡做主备模式时同理真正在跑流量的一侧满载另一侧在空转。倒换时间不稳定。VRRP主备倒换加上STP重新收敛通常在秒级。对普通办公网络没什么但在数据库、虚拟化集群这种对丢包敏感的场景一秒的丢包可能引发上层业务超时然后触发一堆告警。1.2 VSC把“两台”变成“一台”VSC的核心思路是让两台成员交换机通过专用的高速链路互联共享控制面和转发表项对外呈现为单一的逻辑设备。下联交换机只需要接一次不需要做双归服务器通过跨设备链路聚合两条链路同时转发网关也只在逻辑设备上配置一份自动完成跨框备份。实际体验最明显的一点是管理起来从“两台设备同步修改”变成“一台设备集中配置”配置同步是自动完成的。主设备故障后备机接管控制面转发层面因为表项本来就在框间同步所以业务中断时间很短体感远好于传统VRRP方案。1.3 适用场景与不适用场景VSC比较适合同一机房内、物理位置相邻的交换机比如数据中心的汇聚层、园区的核心层、虚拟化集群的接入层。两台设备距离越近VSC互联链路越短可靠性越高。跨楼宇、跨机房的场景不建议上VSC。VSC要求两台设备之间必须有高性能、低时延的互联链路距离拉远之后光缆成本高而且一旦互联链路中断整个逻辑设备会分裂成两台独立设备处理不好就是“双主”脑裂。跨地域高可用应该用独立的网关虚拟化方案或者三层路由冗余来实现而不是靠VSC。2. 上线前必须定死的五件事拓扑、编号、转发模式与前置检查VSC最忌讳“线拉好了直接配”很多后续排障问题都是规划阶段埋下的。我习惯在动手之前先把下面几件事全部定下来写成一张表格发给相关同事确认。2.1 物理拓扑环形还是链形VSC成员之间通过VSC链路互联常见拓扑有环形和链形。环形是每台设备都有两条VSC链路分别连到相邻两台形成闭合环路链形则是一条串到头只在两端闭合。对比项环形链形链路冗余性单条VSC链路故障不影响集群中间链路断开会分裂带宽开销VSC流量可走两个方向带宽更大跨框流量路径单一端口占用每台设备至少两个VSC端口每台设备一个端口即可推荐场景生产核心、对可靠性要求高接入层、成本敏感场景实际项目里我基本都选环形两台设备各用四个端口做VSC组成双环形互联。端口多花一点换来的是一条链路断掉后整个VSC完全无感的余量这笔账划算。2.2 成员编号与接口命名的逻辑VSC里每台成员交换机有唯一的成员编号接口命名会带上编号比如gei_1/1/1和gei_2/1/1分别表示1号机和2号机的1槽位1口。这个编号一开始就要规划好上线后尽量不要改。编号一旦和物理位置绑定后续的端口配置、监控脚本、告警信息都会沿着这套命名走下去。我见过有项目上线时没固定编号设备重启后槽位号漂移结果所有涉及接口的脚本全部失效排查了大半天才发现是编号变了。所以上线前我必做一张“物理位置-设备名-成员编号-管理IP”的对照表贴在机柜门上配置时照着写。2.3 转发模式本地优先还是跨框转发VSC支持配置帧的转发模式这直接决定跨框流量的路径。本地优先转发也叫Local Prefer转发。流量尽量在本地成员交换机完成转发只有目的地址在远端成员上时才跨VSC链路。适合南北向流量为主的场景比如大部分流量是服务器到网关、服务器到上联出口这种模式跨框带宽占用小时延也更低。跨框转发。流量统一进入转发面后按转发表决定出端口不一定本地优先。适合东西向大流量且分布均匀的场景但会吃掉不少VSC链路带宽。大多数业务我建议选择本地优先转发配置前先想清楚自己的流量模型别随手选。2.4 版本与License前置检查VSC要求所有成员交换机的软件版本一致最好是同型号同BootROM版本。版本不一致在运行中可能不会立刻出问题但一旦触发主备倒换或配置同步差异命令会被覆盖或不被识别故障定位难度直接翻倍。同时要检查VSC授权是否已激活。部分型号的VSC功能需要License没有授权就开启会报错或者功能受限。我习惯在配置前执行show license确认省得配到一半才发现授权缺失。2.5 VSC链路端口的选择VSC链路最好是独立的万兆或更高带宽端口不要和业务口混用。常规经验是VSC链路的总带宽不建议低于上行业务收敛带宽否则高峰期跨框流量可能把链路打满影响数据转发。端口准备好之后还要做光模块自检检查收发光功率是否正常别拿一根脏光纤做完互联上线后再断链就头大了。3. 配置实例从物理接线到逻辑设备生效的完整过程下面以两台同型号中兴交换机做汇聚VSC为例逐步演示配置过程。命令以常见软件版本为例不同版本字段可能有差异执行前请对照当前版本命令参考确认。3.1 物理连接与基础登录配置先将两台设备断电规范上架规划好1号机、2号机的物理位置用光纤把两台设备的VSC链路端口互联。随后恢复供电用Console线分别登录两台设备先完成最基础的主机名和管理地址配置。// 1号机操作 hostname CORE-SW-01 interface mgi0/1/0 ip address 192.168.10.1/24 no shutdown ! // 2号机操作 hostname CORE-SW-02 interface mgi0/1/0 ip address 192.168.10.2/24 no shutdown !管理地址配好后通过管理网络远程登录后续操作不需要再频繁插Console线。这个阶段不建议跳过因为VSC配置过程中可能会触发设备重启或端口初始化远程管理和Console双通道都能用得上的话后续操作容错率高很多。3.2 创建VSC域并协商主备角色VSC的核心配置在1号机上进行2号机后续会自动同步。首先是开启VSC功能并创建域。vsc enable vsc domain 1配置完成后成员交换机会通过VSC链路协商主备角色。默认情况下先启动的设备会成为主设备如果想指定某台设备为主可以通过调整优先级来控制。比如想让1号机稳定担任主设备可以配置较高的优先级。vsc priority 200 vsc device 12号机同样开启VSC功能加入同一个域。vsc enable vsc domain 1 vsc priority 100 vsc device 2这里vsc device的作用是固定成员编号防止设备重启后编号漂移。优先级高的成员会成为控制主设备承载控制面的处理工作另一个成员则处于热备状态同步所有配置和转发状态。3.3 配置VSC链路端口接下来要把选定的物理端口加入VSC链路。这部分配置要在每台成员设备上各自完成同时把对端端口也加进去。这里以1号机端口gei_1/1/1和gei_1/1/2、2号机端口gei_2/1/1和gei_2/1/2为例。// 1号机配置 interface gei_1/1/1 vsc-port ! interface gei_1/1/2 vsc-port ! // 2号机配置 interface gei_2/1/1 vsc-port ! interface gei_2/1/2 vsc-port !把端口配置为vsc-port后该端口不再承载普通业务专门用于成员间通信包括控制消息和跨框数据转发。配置完成后VSC会开始协商正常情况下两台设备会建立集群关系。3.4 配置分裂检测解决最危险的“双主”场景VSC最危险的故障是两台成员设备之间的VSC链路全部中断此时两台设备失去联系都认为自己还是原来那台逻辑设备继续同时转发和管理也就是“双主”脑裂。此时下联交换机如果还在正常转发网络就可能出大问题。解决办法是配置分裂检测机制也就是MAD检测。中兴设备常用专用链路方式用一根独立的网线或光纤直连两台设备的管理口或专用检测口一旦VSC链路中断两台设备通过该链路感知对端仍然存活从而主动关闭备份设备的业务端口避免出现双主。vsc mad enable interface mgi0/1/1这里用的是mgi0/1/1作为MAD检测接口前提是两台设备之间已经用独立的网线或光纤连接了这个接口。MAD链路必须是独立链路不能和VSC链路共享同一根物理线路否则VSC断了MAD也必然断了检测就失效了。3.5 业务配置只需在主设备上执行一次VSC生效后业务配置只需要在主设备上执行系统会自动同步到备设备。比如配置VLAN、VLAN网关和跨设备链路聚合都在主设备上完成。vlan 100 name Server-Vlan ! interface vlan100 ip address 192.168.100.254/24 ! interface gei_1/1/10 switchport access vlan 100 ! interface gei_2/1/10 switchport access vlan 100 !注意这里直接引用了gei_2/1/10也就是2号机的端口在主设备上一样可以配置这是VSC配置同步的便利性。如果想配置跨设备链路聚合让服务器双网卡同时工作则用聚合口把两台设备的端口绑在一起。interface smartgroup1 switchport trunk allow vlan all ! interface gei_1/1/10 smartgroup 1 ! interface gei_2/1/10 smartgroup 1 !这样服务器做双归接入时两条物理链路属于同一个聚合口同时转发并且任一台成员设备故障链路依然通过另一台转发。VSC加跨设备链路聚合的组合是虚拟化集群接入的标准姿势。3.6 保存配置并确认同步状态配置完成后在主设备上保存配置并确认配置已同步到备设备。write show vsc configuration sync-status看到同步状态正常后再核对一遍两台设备的启动配置确保所有业务配置都已在备设备上生成。这里有个细节VSC配置同步有方向性平时修改配置都应在主设备上进行如果在备设备上直接修改下次同步时可能被主设备的配置覆盖掉这一点全团队都要知道别各改各的。4. 验证与排障怎么看集群健康度怎么做倒换测试配置完成后不等于工作结束验证这一步最能反映集群是否真正健康。VSC的验证分三层控制面状态、数据面状态、故障倒换能力。4.1 查看集群成员和角色登录主设备执行下面命令确认成员状态。show vsc status show vsc device正常状态应该是两个成员都处于“正常工作”状态角色分别为主备。如果某个成员显示“离线”或“协商中”需要检查VSC链路端口状态和光模块收发光。4.2 查看VSC链路健康度VSC链路是集群的生命线需要单独看端口状态、带宽利用率和错误计数。show vsc link-status show interface gei_1/1/1重点看两个指标input errors和output errors是否为非零且持续增长以及光模块收发光功率是否在正常范围。链路有误码但没断是最容易忽略的隐患它不会直接触发倒换但会悄悄增加跨框转发时延。4.3 主备倒换测试验证集群可靠性最直接的方式是主动做一次倒换测试确认备机可以无缝接管。vsc switchover执行该命令会强制控制面切换到备设备此时业务应该无感知或只有极短的中断。测试时要在下联设备上持续ping网关地址观察倒换过程中的丢包情况。正常情况下丢包应控制在个位数以内甚至为零如果出现明显丢包需要检查VSC链路带宽和转发模式。倒换完成后再次查看show vsc status确认新的主备角色分配正常再观察一段时间确认业务无异常。4.4 MAD分裂测试找一个维护窗口拔掉两台设备之间的VSC链路光纤模拟最极端的分裂故障。show vsc mad status拔掉VSC链路后MAD机制应触发备份设备自动关闭业务端口并进入“分裂检测”状态主设备继续正常转发业务恢复VSC链路后备份设备重新拉起端口自动回归集群并同步配置。这个测试我不敢说每次都能一次通过但测试通过后对于整套方案的信心会足很多。4.5 常见故障定位速查表故障现象排查思路定位结果成员设备反复重启检查VSC链路端口是否正常协商、光模块收发光大概率是物理链路质量差配置同步不生效确认修改操作是否在主设备执行在备设备上做的修改被覆盖倒换时业务中断明显检查VSC链路带宽利用率、转发模式跨框流量打满VSC链路分裂检测未触发双主检查MAD链路是否被误拔或未配置缺MAD链路或配置失效成员编号漂移检查vsc device是否已配置未固定编号导致接口命名变化5. 实战踩坑记录VSC上线后最容易翻车的几个细节5.1 VSC链路被业务流量打满之前有一次上线后某段业务间歇性丢包查了一圈发现VSC链路的利用率长期超过90%。原因很直接VSC链路用的端口带宽只有万兆而上联业务流量峰值远超这个数跨框流量一多就拥塞。后面扩容了VSC链路加了多组端口做链路聚合丢包就消失了。经验是VSC链路带宽宁可配大不要配小并且要纳入监控设置利用率告警阈值比如超过70%就通知排查而不是等业务出现感知才去查。5.2 版本不一致升级过程把备机升级挂了有一次做版本升级计划是先升备设备、再倒换、再升原主设备。结果备设备升完重启后起不来排查发现备设备原来的BootROM版本和主设备不一致升级包只更新了系统版本BootROM没跟上导致备设备重启后引导异常。回滚后老老实实把两台设备的BootROM先对齐再重新走升级流程才顺利完成。此后我养成了一个习惯任何两台设备组VSC前先对比软件版本、BootROM版本、补丁版本三个全部一致才允许接入集群。5.3 MAD检测链路被误拔差点脑裂MAD检测链路用的是管理口之间的一根网线走线的时候和一堆管理网线绑在一起。有一次运维清理线缆顺手把这根线拔了当时没注意后来VSC链路真的中断了一次两台设备同时进入主状态配置各走各的整个网络乱了一阵子。后来我要求MAD链路单独走线、单独标签并在交换机和监控系统里做了链路状态告警只要MAD链路断开就立即通知。VSC链路和MAD链路这种关键连接细节上多花十分钟故障时能省好几个小时。5.4 在备设备上改配置被同步覆盖团队里有同事习惯登录某一台设备操作直接在备设备上改了一个接口配置结果下次主设备配置刷新时改动直接被覆盖了业务没有生效还难排查。VSC的配置同步是有方向的主设备是配置源所有改动必须在主设备上操作备设备上的配置只作为同步副本。5.5 断电重启后接口编号漂移有一段老设备在重启后出现接口命名变化原因是没固定vsc device编号系统重新分配成员编号后所有带编号的接口配置全部对不上。监控脚本里写的是旧编号的接口结果全部失效。后来把所有VSC域的设备都固定了编号并配合配置备份这个问题再没出现过。6. 集群不只是“一台设备”后续优化与运维建议6.1 跨设备链路聚合配合虚拟化接入VSC的上层最佳搭配是跨设备链路聚合也常被称为M-LAG或双活网关让服务器或下联交换机通过聚合口双归接入两条链路同时转发。这个组合能把可靠性从“设备级冗余”再提升到“链路级负载均衡”。配置聚合口时注意两端成员设备的链路参数要一致包括速率、双工、允许通过的VLAN否则聚合协商可能出问题。6.2 与上层路由协议的联动VSC作为汇聚或核心时上联通常会跑OSPF或BGP。VSC对外是一台逻辑设备上联设备看到的是一个邻居、一个Router ID不再需要为主备各配一套路由会话。配合网关虚拟化无论是上联路由器还是下联交换机配置都能大幅简化。6.3 监控体系要覆盖到VSC内部VSC虽然对外是一台设备但对内仍然是两台物理设备。监控系统不建议只盯逻辑设备本身还要分别监控两台成员设备的CPU、内存、VSC链路流量、MAD链路状态。否则某台成员已经异常但只要主设备还在转发监控看起来就一切正常隐患一直潜伏到故障发生。6.4 定期做倒换演练VSC配置完成后不是一劳永逸的我建议每个季度做一次主备倒换演练确认备份设备随时可以接管。演练既验证设备状态也能验证团队的操作流程是否还熟悉。真正故障来临时所有人的肌肉记忆都是从平时演练中来的。我在实际项目里体会最深的一点是VSC带来的不只是网络架构的简化更是运维心态的改变。以前做割接总是提心吊胆现在两台设备是一台逻辑设备配置、升级、倒换的复杂度都降了一个量级。如果你正在设计核心或汇聚的冗余方案VSC值得好好尝试。
阅读完成 · 觉得有帮助?