0 概述

依托云计算、大数据等先进IT技术, 改进现有智能电网调控基础平台, 研发面向202x年的弹性调控平台, 已成为业界的发展趋势。文献[1]给出分布式监视控制与数据采集(Supervisory Control and Data Acquisition, SCADA)系统架构, 描述了分布式资源和任务管理、实时数据管理和计算处理方法。文献[2]论证了调度自动化系统应用云技术的可行性, 提出一种基于云计算平台的调度自动化系统架构。弹性调控平台是支撑电网调度自动化系统的PaaS实现, 需要设计良好的任务调度策略, 提供稳定的云计算服务。

文献[3]综合考虑云计算环境下资源节点与通信链路的可靠性问题, 设计基于遗传算法的可信云资源调度算法。文献[4]提出一种网格联合调度策略, 减少了虚拟机抢占的数量。文献[5]提出一种基于OpenStack的快速选择调度器。文献[6]结合能量和性能感知的调度策略, 开发一套性能和能量感知的资源分配、任务调度工具。然而, 以上研究均未充分考虑实时数据处理类系统的运行特点, 且任务调度需综合考虑节点的计算、存储、网络等资源供给情况。文献[7]利用博弈理论将调度节点比作博弈的参与者, 综合考虑节点资源和网络性能, 采用混合博弈策略实现Nash均衡。文献[8]中的演化博弈适合解决网络中的动态博弈问题, 描述了网络行为和群体行为的评价指标、分析模型及评价框架。

考虑到弹性调控平台的资源异构性、伸缩性及性能波动性等问题, 任务调度时可在不完全信息条件下演化博弈竞争资源。本文基于演化博弈模型构建包含节点感知器(Node Perceptron, NP)、资源状态服务器(Plat Resource Status Server, PRSS)和任务调度器(Task Scheduler, TS)3个核心构件的任务调度框架。

1 演化博弈模型

本文演化博弈研究的对象是随时间变化的虚拟节点集群, 分析节点行为评分计算、微服务选择运行节点的任务调度技术。文献[8]随机演化博弈的建模过程具体如下:

1) 基本参数设定:决策者是TS, 决策集包含节点感知和任务指令模型, 收益矩阵是节点的行为评分。当决策策略有限时, 所有可能的策略组合可能只收益一种可用矩阵表示的结果, 可用简单的函数表示。

2) 变更决策策略:突变阶段TS尝试新的任务编排策略(执行效果可能较差), 通过不断排除错误, 获得的较高评分策略将被其他节点采用并计算其行为评分。

3) 参数求解:求解演化博弈过程中设置的一些参数, 如服务处理的测量点数量、权重调节因子等。

4) 均衡策略求解:结合平台任务调度的特点, 采用资源性能排序和累计计算方法, 不断修正节点评分策略。

模型选择阶段采用混合博弈法, 根据任务对不同资源的偏好编排执行节点, 完成节点负载预估及行为评分计算。模型突变阶段分析任务的执行效果, 调整节点上任务的资源分配, 获得较高的节点评分策略, 逐步进化构成演化博弈。

1.1 节点感知模型

文献[9]提出资源感知调度算法, 将资源分为硬约束(内存)与软约束(CPU和网络), 设计一种Storm环境下基于权重的任务调度算法。文献[10]研究异构Storm环境下的任务迁移策略, 根据节点CPU、内存和网络带宽的负载情况以及各类资源的优先级顺序, 开展节点选择和任务迁移。本文节点感知模型选择平台关注软硬约束的关键资源, 键值模式量化设计如下:

1) domain

业务域D: < "D-"+name, {name, desc}>; 键为"D-"字符串接名称, 值的属性为名称和描述。

2) class

资源类C: < "C-"+name, {name, desc, method}>; method为类中对象object的原型方法。典型类如下:(1) < "C-Node", {"Node" "节点", [host, Label, store, cpu, mem, disk]}>; store = {calc, storage, net, all}, 依次为计算、存储、网络及综合评分。(2) < "C-Base", {"Base" "基础服务", [weight, status, cpu, mem]}>。(3) < "C-App", {"App" "应用服务", [weight, status, cpu, mem, type, flow]}>。(4) < "C-Net", {"Net" "网络", [TX, RX, peak, rates]}>。

3) object

资源对象O: < "O-"+D.name+":"+C.name+":"+name, {oid, name, desc, register, uptime, mask}>; 键为"O-域名:类名:对象名"; 值中oid为UUID, register={md5, partition, passwd}为对象注册信息(属性依次为MD5码、参数分片号、私有密码), uptime为最后更新的标准秒值(到1970年1月1日的秒数), mask为状态掩码和操作类别。

4) attributes

资源对象属性A: < "A-"+O.oid+":"+C.method_n, {[info, uptime, value]}>, C.method_n对应资源类中的method(n是位次编号), info存储键值信息(空用"-"), uptime是标准秒值, value是浮点型数据(空用"0")。

1.2 任务指令模型

文献[11]的ACOHS算法定义了六元组任务, 使用队列优化任务的选择策略。本文设计将任务指令化处理, 任务TASK={task, target, status}:属性task为任务指令; 任务标签target = {calc, storage, net}, 依次为计算量、存储数据量、网络流量; 任务状态status:-1为异常, 0为待校核, 1为常规, 2为执行校核。task设计如下:

task = {#定义n为资源对象的名称

"Domain":{"create n" "remove n" "show n"}

"Node":{"create nLabel" "remove n" "update n Label_old Label_new" "show n"}, #节点

"Base":{"create N n" "remove N n" "update N n_old n_new" "show N n"}, #基础服务, 定义N为节点名

"App":{"create app N n" "remove app N n" "update app N n_old n_new" "show app N n"}, #业务应用服务

…}

执行节点create指令时自动下载业务标签Label(scada|fert|alarm|app|model|pmi|webd|admin, 用|分隔标示业务)指定的Docker images(存在则不下载), 启动Base类服务。基础服务指令包含"knoded" "kprssd" "ktaskd"等, 分别为NP、PRSS和TS等服务。业务应用基命令app包含"kscadad" "kcontrold" "kalmapid" "kmodeld" "krtud"等, 对象名称格式为k_app_分片编号_主备编号, 如k_kscadad_001_0是处理模型001号分片SCADA主服务(主备编号:0为主服务, 备服务按正整数编号)。

1.3 作业博弈

作业(job)是为完成某项功能而提交到TS的任务队列(FIFS), job = {name, taskQueue}。作业博弈时计算每个节点的等待执行任务数和负载值, 重新编排超配置负载节点上的新增任务。

1) 作业平均偏好和任务计算偏差

(1) job.taskQueue中有n个任务, 取RSDB库中同域内的App任务集(总数h), 计算作业平均偏好:

$ \begin{array}{l} job.ave\left( {calc} \right) = \\ \frac{{\sum\limits_{i = 1}^n {taskQueue\left( i \right).\;\mathit{target}\mathit{.}\;\mathit{calc}} + \sum\limits_{i = 1}^h {RSDB\left( i \right).\;\mathit{target}\mathit{.}\;\mathit{calc}} }}{{n + h}} \end{array} $

(1)

job.ave(storage)和job.ave(net)的计算公式类似于式(1)。

(2) 取队列中的任一任务p, 计算偏差指数:

$ p.\;bias\left( {calc} \right) = \frac{{p.\;\mathit{target}\mathit{.}\;\mathit{calc} - job.\;ave\left( {calc} \right)}}{{job.\;ave\left( {calc} \right)}} $

(2)

p.bias(storage)和p.bias(net)的计算公式类似于式(2)。任务p的calc、storage或net偏差指数高于其对应的平均偏好值越多, 其偏离程度正向越高, 说明任务p对该项偏好越明显, 要求部署节点的对应指标评分越高。

2) 负载预估及校核

节点上已经运行i个业务服务时的平均偏好为job.ave(calc), 执行计划新增j个任务, 负载预估计算:

$ load\left( {calc} \right) = \frac{{job.\;ave\left( {calc} \right) \times \left( {i + j} \right)}}{i} $

(3)

load(storage)和load(net)的计算公式类似于式(3)。当各行为均不超过配置范围时, 可发布编排任务。如果某项负载超过范围, 则需要把负载高的节点上该项目偏差指数最大任务重新编排给其他节点。

1.4 资源对象博弈

资源对象博弈的目的在于使每一个任务竞争到符合其偏好的资源, 通过计算每个节点的评分, 不断演化修正评分策略, 提高任务编排质量。设域中有m个节点。

1) 节点综合评分

为简化计算, 分析节点感知模型中cpu、mem、disk、TX及RX等关键资源的排序位置, 计算节点的行为评分:

(1) 服务启动时Lookup检索Node类节点, 再按节点检索属性值; 启动后调用Listen获取属性变化信息。

(2) 按属性值从大到小排序, 记录节点排序位置Sort。

(3) 计算节点n的评分值:

$ n.\;calcScore = \frac{{100 \times \sqrt {Sort{{\left( {n.\;cpu} \right)}^2} + Sort{{\left( {n.\;mem} \right)}^2}} }}{{2 \times m}} $

(4)

$ \begin{array}{l} n.\;storageScore = \\ \frac{{100 \times \sqrt {Sort{{\left( {n.\;mem} \right)}^2} + Sort{{\left( {n.\;"/"} \right)}^2} + Sort{{\left( {n.\;"/data"} \right)}^2}} }}{{3 \times m}} \end{array} $

(5)

$ n.\;netScore = \frac{{100 \times \sqrt {Sort{{\left( {n.\;Net.\;TX} \right)}^2} + Sort{{\left( {n.\;Net.\;RX} \right)}^2}} }}{{2 \times m}} $

(6)

$ n.\;allScore = \sqrt {n.\;calcScor{e^2} + n.\;storageScor{e^2} + n.\;netScor{e^2}} $

(7)

任务可根据偏好首先编排给节点标签组内对应行为打分最高的节点, 如果审核异常, 则编排给打分次高的节点。任务无特殊要求, 按节点综合评分值编排。

2) 节点性能指数

第k个节点n_k性能指数公式为:

$ n{\rm{\_}}k.perf\left( {calc} \right) = \frac{{n{\rm{\_}}k.\;store.\;calc - \frac{{\sum\limits_{i = 1}^m {node\left( i \right).\;store.\;calc} }}{m}}}{{\frac{{\sum\limits_{i = 1}^m {node\left( i \right).\;store.\;calc} }}{m}}} $

(8)

storage和net的性能指数计算公式类似于式(8)。

$ \begin{array}{l} n{\rm{\_}}k.perf\left( {all} \right) = \\ \sqrt {n{\rm{\_}}k.perf{{\left( {calc} \right)}^2} + n{\rm{\_}}k.perf{{\left( {storage} \right)}^2} + n{\rm{\_}}k.perf{{\left( {net} \right)}^2} } \end{array} $

(9)

当某项性能指数正值越大时, 说明该节点资源性能高于平均水平越显著。

3) 任务满意度

当队列中有n个任务时, 取一任务p的执行节点评分、任务偏差指数从大到小排序所处位置sort_bias、节点性能指数从大到小排序所处位置sort_perf计算p满意度:

$ \begin{array}{l} p.\;satisfy\left( {calc} \right) = a \times {\left( {pnodecalcStore - \frac{{\sum\limits_{i = 1}^m {node\left( i \right)storecalc} }}{m}} \right)^2} + \\ \;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;b \times {\left( {\frac{{sort{\rm{\_}}bias\left( {calc} \right)}}{n} - \frac{{sort{\rm{\_}}perf\left( {calc} \right)}}{n}} \right)^2} \end{array} $

(10)

其中, a、b为权重调节因子(当调整满意度到合理值后, 固定a和b的值), storage和net的任务满意度计算公式类似。分析式(10), 将某项性能排名靠前的资源分配给所有任务中对这项性能有较高要求的任务, 若符合任务调度的需求, 则满意度较高。

1.5 博弈反馈及均衡

节点资源对微服务的计算、存储或网络行为的偏好, 比其他运行微服务更具适应性, 并且种群会更趋向于由其单独构成, 这样的演化稳定结果即单态型, 称为演化稳定策略(Evolutionary Stable Strategy, ESS)。本文中的计算、存储、网络等资源采用单态性演化, 所占用的资源状态相互作用构成矩阵, 可逐步进化构成一个演化博弈。

设节点n上累计执行的任务数为k, 前期calc评分为n.calcScore1(原始评分可初始化为0), 本次任务调度后的评分为n.calcScore2, 则本次调度获得的calc评分对其评分的演化修正公式为:

$ n.\;calcScore = \frac{{k \times n.\;calcStore1 + n.\;calcStore2}}{{k + 1}} $

(11)

storage和net的评分演化修正公式类似于式(11)。

节点可部署的并行执行同一业务服务的主备分片应用个数的限制公式为:

$ \begin{array}{l} mai{n_{{\rm{num}}}} = \left\lceil {\frac{{有效服务数}}{{节点个数}}} \right\rceil \\ backu{p_{{\rm{num}}}} = mai{n_{{\rm{num}}}} + 1 \end{array} $

(12)

节点会依据自身执行任务后的评分改进任务竞争能力。每个节点都会根据其自身资源的特点, 影响评分走势, 节点资源对象的种群稳定结构即达到博弈的均衡。

1.6 任务调度算法

弹性调控平台上任务调度的服务组件架构设计具体如下:

Begin选取业务域;

节点感知、采集信息存储到键值数据库中;

按计算、存储、网络等资源训练排序, 初始化节点综合评分;

资源对象博弈组件{

监视域范围内节点资源信息, 按感知模型更新键值数据库;

按域中资源对象分类排序, 记录排序位置;

计算节点分类评分及综合评分, 分值更新键值数据库;

}

作业博弈组件{

接收新作业job;

while(取待调度的任务p, p∈job.taskQueue) {

计算p的偏差指数, 确定p偏好的资源;

综合评分最高的节点竞争到p, 预估p执行后节点上计算、存储、网络3类负载是否超过阈值;

未超过阈值时用评分最高的节点名组装任务指令p.task;

超过阈值时依次取评分次高的节点竞争p, 直到p被分配; }

发布job的执行计划, 目标节点获取后执行并反馈结果;

}

博弈反馈组件{

收集执行计划的反馈信息, 执行异常的任务需再重发2次;

取键值数据库的评分值, 估算任务满意度的权重调节因子a值和b值, 计算满意度; 权重因子校核稳定后, 固定不变;

后续任务计算的满意度高, 任务的节点调度分配合理; 否则, 修正对应的评分式(4)~式(6), 获取高满意度;

}

博弈均衡组件{

设置突变条件:参考式(12)限制主备分片应用的个数;

取键值数据库APP类的object, 统计超编任务集;

while(取任务p, p∈超编任务集) {

根据p识别业务的服务组, 确定可调度任务的节点组;

检索出节点组内运行主服务最少的节点a和运行备服务最少的节点b; p的操作对象是主服务, p分配给a节点; p的操作对象是备服务, p分配给b节点; }

发布突变执行计划;

取节点组中节点的评分值, 评分表现均趋于平均, 则得到博弈的均衡; 否则说明本次尝试存在缺陷, 可修正突变条件重新尝试;

}

End

2 任务调度框架

本文通过资源对象及属性变化队列OAQueue和任务调度等待队列SWQueue 2个弹性队列, 完成集群节点间的消息通信, 任务调度框架设计如图 1所示。

2.1 节点感知器

节点感知器内部组件包含节点监管服务、业务感知服务和发送器。节点监管服务用于采集节点的CPU、内存、磁盘、网络流量、关键进程等资源信息, 并订阅、执行SWQueue的任务指令。业务感知前置通道状态及流量、事件告警及弹性消息总线流量等网络信息。发送器收集感知结果, 发送给节点的PRSS。

2.2 资源状态服务器

PRSS采用一主多备模式运行, 内置RSDB键值数据库存储感知信息, 提供目录定义和查询服务, 通过资源对象同步组件与OAQueue交互消息。目录查询Listen服务识别主服务器的定义成功信号, 将事务通知节点的资源对象同步组件和TS。目录查询Lookup服务提供调用节点RSDB的实时检索功能, 处理流程如下:

1) 主PRSS接收本地定义事务(create、delete、update或modify)或订阅OAQueue上标志为0的事务, 直接维护本地RSDB; Listen获取资源对象的变化事务(标志为1)转发OAQueue; 主PRSS每执行“配置指定条数”的定义事务, 执行一次DbCheck操作。

2) 备PRSS收到本地定义事务(标志为0)转发给OAQueue; 订阅OAQueue上标志为1的事务更新本地RSDB; 转发的事务被订阅执行, 反馈正确通知。

3) 事务的发起节点若是主服务器, 则发起者得到RSDB处理通知; 发起节点若是备服务器, 则发起者得到反馈通知。

2.3 任务调度器

TS处理任务调度算法组装的任务调度指令, 采用一主多备的网络部署模式运行, 包含4个核心组件:节点行为评分, 等待执行任务分析, 任务编排器和自动调度引擎, 工作流程如图 2所示。

任务调度器的具体步骤如下:

1) 调度器启动后, 目录查询服务定时Lookup查询节点的资源信息按演化博弈模型的计算节点评分值, 提交节点行为评分组件; 通过Listen监听资源的变化信息, 按博弈反馈及均衡算法, 不断修正节点评分。

2) 订阅任务指令组件消费待校核的任务指令, 提交给组建任务队列组件校核, 构建FIFO的Job1队列。

3) 节点打分重排, Job1校核转存Job2队列:

(1) 只编排App类create、remove或update指令。

(2) 取Job1中一App类任务, 编排给业务组中评分最高的节点; 如果是备服务, 则其对应的主服务在编排节点上, 需编排给评分次高的节点; 结果输入Job2。

(3) 返回步骤(2), 编排后续任务, 直到Job1处理完毕。

4) 等待执行任务分析和校核重排:

(1) Lookup查询域中每个节点上运行的微服务个数。

(2) 遍历Job2, 统计每个节点上待执行的任务个数。

(3) 负载预估, 将负载越限的任务重新编排给评分次高的节点; 无负载过高的节点时将Job2赋给Job队列。

5) 自动调度引擎接收Job队列, 审核指令, 判断TS是否为主服务, 若是则将Job转换为执行计划(状态变为1)发送出去, 否则直接把Job发送给SWQueue。

6) 节点监管服务的指令订阅组件, 消费标志为1的指令; 判别是否为在本节点投运的指令, 若是, 则执行指令, 并维护RSDB; 执行后将指令状态改为2后提交SWQueue。如果是节点退出类任务, 则由SCADA编号最小的节点完成目录定义操作。

7) 主调度器自动调度引擎的订阅校核指令组件, 执行SWQueue处理标志为2的指令, 完成闭环验证。

8) 如果常规指令发送20 s后, 主调度器未收到反馈, 则本次任务调度失败, 生成告警信息。当告警确认时, 重新编排失败的指令, 提交“手动编排”组件处理。

2.4 DbCheck

DbCheck依据对象的update时间实现校核:

1) 主PRSS启动Lookup查询出"O-"+D.name开头的指定domain的object; 资源对象同步服务封装object成待校核类事务(标志为2)提交给OAQueue。

2) 备PRSS订阅待校核事务, 得到集合CheckObj, 校核步骤具体如下:

(1) 取CheckObj中的一个待校核对象obj。

(2) 按obj.key查询本地RSDB, 若不存在obj, 则执行create, 并记录日志; 若key存在, 则读取对应的对象obj_local。

(3) 更新时间比较:若obj_local.uptime==obj.uptime, 则返回步骤(1);如果obj_local.uptime<obj.uptime, 则表示本地资源对象存在延迟, 通过远程调阅接口从主PRSS的RSDB下载obj对应的属性信息集, 并在本地执行modify操作; 如果obj_local.uptime>obj.uptime, 则表示obj所执行的节点之前为主节点, 且变化数据未发布, 将obj_local打上modify标志(标志为1)后提交给OAQueue。

3) 备PRSS订阅OAQueue上标志为1的事务, 本地执行定义操作。

3 框架应用及仿真

在广州供电局基于OpenStack与Docker技术^[12]搭建的EMS原型系统上开展图 1所示框架的测试验证, 设原型中每个分片关联一组SCADA应用服务、加载20万个量测点。原型IaaS平台提供固定的虚拟节点资源(10核CPU、64 GB内存), 其资源调度问题可参考文献[13]。通过测试7个~25个并行计算SCADA分片的任务调度性能, 验证了本文调度框架对500万个量测点的实时数据处理的可行性。

分析图 2可知, 任务调度器采用FIFO队列调度模式, 任务指令的优先级:Node>Base>App, 高等级task指令执行完毕后才能执行低等级的指令, 同等级的指令可以并行调度。本文任务指令模型封装了单机版Docker运维操作命令, 依赖任务调度框架实现容器调度。仿真实验对比了测试环境与E8000平台网络对象和Docker Swarm任务调度的优缺点, 实现负载标准差和时间跨度值的可比性验证。

3.1 框架应用

图 1的任务调度框架采用演化博弈模型及云技术改进了E8000平台的网络对象感知调度技术, 通过分析SCADA任务编排、主备服务异常、节点退出等核心业务应用, 描述弹性调控平台业务应用的通用调度规则。

1) SCADA任务编排

设scada标签配置总服务数为25、有效数为7、一主一备模式部署, 测试4个节点(传统物理机一般部署4个节点)打分排序为scada04>scada03>scada02>scada01。参考式(12), 每个节点至多运行2个主服务或3个备服务。主服务按节点打分值从大到小的顺序部署, 打分最高的节点编排上主服务后变为打分最低的节点; 备服务按节点打分值从大到小的逆序部署。SCADA初始编排(服务前缀为k_kscadad_)如表 1所示。

作业创建及执行过程:

(1) ktaskd Domain create EMSI; #创建域

(2) 按SCADA组打分排序的顺序, 创建虚拟机节点:

ktaskd Node create scada04 SCADA; …

(3) 按表 1先主后备服务的顺序生成启动指令集:

ktaskd App create kscadad scada04 k_kscadad_001_0;…

ktaskd App create kscadad scada01 k_kscadad_005_1;

(4) 将以上任务指令(状态为0)写入队列。参考图 2, 完成任务调度。

scada01的Node类感知资源如图 3所示。

在节点新增scada标签后, 计算每个节点运行的最大主服务和备服务数。超过服务限制个数的节点将负载最小的主服务或负载最大的备服务, 迁移到新节点上。

2) 主服务异常

Listen检测到Base类服务异常, 在本节点重启3次, 启动异常发出告警; 检测到App类主服务异常, 将备服务变更为主服务, 并在组内其他节点上启动变更成功的备服务。若k_kscadad_001_0异常, 则调度过程如下:

(1) 检索k_kscadad_001_0服务是否存在, 若不存在, 则此服务正常关闭; 若"O-EMSI:App:scada04:k_kscadad_001_0"存在, 则scada04上服务异常, 需移除:

ktaskd App remove kscadad scada04 k_kscadad_001_0;

(2) 检索出其备服务集, 若k_kscadad_001_1存在, 则:

ktaskd App update kscadad scada01 k_kscadad_001_1 k_kscadad_001_0;

若1号备服务变主服务失败, 则向后变更2号; 以此类推, 直到主服务启动成功。

(3) 001_1备服务编排给scada组内剩余节点评分最高的节点(scada04), 若编排满足要求, 则执行:

ktaskd App create kscadad scada04 k_kscadad_001_1;

(4) 任务指令队列发送给SWQueue。

3) 备服务异常

Listen检测到App类备服务异常, 重启1次仍失败则需编排任务, 如scada01上k_kscadad_001_1异常:

(1) 检索"O-EMSI:App:scada01:k_kscadad_001_1", 若不存在, 则服务正常关闭; 否则服务异常, 先移除服务:

ktaskd App remove kscadad scada01 k_kscadad_001_1;

(2) 生成启动指令:

ktaskd App create kscadad scada01 k_kscadad_001_1;

(3) 任务指令队列发送给SWQueue。

(4) 如果20 s后, 服务还未启动, 选择新节点(scada03无k_kscadad_001_0, 且评分最高)执行启动指令:

ktaskd App create kscadad scada03 k_kscadad_001_1;

(5) 任务指令队列发送给SWQueue。

4) 节点退出

SCADA编号最小的运行节点检测到节点n异常或退出, 需把n上的App类服务迁移到其他节点上, 具体步骤如下:

(1) Lookup检索"O-EMSI:App:n.name:", 生成应用服务对象集合Obj。

(2) Obj中取一个对象obj, 找到obj的基命令。

(3) obj是主服务, 按"主服务异常"处理。

(4) obj是备服务, 按"备服务异常"处理。

(5) 收集执行失败的指令, 返回步骤(3), 直到无失败反馈。

3.2 仿真及对比测试

E8000网络对象技术是一种传统的分布式管理技术, 将分布式系统中的节点、平台或应用服务、重点业务应用等抽象成基于目录服务统一管理的对象, 感知对象的有或无, 采用Leader选举算法实现主备服务的管理。Docker Engine中Swarm提供服务发现、负载均衡、扩展和安全性, 文献[14]对Docker-Swarm进行改进, 提高资源利用率、集群负载均衡及稳定性。容器调度需考虑部署和迁移过程中服务的参数加载问题。文献[15]提出的云平台资源弹性调度策略, 综合考虑数据存储、资源负载和应用服务性能, 比较了Swarm_opt和Swarm的编排性能。

本文在相同的业务应用场景下, 首先开展单个分片的主备服务任务调度实验, 完成容灾耗时对比, 然后增加负载及应用服务数进行负载波动标准差对比, 最后扩展业务分片、增加计算服务, 完成演化调度与Swarm的时间跨度对比。加载一个20万量测点的SCADA分片, 在4个SCADA节点轻负载下逐个停止"kscadad" "kcontrold" "kalmapid" "kmodeld" "krtud"5个主服务(一主三备部署模式), 3种调度策略的主备迁移容灾耗时对比结果如图 4所示。

网络对象调度只需判断对象的有无, 开展分布式Leader选举, 效率最高, Swarm调度嵌入比较大的调度框架, 而演化博弈调度则经历了更复杂的排序评分算法, 容灾效率稍差。网络对象调度只支持单分片模式, 增加SCADA分片容量到120万量测点, 4个SCADA节点重负载下运行20个业务应用服务(主备模式:SCADA服务一主三备, 前置4个服务并行采集, 其他服务一主一备)。依次采用3种调度策略, 完成容灾比对5个服务的主、备异常的任务调度, 计算每轮调度后节点CPU和内存负载的标准差为其负载波动值。在10次任务调度后, 节点上CPU标准差计算方法具体如下:

$ \bar x = \frac{1}{n}\sum\limits_{k = 1}^n {cpu\left( k \right)} $

$ \sigma \left( {CPU} \right) = \sqrt {\frac{1}{n}\sum\limits_{k = 1}^n {{{\left( {cpu\left( k \right) - \bar x} \right)}^2}} } $

其中, n=10, cpu(k)为第k个任务调度后的CPU使用率乘以100;内存标准差按使用率求解。单分片模式各节点上运行的业务应用服务相同, 负载基本均衡。

在图 5中, 3种调度策略的负载波动基本持平。主服务需校核模型, 完成业务计算、组播计算, 资源消耗多, 切换执行节点会导致其负载波动明显。当调度多分片的业务服务时, 文献[13-14]采用Swarm固有的任务编排策略与演化博弈调度策略进行对比。按表 1初始化编排, 选用Swarm-spread策略与图 2的调度器进行比较完成仿真实验。初始SCADA节点排序及评分如表 2、表 3所示。

此时, 将节点的有效分片数从7个逐步扩展到25个, 平台量测点从140万逐步扩展到500万。顺序完成5次不同分片的主、备SCADA服务调度, 时间跨度对比结果如图 6所示。

多分片服务的关联服务及模型加载校核耗时较多。Swarm调度时关注CPU和内存空闲度, 经历10次调度后, 在16个分片时主备服务分布不均衡(存在节点运行2个主服务、11个备服务的情况), 主备负载均衡效果差、忽视了网络因素。随着实验分片的增加, 节点资源负载逐步接近告警值, Swarm片面均衡调度因素的影响越来越明显, 总执行时间呈指数增长趋势。

演化博弈调度综合计算节点的计算、存储、网络资源信息, 给出节点合理的评分后按业务组开展任务调度, 通过任务选择执行节点、节点负载预估、任务执行博弈反馈等手段, 不断进行演化计算。演化博弈编排的任务执行节点负载均衡, 随集群负载的增加任务调度总耗时呈线性增长, 计算复杂性随资源的变化改变较小。

4 结束语

本文研究演化博弈模型并设计弹性调控平台的任务调度框架, 实现对大型并行计算SCADA系统分片应用的任务调度。由于本文调度框架涉及业务感知的信息采集, 因此下一步需将前置采集和消息总线的网络监视信息纳入计算, 采用告警信息修正任务编排策略, 增加测试节点数及调度任务数, 实现更高效及稳定的任务调度。