在拆智能选路那篇的结尾,我说过一句:做到后期你会发现,控制平面的高可用比选路算法更让人头疼。这篇把这个头疼的问题展开。
先抛一个所有 SD-WAN 架构都绕不开的灵魂拷问:控制器挂了,全网会怎样?
如果你评估过 SD-WAN 方案,这个问题值得当面问厂商。答案的质量,直接暴露这套系统的架构功力。因为控制/数据平面分离这个 SD-WAN 的立身之本,在带来集中管理红利的同时,也亲手制造了一个新的单点:那个集中的"大脑"。大脑罢工,全网是继续正常跑,还是集体失明,还是直接瘫痪?三种答案对应三种完全不同的架构水平。
一、先划清楚:控制器挂了,哪些事受影响
很多人对"控制器故障"的想象是灾难片:控制器一挂,全网断连。其实一套设计合格的 SD-WAN,控制器故障的影响要分层看:
不受影响的(应该不受影响的):已建立的转发。 数据平面的转发不依赖控制器实时参与------隧道已经建好、会话表就在边缘设备本地、加密密钥也已下发。控制器失联,存量业务照跑。这叫**"控制平面故障不影响数据平面转发"**,是 SD-WAN 架构的底线要求。如果一个方案控制器一挂存量流量就断,说明它把转发决策做成了每包问询控制器,这架构基本可以一票否决。
受影响的:一切需要"新决策"的事。 新站点无法上线(ZTP 流程走不动)、策略无法变更、选路进入"惯性模式"------设备只能按最后一次收到的策略和本地探测继续跑,全局视角没了。跨站点的新隧道协商也可能受阻。
危险的:失联时间拉长之后。 密钥轮换停摆、证书续期失败、各设备的本地状态逐渐和"全局真相"漂移。失联几分钟是小事,失联几天,恢复时的状态对账就是一场硬仗。
所以控制平面高可用的目标可以精确表述为:把"需要新决策的事"的不可用时间压到最短,并保证恢复后全网状态能正确收敛。
二、边缘侧的自治能力:高可用的第一道防线
反直觉的一点:控制平面高可用,第一道防线不在控制器上,而在边缘设备上。
思路是让边缘在失联时有足够的自治能力,把"必须问控制器"的事压到最少:
策略本地化。 控制器下发的不是"每一次选路结果",而是"选路策略"(权重、阈值、防抖参数)。边缘拿着策略 + 本地实时探测,自己就能算选路------这正是前面选路算法篇讲的那套逻辑跑在边缘。控制器失联,选路照常,只是失去了全局协调。
失联降级预案。 提前下发"失联时怎么办"的规则:比如失联后冻结策略变更、保持现有隧道、新流量按默认策略处理。相当于给边缘一份"断联作战手册"。
本地缓存与宽限期。 密钥、证书、对端信息在边缘留有余量,设计明确的宽限期(比如证书过期前 N 天就该轮换,失联时靠这个余量撑住),而不是掐着点续期。
我踩过的一个坑就在宽限期上:早期把隧道密钥的轮换周期设得很短(觉得安全),结果一次控制器维护窗口拖长,恰好撞上一批设备的密钥到期,新密钥发不下去,隧道陆续重协商失败。从那以后我的原则是:任何有有效期的东西,宽限余量必须显著大于控制平面可能的最长故障时间。 安全性和可用性在这里要做明确的取舍,而且要算着数字做。
三、控制器自身的冗余:经典分布式问题的网络版
边缘自治兜住了底,控制器本身的冗余才是主菜。这里遇到的全是经典分布式系统问题,只是换了网络的皮。
主备还是多活? 主备(Active-Standby)简单:备节点同步主节点状态,主挂了切备。难点在"怎么判定主挂了"和"切换要多快"------判快了容易误切,判慢了不可用时间长。多活(Active-Active)吞吐好、无切换延迟,但立刻引入状态一致性问题:两个控制器同时在线,设备听谁的?策略在 A 上改了、B 还没同步,连到 B 的设备拿到旧策略怎么办?
脑裂是真正的噩梦。 主备之间网络分区,双方都认为对方挂了、都升级为主,两个"大脑"同时向不同的设备下发可能冲突的策略------这比控制器彻底挂掉严重得多,挂掉只是"没有新决策",脑裂是"有两套矛盾的决策"。标准解法是引入仲裁:奇数节点投票(Raft/Paxos 一类共识协议),或第三方仲裁点,保证任一时刻至多一个主。控制器集群用 Raft 做选主和配置日志复制,是目前比较主流的做法。
设备侧的多控制器接入。 光控制器集群化还不够,边缘设备得内置多个控制器地址、支持自动切换和重连风暴保护。这里有个细节容易翻车:控制器恢复的瞬间,几千台设备同时涌上来重连、全量同步状态,能把刚恢复的控制器再打挂一次。重连必须做随机退避和分批,状态同步要支持增量。这个"恢复风暴"的坑,不亲手挂过一次控制器,很难提前想到。
地域级容灾。 单机房集群解决不了机房级故障。跨地域部署控制器,又要面对跨地域的同步延迟和分区概率上升------CAP 的取舍绕不过去。常见的务实做法是:同城多活保低延迟切换,异地做异步复制的灾备,接受极端情况下少量最新变更丢失、靠状态对账补齐。
四、恢复之后:状态收敛这场硬仗
控制器修好只是故障处理的一半,另一半是让全网状态重新对齐,这一步的坑不比故障本身少。
失联期间,边缘按本地策略自治运行,可能发生了:链路切换、会话变化、甚至有设备重启过。控制器恢复后拿到的"全局视图"是过期的。直接按旧视图下发策略,等于拿老地图指挥新战场,轻则策略错乱,重则把正常运行的流量切崩。
正确的顺序应该是:先收,再算,后发------控制器恢复后先从各边缘收取当前真实状态(增量上报),重建全局视图,再基于新视图计算策略,最后灰度下发(先小批设备验证,确认无异常再全网推)。恢复后的第一波策略变更尤其要克制,我的习惯是恢复后设一个观察窗,窗口内除紧急故障外不做主动变更,让系统先稳下来。
五、评估一个方案时,怎么问
把这篇的内容压缩成四个问题,评估 SDWAN 方案时可以直接拿去问:
一问控制器失联,存量转发受不受影响 ------答案必须是"不受",否则免谈。二问失联期间边缘怎么自治 ------听它讲策略本地化和降级预案的细节。三问控制器集群怎么防脑裂 ------听它讲共识机制和仲裁。四问恢复后状态怎么收敛------这是最见功力的一问,能讲出"先收再算后发"和灰度恢复的,基本是真踩过坑的团队。
工业实现上,这套"边缘自治 + 集群共识 + 灰度恢复"是成熟方案的共同套路。以某跨境 SD-WAN 方案(万联 WANFLOW)为例,其架构同样遵循"控制面故障不影响数据面转发"的底线设计,边缘节点在控制器失联时按本地策略维持选路和隧道------这条底线是不是守得住,是我判断一套 SD-WAN 是否达到生产级的第一标准。
写在最后
回到开头的问题:控制器挂了,全网会怎样?现在可以给出合格的答案了------存量业务无感,新决策暂停,边缘按预案自治,控制器以集群冗余把故障时间压短,恢复后按"先收再算后发"灰度收敛。
这一整套,没有任何一个环节有算法上的难度,难的全是工程取舍:自治给多大权限、宽限期留多长余量、一致性和可用性怎么平衡、恢复节奏多快。这也是我说它比选路算法更头疼的原因------选路错了顶多绕点路,控制平面的设计失误,是要在故障那天连本带利还的。