BIGO骨干网设计与实现(二)

2022年初，我们发表了《BIGO骨干网设计与实现（一）》。文章介绍了BIGO骨干网演进至2.0版本、网络控制面引入SDN集中控制器、数据面采用MPLS SR Policy技术、控制器与SR-Policy结合实现智能流量调度的基本工作原理。

回顾骨干网2.0上线以来，控制器已自动处理了数不清的链路及设备故障，精准地调控流量使网络一直保持畅通，发现并解决了大量网络质量劣化事件。更重要的是，高度智能、自动化的骨干网络为业务的高速稳定发展打下了坚实的基础，同时节省了工程师大量的故障恢复以及优化调度时间。BIGO网络团队致力于把不可能变为可能，把SDN的精髓在BIGO全球网络中落地、生根、发芽；

本篇，将深入探讨BIGO骨干网高可用的实现细节。我们从3个方面介绍BIGO骨干网的高可用设计：

    1. 控制面高可用

    2. 数据面高可用

    3. 业务高可用

关于BIGO骨干网控制面的具体实现此处不再介绍，有兴趣的同学可以看回《BIGO骨干网设计与实现（一）》。本章着重介绍控制面的高可用。

控制面高可用被定义为3个层面：1.控制器本身可靠；2.控制器失效网络无损；3.控制器异常可“fallback”。

简单来说，控制器利用了ETCD的RAFT分布式一致性协议进行Leader选举实现高可用。控制器集群启动后，第一件事是选举主从（没有主的集群不允许任何数据更新操作）。选举完成后集群会通过心跳的方式维持主控制器的地位，一旦主控制器失效，就会有从控制器发起新一轮竞选。

通过RAFT协议实现控制器主从机制，确保了控制器集群有可靠的分布式一致性理论依据，有天然的异常处理能力，化解了控制器与底层网络的循环依赖问题，在网络或节点异常时有可预期主从切换行为。

引入“中间层”是系统设计中简化模块依赖关系的常用手段。通过引入中间层解耦上下层依赖，可以让系统结构更加清晰，隔离系统故障，并允许我们对上层系统进行重构(升级)时，不影响下层业务(数据面转发)。引入中间层解耦数据面与控制器之间的依赖关系，是让控制器失效时保证网络无损的关键措施。

骨干网控制器主要的信令传递协议为BGP，BGP本身就有一些网工都非常熟悉的特性适合构建“中间层”——Route Reflection（路由反射）、Graceful Restart（优雅重启）、Long-lived Graceful Restart（长效优雅重启）。

如上图所示，通过独立部署RR（路由反射器），控制器BGP和RR之间开启GR+LLGR Capability，可以实现控制器集群和数据面的解耦。

例如，当主控制器故障，主控制器和RR之间的BGP会话断开。这时RR会保留主控制器宣告的BGP路由（保持时间为控制器指定的GR timer+LLGR timer），且将其标记为“Stale(陈旧)”。当备控制器接管后，重新计算路径并下发的新BGP路由会被RR优选，进而反射到数据面设备，指导网络转发。以上整个过程对转发设备透明，P/PE节点不会丢失任何BGP路由(转发路径)，并在备控制器接管后平滑更新最优路径。

由此，BIGO骨干网通过“中间层”消除了控制器单点故障的影响，实现了控制器的无损平滑升级，即使出现更严重的故障（整个集群不可用），依赖LLGR能力也能争取到充裕的修复时间。

任何网络设备、链路都可能会出现故障，数据面高可用基本要求是必须有冗余的设备和链路。当花大价钱实现了设备和链路的物理冗余，在故障出现时如何让流量丢弃率(丢包时间)降至最低是一项既庞大又复杂的工程。

本章将对故障类型和应对措施逐一拆解，最后介绍BIGO的应对方案，以及控制器如何和传统的网络收敛加速技术协同工作。

在分析以上3类故障前，我们回顾传统网络收敛的步骤，并关注其中耗时：

1. 发现故障：需要切换转发路径的设备感知到网络故障的耗时。

2. 传播故障信息：故障信息由故障点开始往外传播，通常是IGP协议更新(泛洪)，传播时间与网络规模以及物理距离相关。

3. 计算新路径：收集到故障信息后，进行路径计算的耗时。通常是SPF/CSPF计算，计算速度与网络规模相关。

4. 更新硬件转发表：控制面将新计算出来的路径写入硬件转发表的耗时，其速度和设备硬件强相关。

分析上述步骤，逐一寻找应对措施：

1. 如何缩短发现故障耗时，首先想到的可能是调整协议计时器、叠加BFD等方案。但随着网络规模增大，配置过于激进的计时器设置不可取。当观测点远离故障点时，发现故障耗时通常在亚秒级/秒级。反之，距离故障点最近（直连故障点）的设备必然可以最快发现故障。那是否可以让直连故障点的设备去进行路径切换，解决发现故障慢的问题？

2. 传播故障信息的速度受网络规模以及物理距离影响——网越大设备越多，传播任务越繁重；信息传播速度不可能超过光速，横跨地球几大洲的传播时延都在100ms级别。想要消除传播耗时是天方夜谭，是否可以在故障信息传遍网络每一个角落前，就开始切换路径？

3. 路径计算耗时，还是和网络规模相关。既然算得不快，那是否可以“提前计算”？针对每种可能的故障，提前计算可行的绕行路径。

4. 更新硬件转发表，是对硬件表项资源进行重新编排，写入或删除信息的过程。既然绕行路径已提前计算，那也可以提前写入硬件转发表（当发现故障时，直接在转发表中删除原下一跳即可）。

根据以上指导思想，我们再看骨干网的故障场景：

应对穿越故障要复杂得多。BIGO骨干网采用了MPLS SR-Policy技术，转发路径由头端(IngressPE)压入的segment-list控制。这有2种可用的加速收敛方案：由头端绕开故障；由最靠近故障的设备(术语:PLR)绕路。

1）头端绕路的思路是：(由控制器)提前计算出端到端的“不共路”备用路径，并提前写入头端的转发表。这通常称为“路径保护(Path Protection)”技术；

2）由最靠近故障的设备绕路的思路是：网络种每一台设备，都对自身直连的节点/链路提前计算绕行路径，并提前写入自身转发表。这通常称为“设施保护(Facility Protection or Node/Link Protection)”技术。

对比以上两种方案，不难发现路径保护技术“发现故障”需要耗时较长，因此最多只能做到亚秒级收敛速度，而设施保护技术将“发现-传播-计算”3个步骤几乎全部跳过，因此可以实现毫秒级收敛。

另外，还需要关注路由刷新规模问题。对于网络设备硬件来说，故障3/4和故障5/6/7的收敛难度有很大差异。有海量路由的头端设备（IngressPE），即使已将备份路径提前写入硬件，要在硬件中要操作海量前缀（删除故障下一跳）仍然很花时间。这个问题的解决方案是是让设备的FIB结构从扁平变为分层型。相关技术有多种术语，例如“下一跳分离”“间接下一跳”“链式下一跳”“BGP PIC Core/Edge”等，它们方向是一致的（有一些实现上的差异，这里不展开）。下面以一个高度抽象的示意图描述扁平FIB与分层FIB的差异，当故障发生时，在分层型FIB中只需要删除多个前缀共同对应的主用下一跳即可。

我们将故障分门别类，列举了各种可能的故障应对方案后，下面开始介绍BIGO的应对方案。

穿越故障的应对方案，BIGO组合使用了路径保护与设施保护技术。

路径保护通过SR-Policy中包含高、中、低优先级CP(Candidate-Path)实现。如下图所示，高优先级CP定义了主用最优路径，中优先级CP携带与主路径“尽量不共路”的备用路径，低优先级CP是不含任何约束的只有endpoint node-sid的逃生路径。其中高、中优先级CP通过BGP-SR下发，低优先级CP通过Netconf下发。所有路径均使用sBFD进行连通性检测，当发现主路径故障后，可以第一时间切换到备用路径，当主备路径均异常或BGP-SR路由失效时，可以切换至逃生路径。

再提一点，逃生路径本质上是SRBE。我们不使用“fallback”机制而将它放入SR-Policy低优先级CP，可以确保网络无论处于何种状态，采集与监控方案始终一致。

设施保护通过Ti-LFA实现。BIGO骨干网中，Ti-LFA保护了两个方面的内容：其一是保护主备路径中的前缀标签或链路标签；其二是保护用于SR-Policy路径检测的sBFD的“反射包”。这是由于去程sBFD报文会压入标签栈沿Segment-list指定路径转发，而回程(反射包)通常是普通的IP包按IGP最短路径转发，这会导致同一条sBFD会话的协议包来回路径并不一致。可想而知，如果不对sBFD的回包“特别关照”，sBFD很可能会错误地反馈网络故障，甚至导致SR-Policy的主备路径同时中断。

另外要明确一点，设施保护(Ti-LFA)的收敛速度很快，但并不能完全替代路径保护。设施保护最大的问题在于它只能发现常规故障，假定“控制面/协议没问题转发就没问题”，对于软件BUG/芯片故障导致的静默丢包，设施保护几乎“无动于衷”。其次Ti-LFA的支持程度与网络设备厂家软硬件有较大相关性，对于要兼容多厂家多形态设备的BIGO骨干网来说，Ti-LFA在部分节点/链路有一定限制。因此，在BIGO骨干网中需要将路径保护与设施保护技术结合使用。

回顾上文8号故障点（EgressPE）的处理方案，可知要实现其加速收敛的技术复杂度较高，而且各厂家、不同形态设备对相关技术(draft-hegde-rtgwg-egress-protection-sr-networks)的支持程度参次不齐，因此BIGO骨干网暂未部署。所幸设备级故障相当罕见，这个场景的“硬收敛”对骨干网的整体SLA几乎无影响。

而出站链路故障（9号故障点）则常见得多的。尤其是对于骨干网而言，CE依靠长途专线拉远接入PE是十分常见的场景。BIGO通过在PE部署FRR（不同厂家术语有差异，例如huawei auto-frr，cisco bgp pic edge）实现出站链路故障时立即绕行到冗余PE，故障收敛时间控制在毫秒级。

下面以一个实际案例来讲解控制器和数据面网络收敛技术的协同工作。

如下图所示，关注PE1->PE3的一条SR-Policy，有通过adj-sid指定的主路径PE1-P1-P2-P3-PE3，完全不共路的备用路径PE1-PE2-P4-P5-P6-PE4-PE3。为了示例更有代表性，我们假设Segment-list需要分段拼接（设备单次压入标签数量收硬件限制，控制器会自动识别过长的路径并予以拆分），还展示了sBFD的反射包按IGP最短路径转发，SR-Policy主备CP的sBFD回程路径完全重叠的场景。

如下图所示，假设P1-P2之间链路出现故障：

所谓业务高可用，是指网络承载的业务能持续“正常工作”。除了“不断网”，我们还要着重关注网络的资源和质量2个方面：1.确保业务得到的网络资源充裕；2.确保承载业务的网络质量最优。

要做到以上2点，依赖传统的分布式TE相当困难，而通过BIGO的骨干网控制器则可轻松实现。本章节会介绍BIGO骨干网控制器3种基础调度方式，看其如何应用到保障业务高可用中。

“流量调度”、“优化调度”、“故障调度”是BIGO控制器的3种基础调度方式，所有业务逻辑都可以通过这3种调度方式组合实现：

1. 流量调度：周期发现网络中流量超阈值的链路，调整穿越该链路的SR-Policy的路径，使链路流量下降到设定值以下。

2. 优化调度：周期发现网络中“可能不在最优路径”的SR-Policy，重新计算这些SR-Policy的路径，确保其路径最优。“可能不在最优路径”包含多种场景，例如存在满足约束的cost/delay更小路径、当前路径不满足约束、所经过链路的IGP/TE属性发生变化等。

3. 故障调度：实时发现网络中链路故障或SR-Policy故障，调整穿越故障链路的SR-Policy的转发路径，使相关SR-Policy在故障后路径依然最优。

要达成目标，首要是确保网络不拥塞，其次是在资源充裕的前提下保证流量路径最优。

看控制器解决方案前，我们再次回顾传统无集中控制器的RSVP-TE方案的问题：

• 传统RSVP-TE方案基于“资源预留”模型工作。“预留”的资源并非业务实际使用的带宽——“预留”只是控制面逻辑，与数据面的转发行为无直接联系。当业务真实流量超过了预留带宽，可能会导致网络拥塞；若真实流量远小于预留带宽，则会导致网络利用率低下。全局部署auto-bandwidth/TE隧道限速等特性，只能一定程度缓解上述问题。
• 分布式RSVP-TE方案无法感知网络中非TE的“背景流量”，只能通过静态预留或将TE/非TE流量放入特定队列方式，防止其互相影响。
  
• 分布式TE路径的计算/重优化，无法获得全局最优解。不能充分利用网络带宽，在某些情况下还会长期陷入次优路径。
  

1. 控制器通过telemetry持续采集全网流量信息，周期性比对所有链路的实时流量与设定的流量阈值。

2. 当由于网络故障、业务高峰期流量上涨等原因，某些链路的流量超过其设定阈值时，控制器启动流量调度。

3. 针对超阈值链路，控制器计算需要调整的流量大小；并根据途经SL的流量大小、所属SR-Policy优先级等因素，确定出需要调度的SL。

4. 控制器将流量作为约束，对这些SL进行重新算路，使其绕开流量超阈值链路。这时相关链路的流量回落到安全水位之下。

5. 当由于网络故障恢复、业务低峰期流量下降等原因，原本高负荷的链路变得相对空闲时，控制器进行优化调度。

6. 优化调度根据算法，找出所有“可能不在最优路径”的SL；并根据网络流量、SL所属SR-Policy优先级等因素，对其进行重新算路，并调度到总cost/delay更优的路径上。

7. 通过流量调度+优化调度，可确保全网链路不超带宽阈值，不会出现拥塞。高优先级业务全天候均在最优路径中，低优先级业务在高峰期绕行次优路径，低峰期回到最优路径上。

网络质量，我们一般从时延、丢包、抖动3个维度采集数据。在有了这3个数据后，我们可以参考语音通信的标准，结合自身业务特点，给网络计算MOS得分，以统一网络质量的评价标准。

在传统RSVP-TE方案中，无法保证隧道的网络质量，无法在途经链路质量变差时自动调整路径。而通过BIGO的骨干网控制器，结合质量调度、优化调度、故障调度机制，实现了骨干网络基于质量的调度，保证业务承载的网络质量最优：

      ▼版权声明