导读:如何建立一个可扩展、自动化的点对点链接(Peering)管理系统?本文介绍了Facebook/Meta 在自动化Peering方面的最佳实践。
本文译自 Peering automation at Facebook[1]。作者:Jenny Ramseyer, Jakub Heichman
互联网上的流量通过许多不同类型的链接流转。通过 Peering 这种快速且可靠的方法能让不同的网络和服务商之间交换流量。最初,我们常常通过费力不讨好的手动过程来管理 Peering(这显然过于古典)。
可靠的 Peering 对于 Facebook 和每个互联网使用者来说都是至关重要的。但是,如何建立一个可扩展的、自动的 Peering 管理系统,并没有行业标准。因此,我们开发了一种新的自动化方法,可以更快地进行自助式 Peering 配置。本文将分享我们在自动化 Peering 方面沉淀的最佳实践。
自动化 Peering 是怎么运作起来的呢?我们以 Facebook 的用户场景为例。你正准备观看你的朋友刚刚发布的可爱猫咪视频,我们来追踪一下“猫咪视频”到“你的设备”的路径:
选项 A:通常是较慢的、不可靠的、高延迟的路线:
你看到朋友的帖子里有个可爱猫咪视频,你点击了它,迫不及待地想看!在视频到达你的设备之前,Facebook 需要使用性能最佳、最短的可用路径将其发送到你的 ISP。Facebook 和你的 ISP 之间可能还有许多其他网络(通常被称为传输网络)。它们可能在具有潜在容量限制的次优位置相互连接,从而导致猫咪视频缓慢到达您的面前。没有人愿意看一个一直缓冲的猫咪视频吧!
选项 B:通常是更快、更可靠、更直接的路线:
你点击猫咪视频来观看可爱的猫! 在视频到达你的设备之前,Facebook 的流量控制器就意识到有一条快速、直接的方式到达你的 ISP,中间没有其他网络。猫咪视频通过对等交换传播,这是一个共同的交汇点,许多不同类型的网络通过在它们的路由器之间建立边界网关协议(BGP[2])会话来相互连接。这些 Peering[3] 会话允许他们直接交换比特,包括猫咪视频,这有助于提高用户体验的质量、性能、延迟和可靠性。
为什么我们将公共 Peering 自动化
在整个行业中,手动配置 Peering 是一个缓慢的、低效且易出错的过程。随着网络连接到新的互联网交换机(IX)并将多个路由器连接到每个 IX,这一挑战变得更大。
在开发我们的自动化系统之前,我们遇到了同样的困难。同行会通过电子邮件向我们请求建立 Peering 会话。接下来,我们的一位边缘工程师将验证电子邮件并检查我们的相互流量水平。为了确认流量水平是否合适,该团队成员必须检查大量内部仪表板、报告和规则手册,以及外部资源,例如潜在 Peering 的 PeeringDB 记录。然后,团队成员将使用一些内部工具来配置 BGP 会话,回复给对等方,并等待对等方配置他们的网络侧。这种方法有几个问题。首先,没有集中的地方来查看传入的对等请求或现有的对等状态。请求可以通过电子邮件或其他几个带外系统到达。边缘工程师必须跟踪、解析和手动验证每个请求。接下来,对于每个请求,团队成员必须手动启动和监控每个对等点的内部工具,然后,一旦完成,输入对每个对等请求的响应。根据最后的统计,我们估计这个过程每周要花费 9 个多小时--每个工作周有一整天的时间浪费在不必要的手工过程上。
解决方案
我们很高兴地宣布,同行现在可以通过我们的 facebook.com/peering[4] 页面请求他们自己的公共对等会话。
PeeringDB 的 Oauth 服务
PeeringDB[5] 是一个开源的网络,其对等网络信息的数据库,由 PeeringDB 管理员验证和审核。我们相信 PeeringDB 数据库具有价值,并且与业内的其他人一起通过赞助来支持它。由于大多数对等网络将其 PeeringDB 记录作为其他网络使用的真实来源,因此我们将 PeeringDB 的 OAuth 服务视为标准化对等管理身份验证方法的机会。
为了确保在我们的对等页面上提出的对等请求是来自授权人,我们要求请求者使用其 PeeringDB 登录名进行身份验证,并代表他们的网络组织利用 PeeringDB OAuth 服务。对等方不需要提供任何其他身份验证--不需要 Facebook 账户。一旦通过验证,对等方将看到其网络与 Facebook 的所有现有公共对等会话的列表,并可以提交新请求。
在请求会话后,我们的内部流程将接管。所有的 Peer 需要做的就是等待我们的自动电子邮件并配置他们的网络侧。我们还建立了一个监控系统,对我们的对等邮箱进行排序。如果系统检测到 peering 请求,它会自动回复指令以将 Peer 引导到我们的 peering 页面。当然,我们仍会监控收件箱以响应任何非对等查询或支持请求。但这个新引擎大大减少了梳理电子邮件和验证请求所花费的时间。
一旦收到请求,请求就会进入审核队列。如果请求被批准,另一项服务就会启动一个工作流程来建立 peering。首先,它查询 PeeringDB 和我们的内部表以验证和收集相互 peering 信息,如 IP 地址和最大前缀设置。接下来,它在 Facebook 的路由器上配置会话。之后,它给对等方发电子邮件,确认 BGP 会话在 Facebook 侧已准备就绪,并等待 Peer 出现。然后,该工作流会每天检查会话是否建立。在第二、第三、第七和第十三天,它会向 Peer 发送电子邮件,提醒他们配置会话。一旦我们的工作流程检测到所有会话都已建立,我们的工作流程就会发送一封最后的确认邮件。这时,我们的 Peer 应该能够在 facebook.com/peering 的表格中看到新的会话是活跃的。
创建行业标准
自推出以来,我们已收到 170 多个 peering 请求,并批准了其中的 149 个。因此,我们已经自动推送了 1400 多个公有 peering sessions --每周节省的时间超过 8 小时。
使用 PeeringDB OAuth[6],我们能检查 peering 请求提交的有效性,并在对等启动过程中自动执行更多步骤。根据我们使用该系统的经验,我们建议在其他公共对等自动化应用和实施中利用 PeeringDB OAuth 作为行业标准。
在我们的公共对等自动化成功的基础上,我们正在研究如何使我们的专用网络互连(PNI)自动化。私有 peering 比公有 peering 量大的多,我们希望在今年晚些时候提供自助服务选项。我们还在探索使用 PeeringDB OAuth 作为我们为网络伙伴提供的其他服务的替代登录服务的可能性。
引用链接
[1]
原文链接: https://engineering.fb.com/2021/05/20/networking-traffic/peering-automation
[2]
BGP: https://engineering.fb.com/2021/05/13/data-center-engineering/bgp
[3]
Peering: https://engineering.fb.com/2017/08/21/networking-traffic/steering-oceans-of-content-to-the-world
[4]
facebook.com/peering: https://www.facebook.com/peering
[5]
PeeringDB: https://www.peeringdb.com/
[6]
PeeringDB OAuth: https://docs.peeringdb.com/oauth/