技术向：云网融合的探索

本文主要是关于如何设计一个Cloud-Scale的操作系统和通过一系列紧耦合优化运营成本。

云网融合概述

一些事实

云计算的快速发展和5G建设的全面启动使得“云网融合”这几个字频繁的出现。云和网的融合该怎么做？我们来看一些事实。所谓融合肯定是一种你中有我，我中有你的耦合状态。从技术的角度来看，主要就是在通信网中引入云计算的技术，即网络->云化，以及在云计算中引入网络的技术，我们在后面将这个议题称为云->网络化。

前一个话题非常容易理解，无论是运营商5G核心网还是很多公有云的NFV都有这方面的实践。而后一个话题云网络化就是我们今天要探讨的一个议题。是P4可编程交换机和SR可编程网络？是边缘计算或者算力网络？

分布式计算发展

我们还是以史为鉴，看看Amin博士在2020 SIGCOMM keynote的总结。

从早期的人机通信到计算机之间的相互通信，以及传统的机器互通或者业务互通，计算机体系结构的设计主要是以静态数据和计算逻辑为主。本质上是撰写代码去处理数据。

当发展到第三代末期的时候，复杂的应用程序已经无法在单台机器上运行了。阿里巴巴诞生在这个年代，而阿里云的诞生本质也就是第四代分布式计算架构的代表。多核心处理器的出现，Spine-Leaf这样的分布式网络架构，Overlay技术等等。伴随着这些技术人与人的沟通交互变得更加便捷，也没有了难做的生意.

但是这一带架构又遇到一些问题，一方面是由于交互产生的数据流动需要更加实时的计算。从Hadoop到Spark、Flink的转变就可以看出人们对数据交互实时性的需求.另一方面是AI的兴起使得计算范式发生了巨大的变化，人开始向机器寻求洞察力。这种洞察力体现在由机器以数据为中心的计算模式，这种模式并不是简单的去处理数据，而最大的变革是要从数据中抽取能够产生决策的代码。

在这个过程中又遇到了摩尔定律的另一堵墙，核数量、Cache size、片上网络和功耗的限制使得多核处理器发展也遇到了瓶颈。当然可以靠堆一系列资源也可以解决一些问题，但这样又面临着成本的压力。

服务成本优化

正如Amin在第五代分布式计算架构所述，核心是由于摩尔定律受限于单个Socket处理器上的处理能力，因此整个系统更多的要从如何低成本交付服务上考虑。

例如公有云服务的竞争，本质上是运营成本的竞争，因此在这个过程中XGW和神龙智能网卡也就是业务驱动下的产物。一个是针对云网络中的NFV负载做硬件的加速，另一个是解决Hypervisor层的性能损耗。

那么新一个问题来了，底层网络如何降本增效？客户如何高质量低成本的访问到云服务？广域网CDN、数据中心基础架构、SDWAN等等，这些就是云->网络化的关键技术。

DPU的出现

在数据中心内部，将底层网络变得更加简单，然后更多的功能集成到DPU中采用计算 存储和网络更加紧耦合的方式，这就是DPU的内生逻辑。

而DPU出现的原因，本质上就是来自于Scale-out的路逐渐在规模增加后走到了极限。

Amdahl定律大家都懂，Scale-Out的路似乎因为规模正在终结，因此在第五代分布式计算架构需要从计算机体系结构上考虑更加紧耦合的解决方案来获得性能的提升。智能网卡提供了一些基本的连通性加速和批量数据解析、加解密、可靠传输等工作负载的加速，这些数据处理业务固然重要。但它并不是全部，紧耦合需要发生在一切有可能发生的地方，并且要以数据为中心，围绕着数据构建一个平衡的分布式系统才是第五代分布式计算架构的核心。

以数据为中心平衡调度才是整个系统架构的关键词。一方面是计算机体系结构上向以数据为中心的处理架构靠拢，通过一些紧耦合的架构追求单节点的性能。另一方面是整个数据中心或者整个阿里云作为一个操作系统更加均衡的调度数据处理任务。

紧耦合

首先我们来看计算机体系架构的问题，如何设计更加紧耦合的架构。

第一个松耦合的地方便是软件和硬件之间通过通用处理器的指令集交互，针对一些数据密集型的计算任务通用处理器力不从心，因此诞生了大量的专用加速芯片。当然另一方面CPU厂商也不停的往里面加新的指令集。

第二个松耦合地方是在物理设备和虚拟机之间的overhead，利用DPU或者智能网卡构建裸金属服务器和HostOverlay便是在这个地方将物理和虚拟环境更加紧密的耦合在一起。

还有一个松耦合的地方是应用和网络间通过传输层协议解耦，虽然有了一些传输层协议的发展，例如QUIC和RoCEv2，但是真正的应用和网络的紧耦合技术方案还并没有那么清晰的展现出来。QUIC通常用于广域网弱质量时的通信传输优化，RoCEv2主要用于数据中心内部低延迟的跨机DMA访问。

因此我们还会不停的反思，为什么需要传输层去耦合应用和网络。网络保证好拥塞控制、可靠传输、及提供足够大的带宽就好，理应和应用完全无关？

应用、网络松耦合的问题

在SDWAN场景中，由于应用和网络无法协同，通常SDWAN网关基于应用的路由策略都需要DPI引擎，而DPI针对加密流量通常会发生一系列误判。因此Multipath的场景只能简单的拿5G和WiFi切换说事.

而另一方面,为了保证云网络服务访问的质量,通常用户需要搭配复杂的SDWAN 负载均衡 CDN等NFV.

Ruta紧耦合应用和网络

一个更形象化的比喻，应用和网络的紧耦合对应的概念就是车路协同，也就是我常说的赋予应用选路的能力.这样顺带解决了边缘计算和算力网络资源发现等一系列复杂的问题。

路况信息也就是网络中常见的Linkstate,而车就是应用报文。车路协同的关键就是路标如何定义，我们很简单的参考了Segment Routing构建了这个网络。因此在边缘计算中，算力有了这样一个路标点和一系列路况信息供给终端应用选择。这些是我们设计一套新的传输层协议的刚需。

所以基于这种思路，我们设计了Ruta[1][2] ，本质上有两个目的：

• 赋予应用更多的可编程能力
• 降低网络中的网元数量和复杂度，把一些选路跨越VPC负载均衡等各种复杂的有状态的业务熟悉卸载到终端。

同时我们也重构了路由协议的框架，使得路由协议通过ETCD更加容易的和应用交互。

Ruta实际上是在UDP基础之上构造了一个应用程序易于理解的编码方式，而这样的编码方式来源于SRv6但是没有了IPv6的依赖和header过长需要压缩的顾虑。同时协议编码在传输层之上，使得应用非常容易控制。而网络设备处理也非常简单。导流到VPC网络也可以通过Endpoint Behavior灵活编程。

当我们在阿里云和腾讯云上部署了20个Fabric节点。具体演示可以参考[3]

整个系统我们就可以完成200ms可达，并且零丢包。

通过LinkState统计，您可以看到丢包其实发生在一些特定的地方，从运营的角度可以很容易的绕开。如果用网络去做调度，调度本身的计算资源和应用识别都会带来很大的负担，大规模部署时的SPF计算也是很大的成本开销。因此而使用终端应用通信库去调度则把这一部分计算成本转移，而且这些应用明显自己知道带宽的需求，从而更加高效的利用了网络资源。

数据中心网络

谈完了广域网和边缘计算的网络架构，我们再回到数据中心内部，看看这里有那些可以挖掘性能的地方。一个最大的挑战就是算力的增长使得训练的时间越来越短，而网络通信的延迟则越来越明显，占的比重越来越高。随着模型参数的增多，All-Reduce对于网络带宽的压力也越来越大。

摩尔定律失速

我们注意到一个有趣的现象，内存的性能一直没跟上摩尔定律的发展速度，因此内存墙导致了CPU也逐渐失速。但是另一方面，网络这些年的带宽发展速度远超摩尔定律。因此我们很自然的会想到，里面有没有什么可以挖掘的机会。至少取长补短。

CPU I/O和片上网络

实际上您会发现一颗处理器上塞入了大量的核后，片上网络布线是一个非常有挑战的事情，并且片上网络的关键在于如何有效的路由和避免拥塞。而片上网络的对外带宽瓶颈则来自于一颗处理同时需要支持PCIe 内存 处理器互联等三套总线架构。片上网络能否延拓出来和物理网络更好的紧耦合呢？

"北桥"的回归

当我们使用DPU连接处理器和其它器件时，是否想到有个主板上消失很多年的东西叫北桥？北桥消失的原因是为了降低通信延迟和扩大带宽，主要原因是受到FSB通信带宽的限制。而DPU的出现，是因为通信带宽因为一些新的技术远超摩尔定律的发展，同时片上资源紧张，需要将很多功能分担出来。

PAM4和Co-Package Optical技术的出现使得北桥可能再次以DPU的形式回归，同时又紧耦合了网卡等跨机通信组件。

片上网络和数据中心网络

这样的融合，本质上便是将片上网络和数据中心网络紧耦合在一起了。那么放大一步，看看整个数据中心

片上网络如何与数据中心网络紧耦合？在这个问题上探讨，涉及一个拓扑的问题。数据中心FatTree/CLOS的拓扑用了很多年，未来是否适用？

我们来看现在世界第一的超算给我们的答案，片上网络和主机网络的紧耦合，6D-Torus的拓扑结构都是它能取得第一的基石。

CLOS vs *D-Torus

但是数据中心网络拓扑结构用CLOS构建Spine-leaf已经成为一种思维定式，所以您会看到阿里巴巴在EFLOPS可以构建double FatTree和一些调度算法混合来加速AI训练的过程。而Google TPU则是采用了2D-Torus，并且在后期多套系统也是采用*D-Torus扩容。

当然这里也没有好坏之分，如果考虑到性能本身和非阻塞，以及云计算场景中多用户``多应用混跑，肯定是FatTree好。但是非阻塞的成本也较高，所以几乎所有的数据中心都有收敛比的设计.在超大规模的部署过程中，3D-Torus是一种降低成本的选择，并且可扩展性也更好，两者最大的不同在于3D-Torus的环状结构对于以目的地址转发的以太网协议来说可能是一个灾难。但是另一方面，随着Segment-Routing和TI-LFA这样的技术出现，似乎环形拓扑也不是什么灾难了，可靠性还会更好。

Ruta协议的最大优点是两个，一个是可以使用linkstate获悉全网拓扑和拥塞程度以及链路失效情况，另一个是完全自主的路径决策，并通过Segment Routing的方式可以构建指定路径的转发。它为数据中心构建基于*D-Torus的拓扑提供了技术支撑。

例如以AI训练的Ring Allreduce算法为例，Ruta可以在随路转发的时候进行Ring Allreduce。先从简单的一维Ring谈起，如下图所示，节点寻找经过 >N/2个节点的某个节点作为Segment-List中的一段，保证顺时针的数据流向，而最后一个Segment指向自己。

由于目的节点为4，报文沿着环路发送到节点2，2将参数保存并更新，然后转发给3，以此类推，节点4完成参数同步操作后，弹出4标签，灌入1标签继续往1发。最终1收到该报文证明整个环上已经完成同步, 因此也不需要防环了，正好借助于环构建可靠传递机制。

冯诺依曼架构

内存墙

接下来一个问题是内存墙和指令集的问题，冯诺依曼架构本身是一种数据共享，串行执行，指令和数据放在一起的计算范式，但是存储器的发展速度并没有赶上摩尔定律, 拖慢了整个行业，因此才会有一些领域专用的芯片出来。

而这些芯片本身现阶段只会发生在对AI处理，或某些特殊的业务上。如何泛化出一个更加通用的以数据为中心的处理架构才是我们需要考虑的问题。

I/O决定了标量处理模式

追究到根源，本质上是因为那个年代的输入设备和输出设备是标量结构，导致的整个冯诺依曼架构和指令集体系结构是以标量顺序处理为主。

超标量结构，SIMD，或者VLIW暂时解决了一些问题。但是只能针对一些For-loop或者顺序执行的场景，有大量分支的逻辑计算场景就有些力不从心了。所以我们还是要从数据计算本身来看。

而在云时代，实际上大量的标量交互已经发生在了前端和终端。我们可以很容易的用低代码的方式构建表格，让最终用户填写数据。云端的交互更多的变成了一种API对结构体数据的处理, 大量的计算伴随着数据的流动发生。这就是流式计算的处理方式，而另一个就是计算本身以某一段程序存在，或者低代码的方式构建在Serverless的基础上。那么如何围绕着这样的架构构建指令集呢？

Data-Centric ISA

以数据计算为中心的指令集体系结构和冯诺依曼结构的最大区别就是输入输出设备本身由标量变为了结构体，但是相对于一些矢量处理架构，您可以注意到结构体本身的每个字段长度是不等的。而这些操作的主要目的就是将运算中的跟数据解析封装批量写回等操作的。对应到现在的结构就是SideCar和Serverless计算本身在体系结构上的紧耦合。

具体的技术细节就不多展开了，如何实现它存在很多工程上的Trade-off. Xeon Phi和安腾的失败是一个很好的工程上的教训。但是尊重很多处理器厂商在分支预测、缓存优化等技术上的优势也是必须的。

同时相对于ServiceMesh，片上网络和数据中心网络的紧耦合，更多的兼顾了底层网络的调度。使数据在整个体系结构上充分的流动。

云即操作系统

接下来要讲的是这样的处理器结构和片上网络，数据中心网络的紧耦合，将整个云构建成一个大的系统。

如果把这个大的系统拼起来构成一个操作系统，你会看到计算、网络和成熟的存储技术已经基本上搭建好了一个紧耦合的平台。但是作为一个操作系统，还缺什么？调度系统，最后我们就来谈谈这个问题。

Amdahl’s lesser-known law: 1Mbps of IO for every 1Mhz of computation in parallel computing

当我们把整个云看作一个大的操作系统后，面临的是10Tbps以上的数据流入，如何均匀的安排到数万个处理器核心上。一致性Hash有大量内生的缺陷，而数据流量如何协同关联调度，自组织避免拥塞，就近计算，这一系列问题本质上都是NP-Hard的大问题。但不妨在一些小的地方做一些优化，考虑一下数据流的分布维度，统计调度，降低Cache-Miss Rate就是关键了。

洋洋洒洒写了这么多，也就是技术扶贫一下，分享给各个云，当然有些着迷于光的云是不会感兴趣的。但当你逐渐把这一切从头到尾想清楚了，Once-in-a-generation的机会就抓住了。

云的下半场比的是成本，降本增效谁做的好谁才能活下来.

Reference

[1]Ruta ControlPlane:

https://tools.ietf.org/html/draft-zartbot-srou-control-00

[2]Ruta DataPlane:

https://tools.ietf.org/html/draft-zartbot-sr-udp-00

[3]Ruta Demo:

https://github.com/zartbot/ruta_demo/