云平台一体化开发框架及资源调度

2021-12-10周晨曦张弛王升杰郭骏宫帅

现代计算机 2021年30期

周晨曦，张弛，王升杰，郭骏，宫帅

（1.南京南瑞信息通信科技有限公司，南京 210037；2.国网安徽省电力有限公司信息通信分公司，合肥 230061）

0 引言

电力行业采用单云多Region技术领先，架构复杂，全网联动［1］，对后续整体云平台管控运维工作提出了新的挑战。云平台的技术领先对于运维人员的技术深度提出了更高的要求［2］，单云多region技术领先，短时期内需要大量的运维人员技术支撑，来确保运维团队的技术深度［3］。用户长期的基于云平台的技术支撑能力沉淀。运维支持团队包括总部侧及网省侧，较为分散，很难形成统一有效的知识技术体系。影响有效解决运维过程中的问题［4］。

基于云平台架构的复杂度给平台稳定性带来的挑战［5］，主要表现在以下几个方面。日常运维过程中，峰值访问期，将对中心管控节点造成压力。中心管控节点瘫痪后，将直接影响中心化产品及混合部署产品在全网的使用［6］。中心节点及各个单元节点扩容时，对中心管控节点也有所影响，云产品扩容前，需要针对中心管控节点的现有负载进行评估［7］。

云产品版本的统一性及一致性的挑战，根据一朵云特性［8］，要求全网部署云产品保持相同产品版本。产品版本正偏离或逆偏离的偏差，都将有几率影响该云产品全网平台使用的稳定性。

中心节点与单元节点的平台稳定性运维责任划分的挑战［9］，全网一朵云，产品部署形态复杂，运维责任方众多，导致日常工作中，总部与网省的工作协同需要大量沟通，应制定统一联动的运维服务管理流程，做到权责利明确划分。

一云多Region架构下云平台运维的应对，面对已知的运维复杂度和挑战［10］，提升云平台和数据中台一体化运维效率和整体运行稳定性，建立有效的总部/网省联动的一体化运维机制势在必行。

1 云平台技术

云平台一体化运维体系设计需要结合云平台的技术架构，云平台技术架构主要采用一云多re⁃gion架构。一朵云多区域（Region）的架构设计是为了满足多区域部署一朵专有云的需求，在架构设计上分为中心Region和普通Region。一朵云多Region架构如图1所示。

图1 一朵云多Region架构

一朵云，提供统一管控，统一运维，以及统一监控的能力。一致性，与阿里公共云的架构保持一致。

可用性，故障域隔离，当中心Region出现故障时，不影响云平台已申请云实例资源的使用。当普通Region出现问题的情况下，不影响其他Region的使用。云平台提供一套自动化数据中心管理系统，管理数据中心的硬件生命周期与各类静态资源，为各种云产品应用及服务提供通用的版本管理、部署、热升级方案。每个Region部署一套管理服务，管理服务会同步中心Region的服务变量，以供普通Region上的产品或者服务引用。

2 一体化框架设计

依托国网云平台，复用已有组件能力，构建逻辑集中、物理分散、动态分配、统筹利用的研发仿真环境，并实现与生产环境自动化部署。在现有云平台划出部分空间构建开发集成环境、仿真环境，因为与生产环境共用云和数据中台底座，可以直接使用云和数据中台的技术组件，但每个环境单独生成自己独立的实例，网络上与生产环境相互隔离避免干扰。从资源使用角度看，测试环境的节点消耗与生产环境消耗比例为1∶8左右，一体化DevOps架构图如图2所示。

图2 一体化DevOps架构

在现有云平台资源中构建开发集成环境、仿真环境，生产环境。开发集成环境供开发团队开发及单元测试、接口测试、自动化联调测试；仿真环境支撑第三方测试、网络安全仿真验证（靶场）、基层用户体验管控测试及用户仿真培训；研发集成环境及仿真环境与生产环境进行安全隔离。一体化研发管控平台对项目开发提供灵活的接入支撑方式和协作模式，支持人员集中式开发、异地分布式协同开发、现场驻场开发等项目组织模式。

2.1 网络和资源划分

对专有云的VPC进行自行定义划分，每个VPC都有一个路由器、至少一个私网网段和至少一个交换机组成。可自行选择IP地址范围、配置路由表和网关等。

在专有云划分出部分资源进行开发仿真环境建设，同时为了保障生产系统的安全，给开发仿真环境划分一个专用的VPC，将所有的研发仿真资源放入该专用VPC中。这样可以通过对VPC的路由设置，隔断开发仿真环境与生产环境的网络访问，VPC划分架构如图3所示。

图3 VPC划分架构

划分出VPC后，可以将专有网络连接到研发测试团队所在本地网络，形成一个按需定制的网络环境，实现各地开发人员对网上统一开发集成环境的远程访问。

2.2 资源调度框架

云计算平台内部具有大量的计算节点，可以将整个云计算平台抽象为一个连接了所有计算机的无阻塞大型交换机。这个大型交换机的入口端口对应于服务器的出口链路，而出口端口则对应于服务器的入口链路。通过这种抽象，该模型的优势在于只需要考虑入口端口和出口端口，便于对Coflow流量的调度进行分析，且在简单且全平分带宽拓扑结构下具有很高的实用性。E-Aalo资源调度架构如图4所示，主要包括全局协调器和本地守护进程两个部分。

图4 E-Aalo资源调度架构

资源调度架构包括全局协调器和本地守护进程，其中全局协调器负责监测每个作业是否产生通信数据流，对产生通信数据流的作业利用流量放置策略，选择合适的计算节点处理每个通信数据流中的流量并生成对应的策略，接着通知发送节点将通信数据流中的流量从送发送到选择的接收节点。另外，全局协调器还接收发送节点发送来的每个通信数据流已发送的数据流相关的参数，根据这些参数确定不同通信数据流的优先级并发送给本地的守护进程。本地守护进程用来接收全局协调器发送来的通信数据流优先级信息，然后在本地的多级队列中对通信数据流进行调度。

2.3 算法实现

云计算平台将各类任务分成多个子任务进行处理，每个子任务将被分派放置到不同的主机上执行，相应的数据也被传输到执行任务的主机节点上，带来更多的数据流量传输，也导致更大的开销。若该主机上原本就存在相应的数据，就可避免额外的数据传输开销，通过对通信数据流中的流量进行不同的放置可对子任务在不同的主机上进行分配，合理的分配也将会减少数据的传输量，降低时间开销，提高云数据中心的性能，具体云计算平台流量放置调度如算法1所示。

算法1云计算平台流量放置调度

输入:集合Q1,…,Qk对应Cn的k个数据流

输出:Cn的放置方案M1,…,Mk对应的k个数据量的放置方案

1:for all i from 1 to k do

2:for all j from 1 to m do

4: Qi.push（j）

5: end

6: end

7:end

8:for all i from 1 to k do

9:for all j in Qido

10: Mi←arg minj(Accutj)

11:end

12:end

13:return M1,…,Mk

其中，m表示m个待选择的任务分配计算节点；前七行代码对通信数据流C n中的每个数据流f in筛选出潜在的可以直接执行该任务的计算节点；后面代码则从每个数据流f in的潜在可选节点中选出网络负载最小的计算节点。

3 实验及结果

为验证云平台一体化框架模型的合理性和有效性，选取故障处理调度、资源调度效率两个场景进行实验验证。

3.1 故障处理验证

本文选取普通事件处理作为应用场景，保障云平台团队对事件快速高效的响应、诊断、定位制定了包括资源分配调度对应的事件管理流程。确保快速高效的解决事件问题，最大限度地减少对专有云平台及云平台业务的影响，提高整体的服务质量。制定的了事件管理的相应流程。具体处理流程如图5所示。

图5 云平台事件流程

详细流程操作如下：服务台接口人负责发起事件处理请求、在工单系统中提交事件、参照产品布署形态及省份，分派网省侧工单、关闭此次事件处理流程；网省侧技术工程师1线负责日常监控/巡检，向服务台发起普通事件处理请求、针对配置类事件，触发网省侧技术工程师1线普通事件处理流程、参照产品布署形态及省份，将工单系统中的需求工单分派到网省侧工单；总部需求接口人负责需求类事件，触发需求处理流程；总部技术工程师2线负责BUG类事件触发BUG处理流程；总部版本接口人负责在有a-one号和工单号的前提下，启动版本处理流程、收到版本经理汇总的出包信息后，触发版本处理流程依照配置方案进行配置更改操作。