由于以太网的局限性，谷歌从 InfiniBand 和 Cray 的“Aries”互连中汲取了最佳创意，并创建了一个名为 Aquila 的新分布式交换架构和一个新的 GNet 协议栈，该协议栈提供了搜索引擎巨头所提供的那种一致和低延迟几十年来一直在寻找。

这是谷歌所做的事情让 IT 行业的每个人都停下来思考的重要时刻之一。

2003 年的Google 文件系统。2004 年的MapReduce分析平台。2006 年的BigTable NoSQL 数据库。2009 年的仓库级计算概念。2012 年的Spanner分布式数据库。2015 年的Borg集群控制器以及Omega 调度程序2016 年的附加组件。2015 年的Jupiter定制数据中心交换机。2017 年的Espresso边缘路由软件堆栈。仙女座2018 年的虚拟网络堆栈。Google 从未发表过关于其 Colossus 或 GFS2 文件系统、GFS 的继任者和 Spanner 的基础的论文，但它确实在上面的 Spanner 论文中提到了它，并且它确实在冠状病毒期间提供了视频演示去年有关 Colossus 的大流行，以帮助将 Google Cloud 与同行区分开来。

两个旁白：看看问题出在哪里。谷歌正在摆脱数据处理和支撑它的系统软件，并通过调度进入数据中心和边缘的网络，因为它向世界展示了它的手工和技术实力。

谷歌现在另一个有趣的事情是，它没有像所有早期的论文那样透露它在几年前做了什么，而是它现在正在做什么来为未来做准备。计算高层对人才的竞争如此激烈，以至于谷歌需要这样做以吸引那些可能会去创业公司或其众多竞争对手之一的天才。

无论如何，搜索引擎和广告巨头已经有一段时间没有在我们所有人身上投下一篇大论文了，但谷歌再次通过一篇描述Aquila的论文来做到这一点，这是一种低延迟的数据中心结构，它使用自定义交换机和接口逻辑和一个称为 GNet 的自定义协议，与该公司长期以来部署的基于以太网的、数据中心范围的 Clos 网络相比，它提供了低延迟、更可预测和显着降低的尾部延迟。

走不同但相似的道路

借助 Aquila，如果您在阅读这篇论文时稍微眯起眼睛，谷歌似乎已经完成了英特尔可能试图在 Omni-Path 上做的事情，该论文发表在最近举行的网络系统设计与实施 (NSDI) 会议上由 USENIX 协会。具体来说，它借鉴了超级计算机制造商 Cray 创建并于 2013 年 11 月在“Cascade”CX30 机器中宣布的“Aries”专有互连的一些主题。

当然，您会记得，英特尔早在 2012 年 4 月就从 Cray 购买了 Aries 互连，并计划将其部分技术与其 Omni-Path InfiniBand 变体合并，该变体是在 2012 年 1 月从 QLogic 收购该业务时获得的. Aries 具有自适应路由和少量拥塞控制（有时会变得混乱）以及蜻蜓式全对全拓扑，这与超大规模和云构建者使用的 Clos 网络拓扑以及 Hyper-X 网络有时不同由 HPC 中心使用，而不是蜻蜓或胖树拓扑。在不重新连接整个集群的情况下为蜻蜓网络增加容量是比较困难的，但如果你正在安装机器，那就完全没问题了。Clos all-to-all 网络允许相当容易地添加机器，但是机器之间的跳数以及因此的延迟与蜻蜓网络不同。

Cray 的前首席技术官 Steve Scott 领导了其“SeaStar”和“Gemini”以及前面提到的 Aries 互连的设计，这些互连是 Cray XT3、XT4 和 XC 机器的核心，他于 2013 年加入谷歌，直到 2014 年才重新加入 Cray，通过“Rosetta”Slingshot 互连引领其超级计算复兴。斯科特告诉我们，作为谷歌平台组的一员，他非常欣赏网络中尾部延迟的细微之处，但看起来斯科特给他们留下了深刻的印象，即针对特定工作调整的专有协议的重要性，高基数切换绝对峰值带宽，拥塞控制和自适应路由的必要性，比互联网巨头使用的东西更脆弱，还有蜻蜓拓扑。(Scott 于 2020 年 6 月以技术研究员的身份加入 Microsoft Azure，可以合理地预期这家云巨头在 Scott 的帮助下完成了与网络相关的事情。）

简而言之，英特尔花了 2.65 亿美元从 QLogic 和 Cray 购买了这些网络资产，天堂只知道在将 Omni-Path卖给 Cornelis Networks 之前还有多少开发和营销，现在可能希望它发明了像 Aquila 这样的东西。

这个 Aquila 数据中心结构有很多层，目前处于原型阶段，目前还不清楚这将如何与英特尔与谷歌共同设计的“埃文斯山”DPU进行交互和交互。超大规模可能已经在其服务器机群中进行部署。事实证明，位于 Aquila 结构核心的融合交换机/网络设备和 Mount Evans DPU 在各自的路线图上有一个共同的目的地，或者它们在平行的道路上行驶，直到轮胎爆胎。

从零开始，从信元开始，而不是数据包

Aquila 是eagle的拉丁词，它明确地不在支持 Internet 的以太网、IP 或 TCP 和 UDP 协议之上运行，或者尽管如此。（对于这些嵌套协议之间的差异的一个很好的图像，这里有一个很好的解释：“想象一个气动管消息系统。以太网是用于发送消息的管，IP 是管中的信封，而 TCP/ UDP是信封里的一封信。 ”

忘记这一切。Google 全力以赴，创建了它所谓的基于单元的第 2 层交换协议和相关的数据格式，而不是数据包。实际上，一个单元比一个数据包还小，这也是谷歌能够通过 Aquila 结构获得更好的确定性性能和更低的服务器节点之间链路延迟的原因之一。单元格格式针对 RDMA 网络中常用的小数据单元进行了优化，并具有架顶式交换机 ASIC 和网络接口卡的融合网络功能，跨越 Aquila 互连原型的 1,152 个节点规模，它可以平均 4 微秒内读取 RMA。

这种融合的交换机/NIC 野兽、单元数据格式、使用其自己的称为 1RMA 的 RDMA 变体非常有效地处理它的 GNet 协议、带外软件定义的网络结构和蜻蜓拓扑创建了一个自定义的、高速度互连与如果 Aries 和 InfiniBand 在超大规模数据中心有一个爱的孩子，并且这个孩子可以在必要时在其边缘说话和听到以太网会发生什么非常相似。

让我们从 Aquila 硬件开始，然后沿着堆栈向上工作。首先，谷歌不想在这上面花很多钱。

“为了维持一个规模适中的团队的硬件开发工作，我们选择在同一硅片中构建具有 NIC 和交换机功能的单芯片，”在 Aquila 工作的 25 名谷歌研究人员在论文中解释道。“我们的基本见解和出发点是，可以以适度的额外成本将中基交换机集成到现有的 NIC 芯片中，并且可以将许多称为 ToR-in-NIC (TiN) 芯片的这些 NIC/交换机组合连接在一起通过 Pod 中的铜背板，一个与传统架顶式 (ToR) 交换机大小相当的外壳。然后，服务器可以通过 PCIe 连接到 Pod 以实现其 NIC 功能。TiN 交换机将通过优化的第 2 层协议 GNet 提供与同一 Clique 中的其他服务器的连接，并通过标准以太网提供与其他 Clique 中的其他服务器的连接。”

这个“torrinic”芯片上有很多东西。Amin Vahdat 是谷歌系统和服务基础架构团队的工程研究员兼副总裁，在此之前曾长期领导网络基础架构团队，去年这个时候告诉我们，SoC 是新的主板，而创新的焦点，我们并不感到惊讶的是，每个 Aquila 芯片实际上都是一个复合体，其中两个 TiN 在同一个封装中（但不一定在同一个母鹿上，请注意）。Vahdat 是 Aquila 论文的作者之一，无疑推动了开发工作。

如您所见，设备中有一对 PCI-Express 3.0 x16 插槽，允许将一个 256 Gb/秒的胖管道连接到单个服务器或两个 128 Gb/秒的半胖管道用于两台服务器。位于此 PCI-Express 交换机另一侧的是一对网络接口电路——一个讲 100 Gb/sec IP 并且可以通过芯片讲以太网，另一个讲专有 1RMA 协议并连接到 GNet细胞开关。

该单元交换机有 32 个端口，以 28 Gb/秒的速度运行——正如谷歌在上面指出的那样，没有交换机那么多端口，也没有端口那么快。取消编码开销后，这些 GNet 单元交换通道以 25 Gb/秒的速度运行，这与 IBM Power9 处理器上的“Bluelink”OpenCAPI 端口以及“Ampere”A100 GPU 中的 NVLink 3.0 管道中的通道相同。和相关的 NVSwitch 开关。在这些 25 Gb/秒的通道中，有 24 条用于通过铜线链路连接 pod 中的所有服务器节点，并且有 8 条链路可用于将多达 48 个 pod 互连到单个 GNet 结构中，称为“集团”，使用光链路。Cray 和现在谷歌使用的 Dragonfly 拓扑结构明确设计用于限制光收发器和电缆的数量，以便远程连接服务器 pod。

Aquila TiN 具有输入和输出数据包处理引擎，如果来自单元交换机的数据需要离开 Aquila 结构并进入 Google 的以太网网络，则可以与 IP NIC 和以太网 MAC 连接。

谷歌表示，Aquila 织物的单芯片设计旨在降低芯片开发成本，同时“简化库存管理”。在冠状病毒大流行期间一直在等待交换机或 NIC 交付的任何人都知道 Google 在说什么。NIC 的缺乏肯定会减缓服务器的销售。几个月前情况非常糟糕，我们通过经销商听说的一些 HPC 商店正在转向英特尔的 100 Gb/秒 Omni-Path 设备，因为它至少有货。

这种融合网络架构的要点是，谷歌在其数据中心规模的 Clos 网络中嵌套了一个非常快速的蜻蜓网络，该网络基于叶/脊拓扑，不是全对全网络，但确实允许一切都以具有成本效益和可扩展的方式相互连接。

谷歌表示，光链路允许 Aquila 吊舱相距 100 米，并在互连吊舱之间施加 30 纳秒（谷歌称纳秒）的每跳延迟，这是通过前向纠错减少噪音并产生一些潜伏。

如今，大多数交换机都内置了计算功能，谷歌表示大多数交换机都有一个多核 64 位处理器，其主内存介于 8 GB 和 16 GB 之间。但是，通过使用外部 SDN 控制器并使用 Aquila 芯片封装上的本地计算作为每个 TiN 对的端点本地处理器，Aquila 封装可以使用 2 MB 的 32 位单核 Cortex-M7 处理器专用 SRAM 来处理 SDN 堆栈的本地处理需求。运行 GNet 堆栈的外部服务器没有泄露，但这是 Google 的常见设计。

SDN 软件是用 C 和 C++ 编写的，由大约 100,000 行代码组成；Aquila 芯片运行 FreeRTOS 实时操作系统和 lwIP 库。该软件将所有低级 API 公开给 SDN 控制器，该控制器可以访问并直接操作设备的寄存器和其他元素。谷歌补充说，将 Aquila 的固件分发到控制器上，而不是设备上，是绝对有意为之的，其想法是 TiN 设备可以启动 GNet 和以太网链接并尝试链接到网络上的 DHCP 服务器，并等待来自中央 Aquila SDN 控制器的进一步配置命令。

关于 Aquila 网络的一个有趣之处在于，由于它是蜻蜓拓扑，因此您必须从一开始就配置网络中的所有节点，或者每次添加机器时都必须重新连接以获得网络的全部带宽. （这是全对全网络的缺点。）所以谷歌会这样做，然后根据需要添加服务器。这是服务器和网络的示意图，看起来像所有的吊舱：

Aquila 设置在一个机架中有两个 24 个服务器的 Pod，在一个 clique 中有 24 个机架。谷歌正在使用其标准服务器机箱，其适配器卡上有 NIC，在这种情况下是一个 PCI 适配器卡，它链接到一个交换机机箱，该机箱在六个适配器卡上具有十几个 T1N ASIC。蜻蜓网络的第一层是在机箱背板上实现的，有96个光GNet链路从吊舱出来，将48个吊舱连接在一起，全对所有，每个有两条路由。

让许多 ASIC 实现网络的一个副作用是任何给定 ASIC 的爆炸半径都非常小。如果两台服务器共享一个 T1N 并且 T1N 包有两个 ASIC，那么一个包的故障只会淘汰四台服务器。如果一个有 48 台服务器的机架中的一个架顶式交换机烧毁，那么 48 台服务器就会停机。如果整个 Aquila 交换机机箱发生故障，仍然只有 24 台机器被淘汰。

展望未来，谷歌正在研究在未来的 Aquila 设备中为 TiN 设备添加更多计算能力，每个 NIC 的数量相当于一个 Raspberry Pi，这样它就可以运行 Linux。这将允许谷歌向网络添加更高级别的 P4 编程语言抽象层，这是它绝对想做的。

在早期测试中，Aquila 结构能够在结构往返时间（网络术语中的 RTT）中具有低于 40 微秒的尾部延迟，并且在键值上跨 500 台主机的远程内存访问时间低于 10 微秒名为 CliqueMap 的商店。与现有 IP 网络相比，即使在高负载下，该尾部延迟也小 5 倍。

最后一个想法。Aquila 网络的规模并没有那么大，更多地扩展计算将意味着扩展 T1N ASIC 具有更多端口，并且可能（但不一定）具有更高的信号速率以增加带宽以匹配 PCI-Express 5.0 速度. （毕竟这是一个原型。）我们认为谷歌会选择更高的基数而不是更高的带宽，或者至少将差异分开。

然而，还有另一个性能因素需要考虑。七年前，当 Google 谈论 Borg 时，它在一个 pod 中有 10,000 到 50,000 台服务器，这已经很多了。但是谷歌使用的服务器每个插槽可能有几个到十几个核心，每台机器可能有两个插槽。目标很高，称其为平均 20 个内核。但是今天，我们每个服务器插槽有几十个核心，每个插槽有几百个核心，所以可能只需要几千个节点就可以运行除了谷歌最大的工作之外的所有工作。甚至大型作业也可以跨 Aquila pod 分块，然后通过常规以太网链路聚合。在那段时间内，对于整数工作，内核数量增加了 10 倍，每时钟指令 (IPC) 增加了大约 2 倍；浮点性能提高了更多。将其称为每个节点的性能提高 20 倍。据我们所知，谷歌的 pod 大小不需要拉得太远。

更重要的是，(O)1000 集群，作为技术论文的缩写集群，大约有数千个节点，即使它们无法运行最大的模型，也足以完成重要的 HPC 和 AI 工作负载。看看哪些工作适合 Aquila 结构，哪些不适合，这将会很有趣，有趣的是，这项技术可能非常适合许多初创公司、企业、学术和政府企业的规模。因此，即使 Aquila 现在无法扩展，它也可能成为 Google 云上非常高性能的 HPC 和 AI 服务的基础，其中 (O)1000 恰到好处。