我们开发了一种数据中心网络设计，允许部署超过 100 万台服务器的计算集群，峰值二分带宽超过每秒 XNUMX PB。
从 Dmitry Afanasyev 的报告中，您将了解新设计的基本原理、扩展拓扑、由此产生的问题、解决这些问题的选项、“密集连接”中现代网络设备的路由和扩展转发平面功能的特性具有大量 ECMP 路由的拓扑。 此外，迪马还简要介绍了外部连接的组织、物理层、布线系统以及进一步增加容量的方法。
- 大家下午好！ 我叫 Dmitry Afanasyev，是 Yandex 的网络架构师，主要设计数据中心网络。
我的故事将是关于 Yandex 数据中心的更新网络。 这在很大程度上是我们设计的演变，但同时也有一些新元素。 这是一个概述演示，因为需要在很短的时间内包含大量信息。 我们将从选择逻辑拓扑开始。 然后将概述控制平面和数据平面可扩展性问题，选择物理级别将发生的情况，并且我们将研究设备的一些功能。 让我们稍微了解一下使用 MPLS 的数据中心发生的情况，我们之前已经讨论过。
那么，Yandex 的负载和服务如何？ Yandex 是典型的超大规模提供商。 如果我们看用户，我们主要处理用户请求。 还有各种流媒体服务和数据传输，因为我们也有存储服务。 如果靠近后端，那么基础设施负载和服务就会出现在那里，例如分布式对象存储、数据复制，当然还有持久队列。 主要的工作负载类型之一是MapReduce和类似的系统、流处理、机器学习等。
发生这一切的基础设施如何？ 同样，我们是一个非常典型的超大规模企业，尽管我们可能更接近于较小的超大规模企业。 但我们拥有所有的属性。 我们尽可能使用商品硬件和水平扩展。 我们拥有完整的资源池：我们不使用单独的机器、单独的机架，而是将它们组合成一个可互换资源的大型池，并提供一些处理规划和分配的附加服务，并使用整个资源池。
所以我们有了下一个级别——计算集群级别的操作系统。 我们完全控制我们使用的技术堆栈非常重要。 我们控制端点（主机）、网络和软件堆栈。
我们在俄罗斯和国外拥有多个大型数据中心。 它们通过使用 MPLS 技术的主干网连接在一起。 我们的内部基础设施几乎完全构建在 IPv6 上，但由于我们需要服务仍然主要通过 IPv4 传输的外部流量，因此我们必须以某种方式将通过 IPv4 传输的请求传递到前端服务器，并将更多请求传输到外部 IPv4-Internet - 用于例如，用于索引。
数据中心网络设计的最后几次迭代使用了多层 Clos 拓扑，并且仅限 L3。 离开L2不久，我们松了一口气。 最后，我们的基础设施包括数十万个计算（服务器）实例。 前段时间集群规模最大是10万台服务器左右。 这主要是由于那些相同的集群级操作系统、调度程序、资源分配等如何工作。由于基础设施软件方面已经取得了进展，现在的目标规模是一个计算集群中大约有 100 万台服务器，并且我们有一个任务——能够构建网络工厂，在这样的集群中实现高效的资源池。
我们希望从数据中心网络中得到什么？ 首先，有大量廉价且分布相当均匀的带宽。 因为网络是骨干网，通过网络可以汇聚资源。 新的目标规模是一个集群中大约有100万台服务器。
当然，我们还想要一个可扩展且稳定的控制平面，因为在如此庞大的基础设施上，即使是简单的随机事件也会引起很多令人头痛的问题，而且我们不希望控制平面也给我们带来麻烦。 同时，我们希望最小化其中的状态。 病情越小，一切就越好、越稳定，也越容易诊断。
当然，我们需要自动化，因为手动管理这样的基础设施是不可能的，而且已经有一段时间是不可能的了。 我们需要尽可能多的运营支持，以及尽可能提供的 CI/CD 支持。
对于如此规模的数据中心和集群，支持增量部署和扩展而不中断服务的任务变得相当紧迫。 如果在一千台机器规模的集群上，也许接近一万台机器，它们仍然可以作为一个操作来推出——也就是说，我们正在计划扩展基础设施，并且添加几千台机器作为一个操作，那么十万台机器规模的集群不会像这样立即出现，它是经过一段时间建立起来的。 我们希望一直以来已经抽出的东西、已经部署的基础设施都应该可用。
我们曾经提出并留下的一项要求是：支持多租户，即虚拟化或网络分段。 现在我们不需要在网络结构级别执行此操作，因为分片已经转移到主机，这使得扩展对我们来说非常容易。 得益于 IPv6 和庞大的地址空间，我们不需要在内部基础设施中使用重复的地址；所有寻址都已经是唯一的。 并且由于我们对主机进行了过滤和网络分段，因此我们不需要在数据中心网络中创建任何虚拟网络实体。
非常重要的一点是我们不需要什么。 如果可以从网络中删除某些功能，那么生活就会变得更加轻松，并且通常会扩大可用设备和软件的选择范围，从而使诊断变得非常简单。
那么，什么是我们不需要的，什么是我们能够放弃的，在事情发生时并不总是充满喜悦，但在过程完成时却感到极大的宽慰？
首先，放弃L2。 我们不需要 L2，无论是真实的还是模拟的。 未使用主要是因为我们控制应用程序堆栈。 我们的应用程序是水平可扩展的，它们使用L3寻址，它们不太担心某些单独的实例已经消失，它们只是推出一个新的实例，不需要在旧地址上推出，因为有一个位于集群中的机器的单独级别的服务发现和监视。 我们不会将此任务委托给网络。 网络的工作是将数据包从 A 点传送到 B 点。
我们也不存在地址在网络内移动的情况，这需要进行监控。 在许多设计中，这通常需要支持虚拟机移动性。 我们不会在大型 Yandex 的内部基础设施中使用虚拟机的移动性，而且，我们认为即使这样做，也不应该在网络支持的情况下发生。 如果确实需要这样做，则需要在主机级别完成，并将可以迁移到overlay中的地址推送，以免接触或对underlay本身的路由系统（传输网络）进行太多动态更改。
我们不使用的另一种技术是多播。 如果你愿意的话，我可以详细告诉你原因。 这使生活变得更加容易，因为如果有人处理过它并准确地查看了多播控制平面的外观，除了最简单的安装之外，这将是一个非常令人头痛的问题。 更重要的是，例如，很难找到功能良好的开源实现。
最后，我们设计我们的网络，使其不会发生太大变化。 我们可以相信，路由系统中的外部事件流很小。
我们在开发数据中心网络时会遇到哪些问题以及需要考虑哪些限制？ 当然是成本。 可扩展性，我们想要增长到的水平。 需要在不停止服务的情况下进行扩展。 带宽、可用性。 监控系统和运营团队可以了解网络上发生的情况。 自动化支持——同样，尽可能多，因为不同的任务可以在不同的级别上解决，包括引入额外的层。 嗯，[可能]不依赖供应商。 尽管在不同的历史时期，取决于你看哪个部分，这种独立性是更容易或更难实现的。 如果我们看一下网络设备芯片的横截面，那么直到最近，如果我们也想要具有高吞吐量的芯片，那么谈论独立于供应商是非常有条件的。
我们将使用什么逻辑拓扑来构建我们的网络？ 这将是一个多层的 Clos。 事实上，目前没有真正的替代方案。 如果我们有大的基数开关，即使与现在更受学术兴趣的各种先进拓扑相比，Clos 拓扑也相当不错。
多级 Clos 网络的大致结构是怎样的？其中不同的元素分别是什么？ 首先，风起，给自己定位哪里是北，哪里是南，哪里是东，哪里是西。 这种类型的网络通常是由东西向流量非常大的网络建立的。 至于其余的元素，顶部是由较小交换机组装而成的虚拟交换机。 这就是递归构建Clos网络的主要思想。 我们采用某种基数的元素并将它们连接起来，这样我们得到的就可以被认为是具有更大基数的开关。 如果您需要更多，可以重复该过程。
例如，在使用两级 Clos 的情况下，当可以清楚地识别图中垂直的组件时，它们通常称为平面。 如果我们要构建一个具有三级骨干交换机的 Clos（所有这些交换机都不是边界或 ToR 交换机，仅用于传输），那么平面会看起来更复杂；两级交换机看起来就像这样。 我们将 ToR 块或叶子交换机以及与它们关联的第一级主干交换机称为 Pod。 Pod 顶部的 spin-1 级别的 Spine Switch 是 Pod 的顶部，即 Pod 的顶部。 位于整个工厂最顶层的交换机是工厂的顶层，Top of Fabric。
当然，问题出现了：Clos 网络已经建立了一段时间；这个想法本身通常来自经典电话、TDM 网络时代。 也许更好的事情已经出现，也许有些事情可以做得更好？ 是和不是。 理论上是的，在不久的将来实践中肯定不会。 因为有很多有趣的拓扑，其中一些甚至在生产中使用，例如，Dragonfly 用于 HPC 应用程序； 还有一些有趣的拓扑，例如 Xpander、FatClique、Jellyfish。 如果您最近查看 SIGCOMM 或 NSDI 等会议上的报告，您会发现相当多的关于替代拓扑的工作，这些拓扑具有比 Clos 更好的属性（一个或另一个）。
但所有这些拓扑都有一个有趣的特性。 它阻止了它们在数据中心网络中的实施，我们正试图在商品硬件上构建这些网络，并且花费相当合理的资金。 遗憾的是，在所有这些替代拓扑中，大部分带宽无法通过最短路径访问。 因此，我们立即失去了使用传统控制平面的机会。
理论上，问题的解决方案是已知的。 例如，这些是使用 k-最短路径修改链路状态，但是，同样，没有这样的协议可以在生产中实现并在设备上广泛使用。
此外，由于大部分容量无法通过最短路径访问，因此我们需要修改的不仅仅是控制平面来选择所有这些路径（顺便说一句，这在控制平面中明显有更多状态）。 我们仍然需要修改转发平面，并且通常至少需要两个附加功能。 这是一次性做出有关数据包转发的所有决策的能力，例如在主机上。 事实上，这就是源路由，有时在互连网络的文献中这被称为一次性转发决策。 自适应路由是我们在网络元素上需要的功能，例如，归结为我们根据队列上最小负载的信息选择下一跳。 作为示例，其他选项也是可能的。
因此，这个方向很有趣，但是，遗憾的是，我们现在还不能应用它。
好的，我们确定了 Clos 逻辑拓扑。 我们将如何扩展它？ 让我们看看它是如何工作的以及可以做什么。
在 Clos 网络中，我们可以通过某种方式改变两个主要参数并获得某些结果：元素的基数和网络中的层数。 我有一张示意图，说明两者如何影响尺寸。 理想情况下，我们将两者结合起来。
可以看出，Clos网络的最终宽度是南基数各级脊椎交换机的乘积，我们有多少个链路，它如何分支。 这就是我们扩展网络规模的方式。
关于容量，特别是在 ToR 交换机上，有两种扩展选项。 我们可以在保持一般拓扑的同时使用更快的链路，或者可以添加更多平面。
如果你看一下 Clos 网络的扩展版本（在右下角）并返回到下面这张 Clos 网络的图片......
...那么这是完全相同的拓扑，但在这张幻灯片上，它折叠得更紧凑，并且工厂的平面相互叠加。 这是相同的。
从数字上看，Clos 网络的扩展是什么样的？ 在这里，我提供了有关可以获得的网络最大宽度的数据，以及机架、ToR 交换机或叶子交换机的最大数量（如果它们不在机架中），我们可以获得的数据取决于我们用于脊柱级别的交换机基数，以及我们使用了多少级别。
以下是我们可以拥有的机架数量、服务器数量，以及基于每个机架 20 kW 计算的所有这些设备的大约消耗量。 早些时候我提到我们的目标是集群规模约为 100 万台服务器。
可以看出，在整个设计中，有两个半选项值得关注。 有一个带有两层主干和 64 端口交换机的选项，但有点不足。 然后，还有适合两级 128 端口（基数 128）主干交换机或三级基数 32 交换机的完美选择。 在所有情况下，如果有更多的基数和更多的层，您可以构建一个非常大的网络，但如果您考虑预期的消耗，它通常是千兆瓦。 铺设电缆是可能的，但我们不太可能在一个地点获得那么多的电力。 如果你查看数据中心的统计数据和公开数据，你会发现很少有数据中心的估计容量超过150兆瓦。 较大的通常是数据中心园区，几个大型数据中心彼此距离很近。
还有一个重要参数。 如果您查看左栏，就会发现可用带宽列在那里。 很容易看出，在 Clos 网络中，很大一部分端口用于将交换机相互连接。 可用带宽，即有用的带宽，是可以向外部提供给服务器的东西。 当然，我谈论的是条件端口，特别是频段。 通常，网络内的链接比通往服务器的链接更快，但是对于每单位带宽，只要我们可以将其发送到我们的服务器设备，网络本身仍然有一些带宽。 我们制作的关卡越多，向外部提供该条带的具体成本就越高。
而且，即使是这个额外的频带也不完全相同。 虽然跨度很短，但我们可以使用 DAC（直接连接铜缆，即双芯电缆）或多模光学器件，这些器件的成本或多或少是合理的。 一旦我们转向更长的跨度 - 通常，这些都是单模光学器件，并且这种额外带宽的成本会显着增加。
再次回到上一张幻灯片，如果我们创建一个没有超额订阅的 Clos 网络，那么很容易查看图表，了解网络是如何构建的 - 添加每一级主干交换机，我们重复位于底部。 Plus 级别 - 加上与上一级相同的频段、交换机上相同数量的端口以及相同数量的收发器。 因此，非常需要最小化主干交换机的级别数量。
根据这张图，很明显我们确实希望构建基数为 128 的开关之类的东西。
这里原则上和我刚才说的都是一样的，这是一个幻灯片，供以后考虑。
我们可以选择哪些选项作为此类开关？ 对于我们来说，这是一个非常令人高兴的消息，现在这样的网络终于可以建立在单芯片交换机上。 这非常酷，它们有很多不错的功能。 例如，它们几乎没有内部结构。 这意味着它们更容易断裂。 它们以各种方式断裂，但幸运的是它们完全断裂。 在模块化设备中，存在大量故障（非常令人不快），从邻居和控制平面的角度来看，它似乎正在工作，但例如，部分结构已丢失并且无法工作满负荷运转。 并且它的流量是基于它功能齐全的事实来平衡的，我们可能会过载。
或者，例如，背板出现问题，因为模块化设备内部还有高速SerDes - 内部非常复杂。 转发单元之间的符号要么同步，要么不同步。 一般来说，任何由大量元件组成的生产性模块化设备通常在其内部包含相同的 Clos 网络，但诊断起来非常困难。 通常，即使是供应商自己也很难诊断。
并且它有大量的故障场景，其中设备性能下降，但并未完全脱离拓扑。 由于我们的网络很大，所以会积极使用相同元素之间的平衡，网络非常规则，也就是说，一条路径上的一切都井然有序，与另一条路径没有什么不同，对我们来说，简单地失去一些元素会更有利可图。拓扑中的设备，而不是最终陷入其中一些设备似乎可以工作，但其中一些却不能工作的情况。
单芯片设备的下一个优点是它们发展得更好更快。 他们也往往具有更好的能力。 如果我们将大型组装结构围成一圈，那么相同速度的每个机架单元的端口容量几乎是模块化设备的两倍。 围绕单芯片构建的设备明显比模块化设备便宜并且消耗更少的能量。
但是，当然，这都是有原因的，也有缺点。 首先，基数几乎总是小于模块化设备的基数。 如果我们能够获得一款围绕一个芯片构建的具有 128 个端口的设备，那么我们现在就可以毫无问题地获得具有数百个端口的模块化设备。
这是转发表的明显较小的尺寸，并且通常与数据平面可扩展性相关的所有内容。 浅缓冲区。 而且，通常，功能相当有限。 但事实证明，如果您了解这些限制并及时注意规避它们或只是将它们考虑在内，那么这并不那么可怕。 事实上，基数更小的事实在最近终于出现的基数为 128 的设备上不再是问题；我们可以构建两层脊柱。 但仍然不可能建造出任何我们感兴趣的小于两个的东西。 通过一级，可以获得非常小的簇。 甚至我们之前的设计和要求仍然超出了他们。
事实上，如果解决方案突然濒临崩溃，仍然有办法扩展。 由于连接服务器的最后（或第一个）最低级别是 ToR 交换机或叶子交换机，因此我们不需要将一个机架连接到它们。 因此，如果解决方案达不到一半左右，您可以考虑简单地在较低级别使用基数较大的交换机，并将例如两个或三个机架连接到一个交换机中。 这也是一种选择，它有其成本，但效果很好，当您需要达到大约两倍的大小时，它可能是一个很好的解决方案。
总而言之，我们正在构建一个具有两层主干和八个工厂层的拓扑。
物理学会发生什么？ 非常简单的计算。 如果我们有两级主干，那么我们只有三级交换机，并且我们预计网络中将存在三个电缆段：从服务器到叶交换机、到主干 1、到主干 2。用途包括双轴、多模、单模。 在这里，我们需要考虑哪些带材可用、成本是多少、物理尺寸是多少、我们可以覆盖的跨度以及我们将如何升级。
从成本上来说，一切都可以排队。 双轴比有源光学器件便宜得多，比多模收发器便宜，如果您从末端每次飞行都使用它，比 100 Gb 交换机端口便宜一些。 而且，请注意，它的成本低于单模光学器件，因为在需要单模的航班上，在数据中心，由于多种原因，使用 CWDM 是有意义的，而并行单模 (PSM) 工作起来不太方便获得的纤维非常大，如果我们专注于这些技术，我们大约会得到以下价格等级。
另请注意：不幸的是，不太可能使用拆卸的 100 至 4x25 多模端口。 由于SFP28收发器的设计特点，它并不比28 Gbit QSFP100便宜多少。 而且这种针对多模的反汇编效果不太好。
另一个限制是，由于计算集群的规模和服务器的数量，我们的数据中心的物理规模很大。 这意味着至少一次飞行必须使用单一模组完成。 同样，由于 Pod 的物理尺寸，无法运行两个跨度的双轴（铜缆）。
因此，如果我们优化价格并考虑到该设计的几何形状，我们将使用 CWDM 获得一跨双轴、一跨多模和一跨单模。 这考虑了可能的升级路径。
这就是最近的情况，我们的前进方向和可能性。 至少，如何向多模和单模迈向 50 吉比特 SerDes 是很清楚的。 此外，如果您看看现在和未来 400G 的单模收发器中的内容，通常即使 50G SerDes 从电气侧到达，每通道 100 Gbps 也已经可以进入光学。 因此，很可能不会过渡到 50 个，而是过渡到 100 Gigabit SerDes 和每通道 100 Gbps，因为根据许多供应商的承诺，预计它们很快就会上市。 50G SerDes 最快的时期似乎不会很长，因为第一批 100G SerDes 几乎将于明年推出。 一段时间后，它们可能会值合理的钱。
关于物理选择的另一个细微差别。 原则上，我们已经可以使用 400G SerDes 来使用 200 或 50 个千兆端口。 但事实证明这没有多大意义，因为正如我之前所说，我们希望开关上有一个相当大的基数，当然这是在合理的范围内。 我们想要128。如果我们的芯片容量有限并且我们提高了链路速度，那么基数自然会减小，没有奇迹。
我们可以使用飞机来增加总容量，并且没有特殊成本；我们可以增加飞机的数量。 如果我们失去了基数，我们将不得不引入一个额外的级别，因此在当前情况下，在每个芯片当前最大可用容量的情况下，事实证明使用 100 Gb 端口更有效，因为它们允许您以获得更大的基数。
下一个问题是物理是如何组织的，但从电缆基础设施的角度来看。 事实证明，它的组织方式相当有趣。 叶交换机和第一级主干之间的布线 - 那里没有太多链接，一切都构建得相对简单。 但如果我们采用一个平面，内部发生的情况是我们需要将第一层的所有脊椎与第二层的所有脊椎连接起来。
另外，通常，人们对数据中心内部的外观有一些期望。 例如，我们真的很想将电缆捆成一束，然后将它们拉起来，以便将一个高密度配线架完全纳入一个配线架中，这样就不会产生长度问题。 我们设法解决了这个问题。 如果您最初查看逻辑拓扑，您会发现各个平面是独立的，每个平面都可以单独构建。 但是，当我们添加这样的捆绑并希望将整个配线架拖入配线架时，我们必须将不同的平面混合在一个捆绑中，并引入光交叉连接形式的中间结构，以将它们从组装方式重新包装在一个网段上，如何在另一网段上收集它们。 因此，我们获得了一个很好的功能：所有复杂的切换都不会超出机架。 当您需要将某些东西非常牢固地交织在一起时，“展开平面”（有时在克洛斯网络中称为“展开平面”），所有东西都集中在一个机架内。 我们没有高度拆卸、细化到单个链接、在机架之间进行切换。
这就是从电缆基础设施的逻辑组织的角度来看的情况。 在左图中，多色块描绘了第一级主干交换机块，每块八块，以及来自它们的四束电缆，这些电缆与来自主干 2 交换机块的电缆束相交。 。
小方块表示交叉点。 左上角是每个此类交叉点的细分，这实际上是一个 512 x 512 端口交叉连接模块，它重新包装电缆，使它们完全进入一个机架，其中只有一个 spin-2 平面。 右边这张图的扫描更详细一点，涉及到spine-1级别的几个Pod，以及它是如何打包在交叉连接中的，如何到达spine-2级别的。
这就是它的样子。 尚未完全组装的 spin-2 支架（左侧）和交叉连接支架。 不幸的是，那里没什么可看的。 整个结构目前正在我们正在扩建的大型数据中心之一中部署。 这是一项正在进行中的工作，它会看起来更好，也会填写得更好。
一个重要的问题：我们选择了逻辑拓扑并构建了物理结构。 控制平面会发生什么？ 从操作经验来看，有很多报告表明链路状态协议很好，很高兴与它们合作，但不幸的是，它们在密集连接的拓扑上不能很好地扩展。 有一个主要因素可以防止这种情况发生——这就是链路状态协议中洪泛的工作原理。 如果您仅采用洪泛算法并查看我们的网络结构，您会发现每一步都会有非常大的扇出，并且它只会用更新淹没控制平面。 具体来说，这种拓扑与链路状态协议中的传统洪泛算法的混合非常差。
选择是使用 BGP。 关于在大型数据中心使用 BGP 的 RFC 7938 中描述了如何正确准备。 基本思想很简单：每个主机的前缀数量最少，通常网络上的前缀数量最少，如果可能，使用聚合，并抑制路径搜索。 我们想要非常仔细、非常受控的更新分发，这就是所谓的“Valley Free”。 我们希望更新在通过网络时一次性部署。 如果它们起源于底部，它们就会上升，展开的次数不会超过一次。 不应有锯齿状。 锯齿形非常糟糕。
为此，我们使用足够简单的设计来使用底层 BGP 机制。 也就是说，我们使用运行在链路本地上的eBGP，自治系统分配如下：ToR上的自治系统，一个Pod的整个spine-1交换机块上的自治系统，以及整个Top上的一般自治系统织物。 不难看出，即使 BGP 的正常行为也能为我们提供所需的更新分发。
当然，寻址和地址聚合的设计必须与路由的构建方式兼容，从而确保控制平面的稳定性。 传输中的 L3 寻址与拓扑紧密相关，因为如果没有拓扑，就不可能实现聚合；否则，各个地址将渗入路由系统。 不幸的是，另一件事是聚合与多路径不能很好地混合，因为当我们有多路径并且有聚合时，一切都很好，当整个网络健康时，其中不会出现故障。 不幸的是，一旦网络中出现故障并且拓扑的对称性丢失，我们就可以到达宣布该单元的点，从这里我们无法进一步到达我们需要去的地方。 因此，最好在没有更多多路径的地方进行聚合，在我们的例子中，这些是 ToR 交换机。
事实上，可以聚合，但要小心。 如果我们能够在网络故障发生时进行受控分解。 但这是一项相当困难的任务，我们甚至想知道是否可以做到这一点，是否可以添加额外的自动化和有限状态机来正确地启动 BGP 以获得所需的行为。 不幸的是，处理极端情况非常不明显且复杂，并且通过将外部附件附加到 BGP 并不能很好地解决此任务。
在 RIFT 协议框架内已经完成了这方面非常有趣的工作，这将在下一份报告中讨论。
另一件重要的事情是数据平面如何在密集拓扑中扩展，在密集拓扑中我们有大量的替代路径。 在这种情况下，使用了几个附加的数据结构：ECMP 组，它们依次描述下一跳组。
在正常工作的网络中，没有故障的情况下，当我们上Clos拓扑时，只使用一组就足够了，因为所有非本地的东西都默认描述了，我们就可以上去。 当我们从上到下向南走时，所有路径都不是 ECMP，它们是单路径路径。 一切安好。 问题是，经典 Clos 拓扑的独特之处在于，如果我们查看结构的顶部，在任何元素处，只有一条路径可以到达下面的任何元素。 如果沿着这条路径发生故障，那么工厂顶部的这个特定元素对于位于损坏路径后面的那些前缀来说将变得无效。 但对于其余的它是有效的，我们必须解析 ECMP 组并引入一个新的状态。
现代设备上的数据平面可扩展性是什么样的？ 如果我们进行 LPM（最长前缀匹配），一切都很好，超过 100k 前缀。 如果我们谈论的是下一跳组，那么一切都会更糟，有 2-4 千个。 如果我们讨论的是包含下一跳（或邻接）描述的表，则该值介于 16k 到 64k 之间。 这可能会成为一个问题。 这里我们谈到一个有趣的题外话：数据中心中的 MPLS 发生了什么？ 原则上，我们想这么做。
发生了两件事。 我们在主机上进行了微分段；我们不再需要在网络上进行此操作。 不同供应商的支持并不是很好，尤其是在带有 MPLS 的白盒上进行开放实现。 不幸的是，MPLS（至少其传统实现）与 ECMP 的结合非常差。 这就是原因。
这就是 IP 的 ECMP 转发结构的样子。 大量前缀可以使用相同的组和相同的下一跳块（或邻接，这在不同设备的不同文档中可能有不同的称呼）。 重点是，这被描述为传出端口以及将 MAC 地址重写到的端口，以便到达正确的下一跳。 对于 IP，一切看起来都很简单，您可以为同一组、同一下一跃点块使用大量前缀。
经典的MPLS架构意味着，根据传出接口，标签可以被重写为不同的值。 因此，我们需要为每个输入标签保留一个组和一个下一跳块。 可惜的是，这无法扩展。
很容易看出，在我们的设计中，如果我们从脊柱 4000 转向脊柱 64，我们需要大约 1 个 ToR 交换机，最大宽度为 2 个 ECMP 路径。 如果只有一个带有 ToR 的前缀消失，我们几乎无法进入一张 ECMP 组表，并且我们根本无法进入下一跳表。
这并非全无希望，因为像分段路由这样的架构涉及全局标签。 从形式上来说，有可能再次崩溃所有这些下一跳块。 为此，您需要一种通配符类型操作：获取一个标签并将其重写为相同的标签，而无需特定值。 但不幸的是，这在可用的实现中并不存在。
最后，我们需要将外部流量引入数据中心。 怎么做？ 此前，流量是从上方引入 Clos 网络的。 也就是说，有边缘路由器连接到结构顶部的所有设备。 该解决方案适用于中小型尺寸。 不幸的是，为了以这种方式将流量对称地发送到整个网络，我们需要同时到达结构顶部的所有元素，并且当它们超过一百个时，事实证明我们还需要一个大的边缘路由器上的基数。 一般来说，这是要花钱的，因为边缘路由器功能更多，其上的端口会更贵，而且设计也不是很美观。
另一种选择是从下面启动此类流量。 很容易验证 Clos 拓扑的构建方式，即来自下方（即来自 ToR 侧）的流量在两次迭代中均匀分布在整个结构顶部的各个级别之间，从而加载整个网络。 因此，我们引入了一种特殊类型的 Pod，即 Edge Pod，它提供外部连接。
还有一种选择。 例如，Facebook 就是这么做的。 他们称之为 Fabric Aggregator 或 HGRID。 正在引入额外的主干级别来连接多个数据中心。 如果我们没有额外的功能或接口处的封装变化，这种设计是可能的。 如果它们是额外的接触点，那就很困难。 通常，数据中心有更多的功能和一种分隔不同部分的膜。 将这样的膜做得很大是没有意义的，但如果由于某种原因确实需要它，那么考虑将其拿走、使其尽可能宽并将其转移到宿主的可能性是有意义的。 例如，许多云运营商就是这样做的。 他们有覆盖层，他们从主机开始。
我们看到了哪些发展机遇？ 首先，改进对 CI/CD 管道的支持。 我们希望以我们测试的方式飞行并测试我们的飞行方式。 这效果不太好，因为基础设施很大，不可能复制它进行测试。 您需要了解如何将测试元素引入生产基础设施而不放弃它。
更好的仪器和更好的监控几乎从来都不是多余的。 整个问题是努力和回报的平衡。 如果你能通过合理的努力添加它，那就太好了。
网络设备的开放操作系统。 更好的协议和更好的路由系统，例如 RIFT。 还需要研究使用更好的拥塞控制方案，并可能至少在某些时候在集群内引入 RDMA 支持。
展望未来，我们需要先进的拓扑，可能还需要使用更少开销的网络。 在新鲜事物中，最近有关于 HPC Cray Slingshot 结构技术的出版物，该技术基于商用以太网，但可以选择使用更短的接头。 结果，减少了开销。
一切都应该尽可能简单，但不能过于简单。 复杂性是可扩展性的敌人。 简单和规则的结构是我们的朋友。 如果你可以在某个地方进行横向扩展，那就去做吧。 总的来说，现在参与网络技术是一件很棒的事情。 有很多有趣的事情正在发生。 谢谢。
来源： habr.com