跨云计算作为云际计算重要的技术组成，以云服务实体为单位，对实体之间的计算迁移提供支撑，从而提升云服务实体之间整体资源利用率。目前，跨云协作问题已经引起国内外关注：在不同数据中心间资源聚合等方面取得突破，在资源虚拟化、分配动态化和服务自动化等提升资源利用率方面取得进展。

云际计算

云计算发展十年，形成了以数据中心为核心的不同层次的服务，包括架构层(Infrastructure as a Service, IaaS)、平台层(Platform as a Service, PaaS)和软件层(Software as a Service, SaaS)等，由此而形成的云计算市场保持了快速的增长。云服务所呈现的爆发性、全域性和多样性的特点，在规模化、全球化和个性化方面带来了新需求和新挑战。

云计算的一个趋势是，不同云计算平台之间的协作正变得日益频繁。以阿里云为例，每年的“双十一”等销售旺季通常需要大量计算资源，因此在这段时间，阿里云会减少对外的资源供给，导致不少阿里云服务消费者必须暂时迁移到其他云，以保持业务，在销售旺季过后再迁移回阿里云平台。这种现象类似于银行间的“同行拆借”，即多个云之间以合作的方式共同承销服务。但目前由于云平台的异构性，服务迁移的成本依然很高。

对于云服务消费者来说，多云部署服务可以有效提高服务的可用性(availability)，已成为一种主流的服务部署方式。将业务部署在不同的云平台，可以减少单云故障对业务造成的影响^{[1, 2]}，同时也能更好地适应不同的服务负载（见图1）。目前，多云部署主要采用手动部署的方式，同时对故障恢复的处理也依赖云服务消费者自身完成，缺乏一种高效且可靠的可用性保障机制。

图1　多云服务能够有效提高故障容忍能力

在云服务消费者提出新的云平台使用方式的同时，云服务提供者也针对云服务消费者的特点，对自身服务不断进行调整。云服务提供者通常会根据云服务消费者对计算资源使用的周期性进行相应的价格调整，在使用率较低的时间段降低资源的价格，反之则提高，从而实现计算与价格的均衡。例如，亚马逊(Amazon)的现货实例(spot instance)服务允许云服务消费者定下愿意接受的最高价格来租用云服务的闲散资源，同时会根据供需情况周期性地发布即时价格，如图2所示。当云服务消费者设置的价格高于其即时价格时，自动将服务部署在现货实例上并运行，且实际支付价格为系统即时价格；当云服务消费者最高限价低于即时价格时，系统自动终止服务，待即时价格低于云服务消费者最高限价时再次启动服务。因此，在全球化协作带来了“follow-the-sun”^[4]工作流趋势的同时，对计算资源的使用则日益有“follow-the-moon”^[5]的趋势，从而利用云服务提供者的昼夜价差实现低成本、全天候的服务。与此同时，亚马逊也提供了预留、按需与专用等多种计算实例^[6]，满足不同的需求。因此，跨云计算不但带来了更好的资源利用率、容错能力，也提高了计算资源的性价比。

图2　网站us-east.windows.m1.small在亚马逊现货实例的价格随时间变化曲线^[3]

新一代云计算呼唤云际分工协作。以阿里巴巴电子商务全球化为例，支撑此业务的阿里云也需要国际化。这里有两个发展策略：一是自建，但若要满足峰值计算能力，则成本极高；二是合作，面临如何合作的机制挑战。人类工业化的历史经验告诉我们，分工协作是发展方向。早期的工业生产，例如英国的羊毛纺织厂，除了拥有纺织车间等，还需要自建养殖场和自办水陆运输等业务，是“小而全”的、自给自足的作坊式生产，缺乏效率和竞争力。而现代化制造是基于标准化的市场分工与协作。例如国产C919大飞机，由10多个国家、100多个细分行业协同创新、协作生产。现代服务业也给我们同样的启示：航空公司结成航空联盟，实现国际化运营。分工协作也使云服务提供者和云服务消费者双双获益。

基于上述分析，云际计算作为云计算未来发展的新形态和新概念，以云服务实体之间开放协作为基础，通过多方云资源深度融合，方便开发者通过“软件定义”方式定制云服务、创造云价值的新一代云计算模式，力求实现服务无边界、云间有协作、资源易共享和价值可转换的云计算愿景。跨云计算作为云际计算重要的技术组成，以云服务实体为单位，对实体之间的计算迁移提供支撑，从而提升云服务实体之间整体资源利用率。目前，跨云协作问题已经引起国内外关注：在不同数据中心间资源聚合等方面取得突破，在资源虚拟化、分配动态化和服务自动化等提升资源利用率方面取得进展。

云际计算典型应用与挑战

典型应用：跨云计算迁移

渲染是现代电影中的一项重要制片技术，需要大量服务器运算完成。渲染有3个重要特点：其一是计算量巨大：电影渲染可以按帧进行，1秒钟通常包含24帧，其中每1帧需要1~10小时，而一部电影的渲染则需要8000万个小时；其二是高度可并行性：每一帧渲染相互独立，因此可以并行计算；其三是出错可重算：每一帧在计算时若出现错误，可以重新计算，不会对其他帧的渲染造成影响。

当某云平台计算资源不足以支撑某次渲染任务时，需要将渲染任务部分或全部迁移到其他云平台。由于渲染任务彼此之间的独立性，部分迁移的渲染任务不会对已完成或正在进行的任务造成影响。

挑战1：跨云平台的资源管理

云际计算是对现有云计算资源的聚合和重组，跨云资源呈现异构性、分散性、复杂性和多样性的特点。从传统云计算模型来看，包括公有云、私有云和代管云等多种不同形态的云平台；从以虚拟机作为计算单元的角度来看，包含专有虚拟机、按需虚拟机、预留虚拟机和临时虚拟机等。这些不同的计算资源一方面在硬件构成方面具有高度异构化的特点，包含不同的CPU、图形处理器(GPU)和固态硬盘(SSD)等不同计算资源、网络设备和存储设备；另一方面，在稳定性、性能和隔离性等方面均具有不同的特点，因此给云计算资源的统一管理带来了巨大的挑战。

挑战主要包括以下方面：首先，计算资源本身存在异构性。云平台计算资源通常包括处理器资源、内存资源、存储I/O资源、网络I/O资源和GPU资源等。同一类计算资源也存在显著差异，例如不同处理器的工作频率、缓存大小、体系架构和支持特性等均不同。对于同一个工作负载，在工作频率和缓存大小相同但体系架构不同的处理器上，其运行效率也会有显著的区别。其次，计算资源的分散性同样面临挑战。云平台A上的处理器资源很难与云平台B的内存资源相结合，因此，如何在实际的物理限制下，将基础计算资源进一步组成特定的资源集作为提供给云服务消费者的最小单元，是一个具有挑战的问题。第三，如何对计算资源进行动态的最优配置，从不同维度根据实际工作负载的需求对资源池进行分配，充分发挥软件定义云际计算的优势，并通过市场驱动的机制根据资源池的动态价格分配资源，也是亟待解决的问题。

挑战2：缺乏对跨云异构计算资源的抽象与解耦

跨云计算需要新的资源抽象方式。不同的云平台在不同的层次对资源进行抽象，包括IaaS、PaaS和SaaS等，以真机、虚拟机和容器等不同形态将资源提供给最终云服务消费者。目前，已经积累了大量基于虚拟机镜像和容器镜像（如Docker等）的云应用。跨云计算平台同样需要无缝支持这些已有应用，如支持以容器为计算实体抽象的标准。

传统的虚拟化技术和容器技术主要是将单一物理硬件平台进行拆分，保证拆分后的不同部件之间的隔离性；而在跨云计算平台，需要在跨物理节点的维度对计算资源进行重新抽象与管理，导致现有的资源抽象在性能、安全性和隔离性等方面面临新的挑战。如何构建面向计算与存储的资源抽象，结合嵌套虚拟化^{[5, 6]}的特点，实现应用与平台的解耦，减少计算状态对平台的依赖，是一个需要解决的问题。

挑战3：跨云计算迁移开销大

计算迁移是云计算平台的重要特性，允许应用突破物理硬件的限制，在资源池的范围内无缝动态部署运行，从而充分提高物理计算资源的利用效率。计算迁移在跨云计算中同样具有巨大需求^{[7, 8]}。跨云计算为计算的迁移带来了两个新的挑战：第一，传统的计算迁移基于虚拟化平台，对底层虚拟机管理器有较大的依赖。跨云计算平台的虚拟化平台通常会存在一定差异，目前还缺乏一种允许在不同虚拟化平台间进行无缝计算迁移的方法。同时，由于虚拟机等计算实体状态多，直接迁移会导致大量的数据转移。不同于云平台内部的迁移，跨云迁移的带宽性能远低于云内部，而网络流量所产生的跨云流量费用远高于云内流量费用，对于具有大量计算数据的应用来说，迁移的成本反而会更高。因此，简单地将传统的虚拟机迁移技术用于跨云环境，会在性能和费用上带来显著的额外负载。第二，目前尚没有一种面向跨云计算平台特性的特定迁移算法。跨云平台由于其物理资源的分布性与异构性特点，对计算迁移提出了新的要求。不同云平台本身具有差异性，不同云平台之间的网络也存在异构性，对离线迁移、在线迁移、静态数据迁移和动态数据迁移等不同的模式，传统的单一迁移方法很难适应所有的场景。因此，如何设计迁移算法，以及如何为具体的场景进行算法适配，也是一个重要的研究问题。

挑战4：缺乏面向跨云计算的效能监控与评价方法

对云计算的效能监控与评价是云平台的重要功能。如亚马逊的CloudWatch^[9]可实时监控计算资源（如CPU、硬盘和网络等）的使用，并可根据云服务消费者定义的规则对资源自动更改。然而，不同的云平台仅提供自身内部的资源监控功能，而无法监控整个云际资源的使用；同时，由于不同云平台的计算资源在处理能力、I/O能力与网络能力等方面各不相同，以及负载、突发中断处理等原因，通常会处于不稳定状态，该不稳定状态会在跨云计算场景下进一步放大。因此，跨云平台一方面需要处理云际资源本身的异构性以及云际资源拥有者的多样性，从而提供一种全局的资源监控能力，对不同计算资源进行监控与评价；另一方面，由于对隐私性和安全性的考虑，不能采用中心化的资源监控方式。因此，需要对不同平台的监控数据进行处理，并需要一种新的去中心化的资源监控与评价方法，这也对跨云计算提出了新的挑战。

跨云计算研究技术路线

跨云平台的划分式资源池管理与全局任务部署  

为实现跨云平台的高效资源管理，可采用“划分式资源池”的思想，将资源按照局部性和不同属性建立层次化的计算资源池，其中每个资源池按照不同资源类型提供相应的子资源池，如计算单元和存储资源池等。该方法借鉴了“划分式全局地址空间”的思想，即每个实例都能看到全局地址空间，但是对地址空间进行了分区。如果需要跨地址空间访问资源，那么就需要显示指定所需要的地址空间，并且对访问的对象进行序列化与反序列化。每个资源池内需要提供细粒度的资源抽象和虚拟化方法，从而提供物理资源的可编程接口，以支持管理功能可编程；同时需要建立计算资源属性的“需求-供给”映射机制。

可从存储资源与计算资源两个方面开展云际资源的多尺度聚合，同时支持应用与平台的解耦。在存储资源方面，在划分式资源池化的基础上，对异构、地理分布资源提供统一的上层接口。拟研究对上提供基于键值存储的接口，并将地理分布信息键入到键中，以便有效支持存储系统的局部性访问，从而减少访问延迟。在键值存储接口的基础上研究多种一致性模型，包括强一致性、因果一致性和最终一致性等，在云际存储系统中的应用以及与应用需求的匹配。探索基于云际存储的跨几何分布数据副本技术，为应用提供高可靠、高性价比的存储系统。在数据访问控制与安全隐私控制方面，在遵循云服务消费者数据隐私的前提下，提供高吞吐、低延迟的数据访问。同时，研究将一致性、安全性和地理信息分布等信息API化的方法，从而在提供资源虚拟化的同时提供良好的管理功能可编程性。

在计算存储资源协同管理方面，可利用云际分布式存储系统提供的存储资源虚拟化与提供的管理功能可编程等方法，将计算与存储资源进行进一步解耦，如将计算时所需的存储由存储资源进行统一管理，对不同类型的计算任务，进行全局的任务部署。同时利用云际存储所提供的管理功能与可编程性较好的特点，实现“存算联动”以减少数据的传输。

跨云计算的资源抽象与解耦

为构建面向计算与存储的资源抽象，实现应用与平台的解耦，减少计算状态对平台的依赖，将探索在硬件与应用之间构建面向计算与存储的资源抽象的方法。一种方法是将存储系统抽象为键值存储系统，实现对存储资源的统一接口，并在此上通过划分式资源池等方式构建存储资源的统一管理与聚合。同时，通过应用状态与系统状态分离的计算单元状态进行抽象，可减少计算状态对平台的依赖，从而在很大程度上支持应用与平台的解耦。

在计算资源抽象方面，需要在基于容器的虚拟计算池方面有进一步的突破。首先，可通过扩展容器抽象（如Docker）以支持跨云交互，充分挖掘硬件资源，包括如何充分挖掘硬件资源的自虚拟化特性显著降低容器资源访问的性能；其次，探索如何提高基于容器的运行环境隔离性，通过对Intel和AMD的最新硬件安全特性的充分挖掘，对同一物理平台的不同容器实例进行内核层级的深度隔离；第三，利用基于安全点的应用状态存储，分离应用状态与系统状态；最后，利用软硬件协同的设计方式，进一步实现异构计算资源的容器级虚拟化，包括GPU和神经处理单元(Neural Processing Unit, NPU)的容器化等。

计算任务跨云迁移

在计算任务迁移方面，为了解决平台异构性以及分布性所带来的挑战，我们将设计一套跨云的计算聚合系统，支持跨云的计算资源聚合，并利用云际存储系统，简化应用状态的跨云迁移。首先，通过划分式资源池提供的资源地理分布信息，允许资源池管理器尽可能按照数据局部性分配资源，基于“移动计算”而非“移动数据”的原理，通过在面向存储资源的资源池、面向计算的资源池这两个层次对资源进行抽象和统一，从而使计算能够在不同的云平台之间无缝移动；其次，在面向云际平台的存储系统上，进一步支持将应用状态与系统状态分离，设计基于安全点的状态迁移方法，以及基于安全点的一致性状态保存，从而显著减少跨云应用迁移的开销，并利用云际分布式存储系统的多副本功能，进一步简化需要迁移的状态；再次，基于半同构系统的在线迁移，在包括Docker、atop、VM等混合虚拟化方案的平台上，实现不同云平台之间的在线迁移，同时支持容器抽象在容器、虚拟机等平台上进行动态切换，从而使得云际资源间的管理更为灵活；最后，针对不同的场景，提供迁移算法池，以及相应的迁移双方协商迁移的方法，以适应不同的迁移场景需求。

效能监控与评价模型

在效能的监控和评价方面，须通过系统建模的方式对效能进行研究和监控。首先，通过对历史数据的收集和处理，通过机器学习等方法进行拟合，以构建效能模型，并将所得到的效能模型应用到在线监控中，对实际生产环境进行预测；其次，在现有的云内资源监控基础上，实现云际的资源监控，探索去中心化的资源监控机制，由每个自治体提供对应的监控信息语义，并将其汇总后进行统一管理，利用区块链等技术允许不同云平台之间的协助与共享；再次，探索如何在监控的准确性与数据隐私性之间进行权衡，基于“安全多方计算”进行数据交换，并结合不同的需求在保证所需精确性的同时对监控数据进行可量化的模糊化处理。 ■

参考文献

[1] CNET科技资讯网. Google Apps拖累Gmail又当机中断持续将近22小时[OL]. (2009-03-13). http://www.cnetnews.com.cn/2009/0313/1355592.shtml.

[2] Amazon S3存储中断影响企业营运[OL]. (2008-02-18). http://blog.csdn.net/phphot/article/details/2105033.

[3] Ben-Yehuda O A, Ben-Yehuda M, Schuster A, et al. Deconstructing Amazon EC2 spot instance pricing[J]. ACM Transactions on Economics and Computation. 2013, 1(3), Article No.16.

[4] Wikipedia. Follow-the-Sun[OL]. https://en.wikipedia.org/wiki/Follow-the-sun.

[5] Wikipedia.Follow-the-Moon[OL].https://en.wikipedia.org/wiki/Follow-the-sun#Follow-the-moon.

[6] Amazon EC2 Pricing[OL]. https://aws.amazon.com/ec2/pricing/?nc1=h_ls.

[7] Palesandro A, Lacoste M, Bennani N. Nested virtualization meets micro-hypervisors: Towards a virtualization architecture for user-centric multi- clouds[C]//Proceedings of First ComPAS Workshop on Cloud Security (SEC2), 2015.

[8] Zhang F, Chen J, Chen H, et al. CloudVisor: retrofitting protection of virtual machines in multi-tenant cloud with neste d virtualization[C]//Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles. New York: ACM Press. 2011: 203-216.

[9] Dan W, Jamjoom H, Weatherspoon H. The Xen-Blanket: virtualize once, run everywhere[C]//Proceedings of the 7th ACM european conference on Computer Systems. New York: ACM Press. 2012: 113-126.

[10] Liu C, Mao Y. Inception: Towards a Nested Cloud Architecture[C]//Proceedings of the 5th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud 13), USENIX Association. 2013.

[11] CloudWatch, Amazon. Monitoring for AWS Cloud Resources. (2013).