Facebook SDN 广域网流量调度设计解决方案

作者：罗华

相比Google的SDN流量调度方案，Facebook的Edge Fabric更具备可学习性，通过扩展一些组件来采集路由和流量信息，就可以通过使用标准的BGP来实现自动化的流量调度，对于很多内容服务商来说只是需要添加少量组件就可以实现。

汇总起来的组件如下：

· 网络的BGP架构； · 网络内的流量采集（IPFIX或者sFlow）； · BGP路由信息采集：BMP； · 服务器端eBPF标识流量、被动测量性能； · 整体控制框架。

大多数互联网公司只是缺最后两个部分而已。最后一部分丰俭由人，量力而行，都可以实现。  

 

Facebook的用户数量超过20亿，通过部署在6大洲的几十个PoP节点向最终用户提供服务，这些PoP节点通过BGP连接传统运营商，每个节点的BGP连接数量从几十个到几百个不等。如何向最终用户提供更好的服务，就需要将流量在这些BGP连接中合理调度了。

Facebook使用的叫做Edge Fabric的系统来实现这个任务，从广义范畴上来讲，这是一套SDN系统，但具体对比同样功效的Google的Espresso，还是可以看出两者之间的差异是比较大的。简单说Google的Espresso通过全局的应用感知在自研软件、自研硬件上面来实现全球流量控制，Facebook则通过整体框架来实现性能感知的BGP调度，不仅可以用于自研设备、同时还将第三方的商业路由器纳入统一的实现框架。这对于其他互联网公司来讲更具参考意义。

Edge Fabric有效的帮助Facebook降低的广域链路的拥塞、丢包，同时大大提高了这些BGP连接的利用效率、节省了费用。

前   言

对比互联网的十几年前，近年来流量有着截然不同的特点。流量越来越多地来自少数大型内容提供商、云提供商和CDN网络。目前，仅十个AS（自治系统）就贡献了互联网上70%的流量，而在2007年，需要数千个AS才能达到这个量级。这种内容整合在很大程度上源于视频、流媒体的崛起，如今，视频、流媒体构成了互联网上的主要流量。这种视频流量既需要高吞吐量，又需要低延迟，在这种情况下，传输质量会极大影响用户体验。   为了提供这种高容量、高要求的流量，并改善用户感知的性能和可用性，这些内容服务商已经重塑了他们自己的网络拓扑结构。他们在全球部署众多的PoP节点和具备有直连到最终用户的电信运营商互联，为其提供服务。PoP节点通常有多个BGP可用路径到达用户网络，这使得它可以优选最“短”（AS-Path最短，但并非100%最优）路径。这种丰富的互联性使网络运营者能够控制大部分的路径，总的来说提供了必要的容量。相比之下，传统的通过大型电信运营商层级互联的体系架构很难提供所需的容量，以满足流量快速增长的需求。

尽管这种多BGP连接的连通性可能提供性能优势，但服务商想利用这些优势时会面临挑战。最重要的是，尽管在传输的流量和拓扑上发生了巨大的变化，但路由流量的上层控制协议还是：BGP。BGP自身的本质并不适合在扁平的拓扑结构上处理大量合并的流量：

BGP无法感知容量：BGP的互连带宽和路径的容量都是有限的。在对一个大型内容服务商网络的监测表明，通过BGP策略的优选路径，流量无法在这个路径中获得需要的足够带宽。内容服务商在做路由决策的时候应该考虑到这些限制，特别是因为可能会因为有大量的速率自适应视频流量而导致拥塞。

BGP无法感知性能。

在任何PoP节点，如果按照BGP的缺省最优路径转发流量，可能会导致性能（性能：端到端的流量性能）不佳。BGP在选择路径时所依赖的属性：例如AS-Path的长度、MED 等，都不是与性能实时强相关的。

想要让BGP实现基于性能感知而替代传统的选路机制是具有相当的挑战性。首先，BGP协议中不包含性能信息，性能感知的决策需要依靠外部机制来获得性能数据；第二，到达目的地的路径的性能指标可能会随着时间的变化而变化（例如，负载的响应），但BGP协议仅在更改策略或路由发送变化时才会改变其优选路径；第三，为了跟踪性能数据，内容服务商可能需要准实时的地监测多个非最优的可用路径，但传统BGP在任何时间点只能使用一条最优路径到达目的地；第四，由于BGP对每个目的地都只使用一条路径（非内网ECMP，特指边缘出口），它本身不支持将性能敏感的流量和弹性流量分配到不同的路径上、以便在各自期望的最佳路径上更好地利用有限的带宽。   尽管BGP存在上面所述的种种限制，Facebook还是通过Edge Fabric成功的部署到几十个PoP节点的生产网络中服务其20多亿的用户，本文将阐述Edge Fabric如何设计构建，并提供下面三点贡献：

首先，由于上述BGP限制的影响大小取决于网络的设计。网络连通性和流量特性，使得流行的内容服务商难以管理其出口流量。在Facebook中, PoP点通常有四个或更多的出口路由到其众多的客户网络。在实际的出口监测中，Facebook发现有10%的出口会由于BGP策略的分配问题导致某些地址前缀的流量需求是其出口带宽的2倍，这导致了这些出口的拥塞，然而其他出口这个时候还有剩余可用的带宽。从PoP节点到目的地的流量需求可能是很难预测的，同一目的地前缀的流量在几周内最高值和最低值之间会有多达170倍的差异。虽然Facebook的丰富的出口连接提供了更短的BGP路径、更多的路由选择以及更高的单个出口带宽，但单个路径的容量限制和变化的流量需求使得这种连接变得很难使用。必须使用动态变化的路由协议来处理流量，才能在这些限制内应对实时变化的流量实现优化的效率和性能。

其次，Facebook提出了Edge Fabric的设计，一个基于出口流量优化的路由系统。Edge Fabric从Peer（特指BGP邻居，Facebook的Peer通常是电信运营商）路由器接收BGP路由，监控出口方向数据的带宽和流量需求，并决定如何将出口方向流量分配给BGP的出口。Edge Fabric通过向BGP注入路由的方式来影响BGP的缺省选路过程。2013年开始Edge Fabric就开始了在生产网络中的实际部署。

第三，通过让Edge Fabric沿着几条BGP的可选路径（不只是BGP的最优路径）对每个目的地前缀进行持续的性能监测。Edge Fabric将一小部分流量切换到这几条备选路径上来测试、收集这些路径的性能数据。通过对4个PoP节点的的测量数据显示：有5%的地址前缀通过选择非最优的BGP路径，可以看到其延迟平均减少了20毫秒。  

设计的考量

PoP节点

为了减少到最终用户的延迟，Facebook在全球数十个地点部署了PoP节点。PoP节点的整体架构参见图1：服务器通过架内交换机RSW和聚合交换机ASW的BGP连接最终汇聚连接到多个出口互联路由器PR（Peering Router）。  

图1：Facebook PoP节点架构图   通过分布在全球的多个地点的PoP节点，可以有效的降低到最终用户的延迟：1）就近本地的缓存可以直接给最终用户提供内容；2）用户的TCP连接直接在就近的PoP节点终结。

Facebook的更细一些路由只会由一个PoP节点宣告出来，这意味着，去往这个地址前缀进入哪个PoP节点数据中心是明确的、独一无二的。至于如何选择使用哪一个PoP节点取决于通过基于DNS的全球负载均衡系统（根据客户端请求DNS的源地址来回应不同的PoP节点的地址）来实现的。在PoP节点之间实现的负载均衡系统是通过捕获邻居PoP点给用户提供服务的性能来监控，从而优化后续的决定（选择最优的PoP节点）。PoP节点的选择不在本文描述范围。Edge Fabric实现的是同一个PoP节点内部不同的BGP出口之间的流量调度（前提是流量的进、出都是同一个PoP节点），这个和Google的Espresso的调度范围有区别（Espresso可以实现全球调度，即流量从一个PoP节点进，另一个PoP节点出）。

从路由、流量的角度来分析一下。图2把Facebook前20个PoP节点的流量相对情况展示了出来。其中整体95%的流量来自于大约65000个地址前缀。参见图3展示了这20个PoP节点各自承载了95%流量的地址前缀的数量，可以看到很多PoP节点承载了大部分的流量的地址前缀数量很少，大多数都是在几千条以下，有16个PoP节点的地址前缀数量少于6500条。  

图2：前20个PoP节点流量对比  

图3：20个 PoP节点95%流量来自的地址前缀数量   进一步查看每一个PoP节点中贡献其95%流量的地址前缀条目的组成，参见图4：大比例都是低于10条路由，所以少量路由的更改就能影响很大的流量变动。  

图4：20个PoP节点中95%的流量路由占比  

AS域间连接

PoP节点通过PR（Peering Router）来连接其他AS域，这些BGP出口可分为：

1）穿透连接（Transit Providers）：通常是电信运营商提供给Facebook一个PNI（私有网络连接），可以访问全球所有网段； 2）对等互联（Peers）：提供对等连接到运营商以及其下联的用户；对等互联还可以按照连接当时再分为：

私有对等互联：通过专用的出口线路进行私有网络连接；

公有对等互联：通过公共的互联网交换中心互联（IXP）；

路由服务器互联：通过IXP的路由服务器（非直连方式）接收路由、发送流量；

通常PoP节点内对同一个AS域存在多个BGP连接，例如：既有私有的对等互联，也有通过IXP的公有对等互联。为了避免单点故障，通常PoP节点会和超过2个提供穿透服务的电信运营商互联，每个运营商的BGP连接会分布在2个或者多个PR路由器上。虽然PR路由器上连接的出口数量或者带宽可能有不同，但尽可能的会让每个PR具备有相同的出口带宽总容量。

在PR上不同类型的出口互联中，优选对等互联出口，然后才是穿透连接出口 （通过BGP的Local Preference属性控制）， AS-Path路径长度作为随后的BGP选路的条件。当有多条可选路径时，PR选路的优先顺序按照BGP路由的来源区分：私有对等互联 > 公共对等互联 > 路由服务器互联。在设计中，将出口互联的类型通过数字编码体现在MED属性里（抹去对端发送过来的MED值，设置成Facebook自己设计的值）。对比穿透连接出口和对等互联出口，会优选对等互联，因为通过观察发现对等互联出口通常在后半程的路径上更少出现拥塞（提供穿透连接的通常是一个大型运营商，通过其各种外部互联再转发到最终目的地所在的AS域，而对等连接属于同一个运营商控制的网络、通常有更好的内部互联质量）。相对公共对等互联（IXP），Facebook更优选具备专属带宽的私有对等互联出口，这样可以避免了出口交叉拥塞的可能性（IXP的互联带宽是多家互联机构共享的）。

PoP点内部的PR和ASW之间是启用了BGP多路径功能。PR或者ASW会使用ECMP在多路径上发送流量。

表1：五个PoP节点的各种出口带宽和流量比例   总的来说，Facebook整网拥有上千个BGP出口。参见表1显示了5个PoP节点的每种类型的BGP出口所占的比例。表中显示的每个PoP都有数百个BGP出口，从而具备有丰富多样的连接性。该表还显示了每个PoP节点按照BGP出口类型区分的流量比例（假设所有流量都按照BGP缺省优选路径，不考虑出口实际容量）。尽管私有对等互联的数量在任何PoP节点中最多占四分之一（数量占比12%~25%，欧洲比较特殊，只有2%），但它们接收的流量却占比极大，除了欧洲PoP-11节点（欧洲的互联中心IXP发展一直位于全球前列，其自身技术能力、IXP互联能力和质量都非常出色，所以IXP成在欧洲互联的首选，PoP-11通过IXP互联的流量占比45%）。除了PoP-11节点之外，80%以上的出口流量都到分布在私有对等、公共对等和路由服务器互联出口上，而不是通过穿透连接出口，这也是如今大型内容服务商实现“扁平化”的一个例子。然而，BGP出口类型的分布在不同的PoP节点中因数量和流量而有很大的不同。  

BGP协议的挑战

随着用户需求的增加和Facebook迅速扩展其PoP节点以及基础设施和出口，Facebook遇到了由于BGP自身的限制而带来的挑战，这促使诞生了Edge Fabric：通过BGP来实现路由的动态调整的SDN方案。任何静态的域间路由策略都有可能面临类似的挑战（也就是说任何运行BGP的具有足够大规模的服务商都会面临这个痛点）。   互联出口带宽是有限的，但BGP无法感知容量   尽管Facebook建立了很多PoP节点，扩大了出口容量，并优选了私有对等互联，但一个出口链路的容量不足以容纳想要发送的所有流量。需求的快速增长会迅速导致现有的出口容量不足，在某些情况下，没法进行出口扩容或者可能需要几个月的时间。需求的短期激增（可能因为某些事件或者节假日到来）或由于故障导致的出口容量减少，都会导致需求和可用的出口容量之间的波动。此外，PoP节点就近服务周边的用户，因此，就近地区用户的作息会导致每天的需求是同步的，按每天都会有同步的峰值，可能在短时间内超过其出口容量。此外，特定的某个BGP Peer的出口带宽可能没有均匀地分布在相应的PR路由器上面，然而ASW通过ECMP将均担的流量平均的送到这些PR上，也会导致某些PR会有拥塞（ASW对出口带宽信息不可见，因为BGP没法感知容量）。通常，给出口分配超量的流量会导致拥塞延迟和丢包，而且还会因为数据包重传导致服务器的负荷也增加。

本文描述了如何实现建立在BGP之上还能感知容量的出口决策系统。为了更好的理解Facebook面临的问题，通过对2天实际流量的数据（每个PR出口上的每个地址前缀流量，按分钟取均值）进行分析。

图5展示了没有使用Edge Fabric来进行优化控制的情况，所有PoP节点的80%的地址段都经历了拥塞。  

图5：PoP节点中拥塞的路由的百分比   图6展示了没有使用Edge Fabric的情况，分配到出口上的流量和实际端口带宽的倍数关系。有10%的端口会因为BGP策略的问题导致分配到的流量是实际端口容量的2倍（靠上部的蓝圈），在中线50%的端口会经历分配大约1.19倍的端口带宽的流量（超量19%，中部的蓝圈）。就是在类似的这些情况下，Facebook发现自己无法获得足够的出口容量，这促使Facebook设计了Edge Fabric，以克服BGP无法独自处理的这种情况。  

图6：端口分配的流量对比实际带宽   BGP的选路可能会损害性能   Facebook的BGP路由策略倾向于选择那些有可能优化流量性能的路径。该路由策略在有对等互联出口路由的情况下避免中转路由，BGP选路会优选更短的AS路径（通常延迟更低），同时会优先使用具有私有对等互联的出口，而不是可能遭遇拥塞的公共对等互联出口。然而，BGP本身并不能感知性能，因此这个策略依赖于一些属性：比如AS-Path的长度，这些属性的为后期设计的实现了抛砖引玉的效果。  

图7：BGP最优路径和次优、第三路径的时延对比   为了理解这个问题的严重性，我们比较了四个不同PoP节点的不同路径的性能，一个在北美（PoP-19），一个是欧洲（PoP-11），两个在亚太（PoP-2和PoP-16）。测试中将所有IP地址网段中的一小部分实际用户流量迁移到BGP的次优和第三优选路径上。在后面是章节会详细的描述如何进行这些测量。图7描述了BGP的首选路径和非首选路径之间的流量往返的总体延迟的差异。从图中可以看出，如果将对从BGP的首选路径切换到第二首选路径， 5%的 （图上上面的绿圈）可以减少20+毫秒的的总延迟（Facebook认为20+毫秒的差异是有作用的改进），有3%（图上下面的绿圈）切换到BGP的第三路径能有相应的优化改善。就前面提及的数据，这一小部分百分比的地址前缀代表了大量的流量。结果还表明，对于74%的 选用次优路径能获得延迟优化（只是优化效果小于20毫秒），这表明，可以通过将流量绕道到非最优路径来避免出口拥塞。  

设计目标和设计决策

互联出口带宽是有限的，但BGP无法感知容量   出口流量调度的整体设计目标是为了克服BGP的限制以及使得Facebook能够使用域间互联来优化性能：

· 对于给定的有限容量的出口和受拥塞影响的性能，路由决策系统必须能感知容量、链路利用率和流量需求及其变化； · 路由决策系统需要能考量性能信息及其变化，同时利用BGP的路由策略；

为了完成这个目标，Facebook从2013年起开始开发Edge Fabric系统，这是一个能控制PoP节点出口流量的流量工程系统。下一章将描述Edge Fabric如何动态的迁移流量避免拥塞。再后面将会描述随着时间的推移，由于不断变化的需求和运营经验，如何提高了Edge Fabric的稳定性和对抗拥塞的能力。此外，Facebook还研究了如何使用测量技术来提高出口路由性能，如何开始将其度量纳入路由的决策中去。

对于Edge Fabric的整体设计，关于面临的一些选择上面进行了以下的决策：

基于单个PoP节点调度流量   全局负载均衡系统将用户请求映射到某个特定PoP节点，而Edge Fabric将对于用户请求的出流量分配到出口路径上，流量从进入的同一个PoP节点流出，进出流量是对称的。因此，Edge Fabric只需要在每个PoP节点的颗粒度上做操作，它不用协调全球出口流量。这种设计允许在PoP节点的组件设计中，减少了对远端相应系统的依赖，降低了决策过程的控制范围和实现复杂性。然后，可以在一个PoP节点上单独重启或重新配置Edge Fabric，而不会影响其他PoP节点。   通过SDN来实现集中控制   设计的最终选择是一种基于SDN的实现，PoP节点的集中控制器接收PoP节点网络内的相关状态，然后再确定形成网络路由的决策。这种实现方法具备了SDN的优点：与分布式方法相比，它更容易开发、测试和迭代。因为Facebook是通过BGP连接到各种对等互联出口，所以PoP节点接收到的这些BGP路由也成为了网络状态中的一部分，这些信息会源源不断的传入SDN控制器，形成最终的路由决策。   将实时流量的性能指标纳入决策   控制器每分钟会接收多次容量和需求测量值数据，使得Edge Fabric在出口不超载的情况下最大化的利用优选路径。Facebook在服务器端监控了客户流量的性能数据。通过在PR路由器上使用备选路径的路由表（独立与主路由表之外的），将随机选择的部分生产流量迁移到备选路径上，从而增加了并行测量多条不同路径的能力。这种方法保证了测量方式可以捕获真实反映用户感知的性能指标。Edge Fabric可以让BGP选择非BGP缺省的最佳路由，这奠定了基于性能感知路由决策系统的基石。   使用BGP同时进行路由和控制   尽管有集中控制器，但缺省情况下每个PR路由器在本地自行进行BGP路由决策和交换路由，只有当控制器想要改变某些地址前缀的BGP缺省选路时，才会进行干预。为了更改一个BGP选路决策，Edge Fabric将备选路由设置更高的Local_Preference，并通过BGP进程宣告给PR路由器，PR基于Local_Preference来选择更改的优选路由。在已经建立的BGP路由架构之上来构建Edge Fabric可以简化系统的整体部署，即使整个系统失效也可以让网络回到BGP自行的缺省路由策略，同时可以利用现有的运营团队以及他们在BGP领域的专业能力和网络监控基础设施。   有效利用现有商用的软硬件技术   通过使用经历实战考验的商用设备和行业标准，避免了硬件的定制化和软件的全新设计。Edge Fabric使用了BGP、IPFIX、sFlow、ISIS-SR、eBPF和BMP来实现整体功能。

总体而言，Edge Fabric的设计重视简单性和与Facebook现有基础设施、系统和实践的兼容性。它满足主要目标 — 避免出口过载拥塞 — 不需要对服务器或客户端应用程序进行任何更改，只在路由器和控制器之间增加BGP进程。第二目标：性能感知路由系统的实现需要依赖于服务器上简单的监控软件改造和在路由器上添加备选路径路由表，这都是现有设备具备的基础功能。  

避免边缘拥塞

Edge Fabric由松耦合的微服务组成。参见图8。缺省情况下，Allocator（路由分配器）每30秒从其他服务组件接收网络当前的路由（BMP Collector）和流量状态（Traffic Collector），预测计算出口的利用率，并生成一组更改的路由前缀来进行出口流量的路径迁移，对于每个地址前缀，通过迁移到次优或者第三路径上去来避免BGP缺省优选路径的拥塞。另一个服务进程（BGP Injector）通过BGP向路由器注入定制的BGP路由来实现对BGP缺省路由的更改。30秒的时间间隔可以使得更容易地分析控制器的行为，但如果需要的话，可以降低30秒这个间隔，比如：流量的变化周期更短。

图8：Edge Fabric整体架构  

获取网络状态（输入）

Edge Fabric需要知道从该PoP节点到目的地的所有可用的BGP路由，以及其缺省的优选路径。此外，还需要知道PoP节点中去往每个目的地的流量大小和PoP节点出口端口的带宽容量。   BGP路由信息   1）每个地址前缀的所有可用路由   BGP监控协议BMP（BGP Monitoring Protocol）允许路由器共享其从其他BGP邻居接收到的所有BGP路由的信息快照（在RIB中的所有BGP路由），并将后续更新也发送给订阅方。BMP Collector（BMP采集器）维护所有BGP路由器的BMP订阅，为Edge Fabric提供每个PR路由器的实时RIB视图。相比之下的另一个方案：让Edge Fabric与每台BGP路由器保持BGP会话，但这种方式只能看到每台路由器BGP的最佳路径，其他非优选的BGP路由就无法看到了。所在最终选择了BMP方式。   2）地址前缀的优选路由   BMP Collector只是搜集路由，并不知道BGP如何选路，即使路由器使用ECMP在多条等价路径上分割流量，BGP路由器也只共享一条路径出来。控制器还需要知道在没有Edge Fabric改动的情况下，BGP优选的是哪条路径。因此，控制器需要自己实现BGP选路的模拟算法，用来为每个目的地模拟BGP最佳路径的选择计算（利用BMP收到的多条BGP路径信息，忽略Edge Fabric的路由改动）。（当然，Facebook在自研FBOSS上的积累可以复用在这里了。）   流量信息   1）每个地址前缀当前的流量   Traffic Collector（流量采集器）通过对PoP节点内所有设备进行流量（IPFIX或sFlow，取决于路由器的支持程度）采样，并根据BGP的路由网段进行的最长匹配来做聚合，最终计算出来每条BGP路由前缀在两分钟内的平均流量速率。所有的流量都是实时采集的数据而不是读取历史记录，因为如果不能做到分钟级别的实时性，有可能全球负载均衡系统已经将流量从一个PoP节点切换到另一个去了，那么PoP节点内的流量工程已经就没有意义了，甚至会出现错误的预测计算。

当某个目的地网段前缀的汇聚速率超过了配置的阈值（例如：250Mbps）时，Edge Fabric系统将该地址网段前缀进行细分拆解（例如：将一个/20的网段拆分为两个/21的网段，这个过程不会有流量丢失），直到所有目的地网段的汇聚速率低于配置的那个阈值。对于大网段前缀的拆分可以让Allocator做出更细颗粒度的决策，并将由于出口过载而必须进行绕道的流量降低到最少。   2）出口端口信息   Allocator从集中的网络管控平台（Robotron）中获得每个PR路由器上的BGP出口端口列表，并每6秒通过SNMP查询PR路由器相应接口的容量，使Allocator能够快速响应由于故障或配置导致的出口容量变化。   3）预测的端口利用率   Allocator利用前面采集到的路由信息、流量信息来进行预测计算：按照不进行任何路径改动的情况下：BGP路由按照各自的缺省最优路径，目的地前缀的流量叠加在路径和出口上（对于出现ECMP的情况，按照理论上的流量平均分配来计算），最终计算出每个BGP出口上的利用率。

Edge Fabric使用的是预测计算的结果而非实际采集的利用率来做决策，这么做的最重要的原因是：保证整个过程是无状态的，不需要依赖Edge Fabric的历史数据和状态。无状态的实现带来最大的好处是极大的简化了整体设计：Allocator在一个计算周期内就能实现其最优决策，完全不用依赖之前的状态，这对于整体系统的冗余、切换等等都带来了极大的便捷。在后面的章节会更细致的描述为什么选用了无状态设计。

根据预测计算的出口利用率，如果不进行操控改变BGP缺省选路的情况下，Allocator能确定出哪些出口将出现过载。如果端口利用率接近95%，Facebook会认为开始过载了，95%的利用率是在处理端口效率和留出的缓冲空间之间做出的平衡。  

产生更改（决策）

Allocator根据会出现的出口过载来进行流量的迁移。对于每个过载的出口，Allocator能识别需要流出到该接口的所有目的地前缀网段、及其相应的流量需求、以及每个前缀可用的其他BGP路径。然后，Allocator通过 <前缀，备选路由> 列表，按照下面的处理过程来将其从该出口迁移到其他出口上去：

1. 相对IPv6，优先选择IPv4。

2. 优选一个对等互联出口，其本身也优选Facebook作为它的优选备用路径的。这是通过和对端BGP传递的路由中携带的Community属性来识别的，这些属性值含有Facebook预定的路径优选信息。

3. 对于给定目的地前缀的备选路径可能有多条，在这些备选路径的BGP路由中，优选具有最长网段匹配的路由（例如：/22网段优先于/21网段）。

4. 优选本身就是BGP的最优路径的。参见前面描述的对等互联出口会比穿透连接出口更优选的整体策略，如果Allocator决定将一个目的地前缀从现在的公共互联出口（IXP）迁移到穿透连接出口上，面临多个穿透出口的选择，如果在某个穿透连接上的路由本身就是最优路径，那么就优选这个出口。

5. 剩下的选路原则沿用BGP标准的策略，如果存在多条备选路径，那么Allocator会使用前后一致的方式进行排序，这样会增加流量的均衡性。   当一对 <前缀，备选路由> 被选中以后，Allocator会记录这个决定然后更新整个流量预测：将这个地址段的流量从之前的路径、出口迁移到新的路径、出口上。当然，前面提及的超过设置的流量（例如：250Mbps）值会将地址网段进行拆分。

Allocator会继续选择地址前缀网段来进行以上操作，直到出口不会再有过载的情况，或者是所有前缀网段的BGP路由都没有可用的次优路由存在。

因为整个处理过程是无状态的，不需要参考之前的状态，系统每30秒将接收到的信息（路由和流量）进行一次计算，做出新的流量切换决策。为了减少对流量的搅动，Facebook设计了一套优选机制，使用一致的考量顺序来综合端口、地址前缀、绕道的路径等因素，这种一致的考量使得Allocator在前后的计算中会尽量得出相同的计算结果。其他的流量操控行为常常是因为流量速率和可用路由的变化而导致的。

对于某些持续增长的流量，出口剩余的可用带宽（大约5%）空间可以留作Allocator在两次计算间隔内的缓冲，用以预防Allocator还没来的急操作出口就开始拥塞了的情况。如果流量切换到次优路径，但其BGP路由被撤销了，那么控制器也会撤销、停用这条次优路由，避免流量黑洞。  

使用Allocator控制（输出）

在每一轮计算操控中，Allocator生成一组新的BGP路由更新来覆盖原有的BGP缺省选路，实现的方式是给每个BGP更新的路由分配一个足够高的Local_Preference。Allocator将BGP更新的路由信息传递给BGP Injector服务，该注入服务与PoP节点中的每一台PR路由器建立了BGP连接，并通过向目标PR路由器宣告BGP更新路由来实现对原有BGP缺省选路决策的更改。由于注入的BGP更新路由具有更高的Local_Preference（在标准的BGP选路判断中，对可用路由来说这是最高优先级）值，并且通过iBGP在PR和AWS之间传播，所以PoP节点网络内的所有路由器会优选这个注入的BGP路由。BGP Injector会同时撤销当前失效的更改路由（上一轮的注入路由，本轮计算后失效了）。

从全局角度来看，虽然Edge Fabric和全局负载均衡系统有各自的独立决策流程，但两者的处理结果需要协调一致、而不能相互冲突。首先，我们需要防止Edge Fabric决策和全局负载均衡系统的决策以会导致振荡的方式相互影响。在选择用哪一个PoP节点来响应用户的请求时，全球负载均衡系统会根据PoP节点的性能、Facebook的整体BGP策略，通过可配的设置，在这个时候的决策不会参考Edge Fabric更改以后的BGP路由。考量另一个可能性，如果全球负载均衡系统也同时参考BGP Injector产生的更改以后的路由，那么在全局的第一级导流决策中，这个最终用户的流量会被分配到其他PoP节点去，那么之前那个PoP节点的预测计算就会发生错误，流量已经不存在了，那么预测的出口拥塞也不准确了，这更容易让Edge Fabric和全局负载均衡系统之间发生振荡。其次，全局负载均衡系统从全网的角度来监控用户网段流量和出口端口的利用率，这方便在全局PoP节点之间来流量调度。所以Edge Fabric就能够专注于PoP节点内的所有出口过载情况，再进行流量操控避免拥塞。  

部署、测试、监控

Edge Fabric软件的迭代、部署通常每周都会进行，在这个过程中使用多级发布流程来降低整体风险。首先，因为整个设计是模块化和无状态的，所以在测试方面，可以为Edge Fabric和其依赖的每个独立组件进行全面和完整的自动化测试。其次，由于控制器是无状态的，同时使用的是预测计算而非实际利用率，这样被测试的“影子”控制器可以运行在沙箱里，通过测试环境获取的网络状态信息和生产网络里面控制器获取的信息是一样的，按照这种方式来进行测试，不需要去获取生产网络在线控制器的状态，也不需要获得之前控制器的决策状态，使得测试更加易于实现。不断的从版本库中创建最新版本的影子控制器实例，在测试环境中运行、预测判断，再与生产网络中运行的控制器的决策结果去做对比，在这个过程中不断的优化、解决问题。在部署新版本之前，需要仔细评估对比这些测试结果。第三，由于Facebook是按照PoP节点为单位来部署Edge Fabric和其依赖组件，对于新版本的部署可以实现逐个PoP节点部署的灰度上线方式，当然灰度部署也是基于自动化实现的。当Edge Fabric控制器更新版本后，BGP Injector继续执行上一轮的命令（发送BGP更新路由），直到收到新的控制器产生的指令（通常在5分钟以内）。如果需要更新BGP Injector服务，PR路由器会保持现有注入的路由直到新的BGP Injtector服务重启完成（这是得益于BGP GR，Graceful Restart）。

虽然无状态控制器易于进行自动化测试，但它也特别容易受到BGP路由或流量速率数据错误的影响，这些数据是控制器进行预测计算的基础，其准确度会直接导致预测的出口利用率不正确。为了追踪这种错误的预测，Facebook使用监控系统来对比预测计算的结果和出口实际的利用率，在配置的时间间隔内出现超过5%的偏差会触发告警。通过这个流程，可以捕捉、识别、纠正可能存在的路由策略中的Bug以及PR路由器通过IPFIX和sFlow导出采集流量中的问题。控制器的预测计算是将流量均分到所有的ECMP路径上。同样，监控系统可以监控到由于ECMP实现不完美导致的流量不均衡的情况，这个时候可以通过Edge Fabric注入路由使用单个PR出口路由器来避免ECMP多路径不均衡的情况。

整个Edge Fabric是建立在分布式BGP路由决策系统之上的，也就是说，每个路由器还是独立进行选路判断，这有利于复用现有的整体网络架构，但BGP本身的复杂性也可能造成运维中的故障。例如在某个场景中，由于配置错误导致Edge Fabric注入的路由没有被PoP节点内所有的路由器收到，这造成了导致之前出口过载的流量被迁移到另一个并非预期的出口上，结果导致那个出口出现了拥塞。为了检测这种错误配置，Facebook构建了一个审计系统，定期比较Edge Fabric的输出结果与当前的网络状态和流量模式。  

BGP迈向性能感知

Edge Fabric能够避免由于网络边缘的链路拥塞而导致的性能问题。然而，由于BGP本身选路机制的限制，Facebook最终用户的性能任然可能不是处于最优的状态。想让BGP选路一直走在最优的性能路径上是颇为困难的事情：缺省的选路未必是最优性能的路径，选择的次优路径也不一定是，即使在所有情况下都是最优的，但迁移路径的时候还是可能出现性能降低甚至比不上之前的缺省选择。

此外，虽然Facebook直接连接到了许多边缘网络（类似其他大型内容服务商一样，前面描述的互联网“扁平化”），但其他边缘网络（Facebook通过IXP或穿透连接）的性能可能会受到其下游网络拥塞的影响，这是Edge Fabric无法进行优化处理的。即使Facebook直连边缘网络的情况下，其下游网络的拥塞仍然会导致端到端的性能降低。由于瞬态故障和流量波动，每条路径的最优性能可能会随着时间的变化而变化，因此基于性能的决策需要对变化做出及时的响应。但BGP既不能提供性能的可见性，也不能提供基于性能的显式决策能力。

为了使路由决策能够结合性能指标，需要并行地、连续地测量到达目的地的多条可用路径。此外，为了使Edge Fabric能够最好地利用可用出口带宽，需要能够对特定类型的流量进行优先级排序（例如：预测出口会出现过载时，对实时视频流优先级排序），但由于BGP只支持基于目的地的路由，仅靠BGP无法实现上述目标。

下面的小节描述了如何将特定的流量导向特定的路径，然后在下一个小节描述了如何能监测到同一个目的地前缀的多个可用BGP路径的各自的性能。这两种机制已经应用到Edge Fabric的生产网络中。本章的最后一小节讨论未来的用例，这些用例将测量特定引导的流量，以来启用能感知性能的路由系统。  

将流量迁移到备选路径

为了克服BGP只能支持基于目的地的路由的限制，通过建立一种机制来优化：允许为特定的流量选择其流经的路径。该机制只需要在：1）服务器上做软件上的小改动；2）PR路由器上进行小量的配置修改即可；并且不需要服务器和其他网络设备互动（包括PR）：服务器可以在不知道PR路由器的网络状态的情况下，为每个流量做出其决策。

· 服务器选择并标记需要特殊处理的流量。具体来说，服务器将所选流量的IP报文中的DSCP字段设置为一个预定义的值。不同的DSCP值代表最终会选择不同的出口、路径，例如：缺省BGP优选、次优路径、第三选择路径等。在实际应用中，服务器可以将一个数据流基于其最终目的标记为不同的DSCP值，比如：用于测量备选路径的性能；或者将该流量引导到需要实时、性能敏感的路径上去。

· PR路由器上的路由策略。PR路由器按照预先设定好的DSCP值，将不同的DSCP值的流量导入不同的路由表进行转发（路由器上有主路由表，同时PR上面创建了很多不同的路由表，里面搭配不同的BGP路径，用此来实现不同的路径优选）。为每个DSCP值的流量配备一个单独的路由表（每个路由表中同一目的地的BGP优选路由会不一样，从而实现选择不同的出口）。

· 控制器注入路由。控制器将路由注入到PR路由器的备选路径路由表中，用以控制流量的出口选择。如果控制器没有为特定的目的地注入路由，则该流量将根据PR的主路由表进行路由，就是BGP的缺省优选路径。   这种实现方法不需要在服务器、路由器和控制器之间持续同步状态。服务器在为其流量设置DSCP标记值的时候可以完全不知道网络设备的状态，控制器也可以根据需要将路由注入到备选路由表中来控制相应DSCP标记报文的路径。

此外，PoP节点内ASW层不需要知道分配给流量的DSCP值的含义，它只是根据BGP的缺省优选路径转发IP流量。在这种情况下，流量不一定会发送到正确的PR上去，因为控制器计算出来的出口可能位于某个PR，但ASW却基于缺省最优路径将流量发送给了另一个PR。对于这种情况，控制器会在缺少对应出口的PR路由器上注入BGP备选路由，并将该路由的下一跳设置为正确的PR路由器。这个时候，流量将从一个PR路由器转发到另一个PR路由器，这通常会引起路由环，因为ASW只是根据BGP的最优目的地路由来转发流量。为了避免这种情况，将PR之间使用IS-IS SR来实现流量的迁移，而迁移路径中间的ASW是基于SR的MPLS标签进行转发的，IP信息对它不可见，所以可以避免路由环。  

监测备选路径的性能

最终用户的TCP连接终结在PoP节点内的前端服务器上，前端服务器将HTTP请求代理到后端服务器。通过上面描述的机制来随机的选择一些流量，并通过次优路径来转发。这使得Facebook可以通过现有的基础设施收集测量实际流量的数据指标，记录前端服务器观察到的客户端连接的性能。  

随机选择的用户流量

  通过一个部署在前端服务器上运行的程序，可以随机选择数据流，并标记让其沿着次优路径转发，这个程序的核心组件是使用eBPF（Extended Berkeley Packet Filter）。eBPF允许将其加载到内核中，以便有效地处理、记录从服务器发出的所有数据包。使用这种方式，不需要对现有的客户端或服务器端的应用程序进行任何更改。   通过设置预定义的DSCP值，eBPF程序随机选择部分数据流（比例可配置）引导到次优路径上进行路径性能监测。这个eBPF程序的配置可以动态更改，包含最重要的参数是：多少百分比的流量需要标记成哪个DSCP值。例如，要测量每个地址前缀的两条备选路径，配置可以将数据流的0.75%分配为DSCP值12，将数据流的0.25%分配为DSCP值24，流量到达PR路由器，会因为DSCP的12、24而分配不同的出口。考虑到Facebook的体量，这一小部分比例的仍然会产生大量的测量结果。

这是方式称作被动监测。设计之初在主动监测（主动Ping或者各种TCP进程的模拟）和被动监测之间的选择上，Facebook选择了被动监测，因为主动测量不能代表真实用户感知到的性能，这当中会有很大的偏差，而Facebook的eBPF的实现方式完全获得了最终用户最准确的各种性能数据。   注入路由   Edge Fabric使用了AltPath Controller（备选路径控制器）来将路由注入到专门的备选路由表。控制器生成备选路径的时候只是考量过去10分钟内流量信息，这种实现大大减少了备选路由表的大小。

每隔30秒，AltPath Controller使用从BMP Collector服务进程获取的BGP路由信息来决定为每个目的地前缀选择的备选路径，然后服务器为相应的流量标记相应的DSCP值。然后控制器使用BGP Injector将每个DSCP值对于的BGP备选路由注入到相应的PR路由器的备选路由表中。

AltPath Controller还可以对一些目的地AS号进行屏蔽备选路径测量的功能，简单输入一组目标AS号即可。流量工程团队根据之前的实操经验将一些可能会引起极差用户体验的备选路径的AS号添加进去，避免选中了这些备选路径降低了最终用户的性能。  

监测性能

当客户端TCP连接终结时，前端服务器会将该路径的性能评测指标记录下来。这些服务器使用一个单独的eBPF来捕捉需要采用的TCP连接，通常典型的采样比为1：1000。采集的性能数据包括：重传速率、RTO（Retransmission Timeout重传超时时间）、SRTT（Smoothed Round-Trip Times平滑往返时间）和发送/接收的数据包分段数量。此外，服务器还对HTTP事务进程进行采样，并对每个响应的客户请求的下载吞吐量也进行测量。服务器也会记录eBPF程序分配给相应数据流的DSCP值。采集器将样本与出口路由信息关联起来，这样分散的采样样本可以按照出口路由网段来汇聚，最后叠加计算出按照每条路由这个颗粒度的汇聚流量信息。  

性能感知路由的未来用例

前面两个小节描述的机制使得可以将流量迁移到备选路径上去，同时也能测量备选路径的性能。  

使用BGP来更改路径

如今，Edge Fabric改变了BGP的缺省选路过程，以缓解Facebook网络边缘的拥塞。展望未来，可以通过合并AltPath的测量来优化Edge Fabric。首先，Edge Fabric可以使用这些测量数据来确定在哪些情况下，即使出口没有拥塞，也可以通过改写BGP的缺省选路来提高性能。在当前路径的性能下降时，AltPath测量可以确定是否可以通过更改路径来规避这种问题，或者性能问题存在于所有可选路径上（前面提及的用户侧网络/下游网络的拥塞导致问题不可避免）。其次，Edge Fabric可以测量备选路径，以确保在出现拥塞时，将流量切换到性能最佳的备选路径上。最后，备选路径测量可以帮助运维团队识别绕道流量的性能影响，这可以为网络规划团队做决策时提供数据。  

优化有限的出口容量

当出口带宽容量有限时，Edge Fabric可能被迫将流量切换到性能相对较差一些的路径上。Edge Fabric可以通过将一些不太可能受到影响的流量切换到其他备选路径上，以便更好地利用主路径上的有限容量。首先，Edge Fabric可以修改其选路决策标准，以更倾向于迁移在备选路径上性能几乎不会下降的地址前缀的流量。其次，更高优先级的流量可以通过受约束的路径路由来调整。前端服务器可以为优先级较高的流量（比如实时视频流）设置预定义的DSCP值。然后，当Edge Fabric通过注入路由将流量从过载的接口上迁移出去时，它同时将更改的路由注入到PR的备选路由表中，可以使DSCP优先级高的流量在性能更好的路径上传送。Traffic Collector收集的IPFIX和sFlow采样都包含有DSCP字段，因此Edge Fabric可以确定相应DSCP值的流量速率，并在每一轮的预测中对此进行计算。  

实际运行效果

部署状态和评估数据集

Edge Fabric部署在全球的生产网络中，在所有的PoP节点中通过备选路径来避免出口拥塞。下一小节描述了对2017年1月的其中两天的数据进行的研究，当时并没有使用无状态的控制器。这个研究使用了早期的有状态的控制器，该控制器没有使用自动分割大流量地址前缀的功能。虽然没有进行正式的评估，但Facebook相信其无状态控制器比有状态控制器获得了更好的出口利用率。

现在在PoP节点中部署了AltPath，在“性能感知评估”小节展示的效果是从2016年最先开始部署的4个PoP节点，在一定程度上选择这4个PoP节点是因为它们有丰富的出口连接：一个在北美（PoP-19），一个在欧洲（PoP-11），和两个在亚太地区（PoP-2和PoP-16）。这4个PoP节点加起来的流量约占20个PoP节点总量的18%。当前，没有使用AltPath自动测量来通知生产网络并形成路由决策，但是后面会介绍将其集成到路由决策中的影响和挑战的试验结果。

在每个路由器上创建了两个备选路由表（缺省主路由表之外的），将所有路由前缀的BGP的次优和BGP第三优选路径分别放置到两个创建的路由表中。在2016年的测量实现中还没有使用基于DSCP的方法，而是根据流量的目的端口将流量分配给对应的路由表。对于每个备选路由表，生成了一组独有与之对应的端口，它们大约匹配总流量的0.5%，然后在PR上配置规则，将匹配这些端口的流量迁移到其中的一个路由表中，再做选路。为了增加备选路径的测量次数，当数据连接命中AltPath的端口集时就对现有的测量采样比扩大100。通过这个方式，每个备选路径接收到的0.5%的流量，会检测其在主路径的大约50%的流量。  

评估容量感知路由的效果

Edge Fabric是否实现了它的主要目标，即在实现提高出口利用率的同时避免出口拥塞？Edge Fabric通过使备选路径来防止拥塞。在研究过程中，有空闲带宽的备选路径始终存在，这为Edge Fabric实现避免过载提供了可能性。尤其是，提供穿透连接的运营商可以将流量送到任何目的地，在研究期间，任何单个PoP节点（每分钟采样）观察到的最大瞬时利用率是55%。Edge Fabric成功地防止了出口流量过载，当Edge Fabric选用优选路径时，出口上没有丢包，且使用备选路径的99.9%的时间内也没有丢包。

Edge Fabric迁移了多少流量到备选路径上？图9显示了Edge Fabric从每个出口启用迁移的时间分布。在评估期间，Edge Fabric至少在18%的端口上启用过一次备选路径流量切换，并且在一半的时间内，至少5%的出口进行过流量迁移（图中蓝色圆圈）。  

图9：Edge Fabric切换流量的时长和间隔   图10显示了每个流量迁移的持续的时间，以及给定（PoP，目的地前缀）的两次迁移之间的间隔时间。平均流量迁移的时间为22分钟，10%的迁移时间持续了超过6小时。有趣的是，流量迁移中位数的时间更短 — 只有14分钟 — 但尾部更长，36%的流量迁移中有超过3小时的间隔，相当大一部分的间隔足够长，这表明流量迁移发生在一个较短的每天的高峰期内。  

图10：Edge Fabric迁移的流量占比   图11显示了在一周的时间内，20个PoP节点进行迁移的流量所占的比例（红色曲线），以及其中一个迁移流量占比最高的PoP节点（在这20个PoP中）的迁移流量所占的比例（蓝色曲线）。全局和PoP节点流量迁移的模式显示了每天流量变化的规律，迁移流量的占比只是总流量的一小部分，正如前面提及的PoP节点通常具备45%（瞬时最大55%的利用率）的富裕带宽，这些闲置的容量足以吸收迁移的流量。Edge Fabric使得PoP节点能够利用节点内的其他可用出口的闲置的带宽，动态地从过载端口迁移流量，否则那些端口会变得异常拥塞。  

图11：一周的每天进行流量迁移的比例  

评估性能感知的路由的效果

本节将研究相同目的地前缀的不同路径之间的性能差异，以及系统是否可以使用这些信息来选择优于BGP缺省优选路径的其他备选路径。通过在4个部署了备选路径测量系统的PoP节点，监测了7天的生产网络流量，包括测量了：每个目的地前缀的备选路径，一共有超过3.5亿条备选路径、终点到2万个AS域，平均每个 <备用路径，目的地前缀> 进行了8000次测量。

通过测量备选路径做出更好的决策对性能有多大影响？使用这些测量的数据来改写PoP-2节点上用户实际生产流量的优选路径，AltPath识别出400个目的地前缀，并测量出这些目的地前缀的备选路径的中位数时延至少比缺省情况要快20毫秒（丢包率没有增加）。Edge Fabric获得了这些信息，并在PoP节点上通过注入路由改变缺省的优选路径，将这些目的地前缀的生产流量迁移到备选路径上。这些注入持续了24小时。  

图12：BGP备选路径对比优选路径的性能变化（负数为优化了）   图12展示了备选路径的性能和BGP缺省优选路径的对比，：AltPath指定的路径（目前承载大部分流量）和BGP缺省的首选路径的性能的对比。对于这些前缀，45%的前缀实现了至少20ms的中值延迟（蓝圈1），28%的前缀至少提高了100ms（蓝圈2）。在另一方面，有些备选路径的改写没有获得预期的效果：例如，有17%的前缀的延迟的中位值反而比缺省路径多了20毫秒（蓝圈3），还有1%的前缀的延迟至少比缺省路径慢了100毫秒（蓝圈4）。如果系统动态调整路由（而非这种一次性静态改动)，这些结果表明可能出现振荡。这些情况中的绝大多数是因为目的地前缀从对等互联出口迁移到了穿透连接出口上去了。

当更改路径后导致结果出现更差的性能时，推测这种异常可能是来源于两个因素的结合：1）路径的性能和加载在上面的流量是某种函数关系；2）路径的性能是随着时间的推移而改变的。在未来的工作中，Facebook打算通过对流量进行更细粒度的迁移来研究这些问题，这样就可以了解放置在特定路径上的流量负载如何影响其性能。此外，这一挑战还需要一个健壮和快速反应的控制系统来决定是否进行迁移，不仅基于单个前缀的测量，还取决于相同路径上其他的流量是否被迁移进来或者迁移出去，同时还要考量历史数据等其他的影响因素。要实现这个目标，需要进一步的提高AltPath的测量采样率，这样控制器就能够有足够的样本来评估更短时间内的性能。

AltPath还识别出有700个目的地前缀的BGP路由的第三优选路径要优于其次优路径，因此将Edge Fabric配置为可以使用第三优选路径来做流量迁移的备选路径。然而，在的实验中，只有不到5%的这些前缀被Edge Fabric选中进行流量迁移。在这些迁移路径中，通过比较选中的迁移路径和BGP的次优路径两者的AltPath测量性能，发现除了2个前缀外，所有迁移的流量都获得了更好的性能。这一结果表明，AltPath能够有效的帮助Edge Fabric使用迁移路径来解决拥塞问题。

AltPath能准确地捕获端到端性能吗？利用BGP对等测试床进行了对照实验。测试床直接在AMS- IX（位于阿姆斯特丹的互联网交换中心）上的公共枢纽与Facebook对等互联，而对等网络的宣告也通过对等网络的穿透互联运营商到达了Facebook的网络。模拟客户端的IP地址通过穿透运营商和与Facebook直接连接都进行了BGP宣告。客户端持续使用HTTP从Facebook获取515KB和30KB的文件，保持客户端CPU和带宽利用率低于20%。随着时间的推移，使用Linux的流量控制框架来引入40毫秒的延迟，这个延迟叠加在：与Facebook直连的路径、穿透路径或两者同时叠加。使用AltPath来测量5分钟内直连路径和穿透路径的性能差异。在持续的18个小时的实验中，AltPath在所有测量结果中的测试误差都在2.2毫秒以内，平均误差为0.6毫秒。这种精准度足以满足Edge Fabric在做流量迁移决策时所需的要求。  

运维经验

Edge Fabric经过多年的发展，以响应PoP节点的增长和运营经验的实现。目前Edge Fabric的设计专注于提供需要的灵活性来处理不同出口路由的场景，但在任何可能的情况下，整体设计都倾向于使用易于理解的技术和协议，而不是更复杂的方式。  

Edge Fabric控制层的演进

当PoP节点数量和其规模不断的增长时，Facebook更是追寻简单、可扩展的设计架构。这些期望的特性需要对设计的组件进行持续的评估和改进，并仔细考虑这些设计决策将产生什么样的长期影响。  

从有状态到无状态控制

当前Edge Fabric的实现是无状态的，这意味着它在每30秒的周期中从零开始进行计算、分配和更改决策，而不需要知道它之前的迁移决定。由于设计简单，这种方法有许多优点。例如，因为无状态Allocator通过收集到所有它需要的信息（路由和流量）就可以开始每个运行周期，并在控制器没有干预的情况下预测计算出口的利用率，所以测试、重启或发生故障时迁移控制器是很简单的。给定输入和预测，控制器只需要计算出应该迁移哪些流量，测试也可以非常简单的通过提供输入场景、检查决策结果来完成。

相比之下，之前的有状态的实现需要在每一轮计算之后在本地和远端记录Allocator的状态。如果控制器由于升级或失败而重新启动，它必须从远端记录中恢复之前的决策，这增加了复杂性。此外，有状态控制器的决策过程更加复杂，因为控制器不仅要决定当出口过载时哪些目的地前缀要迁移，而且还要决定在给定的当前出口负载下，要删除哪些现有的迁移决策。因为有状态控制器在出口利用率降到阈值以下时才会考虑删除迁移决策，所以当出口利用率持续增加时，它无法回溯，而且它的下一步决策选项会受到之前操作结果的影响。在某些情况下，控制器会将一个目的地前缀迁移到一个备选路径上，但在下一个计算周期中，再次迁移该流量。维护这些状态和决策的记录使得实现和测试变得异常复杂，因为程序逻辑实现和测试工作必须要注入相关联的一系列状态和决策，这些复杂性最终成为了设计无状态实现方式的驱动因素。   从基于主机的路由到基于边缘的路由   目前的Edge Fabric的实现使用BGP来完成路由更改，并且只要求主机对需要特殊处理的流量设置相应的DSCP值即可，例如前面提及的用于备选路径测量的流量。相比之下，以前的Edge Fabric实现依赖于基于主机的路由来实现更改。在主机路由模型中，控制器需要在PoP节点内的每台服务器上安装其流量规则。这些规则将用于标记到达不同目的地的流量。然后在对应的PR路由器上使用相应的规则来匹配这些流量标记，最后通过绕过标准IP路由（策略路由）将数据报文从指定的出口送出去。

在基于主机的路由时代，Edge Fabric先后在生产网络中实现过三种不同的标记机制：MPLS、DSCP和GRE（基于MPLS的实现比目前的Edge Fabric更进一步，它根据主机的决策来路由所有出口流量，有效地将所有IP路由决策从我们的PR中转移出去）。MPLS和DSCP与早期的PoP架构是兼容的，在这个架构中， 跨PR的对等互联和穿透连接出口是平衡的，任何需要迁移的流量都被发送到穿透连接的出口上去了。由于流量受ECMP约束，所有PR对所有出口有相同的规则（例如，DSCP值12将使流量在所有PR路由器上转发到穿透运营商X，这需要所有的PR都具备到X的出口）。然而，随着的PoP架构的发展，PR之间的对等互联和穿透出口的容量越来越不平衡，并且想要具体控制某个PR出口的流量，在那个设计中使用GRE隧道在服务器和PR路由器之间转发流量。

从使用过的这些机制的经验来看，Facebook发现要同时获得软硬件供应商对隧道协议的快速、强有力的支持是非常重要的。让终端主机担负路由流量到指定出口的责任，使得调试和审计网络的行为变得更加困难，因为必须在多个层面上进行配置检查。此外，当出口发生故障或路由撤回时，终端主机必须迅速做出反应，以避免黑洞流量，这使得终端主机、PR路由器和控制器之间的信息同步至关重要。

相比之下，目前版本的Edge Fabric不需要主机知道网络状态，通过在PR注入更改的BGP路由实现，降低了同步的复杂性。此外，这种方式使PR能够应对控制器的某条决策失效的情况，以防止流量黑洞，例如：因出口故障导致PR接收到的备选路径不可用了，那么PR路由器还是可以使用BGP选路机制找到下一个优选路由。

基于边缘路由实现方式比基于主机路由具备更多的优点，同时还更简单。虽然基于主机路由能让主机对数据包的路由方式有更多的控制能力，但由于以下的种种原因，这种额外灵活性带来的优点并不足以抵消实现的复杂性带来的难度。首先，测量结果表明，大多数流量还是使用的BGP缺省优选路径（参见图12，迁移的流量平均峰值在10%左右），Edge Fabric仅覆盖了一小部分流量用以避免拥塞或提高性能。其次，改变基于目的地路径的实现方法可以允许服务器标记选择的流量（设置数据包的DSCP值）以期望进行特殊处理，并允许控制器决定这些流量的路径是否应该被更改。虽然这种解耦方式限制了服务器的控制力度，但是整个系统的设计更为简单、故障排错也更容易，并且对于实际场景来讲具备了足够的灵活性。第三，因为Facebook选择的全局流量均衡模式是流量在一个PoP节点进出对称（同一个PoP节点进，同一个节点出），所以对于出口的选择来说相对有限，决定发送到那个PR路由器即可。如果全局负载均衡系统探测到另一个PoP节点可以提供更好的性能，那么全局负载均衡系统直接将用户切换到那个PoP即可。  

从全局到单一PoP节点

以前，Facebook网内的PoP节点之间是运行iBGP来传播来外部的eBGP路由。这种情况下，用户的流量从一个PoP节点流入，但可以通过另一个PoP节点流出。在某些情况下，通过内部的广域网将流量从一个远端的PoP节点的出口送出可以提高性能，但必须有相应的机制来防止它引起振荡。例如，过载的出口上的一些流量可能已经通过远端PoP进入。如果Edge Fabric在出口PoP节点内改写路由以避免拥塞，更新路由将传播到另一个入口PoP节点。如果通过改写BGP路由让入口PoP节点停止优选出口PoP节点，那么这个预测流量就不会计入本地的出口流量中，本地出口的无过载状态可能会让Edge Fabric去掉之前的BGP路径改写行为，这会导致本地出口又出现拥塞，流量再次迁移到远端PoP节点，流量在两个PoP节点之间不断震荡。为了防止这种“入口PoP优选出口PoP节点”的情况，控制器将改写的BGP路由属性设置成与原始路由相同。但控制器在操控BGP属性上会混淆路由信息，给运维团队理解和调试出向路由带来了困难。在提高了全局负载均衡系统映射的准确性和颗粒度以后，Facebook就去掉了PoP节点之间的路由互传（去掉了iBGP进程），现在流量的进出都在同一个PoP节点上。由于全局负载均衡系统控制流量进入的PoP节点，它可以将客户的流量负载分担到它认为等价的几个PoP节点上，这样可以同时利用多个PoP节点的出口容量。这使得Facebook可以避免使用内部骨干网在PoP节点之间来传递最终用户的流量，并简化了Edge Fabric的设计。  

从平衡到非平衡容量

随着的PoP节点的不断增长， PoP节点的设计也需要随之优化来处理很多边缘场景。当增加PoP节点的数量和规模时，PR路由器上面开始有更多不平均的出口互联带宽，部分原因是互联出口的连接的不均衡增长，但也可能是由于发生故障和长时间的修复时间（海缆差不多2个月就会断一次，平均7个小时来修复）。这些因素都造成了PR上出口带宽不均衡的问题，现有设计中ASW使用的是ECMP将流量发送给多个PR，但ASW对于PR的不均衡出口并不知道，所以会导致均衡的流量进入PR但出口容量不均衡导致的问题。对于这个问题，可以考虑使用WCMP来解决，而不用在Edge Fabric上实现。

然而，由于种种原因，最终选择了扩展Edge Fabric的功能来处理这些容量失衡的情况。首先，虽然有许多路由和交换芯片支持WCMP，但与ECMP相比，供应商对WCMP的采用和支持要少得多，这使得采用WCMP方案的风险更大。即使使用vanilla-ECMP算法，也能观察到不均衡的流量分布和其他问题以及意想不到的行为。其次，由于供应商使用的WCMP实现是私有的，所以无法预测WCMP将如何运行，这使得预测计算和工程流量更加困难，并可能增加Edge Fabric的复杂性。最后，WCMP实现需要对路由器的整个路由表进行操作，路由表在发生变化以后可能需要分钟级别的时间来收敛，在此期间可能没法有效的进行正确的均衡流量。相比之下，Edge Fabric可以识别出流量的目的地网段的子集及其流量，并在几秒钟内进行更改路由注入，从而缓解故障。  

IXP的挑战

互联网交换中心（IXP）一直是学术界关注的焦点，同时也对Facebook这种规模的内容服务商提出了挑战。与PNI（专用的私有连接）相比，内容服务商无法知道 Peer的端口到底有多少可用容量，因为在IXP的其他Peer网络可能也在向它发送数据（IXP的典型拓扑是通过交换机实现Hub-Spoke式互联）。这种有限的可见性使得避免拥塞的同时期望最大限度地利用接口容量变得更加困难。Edge Fabric通过设置每一个Peer出口的速率限制，来实现对Peer出口容量的可见性，以避免阻塞。在这种场景中，直接联系IXP的各个Peer来获得、设置其容量限制是更有效的方式。这种方式类似和具备PNI的出口一样，只是会对利用率进行限制。  

相关工作

CDN流量工程

随着CDN流量的增长，研究者和工程师们提出了新的流量工程解决方案。在CDN流量工程中，Edge Fabric也采用了一种常见的方法，即集中SDN的方式来控制，将网络和流量信息结合起来配置网络设备。

研究人员已经研究了多种客户端请求流量的处理方法，包括使用Anycast和DNS扩展作为将客户端请求流量引导到“就近”的服务器上的机制。这些解决方案针对的是与前文中所描述的不一样的挑战，这些方案也是Edge Fabric的有效补充。Facebook采用了这些解决方案来选择客户端流量去往那个PoP节点，但在PoP内仍然需要Edge Fabric来选择合适的出口回送去往客户端的流量。

与Edge Fabric更相关的是Footprint（微软的流量调度系统）、PECAN、Entact和Espresso（Google的B2广域网流量调度），它们选择PoP节点或者路径的时候是考量的路径的性能。Footprint专注于在PoP节点之间迁移长连接有状态的会话负载，以避免拥塞；PECAN专注于度量性能和选择入口路由（入向流量），Edge Fabric设计用于在备选出口（出向流量）之间迁移流量，以避免拥塞。这三个设计方案是互补的：Edge Fabric的技术可以应用于Footprint和PECAN，反之亦然。

Entact和Espresso是最相似的。Entact通过一种精心设计的方法，平衡了BGP的性能、负载和成本，通过仿真来评估BGP的缺省选路策略。与AltPath类似，Entact将一些流量导向备选路径，以测量其性能。Facebook以这个想法为基础，按照自身用户流量的特点做了相应改进，然后在生产环境中大规模部署。例如，Entact测量目的地网段前缀内的单个IP地址的备选路径性能，而AltPath则是在地址空间内随机选择流量，以防不同地址具有不同性能的情况，并允许在将来基于应用区分的路由也可以使用这个机制。Entact使用主动测量（Ping）来测量路径性能，但无法在许多前缀中找到响应地址，因此只能对26%的MSN流量做出决策。对响应地址的需求也限制了Entact可以并行测量的备选路径的数量，并使得它没法实现通过分割聚合地址前缀来增加决策颗粒度。这些原子分配的方式对于Entact的最佳流量分配来讲，可能不是一个很好的近似值估算，因为它前提条件是：需要能够在多个路径上任意地将地址前缀的流量分割并测量。Edge Fabric采用了类似于Entact的方法，但不同的是基于生产流量的被动测量方式，它使用Facebook现有的服务器端的测量基础设施来采集能够代表整个用户群流量的数据，并且能够分割地址前缀以增加决策颗粒度。并且可以使用现有PR路由器所能支持的尽可能多的并行路径。

Espresso是谷歌的SDN流量调度系统，用于控制出口路由。Espresso和Edge Fabric都是由大型内容服务商设计的，在面对PoP节点和流量的快速增长的同时，它们需要克服BGP协议自身和BGP路由器的挑战。它们的高阶设计实现方式都类似：集中控制路由，同时保留BGP作为和对端互联的接口。然而，这两个系统在许多其他重要的设计决策上对其决策因素有不同的优先级排序，这些优先级的排序也最终影响了设计的结果。Espresso使用定制的架构来消除对支持互联网全球路由表的的需求（Google的OpenFlow的硬件无法支持全球路由表），而Edge Fabric则依赖于BGP和供应商的BGP路由器来构建（商业路由器可以轻松支持全球路由表）。Edge Fabric通过隔离PoP节点来限制它的多个路由表的大小，这样每个PoP节点承载用户流量的地址前缀数量就很低（图3）。而Facebook通过隔离地址前缀宣告、入口策略、出口策略和对单个PoP节点的控制来实现了简单性（都是基于BGP协议的标准通用属性），Espresso使用集中的全局控制器，可以将流量通过广域网路由到远端的PoP节点出口，提供了灵活性。Edge Fabric的控制器只在PoP节点内决定出口，并将其推送给本节点内的PR路由器，可以让主机和网络状态之间解耦。另一方面，Espresso将路由决策推给主机，使其灵活性最大化，但需要更复杂的控制器架构和主机上的路由状态保持实时同步，这样才能防止流量黑洞。前面描述了这些权衡以及最后的选择，这都是基于Facebook过去在PoP节点和基于主机路由之间流量控制的经验（早期的Edge Fabric设计更类似于Espresso）。当然，Espresso也有自己的一些方法来应对本节所描述的挑战。

B4（Google的数据中心网络）和SWAN（微软的集中控制器，处理网络拥塞）的集中控制是跨数据中心网络的，在不影响高优先级流量性能的情况下最大化利用率。Edge Fabric也有类似的目标，它也使用集中控制。然而，背景的不同带来了新的挑战。特别是B4和SWAN是在一个封闭的环境中运行的，所有的主机和网络设备都是统一管理的，大部分的流量都可以容忍时延和损失（东西流量，低优先级的用户数据同步的流量为主）。相反，Edge Fabric控制网络和用户的出口流量。此外，大部分是自适应速率的视频流量（南北流量，最终用户的直接流量），其延迟要求远远超过数据中心间广域网的弹性流量。Fibbing集中控制传统的OSPF网络，注入路由信息让域内路由器优选特定路由。Edge Fabric的控制器类似地注入路由，但注入的BGP路由对于全网的可见性和控制要少得多（只在PR路由器生效）。  

性能监控

对于CDN流量工程，现有的技术通过向网络注入测量流量（主动测量）或被动地监控正在运行的流量来测量路径性能（被动测量）。主动测量技术需要通过专属工具产生、收集测量数据或者部署专用测量点。被动测量技术通常需要网络设备的监控功能（一般很贵）。Edge Fabric在Facebook的服务器上采用的是被动测量技术，它允许：1）在不需要测量上百万用户的情况下监控所有路径和服务，2）与并入路径的专用测量设备相比，可以收集更丰富的指标（如SRTT）。   有意了解更多Tier-1 OTT技术趋势，可以添加微信共同讨论：       参考文献：Engineering egress with edge fabric - Steering oceans of content to the world      

编辑：黄飞