面向突变负载的容器资源弹性供给服务策略

闫承鑫,陈宁江,刘文斌,薛逸君

(广西大学 计算机与电子信息学院,南宁 530004)

1 引 言

容器1是一种轻量级的虚拟化技术,具有封装粒度小,部署效率高等优势,适合突发性和不确定性负载场景,逐渐成为应用运行支撑的主流基础设施环境.本文将这类突变负载称之为flash-crowd场景[1],是指大量用户同时访问服务导致的请求量远远超过服务器的负载能力,引起服务延迟增加或服务器宕机的问题,如电子商务应用中的秒杀、抢购和春运抢票等.文献[2]实验数据表明:Docker在该类突发负载应用场景下会随着请求并发量的持续增加,系统表现出流量停滞在400 Mbps至900 Mbps区间、并且响应响应时间增长3.85倍的问题.在flash-crowd场景下,由于服务器负载过重导致了服务器缓冲区的大量消耗,并且计算资源无法及时按需扩展来进行资源补充,所以请求需要等待较长时间的响应,造成了严重的SLA违约.

在Flash-crowd场景下,重点关注的是集群网络负载的监测和控制工作,容器云的突发负载环境下需要对计算资源具有高性能的弹性伸缩控制,所以不能照搬以往的工作.而另一种场景下,系统面临的工作负载则具有较强的动态性和周期性,被称为time-of-day效应[3].不少研究工作探讨了云服务环境下如何面向海量请求处理的需求来保障服务响应的实时性,但主要集中在解决time-of-day或month-of-year效应的场景.此类工作采用工作调度和负载控制的方式在一定程度上提高了系统的并发处理能力.但由于突发负载场景下对服务响应有较高的要求,故需要考虑云服务的载体和负载预测的问题.

2 相关工作

文献[1]提出了一种session级别的flash crowd控制策略SGAC,将session控制粒度和request控制粒度相结合,采用请求平均返回时延作为检测和控制的依据.文献[3]提出了一种基于Lyapunov优化技术的在线决策算法,通过该算法来

进行相应的请求分配.文献[4]采用排队理论构建两个自适应主动控制器来预测flash-crowd的发生时间,从而实现云的弹性伸缩控制.在考虑实时多工作处理方面,文献[5]和[6]提出了将docker容器嵌入工作流中的思想,并分别采用了三种不同粒度的嵌入策略进行了对比验证.文献[7]docker容器的批调度系统,通过调度器的选择算法进行工作的调度处理.文献[8]提出将BPEL引擎和docker进行结合的方式,使得其能够支持面向服务的多租户处理环境,有效的提高了系统的多工作处理性能.

在弹性控制方面,一类工作面向容器的弹性控制.例如:文献[9]提出了一种ECoWare自动化扩展技术,允许容器化的应用程序在虚拟机上扩展其资源(VM)级别和容器级别的扩容.亚马逊提供了一种Amazon Elastic Compute Cloud(EC2)2云端可调整大小的计算能力来进行扩容.另一类面向虚拟机弹性控制,例如:文献[10]和文献[11]采用了阈值设置的控制方法,通过监测当工作负载的增加超过某一阈值,自动分配更多的资源满足用户的SLA.文献[12]提出了一种基于反馈控制方法的CPU、内存和I/O等虚拟资源自适应配置器.文献[13]提出了一种虚拟机弹性伸缩的云基准策略,同时考虑了QoS、价格、容量和生产力等多个基准来进行弹性伸缩.由于以往的弹性控制工作为多次供给方法,忽视了突发环境下的资源供给频度的问题.

在预测方面,以往的分布式系统、中间件场景主要的预测方法为负载特分类与识别.例如,文献[14]提出了一种基于模式匹配的云计算资源负荷预测方法来预测下一时间段的云计算资源负荷.文献[15]提出了一种基于负荷数据分类的负荷预测方法,在隐形马尔科夫模型对不同类型的资源负荷数据进行特征分析的基础上进行预测.文献[16]提出了一种多供应商的云计算用户的资源分配方法,该方法对具有不同特性的资源负荷进行分类预测以获取用户在未来一段时问内的资源需求量.这些相关工作适用于具有强动态性和非线性的云资源负荷预测,但在突发负载的场景下,局限性在于如何寻找合适的历史负荷数据进行匹配.

总体而言,这些工作解决的都是time-of-day场景下的负载问题,但在flash-crowd场景下对负载的预测和容器供给策略等方面考虑不多,造成了容器扩展频度过高的问题.为了降低容器扩展的频度,需要对容器的数量需求进行预测,实现一次多个容器的扩展策略.如图1所示.其中,C1、C2、C3分别代表三种不同的容器Container C1<0.6>、Container C2<0.3>、Container C3<0.2>,括号内数值代表容器的大小.横坐标表示伸缩的次数,纵坐标表示容器的数量.图(1)为传统系统的伸缩方式,逐次拷贝多个不同类型的容器.图(2)为本文所采用的伸缩方式,通过对多种容器的多个拷贝来实现,有效降低突发负载情况下容器拷贝的频度.由于采用了这种方式的扩展,同时也引入了容器供给时间预测和容器供给数量问题以及有关服务质量、价格的容器供给多目标优化问题.

关于Docker的扩展问题,文献[17]建立了一种集成HA中间件的容器,通过组件的调度方案来实现集群的高可用.文献[18]设计了一种基于docker容器的分布式服务模型,实现了细粒度缩放的分布式系统.文献[19]使用docker和openstack构建了一种云服务架构,以优化docker的性能为目标.这些工作解决的都是time-of-day场景下的负载问题,但在flash-crowd场景下对负载的预测和容器供给策略等方面考虑不多,造成了容器扩展频度过高的问题.为了降低容器扩展的频度,需要对容器的数量需求进行预测,实现一次多个容器的扩展策略.以往相关的工作主要为基于模式匹配的预测策略,需要通过检测获得整个负载的曲线,然后和历史数据进行相应的匹配工作.而突发负载对于服务响应实时性有很高的要求.本文工作主要的贡献包括:

图1 Docker弹性扩展对比Fig.1 Extension comparison of Elastic Docker

1)建立容器供给时间预测模型,通过容器时间预测算法来预测负载增长的趋势,设定容器弹性伸缩的资源供给点和资源供给的区间.由于可以预先进行相应服务的容器拷贝工作,从而有效的满足了突发负载场景下对响应实时性的需求.

2)容器供给策略的实现,采用灰色预测模型对历史数据进行分析,来计算下一时间段的容器需求,制定容器供给数量的策略.由于有效的降低了伸缩的频度,避免了突发负载场景下服务频繁拷贝现象的出现.

3 容器资源供给策略

3.1 容器弹性供给框架

本文的容器弹性供给框架基于原生docker,并在此基础上加入了Elastic Controller弹性控制器.Elastic Controller主要包括MQueueSet、Predict controller和Message_bus三个组件.其中,Predict controller对负载数据进行预测处理,得出容器的供给时间和容器数量的预测值.由于以往的秒级处理能力无法满足flash crowd场景下的业务需求,故原生docker面临着突发负载场景下,缺乏快速自动化的扩展功能的问题.

3.2 容器供给时间预测

容器资源供给模型是根据突发负载场景下的负载特征,定义了突发负载的预测点,容器供给开始点和容器供给区间模型.模型中的曲线表示突发负载的特征曲线,纵坐标为负载的吞吐量,横坐标为时间,如图2所示.其中含容器供给开始点(Container supply start point)、容器预测点(Container predict point)、容器供给结束点Container supply end point.时间滑块Time slider代表预测的时期,step代表每一期的大小,k′代表预测期数的大小.

图2 容器资源供给模型Fig.2 Supply model of container resource

为了能够有效的确定突发负载的开始时刻,本文在预测过程中根据突发负载曲线的分段特征,采用“移动平均法+三次指数平滑法”的预测算法进行预测.相较于已有的趋势预测方法,本文的预测算法更适用于flash crowd场景下负载曲线的分阶段特征.

由于突发负载过程中时间序列数据的倾向线呈非线性,三次指数平滑法对于该场景有较好的预测性能.预测的具体步骤如下:

1)采用移动平均法来预测负载增量的变化趋势,计算后面第t时期(t = LNi)的负载变化的斜率,定义趋势期数参数LN={LN1,LN2,…,LNi}.移动平均法以最近实际值的一次移动平均值起点,以二次移动平均值估计趋势变化的斜率,建立请求负载增量预测模型,即:

(1)

(2)

(3)

4)依据趋势预测结果来确定容器供给点的区间.参数slopeLNi为监测负载曲线的斜率.当Container predict point的负载值出现多次slopeLNi<0时说明负载出现减弱.最后,根据策略确定出资源供给的结束点,这两点作为负载斜率预测区间来进行资源的供给LNi+k′.具体步骤如算法1所示.

算法1.资源供给区间设置算法

Input:L={L1,L2,…,Lt}.

1.Begin

2.GetYLNi + k′(n 1) and slopeLNi+k′from L={L1,L2,…,Lt};

3.Sett=LNi+k′;

7.ELSEIFslopeLNi+k′greater than the system setting;

8. Get stepnew=slopeLNi+k′×stepold,LNi+k′;

10.ENDINF

12.END

3.3 容器数量需求值预测

(4)

对框架下的n个服务按式(1)进行累加,得到服务集群所属容器分配的微分方程.求解得出微分方程的解集:

(5)

故由最小乘积得到:

(6)

通过分离变量法求解:

(7)

4 实 验

原型系统Elastic-Docker主要有MQueueSet Module、SSH2 Monitor、Elastic Module等模块组成,采用的核心软件包有docker-java.jar、docker-py.jar、Kafka_2.10.jar、Zookeeper-3.3.4.jar、Zkclient-0.3.jar、ganymed-ssh2-build210.jar.采用的第三方产品包括:Kafka消息中间件、Mysql数据库、Zookeeper和Docker容器.我们选取电商项目作为部署对象,电商项目采用了TPC-W的基准程序.为了验证本文提出的容器云弹性伸缩策略在容器预测值的准确性以及容器云弹性伸缩的有效性,本文设置了四组实验.

4.1 负载预测精度和供给效果对比

为了验证容器供给时间预测值的准确度,通过使用LoadRunner生成固定的负载曲线,运行预测程序来进行多次的实验验证.负载区间为[0,1200],持续的计算预测的负载值,对负载值绘制曲线.

图3 容器供给时间预测Fig.3 Prediction of container supply time

由图3(a)和图3(b)可知,本文的预测相较于原有的docker系统大幅提高了并发处理能力.在区间[0,1200]的突发负载区间内保持了较好的预测精度,对比实际负载曲线和预测负载值曲线,验证了本文的预测策略能够较好的预测容器的供给时间.

4.2 容器数量需求预测精度与误差分析

为了验证容器数量需求预测值的准确度,我们选取从100条batch到1500条batch的突发负载环境下进行了20次实验,并和实际的监测数据值进行对比,容器数量需求预测结果如图4所示.

图4 容器数量需求预测 Fig.4 Prediction of container quantity requirement

由图4可知,在突发负载场景下相较于其他预测方法,灰度预测模型能够较好地预测容器需求数量的数值大小.

4.3 资源利用率对比

为了验证本文消息处理机制在系统资源使用效率方面的情况,在突发负载场景下分别采用Elastic-docker、FC-LRU、EC2和Threshold四种不同方式进行弹性伸缩控制,并持续的监测容器集群CPU和内存资源使用率情况.通过不断的获取CPU的使用情况,验证本策略在突发负载时资源使用率高的优势.

由图5中可看出,随着单位时间内容器集群负载量的增加,4种弹性伸缩系统管理下的容器集群CPU消耗量逐渐增加.故可以看出本文系统在确保用户SLA的前提下,在容器集群的资源使用效率方面仍具有优势.

图5 CPU使用率对比Fig.5 Usage Comparison of CPU

4.4 弹性伸缩效果

为验证Elastic-docker对于docker集群的弹性伸缩效果,对比工作负载情况和容器数量情况.使用shop容器镜像作为弹性伸缩测试的单位,根据“Scaling=实时的容器数量×shop容器承受负载的阈值”计算出scaling曲线,分别对比了Elastic-docker和EC2两种弹性伸缩模型进行弹性伸缩效果的对比,实线代表弹性伸缩控制曲线,虚线代表实际的工作负载曲线.如图6所示.

相较于EC2的弹性伸缩效果,Elastic-docker的弹性伸缩具备更低的扩展频次.从如图的实验结果可看出EC2出现了多次的SLA违约情况,并且相较于Elastic-docker的弹性伸缩控制,EC2情况下伸缩的频度较高,而这种频繁的open/close模式的伸缩造成了容器集群较为频繁的抖动现象,产生了额外的开销.故可知Elastic-docker能够较好的满足用户SLA,而不产生过多的伸缩次数.

图6 容器云弹性伸缩效果对比Fig.6 Comparison of elastic container stretching

5 讨 论

通过实验对几种不同的弹性伸缩方式进行对比,结果证明了Elastic-docker弹性伸缩策略在突发负载场景下,相较于相关工作中的其他系统具有较好的弹性伸缩性能.本文的预测策略能较准确的对突发的负载进行预测,进行相应的容器供给预测,并且容器集群的CPU、内存资源的使用效率得到了大幅提升.实验验证了本文的策略能够满足大规模消息下服务及时响应的需求,并有效提高系统的性能.