Facebook 的自动化点对点连接

灵雀云

发布于 2022-06-06 10:38:05

5430

发布于 2022-06-06 10:38:05

文章被收录于专栏：云原生技术社区云原生技术社区

导读：如何建立一个可扩展、自动化的点对点链接（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 的表格中看到新的会话是活跃的。