要在数据中心实现快速收敛?你需要一个快速IP Fabric



  • 先说一句看起来很“傻”,但在我看来并非琐碎的话:如果一切都按预期进行……那么一切就都会顺利进行。

    想象一下这样的网络:你设置链接,配置路由协议,检查端点是否可达。在正常情况下,数据包会如愿以偿地流动,用户也会对自己的体验感到满意。

    但是,如果网络内部出现故障怎么办?我们确实设置了路由协议来交换和传播路由信息,但这还不够。路由协议不一定要简单地提供端点之间的可到达性,它们必须被设计成能够高效地应对网络故障。

    那么“高效”又是什么意思?如果我们是在学校里学习,“高效”的意思就是快,我们确实希望将流量损失降到最低,因为这会导致服务中断,同时我们还希望系统的算法能够快速从故障中恢复。如果我们是在公司工作,“高效”仍然意味着快,压力也会更大,服务中断就意味着“金钱的损失”……

    总之,在这两种情况下,效率都意味着“快”。网络在处理故障的时候,必须要快。我们要尽可能地减少流量损失!

    这就引出了网络设计的一个基本话题:收敛!

    数据中心内部的收敛

    自第一个网络部署以来,网络收敛一直是非常重要的一个方面。

    当然,当你开始学习计算机网络时,一定听说过当一条链路故障时的生成树收敛,OSPF重新计算路径所需的时间,用于实现邻居关系的bgp保持计时器不再活跃等等。

    所有这些考虑因素在创建网络时仍然存在,而且至关重要,现在,我们把它们带到了数据中心里面。

    说到数据中心,我指的是IP Fabric,一个使用BGP作为路由协议的leaf和spine网络,并在leaf层限制L2功能(ERB模型)。有了这些假设,就不难理解很多“老”的快速收敛概念又回来了。

    让我们来看一个示例拓扑:
    16b28aca-a768-4682-a37d-7605c044c8d5-image.png
    我们有一个2×2的IP Fabric(2个leaves,2个spines),一个DC网关连接到两个spine(在真实的网络中,我们很可能有冗余的DC网关)。

    我们有服务器连接到leaves上,这些服务器是多归属连接到Fabric上的(绑定接口,每个leaf上都有一个成员连接)。

    来看看收敛是在哪里成为对话的一部分。

    在服务器和leaf之间,我们有一个LAG,因此,收敛主要是在一个成员故障的情况下,绑定失败的速度。在这里,我们期望亚秒级的故障切换时间,或者最坏的场景下,我们依靠LACP定时器(如果使用快速速率,那么我们期望检测时间为3×1秒)。

    而在IP Fabric内部,事情变得更加复杂……

    VTEPS的可达性取决于底层BGP。这里的收敛,是指BGP收敛。由于直接连接的接口地址之间使用的是eBGP,所以故障转移应该是非常快的。Hold Time不应该出现(除非软件层面的问题);BFD也可以做类似的考虑。

    接下来,对于EVPN驱动的连接,fabric ibgp overlay就变得相关了。在这里,由于在环回地址之间建立了BGP,来自BFD的帮助就成为关键。

    现在,让我来预测一下这个讨论的关键论点吧。2个leaf节点之间有多条路径;这来自于leaf & spine架构在两个leaf节点之间提供的多条ecmp路径。想象一下,从leaf1到leaf2的overlay ibgp数据包穿越spine1。如果leaf1-spine1的链接失效,并不意味着两个leaf不能再连通;它们可以通过spine2的备用路径。

    因此,overlay ibgp bfd定时器的速度不能快于underlay适应故障并提供leaf1和leaf2之间的备用路径所需的时间。由于underlay依赖于直连的接口地址之间配置的eBGP,反应时间应该非常快,因此我们可以设置非常低的BFD定时器。

    此外,由于设备上启用了ecmp,当一条链路发生故障时,leaf和spine已经将替代路径加载到FIB(包转发引擎表)中;这进一步将收敛时间降到最低,因为我们消除了将替代路由从RIB加载到FIB所需的时间(虽然很短,但它仍然存在)。

    这给了我们什么启示呢?

    如果系统A的收敛时间为X,而系统B使用系统A作为传输层,那么系统B的收敛时间不可能比X更快!

    这在后面会很方便。

    出于关闭fabric收敛的考虑,当一个ESI成员失败时,必须发送type 1 withdraw路由,以便让其它leaf知道有些MAC不能再通过发起这些type 1路由的leaf到达。某种程度上,这与ibgp overlay收敛有关。

    最后我们要涉及的部分是DCGW和和spine之间的路径。在这里,我假设了一个设计,有单独的p2p链路连接DCGW和spine(没有ESI LAG),并且eBGP会话通过直连的接口地址建立。在这种情况下,为Fabric eBGP underlay所做的考虑仍然有效,因为我们使用相同的动态路由协议。

    这涵盖了数据中心内部不同的收敛方面。

    南北流量路径收敛场景

    现在,让我们看看当需要在南北流量路径上进行收敛时会发生什么。

    考虑一下下面这个场景:
    5e60bf0b-4ebc-4896-beee-1fa7e94e3ffd-image.png
    我们有一个双归属到两个Leaf节点的VNF虚拟路由器 由于某些原因必须与DCGW对话。这条路径代表了南北流量的一个典型例子。

    现在,想象一下这两个端点通过BGP会话交换路由信息的情形。

    虚拟路由器可能充当DC内部运行的虚拟机的虚拟路由反射器。如果你仔细想想,这种用例并不是虚幻的。设置一个虚拟的RR是有意义的;你可能会通过依靠IP Fabric路由来实现类似的东西,但是很可能的是,你不希望在leaf(或spine)RIB里面带来太多的路由。

    此外,如果考虑到Contrail,Contrail Controller节点将作为路由反射器,并且与DCGW交换路由信息。

    在BGP会话的基础上,我们还配置了BFD,以便有更快的故障检测能力。

    现在,最大的问题是……如何设置BFD定时器?

    让我们看看,在正常情况下,BGP和BFD包可能流向哪里:
    3debfb3d-5c97-43ac-af19-7eab133558c1-image.png
    有四条可能的路径。第一次裂变发生在VNF层,取决于哈希函数的计算来选择一个LAG成员。第二次裂变发生在leaf上,因为DCGW可以通过2条ecmp路径到达。当然,属于同一个流的数据包(相同的5-tuple)将采取相同的路径,因为哈希函数给所有数据包的结果是相同的。

    可能发生的故障推演

    现在,我们来看看可能的故障。

    一个LAG成员可能会发生故障:
    a6652a16-bb4b-4c42-92a1-db93e8683c97-image.png
    如前所述,在这里,收敛时间取决于LAG的反应;假设需要X时间才能收敛。

    另一种可能发生的故障是leaf-spine故障:
    065bdbd8-5a47-4daf-b921-1f47e49f344f-image.png
    在这种情况下,收敛时间取决于underlay BGP(记住,我们是在ERB模型中,所以evpn对端到端路径没有影响)。假设需要Y时间才能收敛。

    回到我们的BFD定时器问题。在这两种故障场景下,BGP端点(虚拟路由器和DCGW)仍然可以通过替代路径到达对方。重要的是,我们必须允许fabric在端到端BGP会话下线之前提供该替代路径。这意味着BFD故障检测时间必须至少是max(X,Y)。

    这告诉我们在谈论数据中心的收敛时一些最基本的东西:每次我们“围绕IP Fabric设计收敛”的时候,都依赖于IP Fabric的收敛时间。

    这对现代架构有很大影响。想一想vEPG的用例:整个移动链将依赖于Fabric收敛。对于任何在数据中心内运行的应用来说,Fabric的恢复速度越快越好。

    虚拟环境下的收敛案例

    让我们简单看一下我们描述的一个例子。

    我在一个虚拟环境中构建了之前展示的拓扑结构。由于是虚拟环境,设备之间并不是通过真实的线缆连接,而是通过中间的虚拟交换机进行连接。
    f8a5012f-1acb-42ef-bae9-669488b7cfc7-image.png
    这就意味着,如果S2接口发生故障,S1接口不会宕机,因为S1-vswitch的链路还在。

    这是我的虚拟实验室环境的一个限制条件。

    这主要意味着两点。第一,如果leaf上的LAG成员被禁用,虚拟路由器会在LACP检测到故障后发现这一情况。第二,fabric BGP underlay必须依赖hold timer。由于这个定时器太长,我把BFD也配置在这些会话上。

    其实,这些虚拟环境给出的限制对我们的目的来说并不坏。由于我们不得不处理以秒为单位的收敛时间,因此将更容易观察到我们感兴趣的事件。

    在fabric内部,我为BGP underlay配置了以下BFD定时器:

    set groups bf_underlay protocols bgp group underlay bfd-liveness-detection minimum-interval 1000
    set groups bf_underlay protocols bgp group underlay bfd-liveness-detection multiplier 5
    

    定时器很大,正如所说,这是选择出来的。

    在虚拟路由器上,我们做如下设置:

    set protocols bgp group dcgw bfd-liveness-detection minimum-interval 300
    set protocols bgp group dcgw bfd-liveness-detection multiplier 3
    

    这些是端到端(虚拟路由器-DCGW)BGP会话的BFD定时器。

    我们有大约1秒与5秒两种情况。

    此时,我们禁用BGP和BFD数据包流动的leaf spine链路。

    大约1秒后,在虚拟路由器上,由于BFD会话关闭,BGP会话被关闭:

    Feb 12 02:14:55  bms bfdd[6205]: BFD Session 1.1.1.1 (IFL 0) state Up -> Down LD/RD(16/17) Up time:00:02:09 Local diag: NbrSignal Remote diag: CtlExpire Reason: Received DOWN from PEER.
    Feb 12 02:14:55  bms bfdd[6205]: BFDD_TRAP_MHOP_STATE_DOWN: local discriminator: 16, new state: down, peer addr: 1.1.1.1
    

    无论如何,虚拟路由器和DCGW仍然可以通过fabric提供的替代路径相连通,我们只需要等待fabric收敛。

    4秒之后发生了什么:

    Feb 12 02:14:59  leaf2 bfdd[1739]: BFDD_STATE_UP_TO_DOWN: BFD Session 192.168.3.1 (IFL 567) state Up -> Down LD/RD(16/17) Up time:00:05:02 Local diag: CtlExpire Remote diag: None Reason: Detect Timer Expiry.
    Feb 12 02:14:59  leaf2 rpd[1728]: bgp_bfd_callback:187: NOTIFICATION sent to 192.168.3.1 (External AS 65511): code 6 (Cease) subcode 9 (Hard Reset), Reason: BFD Session Down
    Feb 12 02:14:59  leaf2 bfdd[1739]: BFDD_TRAP_SHOP_STATE_DOWN: local discriminator: 16, new state: down, interface: xe-0/0/0.0, peer addr: 192.168.3.1
    

    这4秒钟来自于两个BFD会话上配置的检测时间的差异。

    接下来会发生什么?Fabric收敛,端到端BGP会话(虚拟路由器到DCGW)又出现了。结果呢?我们导致了BGP会话flap!

    为了避免这种情况,我们需要在端到端会话上增加BFD定时器的时间;例如增加到3×2.5秒:

    set protocols bgp group dcgw bfd-liveness-detection minimum-interval 2500
    set protocols bgp group dcgw bfd-liveness-detection multiplier 3
    

    在这种情况下,我们给fabric必要的时间来收敛,避免不必要的flapping(考虑到当DCGW将这些路由发送到其它地方,flapping的影响可能会扩展到其它设备,将导致整个网络的不稳定)。

    如果将BGP underlay BFD检测时间降低到2秒呢?在这种情况下,LAG故障切换(LACP 3秒)将成为约束条件,也就是说端到端BFD检测时间应该高于3秒。

    这完美的说明了在数据中心环境中运行的服务,其快速收敛的处理离不开fabric的收敛。

    那么,我的虚拟化服务能快速收敛吗?是的……但可能不会比你的IP Fabric更快!


    原文链接:https://iosonounrouter.wordpress.com/2020/02/13/to-have-fast-convergence-inside-a-dc-you-need-a-fast-ip-fabric/
    作者:Umberto Manferdini 译者:TF编译组



Log in to reply