一种可靠的高弹性云构架设计与实验

李明照， 王国勇

(洛阳理工学院 计算机与信息工程学院， 河南 洛阳 471023)

随着网络大数据等先进技术的快速发展，云计算领域对云框架的稳定性要求越发严格.为了节省云计算成本，加强服务器本身的鲁棒性，云框架稳定性设计需求由此产生[1].云计算框架作为当今迅速崛起的一种前沿技术，其用群计算的方式将众多单独的计算机经过高速局域网相连，提供更高计算效率[2].该技术在一定程度上将计算机与数据计算串联，由硬件支持转变成软件支持，同时拥有实时动态、自适应能力强的特征，优秀的框架集成机制能够更加完美地实现用户要求[3].

自云计算框架被提出以来，该技术在云计算领域发展尤为迅速.云计算框架结合数据网络，经过汇总、改良以及管理资源等一系列方式满足不同需求.云计算框架符合当下网络条件时，该网络数据的资源将可以随意使用，并不会因条件而被制约，用户可以在任意时间、地点来使用这项服务.但由于互联网用户的普遍性与数据分散性，导致当前云框架面临的问题更加多样化，如何有效地管制这些问题，是现在云框架研究领域需要解决的问题.

学者王毅敏[4]曾提出，根据SaaS平台来构建云框架，经过云计算用户对环境的选择完成设计.该框架在一定程度上能够大幅度提升执行指令的及时回应率，尽可能全面满足用户的基本要求，稳定系数高，可靠性较为优秀.但该框架在现实复杂数据计算中，存在效率低、网络运行不流畅的问题.针对上述问题，本文提出了云计算网络高弹性云构架设计方法，并对其可靠性进行分析.通过实验证明，该云框架弹性高、数据流稳定、信息准确丰富，具有优质的可靠性.

1 云框架负载问题分析

当前云计算框架下负载存在的主要问题是：通信服务器节点i在传递数据包的过程中，需要对比相邻节点的约束值，选取最优条件下的节点转发.一旦选取了最优节点，完成了数据包的转发任务，需要返回一个参数值，更新参数值与其他约束条件，以保证后面节点的信息传递更新.但是，由于不同位置的节点功能和处理能力不相同，节点承载的任务数量不能处于平衡状态，一旦发生负载不均衡，会造成网络拥塞，导致所有的候选节点发送失败，进而造成转发节点选择失败.

设云框架下的节点i∈S，并设定约束Q值.若节点i转发信息成功，其反馈计算表达式为

(1)

式中：D(i，k)为两个节点间的距离；e(i，k)为转发过程的能量开销；a为节点覆盖率；b为能量效率.在云计算框架下，通信成功会有反馈；通信失败，则会得到一个反馈(惩罚)，约束值更新为

Qt+1(i)=(1-λ)Qt(i)+λw(i)

(2)

式中，λ为学习速率，用来控制Q值的迭代刷新速度.约束值更新后，得到云框架下拥塞节点选择示意图如图1所示.

云框架下通信节点i通过约束Q值转发信息，将数据包传递给目标节点T，完成数据处理.当数据包来到传递路径上的节点2时，节点2有2—3和2—5两种路径可供选择，在节点2中Q值最大的邻居节点为节点3，因此数据包被发往节点3.以此类推，但节点3承载的任务数量过多，导致节点3所在区域发生了拥塞，造成了数据包在节点3发送延时增大，到达节点4的时间增加.网络阻塞的情况越严重，延时次数越多，Q值将越小.一旦约束值过小，会发生完全拥塞，甚至造成网络瘫痪，数据包直接丢失，云框架可靠性下降.

图1 云框架拥塞节点选择Fig.1 Node selection under congestion of cloud framework

2 高弹性云构架设计

云框架由并行计算、分散式计算以及网格计算组成，其中也包含了各项基础设施，即是相关服务.服务包括平台服务以及软件服务，同时拥有更加明显的7项特点：灵活性、单独性、紧急性、分享性、可扩性、安全性及持续性.结合这些特点，框架可以基于用户的要求来做出预期指令，良好的框架设计可完全避开忙碌期间而造成的服务器高负荷运转阶段，使云计算可靠性得到提升.

2.1 云框架弹性级别参数设计

云框架弹性是指数据发送需求的弹性区间，具体表示数据量变动造成节点负载变动的可能性，即是一个通信需求量针对节点改变的自适应程度[5]，计算表达式为

(3)

式中：ΔJ/J为通信数据需求量的变化率；ΔP/P为节点负载变动率.数据量和节点负载的变动比例完全相向，所以弹性系数为正值.云框架下的弹性需求及影响条件如表1所示.

在实际应用中，通信效果越好，则节点负载就会越高，进而将会造成拥塞.任意一条路径资源需求量越高，局部网络负载就会越重，可能导致网络故障等问题.

表1 云框架下的弹性需求及影响条件Tab.1 Elastic requirements and influence conditions under cloud framework

2.2 蚁群算法

蚁群算法是一种高智能算法，经过改良优化后可演化为深度学习算法[6-7].本文使用该算法计算云框架下服务器的数据最优传递路径，选取最优节点，并确定其可行性.

设m为蚁群数量，dij(i，j=1，2，…，n)为相邻路径节点i和j的间距，则在t时刻，蚂蚁k由i到j的概率为

(4)

式中：τij(t)为节点间路径的信息素浓度；ηij为启发因子，代表蚂蚁从i到j的预计效果深浅，一般取ηij=1/dij；α为路径上信息量的权重系数[8]；β为启发因子权重系数[9]；Ak为蚂蚁k目前可以经过的点.

n个时间段后，蚂蚁走过每一个路径节点，完成一次路径循环.每只蚂蚁路过的点，就是一个相对应的解.针对每一条路径上的信息作出更新处理，即

τij(t+n)=(1-y)τij(t)+Δτij

(5)

式中，y∈(0，1)为信息量τij(t)随时间变化产生的老化程度.

2.3 基于弹性约束的云框架负载均衡设计

由于现有云框架下节点搜索容易陷入局部最优解[10]，无法找到全局最优解，且最优节点上用户数量巨大，负载过重，可能导致拥塞.为减少该现象发生，在确定云框架弹性后，可将约束条件进行相关处理.

首先，假设最初通信成本为V0，如果该条件成立，则收益为W=MV0，其中，M为云框架下用户数量.其次，设置好每个服务器之间的距离，dij能够代表服务方的资源消耗与用户的需求喜好，距离越长，消耗的云资源越多，同等用户对该系统的需求越高.

为了能够提升整体框架的运用率，降低网络风险，本文根据均衡优化算法再次做出改良：在选取下一个服务器的同时，需要在弹性约束下，考虑距离与负载的问题，式(4)进一步约束为

(6)

3 仿真实验结果

3.1 云框架模拟测试

为了验证设计云框架的可靠性，进行了相关模拟实验.首先构建设计了基于蚁群算法和弹性约束的云框架结构，以节点i的数据传输为例，其传输路径如图2所示.

图2 云框架数据传输示意图Fig.2 Schematic diagram of data transmission under cloud framework

根据图2可以看出，采用蚁群算法计算得出节点i的传输路径共有两条，分别为i—1—2—3—4—T和i—1—2—5—6—7—T.第1条路径距离较短，传输时间较快，但是此时节点3、4的负载过高.此时需要引入弹性约束，在考虑距离的基础上引入节点负载能力作为约束参量，在两种参量的约束下，选取全局最优解，此时节点i将选择第2条路径来传输数据，避免了网络拥塞.

为进一步验证图2所示云框架的负载均衡特性，在云计算虚拟机数据库中选取10 GB数据组成网络结构，该网络结构图节点负载情况如图3所示.

采用文献[4]方法作为实验对比方法，分别测试云构架设计前后的节点负载情况，获得负载调度响应时间对比结果如图4所示.

分析对比图4可以发现，优化前的节点负载调度响应时间最慢，在数据量为10 GB时的调度响应时间为60 s；采用文献[4]方法对节点负载调度优化后，在数据量为10 GB时的调度响应时间为24 s；而采用所提方法优化后的调度响应时间为5 s.由此可见，所提方法能在最短时间内完成节点调度，基本实现云框架全局的负载均衡.

图3 网络结构节点负载示意图Fig.3 Schematic diagram of node load in network structure

图4 云框架用户负载响应时间图Fig.4 Load response time diagram of users under cloud framework

3.2 云框架下节点分布覆盖测试

假设云框架下各种服务器计算节点必须合理部署，本文采用国际通用的Voronoi划分方法[11]对图3所示的云框架节点进行划分，将其放在指定坐标系中，测试200 mm×200 mm空间范围内10 GB数据的节点覆盖率，得到Voronoi划分结果如图5所示.

在图5云框架节点位置分布基础上，对比测试文献[4]及本文算法节点负载情况，得到节点负载分布图如图6所示.比较图6可知，采用文献[4]方法优化后的云框架节点分布拥挤，节点超负载；而本文设计的云框架节点分布明显比优化前稀疏，且节点分布均匀，节点覆盖率高，没有明显的多重覆盖区域.

4 结 论

针对云计算网络节点负载不均衡问题，设计了一种高弹性云构架，并引入蚁群算法和弹性需求作为理论依据.同时，为了避免节点选择陷入局部最优解，运用需求弹性理论，引入弹性约束因子，动态改变信息浓度，使算法收敛到全局最优，从而使云框架达到负载均衡.通过实验对比可知，优化后的云构架能够选择最优传输路径，节点超负载状况得到了明显改善，节点覆盖率高.说明设计的云构架具有优质的平台可行性和运行弹性，在有效控制能量消耗的同时，还能延长网络稳定时间.

图5 云框架下的节点Voronoi划分图Fig.5 Voronoi partition diagram of nodes under cloud framework

图6 云框架下节点负载分布对比图Fig.6 Comparison of node load distribution under cloud framework