Introducing data center fabric, the next-generation Facebook data center network

介绍数据中心Fabric：下一代Facebook数据中心网络

作者/机构: Alexey Andreyev (Facebook)

A1 主要贡献

本文介绍了Facebook为其新一代数据中心（从Altoona设施开始）设计并成功部署的全新网络架构——数据中心Fabric。

核心问题:
随着Facebook用户和服务的指数级增长，其内部“机器到机器”的流量每不到一年就翻一番。原有的基于“集群（cluster）”的网络架构遇到了瓶颈：
1. 规模限制：集群的规模受限于大型、高端口密度核心交换机的物理端口数，而这类设备仅由少数供应商提供，且升级到更高带宽时端口密度往往不足。
2. 运维复杂性：大型核心交换机是专有设备，其内部架构复杂，需要专门的软硬件知识进行运维和故障排查，且单点故障影响范围巨大。
3. 带宽平衡难题：在集群规模、机架带宽和跨集群带宽之间维持长期平衡非常困难。传统设计中，跨集群带宽远小于集群内带宽，这限制了需要跨集群通信的分布式应用的扩展。

研究目标:
为了解决上述问题，Facebook的目标是设计一种全新的数据中心网络架构，该架构应能：
1. 打破集群边界：将整个数据中心大楼构建成一个统一的、高性能的网络，而不是一个由多个分层超售的集群组成的系统。
2. 实现快速扩展：提供清晰、简便的路径来快速部署网络和扩展性能，避免每次扩容都对现有基础设施进行大规模的定制化改造。
3. 简化运维：尽管规模和增长速度惊人，但仍要保持网络基础设施的简单性，以便小型高效的工程师团队能够进行管理。

创新点（核心贡献）:
本文提出的数据中心Fabric架构是其核心创新。其主要思想是采用解耦（disaggregated）的方法，将网络分解为小型、标准化的构建单元，并在此基础上构建大规模、高性能、易于扩展的网络。具体创新点如下：
1. 模块化设计：引入了“Pod”作为网络的基本单元。一个Pod是一个小型的三层微集群（仅包含48个服务器机架），由四个Fabric交换机提供服务。这种标准化的“网络乐高”易于在数据中心内灵活部署。
2. 统一的高性能互联：通过创建四个独立的“Spine平面（spine planes）”，将数据中心内所有的Pod均匀地连接起来。每个Pod的Fabric交换机都会连接到其本地平面内的每一个Spine交换机。这种设计为整个数据中心的任意机架之间提供了统一的、高带宽、统计上无阻塞的连接能力。
3. 可扩展性和灵活性：Fabric架构可以在多个维度上独立、平滑地扩展。需要更多计算资源时，增加服务器Pod；需要更多内部网络带宽时，在所有平面上增加Spine交换机；需要更多外部连接时，增加Edge Pod。
4. 软硬件解耦与自动化：网络采用全三层（Layer 3）设计，并仅使用标准的BGP4协议，同时开发了集中式控制器进行路由覆盖。这种设计简化了对交换机的要求，使其可以使用来自多个供应商的商用芯片和中型交换机。同时，配套的“自顶向下”的自动化工具链实现了网络的快速部署、配置和运维，大大降低了运维复杂性。
5. 平滑过渡：为了与现有系统兼容，Fabric在物理上打破了集群，但在逻辑上保留了“虚拟集群”的概念，使得上层应用和管理系统无需改造即可无缝迁移到新架构上。

A3 背景知识与设计原则

集群的局限性

• 过往的集群架构。我们之前的数据中心网络是使用集群构建的。一个集群是一个大型部署单元，包含数百个服务器机柜，其机架顶（TOR）交换机汇聚在一组大型、高基数的集群交换机上。三年多前，我们开发了一种可靠的三层“四立柱（four-post）”架构，提供3+1的集群交换机冗余，其容量是我们之前集群设计的10倍。尽管这种架构在早起的数据中心建设中很有效，但以集群为中心的架构有其局限性。

• 集群规模受限于核心交换机。首先，集群的规模受限于集群交换机的端口密度。为了构建最大的集群，我们需要最大的网络设备，而这些设备仅能从有限的几家供应商处获得。此外，对单台设备大量端口的需求，与提供尽可能高带宽基础设施的愿望是相悖的。向下一代接口速度的演进并不会很快就以XXL的密度出现。在运维上，那些更大、更前沿的设备对我们来说也并非更优。它们拥有专有的内部架构，需要大量的特定平台软硬件知识才能操作和排查故障。由于数据中心的大片区域依赖于少数几台设备，硬件和软件故障的影响也可能非常巨大。

• 集群内外的带宽平衡难题。更困难的是在集群规模、机架带宽和出集群带宽之间维持一个长期的最佳平衡。整个“集群”的概念源于网络的限制——它是由将大量计算资源（服务器机架）放置在大容量集群交换机所支持的高性能网络区域内的需求所决定的。传统上，跨集群连接是超售的，集群间的可用带宽远少于集群内部。这假设并进而要求大多数应用内部的通信都发生在集群内部。然而，我们的应用通过分布式来扩展，不应被这些紧密的边界所束缚。在一个典型的数据中心里有许多集群，机器间的流量在它们之间增长，而不仅仅是在内部。分配更多的端口来容纳跨集群流量会减少集群的规模。随着快速和动态的增长，这种平衡工作永无止境——除非你改变规则。

A2 方法细节

介绍Fabric

• 新一代网络的设计目标。对于我们的下一代数据中心网络设计，我们挑战自己，要将整个数据中心大楼打造成一个高性能网络，而不是一个分层超售的集群系统。我们还希望为网络的快速部署和性能扩展提供一条清晰简单的路径，而不需要每次需要构建更多容量时都拆除或定制化改造庞大的旧有基础设施。

• 采用解耦方法构建网络。为了实现这一目标，我们采取了一种解耦的方法：我们没有使用大型设备和集群，而是将网络分解成小型的相同单元——服务器pod，并在数据中心的所有pod之间创建了统一的高性能连接。

• Pod作为网络的基本单元。Pod并没有什么特别之处——它就像一个三层的微集群。Pod不是由任何硬性的物理属性定义的；它只是我们新Fabric上的一个标准“网络单元”。每个pod由一组我们称为fabric交换机的四台设备提供服务，保持了我们当前用于服务器机架TOR上行链路的3+1四立柱架构的优势，并可在需要时进一步扩展。每个TOR目前有4个40G上行链路，为一个机架的10G连接服务器提供总计160G的带宽容量。
  

  

• Pod的小尺寸优势。不同之处在于我们新单元的尺寸要小得多——每个pod只有48个服务器机架，并且这种规格对于所有pod都是相同的。它是一个高效的构建块，能很好地适应各种数据中心楼层平面图，并且只需要基本的中型交换机来汇聚TOR。fabric交换机较低的端口密度使其内部架构非常简单、模块化和坚固，并且有多种易于从多个来源找到的选择。

• Pod的连接方式和无阻塞设计。另一个显著的不同是pod如何连接在一起形成数据中心网络。对于每个连接到TOR的下行链路端口，我们在pod的fabric交换机上保留了等量的上行链路容量，这使我们能够将网络性能扩展到统计上的无阻塞。

• Spine平面的设计。为了实现全楼范围的连接，我们创建了四个独立的spine交换机“平面”，每个平面内部最多可扩展到48台独立设备。每个pod的每台fabric交换机都连接到其本地平面内的每台spine交换机。Pod和平面共同构成了一个模块化的网络拓扑，能够容纳数十万台10G连接的服务器，扩展到数Pb的对分带宽，并以无超售的机架到机架性能覆盖我们的数据中心大楼。
  

  

• 外部连接设计。对于外部连接，我们为fabric配备了数量灵活的edge pod，每个pod能够为骨干网和我们数据中心站点上的后端楼间fabric提供高达7.68Tbps的带宽，并且可以在相同的设备形态下扩展到100G及更高的端口速度。

• 模块化扩展能力。这种高度模块化的设计使我们能够在一个简单而统一的框架内，快速扩展任何维度的容量。当我们需要更多计算容量时，我们增加服务器pod。当我们需要更多fabric内部网络容量时，我们在所有平面上增加spine交换机。当我们需要更多fabric外部连接时，我们增加edge pod或扩展现有edge交换机上的上行链路。

我们是如何做到的

当我们最初考虑构建fabric时，由于设备和链路的数量，它看起来复杂且令人生畏。然而，我们最终实现的设计比我们惯常的集群设计更简单、更优雅，并且在运维上更高效。以下是我们实现这一目标的过程。

网络技术

• 采用“自顶向下”的设计方法。我们采取了“自顶向下”的方法——首先从整体网络的角度进行思考，然后将必要的操作转化为单个拓扑元素和设备。

• 使用BGP4作为唯一路由协议。我们能够使用标准的BGP4作为唯一的路由协议来构建我们的fabric。为了保持简单，我们只使用了最少的必要协议特性。这使我们能够利用分布式控制平面在收敛方面的性能和可扩展性，同时提供紧密和精细的路由传播管理，并确保与广泛的现有系统和软件兼容。与此同时，我们开发了一个集中的BGP控制器，它能够通过纯软件决策来覆盖fabric上的任何路由路径。我们将这种灵活的混合方法称为“分布式控制，集中式覆盖”。

• 全三层网络设计。网络是全三层的——从TOR上行链路到边缘。和我们所有的网络一样，它是双栈的，原生支持IPv4和IPv6。我们设计的路由方式最小化了RIB和FIB资源的使用，使我们能够利用商用芯片，并保持对交换机的要求尽可能基础。

• 利用ECMP进行流量管理。对于大多数流量，我们的fabric大量使用基于流哈希的等价多路径（ECMP）路由。在Facebook数据中心中，存在着数量巨大且多样的并发流，从统计上看，我们观察到负载在所有fabric链路上几乎是理想的分布。为了防止偶然的“大象流”占据并降低端到端路径的性能，我们使网络具有多速率——所有交换机之间使用40G链路，而服务器则通过TOR上的10G端口连接。我们也有服务器端的手段来“哈希掉”并绕过故障点，如果它们发生的话。

渐进式可扩展性

• 清晰可预测的扩展路径。虽然我们需要一条清晰且可预测的路径来扩展我们的容量，但我们不一定要求在每个部署中从第一天起就拥有一个无阻塞的网络。

• 分阶段实现无阻塞。为了实现无缝的增长能力，我们将整个网络设计和规划为一个端到端的无超售环境。我们为完整的fabric设备园区分配了所有必要的物理资源，并预先构建了所有耗时的被动基础设施“骨架”组件。但我们目前的起点是机架到机架4:1的fabric超售比，每个平面只有12台spine交换机，而最多可以有48台。这个水平使我们能够在全楼范围内实现与我们之前在集群内部所拥有的相同的转发能力。

• 简化的未来扩容。当需求来临时，我们可以以精细的步骤增加此容量，或者我们可以一次性快速跳转到2:1的超售比，甚至完全1:1的无超售状态。我们所需要做的就是在每个平面增加更多的spine设备，而所有用于此的物理和逻辑资源都已就位，使其成为一个快速简单的操作。

物理基础设施

• 物理基础设施的简化。尽管规模庞大，涉及数十万根光纤，但fabric的物理和布线基础设施远没有逻辑网络拓扑图上看起来那么复杂。Facebook的多个基础设施团队共同协作，为fabric网络优化了我们的第三代数据中心建筑设计，缩短了布线长度，并实现了快速部署。我们的Altoona数据中心是这种新建筑布局的第一个实现。
  

  

• 优化的物理布局。从服务器机架或数据大厅MDF（主配线架）的角度来看，几乎没有变化——TOR只是连接到它们的四个独立的汇聚点，和之前的集群一样。对于spine和edge设备，我们在大楼的中心设计了特殊的独立位置，我们称之为BDF（楼宇配线架）室。BDF在建筑启用的早期阶段就被建造并预先装备好fabric。然后，数据大厅在建成后以相同的方式连接到BDF，这极大地减少了网络部署时间。

• 简化的布线设计。从数据大厅MDF的fabric交换机到BDF室的spine交换机的大量光纤实际上是简单且相同的“直线”干线。所有fabric的复杂性都局限在BDF内部，在这里它非常易于管理。我们将每个spine平面及其相应的干线和路径视为一个故障域，我们可以随时安全地将其停止服务而不会对生产产生影响。为了进一步优化光纤长度，我们还将骨干网设备放置在MPOE（最小入口点）房间，直接位于fabric BDF的上方。这使我们能够在一个简单且物理冗余的拓扑中使用短的垂直干线。

• 标准化和自动化布线。此外，BDF中的所有fabric spine平面在设计上都是相同的克隆，并且布线在每个独立的spine平面内部进行本地化。端口布局是可视化的和重复的，所有端口映射都由我们的软件自动生成和验证。

• 部署效率的提升。所有这些使得fabric的部署和布线成为一项平滑、高效且几乎无误的工作，并且是网络需求如何积极影响建筑设计的一个很好的例子。最终，Altoona站点的网络启用时间——从混凝土地面到交换机中有比特流通过——被大大缩短了。

自动化

• 自动化对大规模Fabric的必要性。一个大型的fabric网络——它具有更复杂的拓扑和更多的设备与互连——绝对不是那种可以现实地通过手动方式配置和操作的环境。但是，拓扑的统一性有助于实现更好的可编程性，我们可以使用基于软件的方法来为网络引入更多的自动化和模块化。

• “自顶向下”的自动化理念。为了自动化fabric，我们调整了我们的思维方式，使其更加“自顶向下”——整体网络逻辑优先，然后才是单个设备和组件——从具体的平台细节中抽象出来，一次性操作大量相似的组件。我们使我们的工具能够处理不同的fabric拓扑和形态，创建了一个可以适应不同规模数据中心的模块化解决方案。

• 硬件与自动化的解耦。同样重要的是硬件和自动化的解耦——fabric的转发平面实际上独立于我们的工具，反之亦然。这使我们能够在不对软件进行原则性改变的情况下更换任何特定的组件，并使更广泛的硬件平台与我们的工具兼容。

• 配置工作流。配置工作在fabric层面进行——而不是设备层面——使用定义网络、其构建块和路由逻辑所需的最少数量的高级设置。所有具体的地址、路由策略、端口映射和与供应商无关的组件参数都从这些高级设置中派生出来，渲染成适用的平台特定形式，并推送到设备上。对于每个单独的平台，我们只需要定义几个简单的操作和基本的语法模板。

• 自动化部署和发现。为了加快配置和变更，我们建立了简单而强大的机制来自动在设备上部署配置，并发现任何新设备在fabric中的角色。这使我们能够以几乎无人值守的模式，高效地并行部署大量的fabric组件。

• 监控和故障排查的范式转变。fabric的巨大规模也从根本上改变了我们监控和故障排查的方式。有很多组件和链路，但它们中的大多数行为相同。我们从网络中收集了大量的统计数据，但对于故障排查，我们主要关心基线和异常值，并且更多地依赖于主动审计问题、优先级驱动的警报和自动修复，而不是盯着图表看。对于每种类型的组件，我们都定义了自动规则和一键式操作，以优雅地将其停止服务或重新投入生产。fabric中的单个组件实际上并不重要，硬性故障的东西不需要立即修复。整体行为远比单个盒子或链路重要，这是一个范式的转变。

• 新范式的实际应用。以下是这在实践中的意义：

  • 当自动发现的问题是基础的和已知的，我们进行自动修复和/或警报。
  • 当发生未知事件时，我们发出警报进行修复，然后将其变成我们的机器人下次发生时可以修复的事情。
  • 当检测到故障时，机器会绕路。
  • 当我们需要隔离问题时，我们比较行为并关联事件。
  • 当我们需要快速的高层评估时，我们使用热图。
  • 当我们需要深入分析或观察趋势时，所有数据都在我们掌握之中。

透明过渡

• “集群”概念的演变。如前所述，“集群”的概念最初源于网络的限制。但此后它已演变为一个更广泛的含义，作为一个部署和容量单位。许多其他系统和工作流程都是围绕这个概念设计的，跨越多个不同的技术领域。从早期开始，我们就意识到整个世界不可能在一夜之间被改造。我们需要确保我们所有的系统和操作都能继续平稳运行，尽管底层的网络不同。

• 通过“虚拟集群”实现向后兼容。为了使向fabric的过渡无缝并允许向后兼容，我们保留了“集群”的逻辑概念，但我们现在将其实现为pod的集合。从网络的角度来看，一个集群已经变成只是fabric上的一个虚拟“命名区域”，而构成一个集群的pod在物理上可以位于数据中心楼层的任何地方。但对于所有其他目的，这种“虚拟集群”中的命名和寻址属性与我们正在运行的物理集群园区完全兼容，使得它们对于非网络团队和服务器管理自动化系统来说，外观和感觉完全相同。

• 新架构带来的灵活性。fabric为在数据中心的不同区域——任何有空闲pod的地方——定位“虚拟集群”的计算资源引入了新的灵活性。不再需要将集群限制在特定的连续物理空间内，新的集群大小可以像整个建筑一样大，也可以像一个pod一样小。但我们并没有强迫立即进行大的运营变更——我们只是使其能够根据需要利用这些新的好处成为可能。

• 平滑的部署结果。结果是，我们能够在不中断生产的情况下，推出全新的网络架构。有一个显著的区别：fabric的部署实际上比同等数量的集群更快、更容易。

A4 实验环境与结果

部署环境

• 硬件配置：
  • 服务器与机架：服务器通过10G端口连接到机架顶（TOR）交换机。
  • 交换机：
    • TOR交换机：每个TOR具备4 x 40G上行链路，为每个机架提供160G总带宽。
    • Fabric交换机：每个Pod由4台Fabric交换机构成，采用3+1冗余。
    • Spine交换机：网络包含4个独立的Spine平面，每个平面最多可容纳48台Spine交换机。初始部署为每个平面12台。
    • Edge交换机：部署了灵活数量的Edge Pod用于外部连接，每个Pod能提供高达7.68Tbps的带宽。
  • 链路带宽：所有交换机（TOR, Fabric, Spine, Edge）之间的互连链路均为40G。
  • 物理布局：部署在Facebook的第三代数据中心（首个为Altoona数据中心），该建筑设计为Fabric网络进行了优化，包含专门的BDF（楼宇配线架）室用于放置Spine和Edge设备。
• 软件配置：
  • 网络协议：全三层（Layer 3）网络，原生支持IPv4/IPv6双栈。唯一的路由协议是标准的BGP4。
  • 控制平面：采用“分布式控制，集中式覆盖”的混合模式。BGP协议提供分布式控制，同时自研了一个集中式BGP控制器，能够通过软件决策覆盖任何路由路径。
  • 流量管理：大规模使用基于流哈希的等价多路径（ECMP）路由。
  • 自动化工具：开发了一整套“自顶向下”的自动化工具，用于网络的配置、部署、监控和故障自愈。这些工具与硬件解耦，支持多厂商设备。

实验结果

该文描述的是生产环境的部署成果，而非传统的受控实验。其主要成果如下：
1. 网络容量大幅提升：与等效的集群设计相比，在Altoona数据中心部署的第一代Fabric架构实现了楼内网络容量10倍的增长。并且，在不改变端口速率的情况下，通过增加Spine交换机，未来容量可以轻松增长到超过50倍。
2. 部署效率显著提高：尽管设备和链路数量大幅增加，但由于模块化设计、标准化的物理布线和高度自动化，Fabric网络的部署速度比同等规模的集群网络更快、更容易。Altoona站点的网络启用时间（从水泥地到网络通畅）被大大缩短。
3. 卓越的可扩展性：
* 按需扩展：架构允许按需、独立地扩展计算（增加Pod）、网络（增加Spine交换机）和外部连接（增加Edge Pod）。
* 平滑升级：初始部署为4:1的机架间超售比，但已预留了所有物理和逻辑资源，可以快速、平滑地升级到2:1乃至1:1无超售。
4. 高容错性与运维简化：
* 高容错：网络中存在大量等价路径，使得单个链路或设备的故障变得不再重要，网络能够承受多个组件同时失效而对业务无影响。
* 运维简化：更小、更简单的设备降低了故障排查的难度。自动化系统处理了大部分监控、警报和修复工作，运维范式从“盯着图表”转变为关注“基线和异常”，实现了运维效率的提升。
5. 打破厂商锁定：模块化设计使得Fabric交换机、Spine交换机和Edge交换机可以使用相同的中型交换机硬件平台。这使得Facebook可以从多个供应商采购设备，避免了对单一供应商大型专有设备的依赖。
6. 面向未来：当前的全40G网络设计，可以利用相同的基础设施和光纤网络，在不远的将来快速升级到100G及以上。

A5 结论

Facebook网络工程团队在处理全球最大规模的网络之一时，信奉“保持简单（keep it simple, stupid）”的原则。尽管他们处理的系统本质上可能庞大而复杂，但团队努力使其组件尽可能基础和坚固，并通过设计和自动化来降低运维复杂性。

本文介绍的新Fabric架构也不例外。尽管其规模庞大且拓扑看似复杂，但它是一个高度模块化的系统，拥有大量重复的元素。它易于自动化和部署，并且比一个由多个定制化集群组成的小型集合更容易操作。

Fabric在网络中的任意两点之间提供了大量的等价路径，使得单个线路和设备变得不重要——这样的网络能够在多个组件同时发生故障时幸免于难，且不产生任何影响。更小、更简单的设备意味着更容易进行故障排查。Fabric要求我们创建和改进的自动化工具，使得其部署速度比我们之前的数据中心网络更快，尽管设备和链路的数量有所增加。

我们的模块化设计和组件选型使我们能够将相同的中型交换机硬件平台用于网络中的所有角色——fabric交换机、spine交换机和边缘交换机——使它们成为可以从多个来源采购的简单的“乐高式”构建块。

由于设备端口密度较小，以及对FIB和控制平面需求的最小化，今天作为我们第一个全方位40G网络的起点，将在不远的将来能够快速升级到100G及以上，同时利用相同的基础设施和光纤设备。通过我们Altoona数据中心的第一代Fabric，我们已经实现了与同等集群设计相比10倍的楼内网络容量增长，并且在相同的端口速率下可以轻松增长到50倍以上。