学习
实践
活动
专区
工具
TVP
写文章
专栏首页Tungsten Fabric中文社区要在数据中心实现快速收敛?你需要一个快速IP Fabric
原创

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

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

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

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

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

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

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

数据中心内部的收敛

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

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

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

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

让我们来看一个示例拓扑:

我们有一个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所做的考虑仍然有效,因为我们使用相同的动态路由协议。

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

南北流量路径收敛场景

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

考虑一下下面这个场景:

我们有一个双归属到两个Leaf节点的VNF虚拟路由器 由于某些原因必须与DCGW对话。这条路径代表了南北流量的一个典型例子。

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

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

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

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

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

让我们看看,在正常情况下,BGP和BFD包可能流向哪里:

有四条可能的路径。第一次裂变发生在VNF层,取决于哈希函数的计算来选择一个LAG成员。第二次裂变发生在leaf上,因为DCGW可以通过2条ecmp路径到达。当然,属于同一个流的数据包(相同的5-tuple)将采取相同的路径,因为哈希函数给所有数据包的结果是相同的。

可能发生的故障推演

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

一个LAG成员可能会发生故障:

如前所述,在这里,收敛时间取决于LAG的反应;假设需要X时间才能收敛。

另一种可能发生的故障是leaf-spine故障:

在这种情况下,收敛时间取决于underlay BGP(记住,我们是在ERB模型中,所以evpn对端到端路径没有影响)。假设需要Y时间才能收敛。

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

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

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

虚拟环境下的收敛案例

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

我在一个虚拟环境中构建了之前展示的拓扑结构。由于是虚拟环境,设备之间并不是通过真实的线缆连接,而是通过中间的虚拟交换机进行连接。

这就意味着,如果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编译组


原创声明,本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

登录 后参与评论
0 条评论

相关文章

  • Tungsten Fabric如何实现路由的快速收敛?收敛速度有多快?

    在发布R2008版本之前,Tungsten Fabric无法同时提供南北向和东西向流量的快速收敛。

    Tungsten Fabric
  • 揭秘LOL背后的IT基础架构丨基础设施即代码

    在上一篇文章中,我们讨论了Riot针对全球应用程序部署的解决方案rCluster所涉及的网络的一些内容。具体来说,我们讨论了overlay网络的概念,OpenC...

    Tungsten Fabric
  • 【重识云原生】第四章云网络4.4节——Spine-Leaf网络架构

            1953年,贝尔实验室有一位名叫Charles Clos的研究员,发表了一篇名为《A Study of Non-blocking Switchi...

    江中散人_Jun
  • Tungsten Fabric入门宝典丨关于多集群和多数据中心

    由于在内部使用MPLS-VPN,因此Tungsten Fabric中的virtual-network可以扩展到其它Tungsten Fabric集群。

    Tungsten Fabric
  • SDN实战团分享(五):基于VCS技术 + NSX 控制平台实现SDDC网络架构

    1.数据中心和新的网络架构需要软硬件一体化 看到前面的兄弟关于NSX架构的分享,感到收获良多,Vmware力争实现的平台是一种和硬件解耦,把大部分问题在虚拟化架...

    SDNLAB
  • 到底什么是叶脊网络?

    1953年,贝尔实验室有一位名叫Charles Clos的研究员,发表了一篇名为《A Study of Non-blocking Switching Netwo...

    鲜枣课堂
  • SDN-数据与控制分离

    Control Plane: 控制平面在逻辑上控制转发行为。比如路由协议, 网络中间设备(middlebox: NAT, 负载均衡,firewall, IDS,...

    s09g
  • pps数据无法回答“哪种SDN解决方案更好”,你需要考虑这些

    最近我参与了一个项目,我们在Tungsten Fabric(注:原文为Contrail,本文将以功能一致的Tungsten Fabric替换)集群中部署了虚拟移...

    Tungsten Fabric
  • VXLAN篇之multi-fabric

    作者简介:张磊,思科原厂8年多technical consulting engineer,精通思科数据中心/园区网产品及技术;精通SAN网络架构及产品;熟悉广域...

    SDNLAB
  • 揭秘LOL背后的IT基础架构丨SDN解锁新基础架构

    本文作者David Press和Doug Lardo是Riot的两名工程师,他们致力于改善数据中心网络,以支撑Riot的在线服务。本文是关于该主题的系列文章第三...

    Tungsten Fabric
  • Big Switch推出下一代监控和数据中心交换架构 加速SDN网络转型

    SANTA CLARA,CA(2016年6月22日)- Big Switch Networks®,给全球带来超大设计灵感的网络数据中心领导者,今天宣布其基于SD...

    SDNLAB
  • 云数据中心下的光网络

    引子 过去的10年是互联网高速发展的10年,随着产业的不断发展,应用种类极大丰富,用户规模空前庞大。往往一个应用就拥有千万级别用户,上P数据量。在这样的环境下,...

    鹅厂网事
  • 解耦重构 Internet BGP SDN

    高清视频直播和云计算的蓬勃发展,带来互联网流量持续高速增长,主流云公司的Internet出口带宽都已经达到Tbps级别。 鉴于网络的拥堵大部分发生在出口互联,E...

    SDNLAB
  • 揭秘LOL背后的IT基础架构丨踏上部署多样性的征程

    我叫Jonathan McCaffrey,在Riot的基础架构团队工作。这是该系列文章中的第一篇,我们将深入探讨如何在全球范围内部署和操作后端功能。在深入探讨技...

    Tungsten Fabric
  • TF Live丨KK/建勋:多云、SDN,还有网工进化论

    3月18日,第一场【TF Live】如约而至,活动持续了两个多小时,在线人数将近1000人,互动讨论热闹十足。TF中文社区技术代表、瞻博网络全国合作伙伴技术经理...

    Tungsten Fabric
  • SDN十大落地解决方案

    伴随着互联网和云计算的高速发展,面对各种实时业务如视频语音、移动业务和云数据中心快速发展,传统网络尽管体系完善但也难以招架陈出不穷的需求问题。随着软件定义网络S...

    SDNLAB
  • 当网络传输协议SRD遇上DPU

    SRD(Scalable Reliable Datagram,可扩展的可靠数据报文),是AWS年推出的协议,旨在解决亚马逊的云性能挑战。它是专为AWS数据中心网...

    SDNLAB

扫码关注腾讯云开发者

领取腾讯云代金券