导读：如何建立一个可扩展、自动化的点对点链接（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/
