专栏首页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编译组


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

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

我来说两句

0 条评论
登录 后参与评论

相关文章

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

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

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

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

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

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

    Tungsten Fabric
  • 到底什么是叶脊网络?

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

    鲜枣课堂
  • TF功能开发路线图:盘点2021年Tungsten Fabric聚焦领域

    在Linux基金会主办的“LFN技术会议”上,Tungsten Fabric社区进行了一系列演讲,介绍最新的功能和未来发展方向。今天带来第一篇演讲,看看Tung...

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

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

    Tungsten Fabric
  • 远程部署神器 Fabric,支持 Python3

    如果你搜一圈 "Fabric "关键字,你会发现 90% 的资料都是过时的,因为现在 Fabric 支持 Python3,但是它又不兼容旧版 Fabric。所以...

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

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

    SDNLAB
  • VXLAN篇之multi-fabric

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

    SDNLAB
  • 绯闻女孩传八卦也能作为区块链协议?10分钟告诉你为啥

    随着比特币等数字加密货币的兴起,区块链技术逐渐升温,霎时间,各种区块链技术落地场景应运而生。但是关于区块链技术本身,“去中心化”、“数据不可篡改”、“数据溯源”...

    区块链大本营
  • 如何用Nginx快速搭建一个安全的微服务架构

    美的让人心动
  • 如何用Nginx搭建一个安全的、快速的微服务架构

    本文改编自Chris Stetson发表在nginx.conf 上的一个有关如今的微服务以及如何使用Nginx构建一个快速的、安全的网络系统的演讲,

    吴生
  • 如何用Nginx搭建一个安全的、快速的微服务架构

    今天我们要谈论微服务以及如何使用Nginx构建一个快速的、安全的网络系统。最后,将向您展示一个使用Fabric模式如何非常快速和轻松地构建一个微服务的demo。

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

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

    SDNLAB
  • 细说TF服务链丨如何配置服务链的高级功能

    在之前的文章中,我谈到了什么是服务链,以及如何配置基本的服务链。让我们回顾一下服务链的构建方式:

    Tungsten Fabric
  • 聊聊虚拟分布式路由(VDR)

    在IT行业,软硬件始终在不停向前发展,偶尔还会出现革命性的“巨大飞跃”,虚拟分布式路由(Virtual distributed routing,VDR)就是其中...

    SDNLAB
  • Hyperledger Fabric账本快照--实现数据的快速同步

    | 导语数据同步,也就是区块同步,是区块链实现节点加入、状态恢复等必不可少的一个环节,只有拥有最新状态的节点,才能参与到共识中去,进行下一个新区块的共识。

    tylerwen
  • “Hyperledger Fabric 是假区块链!”

    自 Libra 发布以来,沉寂已久的区块链社区又活跃了起来,一些探索区块链业务的公司也在暗地里较劲不甘落后。相信你也注意到了,这些大公司往往都对现有比特币、以太...

    区块链大本营
  • 解耦重构 Internet BGP SDN

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

    SDNLAB

扫码关注云+社区

领取腾讯云代金券