日前，在国际权威网络顶会SIGCOMM 2022上，阿里云共计6篇高质量论文被主会收录，占收录总数的10%以上，创下了国内历届参会企业的最好成绩。
在基础网络领域，阿里已布局多年，基于可编程芯片技术的数据中心网络和超融合网关设备，构建了端到端的网络性能可预期能力，建成全球超大规模数据中心内的“高速网”，可支持超过10万台服务器的集群弹性扩展能力。
今年年初，阿里巴巴还入选了AI2000评选的全球十大计算机网络研究机构。
这次入选SIGCOMM的论文包括阿里云自研的下一代高性能RDMA网络协议Solar、端网融合可预期数据中心网络架构、可编程网络稳定性保障系统等，这些关键技术构建了阿里云下一代数据中心网络架构——可预期高性能网络，为上层应用提供稳定的可用性、带宽和低延迟保证的网络。
作为可预期高性能网络的关键技术成果之一，本文将对“µFAB”和“Solar”这两篇发表在SIGCOMM2022主论坛的论文进行深度解读。
论文全称：
- 《µFAB：Predictable vFabric on Informative Data Plane》（µFAB：基于信息化数据面的可预期网络）
- 《From Luna to Solar：The Evolutions of the Compute-to-Storage Networks in Alibaba Cloud》（从luna到solar：阿里巴巴的存储网络演进）
01 数据中心为何需要“可预期网络”
当前的数据中心发展面临重大挑战，无论从硬件更迭，应用规模和架构演进都对网络提出了更高的要求。
首先，随着CPU、GPU、TPU、DPU等新型算力硬件的不断推陈出新，大量的数据需要网络进行交互。存储介质的的不断推陈出新，使得磁盘处理的时延从毫秒级降低到了微秒级别，数据读取的吞吐也得到了极大的提升，从而使得网络逐渐成为端到端性能的短板。
其次，ML/HPC、存储、数据库等大型新型分布式系统和应用，对于性能越来越敏感，作为端到端性能的重要一环，势必要求网络提供极致的网络传输服务。例如，ESSD存储要求百万IOPS和100微秒的访问时延，这种情况下任何网络的抖动都会造成应用性能的下降。
另外，分布式机器学习在单集群部署规模已达到10K-100K加速卡的情况下，需要频繁的数据聚合和再分配，依赖网络带宽的保障和微秒级别的网络时延，系统的瓶颈已经逐渐从计算转移到了网络传输。
此外，数据中心的资源池化（包括硬盘、GPU，甚至内存等）已成为主流。资源池化能够带来应用部署的便利，并且不同资源可以独立进行演进升级，更能节省资源降低使用成本。
但资源池化对于网络有非常苛刻的要求，各种资源至少需要100G以上的接入网络带宽和10us以内甚至2us以内的时延。随着内存池化的研发，对于网络的依赖会更加迫切。
02 µFAB：基于信息化数据面的可预期网络
随着云计算不断发展的今天，高性能存储、分布式机器学习、资源池化等应用和架构的变革，对于网络传输的要求越来越高，即使微秒级别的网络异常也会使得应用受影响。而传统的“尽力而为”的网络服务模型已越来越不适应未来应用的需求。
可预期DCN服务模型
µFAB的目标，是在云数据中心为租户提供带宽保障、低延迟保障、以及最大化利用网络带宽资源。
但是，在目前的网络架构中，要同时实现这三点是非常困难，主要原因是：之前的工作通常把网络当做一个黑盒，利用时延、探测等一系列的启发式算法来做速率控制和路径选择，这样便造成了需要毫秒级别的收敛时间，难以满足应用日渐增加的对于性能的需求。
µFAB的设计理念则恰好相反，核心的思想就是网络的透明化和信息化，即是利用可编程网络数据平面提供的链路状态和租户信息，并将这些信息反馈到主机侧用于智能的速率控制和路径选择。
上图所示µFAB的服务模型，每个租户会被分配一个虚拟的网络（Virtual Fabric），该虚拟网络为租户提供最小带宽保障，最大化利用资源，低长尾延迟等三个SLA保障。
而租户的最小带宽分配遵循云的弹性部署规范，租户总带宽之和不会超过网络物理总带宽。µFAB利用可编程网络提供的精确信息，再通过端网协同的机制达到上述目标。
端网协同的具体工作方式为：
- 一方面，主机侧的µFAB-E模块发送探测包，用以获取网络的信息，从而指导其做“速率控制”和“路径选择”。
- 另一方面，网络交换机上的µFAB-C模块收集链路状态和租户的信息，并将这些信息做聚合，插入到发过来的探测包中，反馈给µFAB-E。
带宽延迟保障算法
有了网络透明化和端网协同，如何才能做到带宽和时延的保障呢？
µFAB使用的是按权重分配的做法，这样做的好处是可以很快就能判断出带宽是否得到了满足。即发送窗口的计算方法为：
其中，
是按租户的权重进行的按权分配，∑𝘸而是交换机维护的所有租户的发送窗口之和，
则是根据链路的负载进行的调整，用于最大化链路利用，同时做拥塞避免。
𝜙，𝘸由探测包携带到网络交换机中，∑∅，∑𝘸由交换机维护的租户信息的聚合，而tx，qlen是交换机维护的网络链路信息。
那么，当多个租户同时有流量请求的时候，是不是大家一起发流量就会造成网络拥塞，从而导致长尾时延呢？
µFAB在解决这个问题同时保障长尾低时延的做法是：允许租户无论何时都可以按照最小带宽保障发送，但只有在网络有剩余带宽的情况下，才逐渐地增大发送速率。
这么做的原理是，最小带宽是租户的SLA保障必须满足，而尽可能的提高发送速率则是额外的奖励，时效性要求相对较低。这样既满足了租户对于随时获取最小带宽的承诺，又使得在有多租户突发流量的冲突的时候，依然能够保障网络的长尾时延。
另一个重要的点是，µFAB能够充分利用整个网络的带宽资源，当一个路径上的带宽资源已经被分配完时，能够快速的进行路径切换，从而使用多个路径的网络带宽资源。
在路径切换时，需要考虑两种场景：
- 一是当前路径的带宽已经不满足租户SLA，这种情况需要立刻进行路径切换，但也要注意不要过于频繁地连续切换。
- 二是发现有路径的更多带宽资源的时候，这种情况的路径切换是一种最大化利用网络资源的行为，但相对来说没有紧迫的时间需求，因此不用做得过于频繁。
理论分析和硬件实验
µFAB的理论分析表明，µFAB具备快速收敛，带宽和时延保障等特性，在路径切换中也能做到快速收敛不会造成网络震荡。
我们分别在FPGA和SOC的硬件网卡和Tofino交换机上做了相应的算法实现，并在三层fat-tree的网络拓扑上做了网络层验证和应用层验证。
实验表明，µFAB能提供给租户最小带宽保障和长尾低延迟，同时提供最大化的网络带宽利用，即使面对网络故障的场景下，依然能够快速收敛。
为了验证µFAB对于应用的实际增益，我们将一个租户运行时延敏感型的Memcached，另一个租户运行大带宽的MongoDB应用进行对比实验。
实验表明，µFAB能实现接近于理想状态下的QPS（Query Per Second）和QCT（Query Completion Time）。这是因为µFAB总是能正确的选择流量路径，从而实现性能的隔离，以及快速的响应网络拥塞。上图可以看出µFAB能为应用等提供2.5倍的QPS提升，21倍的长尾延迟下降。
03 从luna到solar：阿里巴巴的存储网络演进
与传统的“尽力而为（best effort）”的网络设计理念不同，可预期高性能网络利用软硬结合，跨层设计和端网协同的理念，提供微秒级别的带宽、延迟保障。
计算存储分离架构
在计算存储分离架构下，所有的存储I/O都需要网络传递，因此网络成为存储应用的重要的瓶颈。而存储流量本身占了整个DCN的60%左右，大量的流量都是很多的小流组成的，例如40%的流量都不超过4KB。因此，存储的流量对于带宽和时延都有极高的要求。
Luna用户态TCP协议
在应对SSD介质带来的低时延同时，传统内核态的tcp协议已然成为端到端性能的瓶颈。与存储内部网络使用RDMA来提高性能所不同，计算到存储网络由于他的特殊要求，例如，需要支持十万个连接这个规模，同时需要很高的互通性，而选择了截然不同的协议。
2018年，阿里云从计算到存储部署了用户态tcp协议luna，实现了网络到存储的零拷贝和无锁、零共享等机制，长尾延迟降低了80%。支持了新发布了ESSD产品，实现百万IOPS和100微秒的I/O时延。
裸金属下的存储挑战
裸金属云为租户提供整个物理主机，这样租户不仅可以灵活地定制机型和虚拟化平台，快速上云，也提供了安全和性能的保障。
例如，租户在使用裸金属服务器时，可以运行自定义的虚拟化平台（如VMware cloud）或是完成多云部署，甚至可以调用硬件底层API功能（如Intel RDT）。
但是，裸金属云在提供给租户更多可能的同时，也面临自身性能和成本的挑战。因为，为了使得将整个物理服务器交付给租户，裸金属不得不将云基础设施软件运行在“非侵入式”的硬件中，通常是网络设备如智能网卡、DPU、IPU、交换机等等。
但这样的部署面临两大挑战：
- 资源受限：相对于物理服务器，这些网络设备通常面临更少的资源和更低的功耗限制。在这种条件下，要实现相同甚至更好的云服务性能变得极具挑战；
- 带宽受限：与传统的虚拟化部署中，hypervisor和租户使用内存拷贝交互数据不同，裸金属场景下的虚拟化和数据交互需要经过智能网卡的缓存、处理和转发，在单个方向上数据会两次通过智能网卡内的PCIe拷贝，数据在网卡中的双向拷贝造成带宽减半。
带宽减半原因由上图所示。当租户发送数据 数据通过主机PCIe到达智能网卡 通过智能网卡内部PCIe到达网卡CPU（一次拷贝） 网卡CPU处理 再通过智能网卡内部PCIe发到网口（二次拷贝），再从网口中发出。
同理，租户从网络中接收数据也要经历2次拷贝，例如，当网口提供双向100Gb/s吞吐时候，租户实际能获得的带宽只有双向50Gb/s。
理想情况下，我们希望数据平面能够直达主机PCIe，不用经历智能网卡内部PCIe的中转。
存储与网络融合的Solar协议
Solar的设计目标是：能够极大地卸载存储和网络处理到硬件网卡中，从而降低CPU开销，提供网络性能，同时能规避网络故障。
但是，面临的现实问题是存储和网络的协议处理都非常复杂，且存在大量的状态。而尤其在资源受限的智能网卡中，能留给存储使用的资源非常有限。做硬件卸载是非常困难的。
因此，solar的设计理念尽可能地减少协议的复杂度，使得可以非常容易地实现硬件卸载。由上图所示，具体做法是网络和存储进行跨层融合，利用网络的jumbo frame使得一个网络的数据包就直接等效成一个存储的block。
这样协议上就不需要维护数据包到block的映射，也不会有在丢包后出线的队首阻塞问题。更少的状态处理也意味着，solar能够节省CPU开销，以及支持多路径等能力。
从线上观测看到，在采用solar之后，计算侧的Storage agent（SA）的长尾时延下降了40%，这是因为solar采用了存储流量的数据平面卸载，这样减少了cpu上的协议处理时延和时延的抖动。同时，由于流量不用经过两次DPU上的PCIe bus，所以网络吞吐能够翻倍。
从多年的线上实际测试数据表明，随着luna和solar的规模化部署，ebs存储的时延在近几年降低了72%，而IOPS提高了3倍。
04 结语
可预期高性能网络，是阿里云基础设施为ML/HPC，高性能存储等新型应用打造的新一代网络架构，核心的目标是“为应用提供微秒级别的时延和带宽保障”，µFAB和Solar分别阐述了实现上述目标的两种重要技术手段：
µFAB揭示了端网协同的融合设计，利用可编程网络提供的精细的网络信息，在端上智能网卡用于速率控制和路径选择；
solar阐述了应用和网络的融合设计理念，利用数据包和数据块的一一映射，从而极大简化状态处理，提高了处理吞吐和降低了时延。这些设计的部署，极大地提升了网络传输的服务质量。
