云计算三层架构_云计算底层架构挑战（二）

1 云场景的底层软硬件挑战

1.1 业务异构加速

我们分析一下用户业务从无到有再到大规模发展的过程中对云主机的需求。一开始的时候，可能并不清楚要运行的业务具有什么样的特征，这样通用的以CPU为计算核心的通用云主机会是比较合适的选择。随着业务的进一步开展，业务场景相对稳定以后，用户对自己的业务也非常熟悉了之后，用户可能会倾向于针对不同的业务选择不同的主机类型，例如针对HPC选择计算优化型，针对大型数据集处理选择内存优化型等等。进一步的，不仅仅业务场景固定，并且计算资源的规模足够大，就有了进一步通过硬件加速来提升性能并且降低成本的诉求。

随着人工智能技术的蓬勃发展，基于GPU加速的机器学习训练及推理得到大规模应用。GPU加速当前主要应用的领域有机器/深度学习、高性能计算、计算流体动力学、计算金融学、地震分析、语音识别、无人驾驶汽车、药物发现、推荐引擎、预测、图像和视频分析、高级文本分析、文档分析、语音、对话式代理、翻译、转录和欺诈检测等。

基于FPGA的加速，因为能够定制加速核心的设计，一般相对GPU来说，具有更高的加速效率，缺点在于硬件编程的技术难度和工作量。因此，基于FPGA的加速主要是以FaaS（FPGA as a Service）平台的模式出现，由Xilinx、Intel或其他供应商提供底层的FPGA软硬件支持，把FPGA封装成标准的平台，一些第三方ISV基于标准的平台开发针对一些主流应用场景的特定的加速核心。在云计算数据中心大规模服务的支持下，FaaS既有了硬件加速的高效，又有了云计算的弹性特征，因此在一些特定领域得到广泛的应用。

异构加速的实现架构是CPU+GPU/FPGA，主要由CPU完成不可加速部分的计算以及整个系统的控制调度，由GPU/FPGA完成特定任务的加速。这种架构面临一些挑战：

l 可加速部分占整个系统的比例有限；

l 因为数据来回搬运的影响，很多场景整体加速效率不明显；

l 额外的GPU/FPGA加速卡导致成本增加；

l 异构加速引入新的实体，计算由一个实体完成变成两个或多个实体协作完成，这导致整个系统复杂度增加；

l GPU、FPGA都有很多种不同的平台，例如NVIDIA GPU的CUDA、Xilinx FPGA的SDAccel、Intel的Accelerator Stack等，这对云计算的硬件成本及运维管理形成挑战；

l 虽然底层软硬件供应商已经为自己硬件平台封装了非常强大并且用户友好的开发和应用框架，但当面对一个新领域的时候，底层距离业务级的用户还是太远，用户自己开发底层软硬件的难度依然很大。

1.2 工作任务卸载

在虚拟化的架构里，系统简单的可以分为两层，Guest层和Host层，Guest层是用户业务层，Host层是后台管理层。Host层的主要工作任务是虚拟化管理、IO的后台处理以及相关的监控、操作和管理等。

在这些Host层的工作任务里，最消耗CPU资源的是IO后台工作任务的处理，如网络的VPC、分布式存储等。Intel在Xeon CPU上做过网络OVS的性能测试：64字节数据包流，消耗四个CPU内核，通过DPDK加速的OVS，最佳性能是8-9 Mpps，带宽为4.6Gbps。随着网络带宽逐渐升级到25G、50G甚至100G，DPDK加速OVS的CPU开销将无法承受。将10-15个甚至更多的CPU核专门用于数据包处理，意味着没有多少剩余的CPU核可以用于用户的业务。在服务器上运行的VM或容器越多，CSP赚到的钱就越多。如果为DPDK-OVS分配大量CPU核，那么在服务器上启动的VM数量将减少，从而降低收入。

Host的其他的工作任务，或多或少也都会占用CPU资源，存在跟用户业务争抢资源的问题，最好都能够卸载到硬件设备。把尽可能多的CPU资源出售给用户业务，来赚取更多的收入。虚拟化Hypervisor包括vCPU的调度、虚拟设备模拟、热迁移、虚拟机管理等，虚拟化的卸载比较复杂，因为涉及到云计算底层软硬件架构的重构。

工作任务卸载跟业务异构加速有很多异同点。相同点在于本质都是通过硬件加速来提升性能，并且都需要软件的协同工作。区别在于工作任务卸载不是局部算法加速，是整体卸载，把所有的处理都放在硬件中实现。

工作任务卸载一般不希望改变现有云计算软件，希望做到跟现有软件系统兼容。工作任务卸载最大的挑战在于如何做好软硬件分离，如何更好的把软硬件功能和接口划分清楚，能够做到在不修改硬件数据面处理的情况下，软件依然能够快速迭代升级。工作任务卸载由硬件负责数据面，软件负责控制面，达到硬件的高效和软件的灵活相统一。

1.3 软硬件接口的标准化和弹性

何谓软硬件接口？就是我们通常所说的IO设备接口。我们通过IO设备接口在软件和硬件之间传输数据，这些数据会在软件中处理，也会在硬件中处理，而IO设备接口就承担了软件和硬件之间的通信接口的角色，因此我们也称之为软硬件接口。

软硬件接口的标准化

数据中心大规模管理以及业务迁移的需要，为了降低复杂度和提高稳定性，云计算平台的一个重要要求就是基于“无差别的一致性的硬件平台”。通常是通过虚拟化技术把底层有差别的不一致的硬件的特性给抹平，给VM提供一个无差别的一致的虚拟硬件服务器。

完全硬件虚拟化技术导致这一要求非常难以满足。我们通过硬件虚拟化技术把CPU里的处理器和内存访问直接暴露给VM，因为主流的服务器都是x86架构的关系，我们依然可以说是无差别的一致性的CPU处理器和内存。但是，让我们通过Pass Through和SR-IOV等技术把硬件设备完全暴露给VM的时候，问题出现了。同一类设备，不同的供应商的接口完全不同，需要加载不同的驱动。即使是同一个供应商，也可能因为产品升级换代的原因，不同的两代产品之间接口无法完全兼容。

所有，当前云计算场景的IO虚拟化技术依然是以类虚拟化技术为主，这不可避免的会影响到IO的性能。随着网络、存储等大带宽、高性能的发展趋势，类虚拟化技术越来越成为影响IO性能的瓶颈。

为了既支持标准化的接口，又能够保证完全硬件虚拟化的IO设备性能，云计算厂家更倾向于公开的、高效的、标准的，并且过去、现在和未来都会广泛使用的设备接口。例如，AWS的网络设备接口选择了ENA、存储选择了NVMe。

软硬件接口的弹性

IO硬件虚拟化，希望很多虚拟的设备共享一个物理的设备。这些设备既可以是同类型的，也可以是不同类型的。物理的硬件接口可以根据实际的需求弹性的配置，这些弹性体现在：

l 接口的类型弹性。我们可以根据不同的场景，配置每个物理接口上需要虚拟的多个不同类型的接口。比如既可以是网络类型的接口，也可以是存储类型的接口，也可以是网络类型和存储类型共存的接口。当然了，也可以是很多其他不同接口类型或接口类型集合。

l 并且每一种类型，还可以再灵活的配置同类型虚拟设备的数量；

l 接口的性能弹性。比如是网络接口，我们可以灵活配置不同的网络的最大带宽、网络包处理的最大PPS值等。而如果是存储接口的话，我们可以灵活配置不同的最大存储吞吐量和IOPS等。

1.4 硬件处理的虚拟化和个性化

云计算场景很大的一个挑战是多租户，当我们把Host层的工作任务从软件转移到硬件处理，就意味着硬件需要实现虚拟化功能来支持多租户。通过PCIe SR-IOV以及多队列（Multi-Queue）技术实现了更细粒度的接口完全硬件虚拟化，在硬件内部，同样需要支持完全硬件虚拟化的“多队列”，实现逻辑上分离的硬件处理引擎，一一对应于每一个队列的处理。

很多硬件里支持多通道（Multi-Channel）技术，硬件处理的虚拟化跟多通道有点类似，但又不完全相同。就像我们服务器虚拟化可以虚拟出各种不同资源配置不同工作处理的虚拟机一样，硬件处理的虚拟化同样需要在队列粒度的层级上实现不同队列的个性化处理。例如块存储场景可能会有数据压缩、加密、备份等需求，网络场景有IPSec、新的网络转发协议的需求，但并不是所有的用户都有同样的诉求，不同的用户的需求可能千差万别，甚至同一个用户的不同实例，需求也不一样。这意味着要实现队列粒度的、有状态的、虚拟化、个性化的硬件处理。

1.5 业务和管理物理分离

后台管理层的工作任务卸载，一般只是卸载部分后台任务；即使卸载的工作任务，也主要是卸载数据面的处理，以此来减少绝大部分的CPU资源消耗，控制面的处理依然还是要运行在后台Host层。而业务和管理物理分离则更加彻底，完全的把后台管理转移到了新的硬件设备，把CPU完全的交付给用户业务使用。业务和管理分离的诉求一方面来自于后端管理和用户业务之间的相互影响，另一方面来自于安全管理，还有一方面来自于用户独占物理服务器的需求。

云计算基于虚拟化的多租户环境下，用户业务和后台的管理共存于一个服务器软件系统里。不仅仅是用户之间可能会因为资源抢占而相互影响，后端管理和用户业务之间也会形成影响。这种影响体现在两方面：

l 虚拟化管理可能对共存于同一个硬件服务器的业务实例造成影响。例如热迁移，如果我们不想让热迁移影响到业务实例的性能，势必增加整体迁移持续的时间，但这样会降低热迁移的效率，并且影响到了业务实例高可用的体验；如果尽可能的减少整体迁移持续时间，势必对其他业务实例性能产生影响。

l 前面我们讲到了后台工作负载会占用CPU资源。例如网络VPC，当某个业务有突发的大流量网络访问的时候，因为后台网络VPC工作负载本质是数据面的处理，因此也会等比例的增加CPU资源消耗。这也会对业务实例性能造成影响。

云计算多租户复杂的环境都共同运行于一个环境里，势必增加比较大的安全风险。一方面是操作系统或虚拟化管理潜在的漏洞，可能会被别有用心之人利用；另一方面，云计算运营管理存在人为失误的可能，这样就会影响到用户实例。

有一些客户有物理机实例的需求，例如一些HPC的场景，性能敏感，即使非常少量的性能损耗也不可接受；例如一些企业用户，之前已经有自己的一套企业级的虚拟化环境，大量的虚机运行于这些企业级的虚拟化环境，用户迁移到云的时候，考虑更多的兼容性的问题，希望是物理机的服务器，不改动底层的虚拟化环境，整体迁移到云计算环境。物理机实例的需求对云计算运行环境提出了非常大的挑战，例如：

l 我们很难把网络VPC、分布式存储等后台IO工作负载添加到用户的业务实例里；

l 无法实现物理机实例的高可用，因为物理机无法迁移；

l 面临很多IO接口不一致的问题。

1.6 硬件的功能扩展

通过软件处理一个任务，相对硬件会具有非常好的灵活性；而硬件处理通常具有更好的处理性能，与此同时灵活性会变差。当硬件处理一旦确定，就很难再更改，也意味着很难再加入新的功能。

传统的SOC芯片里，通常会集成参与数据面处理的高性能处理器，这样，可以通过加入软件处理的方式实现功能扩展。但这样的方式会存在性能瓶颈问题，云计算场景对处理的带宽、延迟、OPS（Operations per Second）等非常敏感，基于软件的性能扩展并不是很好的解决办法。

硬件处理加入的延迟非常有限，几乎可以忽略，而带宽、OPS还能够保持一致。因此，加入独立的扩展硬件处理来进行功能的扩展会是一个比较好的办法。而硬件功能扩展面临如下一些挑战：

l 硬件部分可编程。通过FPGA可以支持硬件可编程，但如果完全的基于FPGA实现所有的硬件处理，势必又得不偿失。因为同样的硬件逻辑基于FPGA的实现比基于ASIC的实现性能更差，成本更高。因此必然是ASIC和FPGA一起的混合体。比如我们把80%的功能ASIC实现，把20%的功能FPGA实现。

l 接口标准化。固定的硬件处理需要给扩展的硬件处理提供标准的数据输入输出接口，扩展的硬件处理需要有标准的配置接口等。

l 功能扩展平台化。与基于FPGA的硬件加速平台类似，需要把支持扩展的整个架构平台化，这样才能比较方便高效的加入扩展的功能。

1.7 让硬件快速迭代

Tick-Tock是英特尔的芯片技术发展的战略模式，也称为嘀嗒模式。在Tick年，设计微架构不变，通过改进制造工艺来提升CPU的性能；而在Tock年，则相反，是制造工艺不变，通过设计全新的处理器微架构来提升CPU性能。通过这种方式，既能稳妥的让制造工艺和微架构设计相互印证，又能够把两年迭代一代处理器变成一年迭代一次。

我们常见的5层网络模型，在一般情况下网络协议栈各层分别实现在硬件、内核态软件和用户态软件。物理层和网络链路层是由以太网和802.11标准所定义的，比较稳定，因此物理层和网络链路层一般实现在硬件里；网络层和传输层作为系统共用的组件，一般是作TCP/IP协议栈集成在操作系统内核里；而应用层的任务则一般交给用户态的程序去实现。

上述这些范例给我们提供了一些思路。如果我们把系统实现按照硬件ASIC、可编程FPGA、底层系统栈、上层应用四类。在硬件这里，我们用硬件ASIC实现一些基础架构和路径，ASIC可以2年左右周期一次迭代；FPGA大概可以半年左右一次迭代，那么在以ASIC为基础的硬件整个生命周期里，我们可以迭代大概4版硬件。通过快速的硬件迭代，可以最大限度的发挥硬件的价值。并且，在下一版本的ASIC迭代里，我们会把一些成熟的硬件逻辑从FPGA卸载到ASIC里，实现硬件里的“卸载”。

硬件快速迭代最大的挑战在于，如何能够像软件系统分层那样，构建分层的硬件系统架构，设计好各个分层的功能，并且定义好标准的、清晰的、简洁的层间接口。

1.8 硬件高可用

对于云计算服务来说，可用性是非常重要的指标。例如AWS的SLA保证在一个区域内，EC2和EBS的月度正常运行时间百分比至少达到99.99%。前面提到了，因为规模的影响，单点的故障在规模的影响下，每天都会发生数百起。主流的互联网系统都是基于大规模服务器集群构建，单点的故障会导致非常严重的问题。软件层面通过非常复杂的技术去保证高可用，例如虚拟机Live Migration、主备切换、负载均衡、分布式存储等。而更直接的做法，还是要想办法在硬件层面实现高可用：

l 提升硬件稳定性。ASIC芯片的初始成本很高，芯片公司只有大规模提升单款芯片的销售数量，才能最大限度的实现销售收入。为了提升数量，就需要让产品适应尽可能多的场景。这是一个非常有挑战的事情，即使芯片经过充分的验证测试，却依然很难保证能够完全适应千奇百怪的各种应用场景。而现在很多互联网公司自己做硬件，不但不需要应付各种各样的应用场景，还能够用实际的业务环境的灰度机制来做好压力测试，效果会好很多。

l 多路独立硬件资源。我们可以通过一定的机制，把多路硬件资源当做一个整体，共同服务于上层软件，当其中有部分资源故障的时候，依然可以为上层软件提供一定程度的可用性。

l 快速故障检测和自重启恢复。因为多租户的影响，需要构建基于硬件虚拟化粒度的故障检测和恢复机制。

l 硬件可在线可升级。我们可以通过FPGA的可现场编程特性，不断的优化硬件设计，提高硬件的稳定性。

1.9 系统整合

前面我们提到了云场景面临的这么多的底层软硬件挑战，其实最大的挑战是如何把应对这些挑战的解决方案整合到一起。我们希望尽可能在不改变上层软件访问方式和风格的基础上，润物细无声的优化底层软硬件架构，来达到性能、成本、管理和用户易用性等方面的统一。我们希望这些方案能够跟云计算，特别是IaaS层，的服务结合起来，通过一些具体的底层软硬件优化来实现价值的快速落地。我们需要在底层软件栈、芯片、板卡、服务器、交换机和基础的物理/虚拟网络架构，以及IaaS/PaaS/Saas层云服务和云计算系统运行管理，甚至机柜、电源、散热、DC管理等基础设施层面，统筹的考虑这些挑战。我们需要更多的底层软硬件创新，来迎接互联网未来快速发展的挑战。

本文作者：

UCloud 操作系统内核团队 硬件研发工程师 黄朝波

参考文献

1. Cloud Application Architectures, George Reese, O’Reilly Media, 2009

2. Data age 2025 White Paper, David Reinsel, John Gantz, John Rydning, by Seagate and IDC, 2018.11, https://www.seagate.com/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

3. Latency, Bandwidth and the New Data Center Network, http://compassdatacenters.com

4. In Modern Datacenters, The Latency Tail Wags The Network Dog, https://www.nextplatform.com/2018/03/27/in-modern-datacenters-the-latency-tail-wags-the-network-dog/

5. 重构网络：SDN架构与实现，杨泽卫、李呈著，电子工业出版社，2017

6. Security in cloud computing: Opportunities and challenges, Mazhar Ali, Samee U. Khan, Athanasios V. Vasilakos, Information sciences, 2015 - Elsevier

7. Intel® Open Network Platform Release 2.1, https://download.01.org/packet-processing/ONPS2.1/Intel_ONP_Release_2.1_Performance_Test_Report_Rev1.0.pdf

8. Three Ways ASAP2 Beats DPDK for Cloud and NFV, https://blog.mellanox.com/2016/12/three-ways-asap2-beats-dpdk-for-cloud-and-nfv/

9. AWS Nitro System, https://amazonaws-china.com/cn/ec2/nitro/

10. AWS EC2 Virtualization 2017: Introducing Nitro, Brendan Gregg, http://www.brendangregg.com/blog/2017-11-29/aws-ec2-virtualization-2017.html

11. AWS Nitro System, James Hamilton, https://perspectives.mvdirona.com/2019/02/aws-nitro-system/

12. https://en.wikipedia.org/wiki/Tensor_processing_unit

13. A Domain-Specific Architecture for Deep Neural Networks, By Norman P. Jouppi, Cliff Young, Nishant Patil, David Patterson, Communications of the ACM, September 2018, Vol. 61

14. In-Datacenter Performance Analysis of a Tensor Processing Unit, Norman P. Jouppi, Cliff Young, Nishant Patil, David Patterson, et al., In Proceedings of ISCA ’17

15. An in-depth look at Google’s first Tensor Processing Unit (TPU), Kaz Sato, Cliff Young, David Patterson, 2017.5, https://cloud.google.com/blog/products/gcp/an-in-depth-look-at-googles-first-tensor-processing-unit-tpu

16. HotStorage 2017, Understanding Rack-Scale Disaggregated Storage, Sergey Legtchenko, Hugh Williams, etc., Microsoft Research

17. HotStorage 2016, Feeding the Pelican: using archival hard drives for cold storage racks, Richard Black, Austin Donnelly, etc., Microsoft Research

18. OSDI 2014, Pelican: A building block for exascale cold data storage, Shobana Balakrishnan, Richard Black, Microsoft Research

19. P4: Programming Protocol-Independent Packet Processors, Pat Bossharty, Nick McKeown, etc., ACM SIGCOMM Computer Communication Review, July 2014

20. The World's Fastest & Most Programmable Networks, Barefoot White Paper, http://www.barefootnetworks.com