一种多云环境中应用编排方案设计

伍尚锋， 李洪赭， 李赛飞

(西南交通大学 信息科学与技术学院， 四川 成都 611756)

0 引言

云计算由最初的普及阶段步入高速发展期，出现了成本低且资源近乎无限的公有云、灵活性和安全性更高的私有云以及兼顾两者优势的混合云等多种云部署模式。单个云相比其他云通常只在某些服务上具有一定的优势，多云的出现既能利用某个云特有的优势，又能避免厂商锁定，成为云计算发展的一个趋势[1]。RightScale2019年云状况调查[2]显示，已有84%的受访企业采用多云策略，比上一年增长了3%。“多云”这个术语兴起于2017年，RedHat将其解释为存在多个源于不同供应商的同类云部署，指出其与混合云的区别。底层物理资源的虚拟化已极大减轻负责基础架构的人员的负担，而云自动化和编排的出现有望将管理人员从日趋增多的复杂环境下资源分配与系统配置中解脱出来。编排即围绕特定目标按照既定流程自动化执行任务，编排后获得一种满足目标、可快速部署、动态调整和重复使用的能力，因而在金融、电力等领域也得到了广泛的使用[3-4]。

1 相关工作

应用编排是在云中自动化创建主机并部署应用服务，目前已有不少研究者对此进行了研究。2013年结构化信息标准促进组织OASIS制定并发布了云应用拓扑编排规范TOSCA(Topology and Orchestration Specification for Cloud Applications)，随后成为事实上的云应用程序建模和编排标准。TOSCA提供一种使用XML、DSL(Domain Specific Language)以及详细信息来定义云应用程序拓扑的方法。Gregory Katsaros等人[5]在云应用的可移植性研究中详细地介绍了OASIS的TOSCA和CAMP(Cloud Application Management for Platforms)规范。TOSCA主要专注于拓扑建模和编排，而CAMP专注于应用程序的部署和管理。张迎[6]设计的云编排框架基于TOSCA规范，采用Winery作为应用拓扑建模工具。Kena Alexander[7]通过扩展CAMP标准充当开发人员和云提供商之间的API，结合TOSCA提供了一种端到端的云编排解决方案，但是该方案需要用户编写符合TOSCA规范的模板文件并在CAMP平台中自定义声明性策略。文献[8]提出了一种基于约束语言的与提供商无关的资源描述语言来避免供应商锁定的问题。文献[9]则对多云部署下云编排可能存在的一些安全性问题进行了研究。Dinkar Sitaram等人[10]另辟蹊径，发现大多数云如AWS、Azure、VMware等都可直接或通过第三方解决方案支持OpenStack API接口，充分利用现有OpenStack基础，使用代理云虚拟化层将其他云作为子云映射到OpenStack云来对多云资源进行统一管控。

从这些研究来看，大多还是通过扩展TOSCA规范、手动编写模板文件的方式来实现应用编排，存在学习成本高、效率较低等问题，因此本文在上述研究的基础上提出一种适用于多云环境的应用编排方案，以降低用户的学习成本、提高应用编排的效率。

2 多云环境中应用编排方案设计

2.1 系统总体结构

多云环境的多个云平台处于不同的地理位置，形成一个个资源孤岛，应用编排系统允许多个云平台的接入，聚合远端云资源，并以业务接口的形式向用户提供服务。系统总体结构如图1所示。

图1 系统总体结构图

由物理层、基础设施层、数据层、业务层和展示层组成。

展示层负责显示视图，即用户在浏览器上看到的页面。该层与用户直接交互，将用户对于资源的申请和服务的使用操作交由业务层进行处理。

业务层是整个系统工作的核心，负责具体的业务逻辑实现，而处理业务所需的数据从展现层或数据层获取。

数据层对系统使用过程中的必需资源和生成数据进行存储和读取。使用关系型数据库MySQL存储用户信息、平台可用资源等结构化数据；对于创建虚拟机使用的镜像等较大的数据，则直接以文件的形式存储到硬盘中。

基础设施层由云平台构成，采用虚拟化技术对底层硬件资源进行抽象，屏蔽不同型号设备之间的差异，对硬件资源进行统一管理，使用户和应用程序不必关注硬件设备的类型、数量和大小。

物理层由数据中心的计算、存储和网络组件构成，保障应用和网络服务可用。计算组件是集群架构中用于数据处理的高性能服务器节点；存储组件由机械硬盘、固态硬盘等存储设备根据不同的应用场景采用不同的存储结构组成；网络组件包括交换机、路由器、网关等通信所必需的硬件设备。

2.2 功能模块设计

对系统进行需求分析，将功能划分为以下六个模块。

(1) 身份认证

身份认证模块负责验证用户名是否存在，用户名与密码是否一致。如果用户身份合法，允许登录系统。用户在系统中可以添加需要接入的云平台授权信息，并将当前用户账号与接入云平台授权信息进行绑定，后续便可利用绑定信息通过API访问云平台的资源。

(2) 资源管理

资源管理模块用于管理接入云平台提供给用户的可用资源。对于网络、虚拟路由器、安全组等租户私有资源，允许当前用户进行增删操作。镜像、实例类型、浮动IP的网络配置等与其他租户共享的公有资源，只能查看。

(3) 图形设计器

一个应用编排模板的常用字段有模板版本、模板描述、参数列表、资源列表和输出列表，其中模板版本和资源列表为必需字段。模板版本标识了该模板适用的平台和版本信息；模板描述说明此模板的用途；资源列表定义需要申请的资源及其依赖关系；资源需要的输入信息可从参数列表传入；输出列表用于返回服务访问的相关信息，如主机的IP地址、开放的端口、Web服务的URL等。

该模块设计用Vue.js框架的component将模板文件资源列表中的元素封装为单个组件，资源配置信息作为组件元素的属性，定义连线规则和包含关系来表示拓扑组件之间的关联关系，用户通过组合组件元素构建应用部署的拓扑模型，最终以SVG图像的形式展示在页面中。这种绘图的方式提取资源列表的基本要素，屏蔽底层具体实现细节，使用户注意力聚焦于应用编排的整体框架，而非模板语法的学习，能够有效提高工作效率。图形设计器的操作流程如图2所示。

图2 拓扑设计流程图

(4) 调度模块

应用部署拓扑模型中包含一组待申请资源，不同模型对资源的需求不同，云平台中各类资源的消耗程度也不一样。如果云平台的内存负荷接近满载，尽管CPU和存储资源满足要求，仍然无法创建资源，剩余的资源就被浪费掉了。为避免云平台资源利用不均衡导致的资源浪费问题，调度模块通过对用户申请的资源和云平台已用资源进行计算，选取资源利用率相对均衡的云平台进行模板下发。

η∈[0,1]

(1)

定义均衡度指数γ表示各类资源消耗接近程度，其值为资源利用率两两之差绝对值的平方和，如式(2)。

(2)

γ越小说明各类资源的使用率越接近，即资源消耗越均衡。资源使用率都相同时，γmin=0。均衡度指数的理论最大值与资源的维度数量有关，如式(3)。

γmax=d24d|d=2n, n∈N* d2*(d2+1)d|d=2n+1, n∈N*

(3)

式(3)计算了云平台的资源消耗均衡度指数，但这只说明了各类资源使用率接近程度，在申请资源时还需考虑到云平台的负载情况。若两个云平台的两种资源使用率分别为40%、50%和70%、90%，预估创建资源后使用率变为65%、55%和95%、95%,尽管后者资源消耗更均衡，但是负载更重，应当把资源创建在前者中。用各类资源使用率的均值作为云平台当前负载大小的度量，则有式(4)。

(4)

综合考虑资源消耗均衡度和云平台负载大小情况后的结果如式(5)所示，选择计算后最小的target值，将资源创建申请下发给对应的云平台k，如式(5)。

(5)

本文设计的调度模块流程如下。

Step1 获取接入的云平台资源负载信息和应用部署模型资源需求信息；

Step2 筛选出可用资源满足申请需求的云平台，若无可用云平台，提示创建失败信息并终止流程；若只有一个云平台可用，进入Step5；

Step3 计算云平台资源均衡度指数和负载；

Step4 按照targetk=γk+Lk对云平台进行排序，选择target最小值对应的云平台；

Step5 将拓扑模型转换为对应的模板文件，下发给云平台。

(5) 流程展示模块

对于一个典型的前端、后台、数据库三层Web应用网站架构，后台程序的运行需要访问数据库服务，前端服务依赖于后台提供的API，在采用多主机部署的方式下，各主机创建和服务部署有先后顺序。该模块通过定时轮询的方式，从数据库中获取资源创建和应用部署的具体执行信息，直到整个流程执行中断或结束。

(6) 虚拟机监控

通过监控虚拟机CPU、内存使用率、磁盘IO等指标，可用历史数据分析应用对资源的消耗情况，并作为反馈调整资源申请中的配置参数，从而完善可重用模板，最大化利用资源。目前对KVM使用最为广泛的管理工具为libvirt，可通过libvirt的python工具包实现对虚拟机监控数据获取。

3 实验及分析

本节主要对方案设计中的调度算法和图形设计器进行仿真实验和功能验证，并与相关方案进行比较。调度算法采用CloudSim框架进行仿真，Task表示待申请资源；Host表示接入的云平台。仿真实验暂且只考虑CPU、内存和磁盘3种虚拟机创建所必需资源，从定义的需求列表中随机选取需求量组成任务列表。仿真云平台配置及一段时间仿真后3种资源使用率，如表1所示。

表1 CloudSim仿真云平台配置

应用编排任务资源需求，如表2所示。

表2 应用编排任务列表

仿真结果为：Task1由 Host3创建，Task2由Host1创建，Task3由Host3创建。

对于Task1，由公式计算出当前云平台负载和均衡度指数γ分别为：Host1(0.592、0.007)、Host2(0.598、0.155)、Host3(0.319、0.191)、Host4(0.544、0.126)。Host 1的均衡度指数为0.007，意味着Task1创建在Host 1上之后各类资源消耗程度将非常接近，然而无论是从负载L还是表1中单项资源使用率来看，Host1都高于综合值更低的Host3，因此Task1被创建到Host3中，此时Host3的负载L值变为0.401。

对于Task2，计算的负载L如前文分析，而均衡度指数分别为：Host1(0.104)、Host2(0.339)、Host3(0.371)、Host4(0.284)。在负载差距不太大的情况下，系统选择将Task2创建在Host1中，此后Host1的磁盘剩余可用量为187 G，不满足Task3的需求，在下次调度过程中不再参与计算。

从Task1和Task2的仿真结果分析可看出，在只考虑单个指标的情况下，任务分配的结果会使得云平台负载更高或资源利用率更不均衡，因此综合考虑两者的情况更为合理。同时Task3计算过程剔除了不满足资源要求的云平台，也符合调度管理的预期结果。

图形设计器功能验证主要是看用户拖拽组件形成的应用部署模型转换而成的模板文件能否被云平台的编排引擎验证通过并执行。在本地机房不同网段下搭建了两个OpenStack Ocata版本云环境，硬件配置信息如表3所示。

表3 云计算平台硬件配置

控制节点是OpenStack的管理节点，运行着Keystone认证服务、Glance管理服务、Heat编排服务、Nova调度服务以及数据库服务等大部分服务。网络节点提供网关、路由器等虚拟化网络资源。计算节点是实际运行虚拟机的节点，运行着libvirt和nova-compute等管理程序。

图形设计器界面如图3所示。

图3 图形化设计器页面

左侧为拓扑组件，通过拖拽组件、连线、双击设置属性便可完成一个简单的应用部署模型，虚拟机启动后的脚本和参数配置写入到模板中的userdata项，利用镜像的cloud-init工具进行数据注入。

系统后端基于OpenStack SDK与云平台交互，采用Django Rest Framework提供RESTful API，模板在下发到具体的云平台执行后，通过命令行工具可以看到资源创建成功结果，如图4所示。

图4 模板执行结果

在主机创建启动后还需一段时间完成服务的部署和配置，便可通过输出信息中的浮动IP地址访问应用服务。

应用编排系统资源创建需要云平台提供支持，只要保证至少有一个云平台租户信息有效，并且租户资源满足需求，系统即可正常工作。目前部署于机房的多云平台，已超过三个月未宕机，而非实验环境中的多个云通常处于不同地理位置，且有各种高可用部署方案，具有抵抗服务同时发生故障风险的能力，基于此合理假设，认为云平台的可靠性满足要求。在该方案中系统被设计为无状态应用，可采用负载均衡来避免单点故障，MySQL数据库使用主从热备方式提供灾难备份。

本方案与其他多云编排相关方案[6,7,10]的对比，主要从是否支持图形化设计、模板文件部署以及除云平台之外需要的额外支持3个方面比较，如表4所示。

表4 方案比较

文献[6]的方案生成的编排包需要特定的运行时环境解析执行，与本方案相比更为复杂。文献[7]实现的是一种跨云的应用部署，其部署场景需要一种超越当前流程编排技术更高级的流程编排支持，与本文研究方向不同。文献[10]使用代理云虚拟化层实现多云资源的管理和创建，但是对于编排并未给出具体实现方案。

4 总结

应用编排一个必不可少的环节就是生成模板文件，然而编写出可用模板需要具备专业知识并且花费大量时间学习相关语法。在多云环境下，各云平台提供专有模板语法和内置函数，这导致应用编排的效率过低。因此，文中提出了一种适用于多云环境的编排方案，通过提供一个图形化的设计器，实现拓扑模型到对应云平台模板文件的转换。模板下发现对云平台负载和均衡度指数的计算也在一定程度上减少了因资源不足导致的应用部署失败，同时可提高资源利用效率。实验结果表明该方案具有一定的可行性。