基于互联云及多云的云化基础设施算力调度

程莹，裴小燕

中国联合网络通信集团有限公司，北京 100033

2020 年4 月，国家发改委首次明确阐述了新基建的具体含义和范围，提出建设以数据中心、智能计算中心为代表的算力基础设施，这是“算力基础设施”这一概念首次在国家政府层面提出。2021 年5 月，国家发改委、中央网信办、工业和信息化部、国家能源局四部委联合发布了《全国一体化大数据中心协同创新体系算力枢纽实施方案》，提出根据能源结构、产业布局、市场发展、气候环境等要素建设“4+4”全国一体化算力网络国家枢纽节点，发展数据中心集群，引导数据中心集约化、规模化、绿色化发展，国家枢纽节点之间进一步打通网络传输通道，加快实施“东数西算”工程，提升跨区域算力调度水平。2022 年2 月，上述四部委再次联合发文，在国家枢纽节点的基础上规划了10 个国家数据中心集群。至此，从国家层面完成了全国一体化大数据中心体系的总体布局设计，“东数西算”工程正式全面启动。

“东数西算”工程通过构建数据中心、云计算、大数据一体化的新型算力网络体系，将东部密集地区的算力需求有序引导到西部，使数据要素跨域流动，优化数据中心建设布局，在缓解东部能源紧张问题的同时，给西部发展开辟新路。“东数西算”工程是一项开启算力经济时代的世纪工程，将算力作为与水、电、气同等重要的国民经济基础设施，与“南水北调”、“西电东送”、“西气东输”三大传统世纪工程相并列。

算力经济产业链包括多个重要的环节和角色，涉及算力生产、算力聚合、算力赋能、算力调度、算力供应、算力交易、算力消费等环节以及算力服务商、算力调度者、算力交易商、算力消费者等角色，这些环节和角色需要各自解决自身的问题，同时还要面对生态链整体整合的问题。“东数西算”的设计理念与近年来电信运营商云网融合、算网融合的战略完美契合，有理由相信，未来通信运营商将结合自身网络和数据中心的优势转型为算力服务商，用户会像过去购买流量套餐一样购买算力服务套餐[1]。如何推进不同算力服务商的算力服务互联互通、协同共享、评测定价，从而实现全国一体化调度，是落实“东数西算”的重要议题。

当前，云服务作为通用算力已成为赋能企业业务单元转型的关键，随着数字化转型的不断深入，用户对算力种类、有效感知、高效利用提出了更高的要求，云服务也逐渐向算力服务演进[2]，成为“新基建”和“东数西算”的基础支撑技术。随着云服务的蓬勃发展，为了满足用户避免被单一厂商锁定、优化成本、数据主权和安全隐私监管、享受不同云服务提供商的服务特性等复杂需求，统筹调度不同云服务提供商的云服务已成为重要的技术和业务发展方向，互联云及多云的理念应用而生。基于互联云及多云的调度方案正逐渐成为“东数西算”全国一体化算力调度的重要技术选择之一。

云网融合这一理念旨在基于信息技术和网络技术的深度融合将计算资源和网络资源紧密协同起来，从而提供一体化的算力资源供给和调度。在融合演进的过程中，依据出发点的不同，存在网侧和云侧两种解决思路。从网络主动适配云的思路出发，网络需要从路由协议到部署模式的全面升级改造，网络软化、算力网络等技术代表了这一领域最新的研究和工程进展。从云计算技术自身的发展思路出发，在网络即服务的基础上，利用多云、互联云实现算力调度。

1.1 网络即服务

云计算作为ICT 领域的代表融合技术，自诞生之日起，就与运营商承载网和数据中心网络有着天然的关联。为规范业界的技术共识，ITU-T 于2014年对网络即服务（Network as a Service,NaaS）进行了标准化定义[3]，旨在将NaaS 定位为一种云服务类别，由云服务提供商（Cloud Service Provider,CSP）向云服务客户（Cloud Service Customer,CSC）提供网络连接和相关网络功能。

基于该定义和典型真实用例（包括IP 与光融合、灵活可扩展的VPN、按需带宽调整、按需网络性能调整、优化的流量工程、虚拟路由器、业务链、云化CDN 等），ITU-T 严格依照用例牵引出功能要求的方法论规范了云业务对电信运营商承载网和数据中心网络在NaaS 连接、NaaS 平台、NaaS 应用方面的功能要求[4]和功能架构[5]，阐述了SDN/NFV 等网络虚拟化技术对云业务发展的支撑性作用。

NaaS 系列标准首次在国际标准化层面从云计算角度提出了网随云动、网络云化的迫切要求，为云网融合奠定了行业共识基础，具有深远的产业影响。

1.2 互联云及多云

根据ITU-T 的定义，互联云（inter-cloud）和多云（multi-cloud）的技术含义有明显差异，核心区别在于是否有云服务合作伙伴[3]（Cloud service partner,CSN）的参与。互联云指的是实现两个及以上云服务提供商之间互通的范式[6]。多云指的是云服务客户在公有云环境中使用由两个及以上云服务提供商同时提供的组合云服务，一般由作为多云管理者的云服务合作伙伴（CSN: multi-cloud manager）通过统一单点实现组合云服务的配置、控制和监控[7]。

根据ITU-T Y.3511 的描述，互联云可以进一步划分为三种模式，分别是云间对等模式（Inter-cloud peering）、云间联盟模式（Inter-cloud federation）、云间中介模式（Inter-cloud intermediary）。

1.2.1 互联云模式

1.2.1.1 云间对等模式

在云间对等模式中，两个CSP 直接相互作用，以便使用对等CSP 提供的服务。云间对等是一种基本模式，它可以独立存在或用于云间联盟模式和云间中介模式。

在云间对等模式中，每个CSP 公开自己的API以用于云互通，CSP 通过使用其他CSP 的API 实现彼此之间的直接互通。如图1 所示，CSP A 使用CSP B 提供的API 与CSP B 交互，反之亦然。由于云间对等模式可以用于云间联盟模式和云间中介模式，所以在CSP A 和CSP B 之间也可以使用统一API。

图1 云间对等模式Fig.1 Inter-cloud peering model

1.2.1.2 云间联盟模式

云间联盟模式涉及在一组对等CSP 内使用云服务。这些CSP 相互组合它们的服务能力，以便向CSC 提供所需要的一组云服务。组成云间联盟的多个CSP 建立并共享统一协议。这些协议可能涉及与服务相关的政策、服务水平协议（SLA）以及与提供服务和资源处理相关的程序。基于相关协议，云间联盟中的CSP 可以在其他CSP 的帮助下提供其云服务。用于云互通的统一API 在云间联盟中定义。如图2 所示，每个CSP 通过该统一API 与云间联盟中的其他CSP 互通。应注意的是，云间联盟模式不一定需要如图2 所示的相互交互CSP 的全互联配置。

图2 云间联盟模式Fig.2 Inter-cloud federation model

1.2.1.3 云间中介模式

在云间中介模式中，CSP 与一个或多个对等CSP 互通并提供由这些CSP 所提供的服务的中介、集合和优选。服务中介包括调节或增强对等CSP 的云服务。服务集合涉及到对等CSP 提供的一组服务。服务优选是指从对等CSP 提供的一组服务中挑选一种服务。

提供服务中介、集合和优选的CSP 与对等CSP之间的互通可以依赖云间对等模式或云间联盟模式。图3 显示了云间中介模式，其中CSP A 为CSP B、C、D 和E 提供的云服务提供中介、集合和优选。

图3 云间中介模式Fig.3 Inter-cloud intermediary model

1.2.2 多云模式

与互联云不同的是，多云模式并不是在不同CSP 之间建立交互关系，而是通过CSN:multi-cloud manager 管理多个CSP 上的云服务，以提供具有互操作性的组合云服务给CSC，如图4 所示。

图4 多云模式Fig.4 Multi-cloud model

CSC 使用CSN:multi-cloud manager 的统一接口，请求公有云中的云服务。CSN: multi-cloud manager在不同的、独立的CSP 中找到符合CSC 要求的可用云服务，并依据约束条件和配置策略将其配置为组合云服务交付给CSC。在使用组合云服务过程中，CSC 通过CSN: multi-cloud manager 提供的统一接口控制和监控它们。

1.3 算力网络

算力网络是近年来业界的研究热点，但目前产业界对其定义和范畴仍有不同理解,技术路线和技术架构尚未统一。总体而言，算力网络是一种面向承载网的新型网络技术，它基于无处不在的网络连接，将动态分布的计算与存储资源互联，通过网络、存储、算力等多维度资源的统一协同调度，使海量的应用能够按需、实时调用泛在分布的计算资源，实现连接和算力在网络的全局优化，提供一致的用户体验[8]。可以将算力网络分为具体的算力网络技术和抽象的算力网络方向两类。具体的算力网络技术研究包括算力感知网络、计算优先网络、算力路由、在网计算等，是算力和网络深度融合的技术研究方向。抽象的算力网络方向是把算力网络作为长期演进方向，但是没有具体如何演进的考虑和论述[9]。

遵循承载网架构和协议的设计思路，算力网络的部署方案可以分为集中式算网编排方案和分布式算力路由协议方案。

1.3.1 集中式算网编排方案

该方案通过集中式的 SDN 控制器和网络功能虚拟化编排器管理和协调功能(NFVO MANO) 实现协同管理和算力路由可达，但算、网属性依然分别处理，属于分布式算力路由协议尚未成熟时的过渡方案。

1.3.2 分布式算力路由协议方案

该方案旨在通过IP 路由协议报文携带算力信息从而利用IP 路由协议的优势实现算力信息的转发，只要算力资源IP 可达，即可实现算力调度。这种方案充分融合了算、网属性，是算力调度网络侧的理想解决方案，其前提是实现算力资源的感知、度量和标识，可以通过扩展现有IP 路由协议或通过overlay 的方式在网络层和传输层之间设置专门的算力路由协议来实现。近年来，业界在分布式算力路由协议领域开展了大量研究和探索[10-13]，但目前尚未形成标准化共识。

1.4 小结

从云网融合的演进过程和目标架构来看，以分布式算力路由协议为代表的网侧方案目前还处于较为初始阶段，尚未在标准和工程实现方面形成业界共识，仍有较长的演进路线。以多云及互联云为基础的云侧方案在标准和工程实践方面已有较多积累和共识，可以作为跨服务商算力调度的重要候选技术。

2.1 云间联盟中的信息交互

图5 显示了云间联盟中涉及多个CSP 的信息交互。在云间联盟中，次要CSP 将其资源作为向主要CSP 提供的一类服务。

图5 云间联盟中的信息交互Fig.5 Interaction in inter-cloud federation

在建立联盟时，主要和次要CSP 在QoS 要求和SLA 之间进行匹配和服务配置策略协商。联盟建立后采取的步骤如下：

（1）CSC 开始使用CSP A 的服务。CSP A 为该CSC 的主要CSP。

（2）主要CSP（即CSP A）因资源短缺造成的服务质量下降决定启动联盟互动协议。CSP A 请求从CSP B 和CSP C 获得计算资源（虚拟机和存储）的信息。CSP B 和CSP C 为此联盟中的次要CSP。

（3）CSP B 和CSP C 就可用资源对CSP A 做出响应。

（4）根据所收到的回复，CSP A 预留CSP B 的资源，估算CSP B 中可用的资源性能并确认所估算的性能是可接受的。

（5）CSP A 启动CSP B 的资源并激活服务（该行动可视为虚拟机迁移或应用重建）从而保持服务质量。

（6）CSP A 决定终止与CSP B 的协作（如CSP A 已获得自己提供服务所需要的重组资源或服务要求下降）并释放CSP B 提供的资源。

这些步骤可用于每个云间联盟涉及到的CSP。云间联盟中的每个CSP 都是其自己CSC 的主要CSP，而向主要CSP 提供资源的CSP 可被视为次要CSP。

2.2 云间中介中的信息交互

图6 显示了云间中介中涉及多个CSP 的信息交互，操作步骤如下：

图6 云间中介中的信息交互Fig.6 Interaction in inter-cloud intermediary

（1）主要CSP 从次要CSP 收集服务信息或次要CSP 将其服务注册到主要CSP，SLA 方面的差异也要得到协商。

（2）主要CSP 通过综合所承担的服务以及次要CSP 提供的服务生成服务目录。

（3）CSC 接入主要CSP 的服务提供目录并在目录中挑选一项或一些服务。

（4）主要CSP 配置并提供由CSC 挑选的服务。该服务可能是由主要CSP 或次要CSP 提供，也可能是主要CSP 和次要CSP 合作提供的。主要CSP 对服务进行中介、集合和/或优选。

事实上，实际的程序将更为复杂。CSC 使用服务的方式多种多样。如所要求的服务由主要CSP 承担，CSC 可直接获得该服务（情况（4-a)）。如所要求的服务是由次要CSP 提供的，CSC 可通过主要CSP 获得次要CSP 的服务（如情况（4-b)和（4-c)）。对于后者，应充分考虑网络条件、服务特性以及CSC 和主要CSP 及相关次要CSP 之间的SLA，以便使CSC 以适当的方式获得服务。

2.3 多云模式中的信息交互

与互联云不同的是，多云环境中的不同CSP 没有建立直接关联关系，而是通过CSN: multi-cloud manager 在CSC 和多个CSP 之间统一建立间接的管理关系。因此，多云中的信息交互与CSN: multicloud manager 密不可分，详细内容如图7 所示，具体步骤如下：

图7 多云中的信息交互Fig.7 Interaction in multi-cloud

（1）为获得跨CSP 的服务，CSC 向CSN: multicloud manager 注册从不同CSP 获得的证书。

（2）CSN: multi-cloud manager分别向对应的CSP 验证证书。

（3）每个CSP 向CSN: multi-cloud manager 提供自己的服务目录。

（4）CSN: multi-cloud manager 将每个CSP 提供的服务目录交付给CSC。

（5）在检查完交付的服务目录后，CSC 请求配置多个可用的云服务，以作为一个组合服务使用。

（6）CSN: multi-cloud manager 根据CSC 的请求向每个CSP 请求云服务。

（7）在每个 CSP 中成功创建所有请求的云服务后，CSN: multi-cloud manager 对创建的云服务进行组合并将其提供给 CSC。

（8）CSN: multi-cloud manager 管理和监控组合云服务。

（9）CSN: multi-cloud manager 向CSC 提供管理和监控数据。

2.4 小结

从上述信息交互可以看出，基于多云及互联云的资源调度需要将计算和网络、存储资源分别处理。为实现多云及互联云间的计算资源调度，通信运营商的承载网需要保证各节点间的互联，不同CSP 之间需要根据服务规划做好共享存储设计。

互联云中不同CSP 的关系需要根据实际情况通过云间协议来启动、维持和结束，运行云间协议的前提是各相关CSP 分别实现可互通的互联云资源/业务处理功能，该功能对外与其它CSP 维持互联关系，对内可以根据需要调度本CSP 的云内资源/业务。

3.1 多云及互联云环境下的基础设施即代码

3.1.1 不可变基础设施

多云及互联云的标准化定义为不同CSP 之间建立合作关系及如何建立合作关系奠定了行业共识，在此基础上一个亟需解决的问题是如何屏蔽异构算力基础设施的差异，抽象算力资源模型，从而在确定CSP 合作关系的前提下实现资源平滑调度。因此，云无关的基础设施部署方案自然成为了多云及互联云环境下算力调度重要支撑技术。这里的云无关基础设施指的是不可变基础设施，作为云原生[14]的代表技术之一，它指的是基础设施环境创建后不接受更新和修改，只能通过整体替换来创建和变更，保持基础设施的一致、可靠以及简单、可预测的部署过程[15]。

不可变基础设施这一设计理念已经在容器技术方面获得了广泛应用，解决了传统可变基础设施一直面临的配置漂移问题。基于这一理念，为解决云无关基础设施的自动化部署，基础设施即代码（Infrastructure as Code,IaC）技术越来越受到业内的重视。

3.1.2 基础设施即代码

基础设施即代码是通过机器可读的定义文件，而不是物理硬件配置或互动配置工具来管理和配置IT 基础设施的过程。这个过程管理的IT 基础设施既包括物理设备，如裸机服务器，也包括虚拟机以及相关的配置资源[16]。业界知名的IaC 工具包括Ansible、Chef、Puppet、SaltStack、Terraform、Pulumi、AWS CloudFormation、GCP Deployment Manager、Azure Resource Manager 等。其中，Terraform[17]以其易于使用、声明式编程、提供开源实现、云无关、可扩展性强等技术特点最受业界欢迎。

Terraform 通过提供程序（provider）与不同的CSP 集成。提供程序是Terraform 插件，用于与外部API 进行交互。每个CSP 都会维护自己的Terraform提供程序，使Terraform 能够管理该CSP 的资源。提供程序作为二进制文件分发到Terraform 注册表上，负责进行身份验证、发出API 请求以及处理超时和错误。注册表中的提供程序可以协同起来，实现多云/互联云基础设施统一管理和调度。图8 展示了通过Terraform 将基础设施同时部署到多个CSP，具体操作步骤如下：

图8 通过Terraform 将基础设施同时部署到多个CSPFig.8 Infrastructure deployment in multiple CSPs by using Terraform

（1）编写Terraform 配置文件。

（2）配置不同CSP 的提供程序。

（3）初始化Terraform。

（4）使用不同CSP 的API 分别部署虚拟机实例。

3.2 基于多云及互联云的云化基础设施算力调度参考架构

基于多云及互联云对云间关系的抽象以及IaC对异构基础设施的抽象和差异屏蔽，本文提出基于多云及互联云的云化基础设施算力调度参考架构，如图9 所示。

图9 基于多云及互联云的云化基础设施算力调度参考架构Fig.9 Computing power scheduling reference architecture based on multi-cloud and inter-cloud

云际互联抽象层：管理不同云际互联数据模型。这些数据模型对多云及互联云中不同CSP 及CSP 和CSN 的关系及协议进行抽象，描述了算力资源的调度策略，主要包括多云数据模型、云间对等数据模型、云间联盟数据模型和云间中介数据模型。

异构算力部署层：通过管理不同CSP 的提供程序、不同CSP 的API、不同数据源、算力部署生命周期完成基础设施即代码的实现。该层连接云际互联抽象层和异构算力资源层，通过解析云际互联抽象层中的云际互联数据模型并将解析结果映射至对应的自动化提供程序，实现对异构算力资源层中不同算力资源的统一部署和调度。

异构算力资源层：管理不同CSP 的异构基础设施，包括但不限于物理机资源、虚拟机资源、容器资源、块存储资源、对象存储资源。

4.1 实验设计

基于前述基于多云及互联云的云化基础设施算力调度参考架构，本文将设计云间联盟模式下的自动负载均衡示例，实现在不同CSP 间平均分发流量，如图10 所示。

图10 云间联盟模式中的负载均衡实验Fig.10 Load balance experiment in inter-cloud federation

简单起见，此处以不同HTTP 页面显示内容来标记不同CSP 的流量承载，不同CSP 的VM 提供特定的HTTP 内容（比如特定文本）给CSC，在页面自动刷新时显示代表不同CSP 的文本，从而验证是否实现了负载均衡。

本示例涉及三个CSP，组成云间联盟模式向CSC 提供云服务X。其中，CSP A 为主要CSP，CSP B 和CSP C 为次要CSP。这三个CSP 建立并共享统一协议，为保证服务X 的可靠性，在服务X 的流量达到某个阈值后自动实现云间联盟内的负载均衡。Terraform 通过不同CSP 的提供程序实现DNS轮询docker 的部署以及不同CSP 内相关虚拟机工作负载的均衡。

4.2 参考实现

4.2.1 数据模型准备

上述云间联盟中的协议可以通过YAML、YANG等语言描述为数据模型并通过云际互联抽象层下发至异构算力部署层。本示例中的协议至少包括的要素为：三个CSP 的主、从关系以及各自的身份验证信息、作为主要CSP 的CSP A 中执行DNS 轮询功能的docker 容器信息以及CSP A 启动负载均衡的阈值。

4.2.2 数据模型解析及资源部署

异构算力部署层中的模型解析及映射功能可以对该数据模型解析并激活CSP A 中可实现DNS轮询功能的docker 容器，从而实现负载均衡。在Terraform 环境下通过配置三个CSP 的提供程序进而通过各自的API 完成部署，配置文件的代码片段如图11 所示。其中，module.csp-x.network_address 指的是每个CSP 中的负载均衡VM 使用一个公有IP 地址将自己注册到负载均衡器。需要说明的是，通常不会为负载均衡器背后的VM 分配一个公有IP 地址，这里仅是为实验配置尽量简单考虑，不同云中的VM使用公有IP 地址比通过隧道把虚拟私有云连接到一起更加简单。

依据图11 的设置，通过对不同CSP 的环境变量配置，本实验可以在页面每次自动刷新时，依次显示“CSP-A”、“CSP-B”和“CSP-C”，说明实现了在不同CSP 间平均分发流量的目的。

图11 配置文件代码片段Fig.11 Code fragment in configuration file

本文在“东数西算”工程的背景下分析了基于云网融合的云化基础设施算力调度关键技术，从网络即服务系列标准中明确的网随云动、网络云化功能要求出发，分析了当前业界网侧和云侧两大针对大规模跨服务商的云化基础设施算力调度解决方案并基于互联云和多云方案展开了云际互联模式分析。在此基础上，结合基础设施即代码技术提出了基于多云及互联云的云化基础设施算力调度参考架构，该参考架构的设计充分考虑了服务商合作关系的模型抽象和屏蔽异构算力资源的自动化部署。此外，基于该参考架构，展示了多服务商环境下如何通过Terraform 实现自动负载均衡部署。

下一步研究和实践的关键方向包括云际互联数据模型的设计和开发、异构算力自动化部署和全生命周期管理、当前算力调度参考架构对高性能计算的适用性扩展、动态基础设施算力调度、云际互联环境下的跨云数据管理等。

利益冲突声明

所有作者声明不存在利益冲突关系。

猜你喜欢 云间多云数据模型 基于区块链的微网绿电交易数据模型研究现代信息科技(2021年21期)2021-05-07登鹳雀楼随想青年文学家(2021年1期)2021-03-24向日葵·成长·礼物作文周刊·小学一年级版(2020年20期)2020-09-02基于Pro/E 的发射装置设计数据快速转化方法舰船科学技术(2020年2期)2020-04-17我写的诗中国诗歌(2018年3期)2018-11-14何氏“十全大补粥”小学生作文·小学低年级适用(2016年4期)2017-01-16经济全球化对我国劳动收入份额影响机制研究——基于面板数据模型党政干部学刊(2015年7期)2015-12-24云间公子落凡尘传奇故事(破茧成蝶)(2015年8期)2015-02-28云间旅人福建文学(2014年5期)2014-06-20

推荐访问:互联 多云 调度