亚马逊的弹性计算云(Amazon Elastic Compute Cloud,EC2) 计算服务[1]历经接近10年的快速发展,目前已经成为IT业界最炙手可热的话题之一,它将计算资源、存储资源和网络资源高度整合,为用户提供高可用、高扩展的计算资源[2]。据最新报告显示,2015年全球公有云市场总额已经突破700亿美元,并且预计会在2018年左右超越1200亿[3]。然而在云计算高速发展的背后却隐藏着许多安全和挑战[4],诸多国内外著名的云服务提供商都曾遭遇过严重的安全事件,如亚马逊网络服务(Amazon Web Services,AWS)遭受僵尸网络攻击[5]、阿里云云盾升级导致租户正常文件被删除[6]等,美国国家标准与技术研究院(National Institute of Standards and Technology,NIST)也在其报告中指出针对多租户场景下,共享公有云资源的模式将会引入新的攻击路径[7]。所以云服务商是否能够给用户提供安全服务成为评估云服务商的重要标准。
当前主流云服务提供商如VMware、阿里云、亚马逊等都为虚拟机提供安全防护,如阿里云的云盾[8]、VMware的NSX[9]和AWS的白皮书中都提到了虚拟机防护概念,随着网络功能虚拟化(Network Function Virtualisation,NFV)技术的不断进展,利用虚拟化技术实现特定安全功能的接入以满足云环境下对租户内部安全功能的灵活可控将成为潮流。进一步地,利用虚拟网络功能转发图(Virtualisation Network Functions Forwarding Graph,VNF FG)定义数据包的流向,实现在NFV环境中将虚拟机流量引流至安全服务网络进行处理[10-11],从而解决安全服务在云环境虚拟网络中的快速部署问题。
一方面,为了方便管理并且尽可能减少安全服务自身的攻击面,当前各大云厂商的安全服务集中部署在安全服务池,并与计算服务资源池相隔离,且安全服务作为增值服务与计算服务相比资源相对有限;另一方面,当租户遭遇安全问题,往往是大量同租户虚拟机请求安全服务,并且要求安全服务快速响应。在这种业务需求下,安全服务资源分配算法既要考虑云环境下的租户属性,如租户购买的安全服务资源配额必须满足,又要将剩下资源快速分配以实现安全资源的快速响应。
针对上述需求,目前已有一些研究成果。文献[12-13]分别提出的基于蚁群算法和改进速率单调(Rate Monotonic,RM)算法的云环境任务资源调度分配算法更多考虑的是虚拟机对外提供服务,并未考虑到多租户场景;文献[14]提出了基于匹配规则的 MapReduce任务调度模型,虽然考虑了云环境中计算节点的动态性,尽可能利用计算节点资源,但是对多租户同时请求安全服务时的并发性和快速响应以及多租户之间的配额、抢占等关系考虑不足;Hadoop中的调度器Fair Scheduler[15]解决了复杂环境下任务的调度问题并且保证了各个租户的公平性,但是参数过于复杂,并不适用于本文单一安全服务的调度任务;文献[16]实现了基于服务质量(Quality of Service,QoS)的资源池创建和调度,但是其对物理资源的使用效率并未作完整考虑。
基于当前安全服务接入多租户中产生的安全服务调度问题,本文研究了相关的调度算法并且结合基础设施即服务 (Infrastructure-as-a-Service,IaaS)环境和接入的场景,设计了安全服务调度框架和安全服务资源分配算法。该算法采用最大最小公平算法为主要思想,结合了云环境下多租户最小共享资源量实现对租户的最小资源量的保证,并且解决了多任务之间的抢占问题。实验结果表明,本文提出的安全服务调度框架可以有效解决安全服务资源不足所导致的资源分配问题,实现多租户环境下安全服务的合理调度。
1 安全服务接入架构及分析 1.1 安全服务接入架构当前典型的安全服务接入架构如图 1所示。当控制单元接收到租户请求后,在安全服务节点中创建一个对应安全服务虚拟机(Security Virtual Machine,SVM),通过虚拟网络接入组件接入到虚拟化节点中为虚拟机提供安全服务。
当SVM启动时,每一个SVM将会对应一个需要服务的租户子网,每一个租户都拥有自己的一个虚拟的安全服务资源池,每当租户有相关安全需求时只需要调用池中实例即可,安全服务接入逻辑图如图 2所示。
每一个租户都拥有属于自己的安全服务虚拟资源池,租户通过Task为子网中的虚拟机提供安全服务时,Task是在虚拟资源池中启动的SVM,底层运行在安全服务节点的安全服务通过调度机制抽象为逻辑上多个独立的资源池,通过合理调度各租户的安全服务来保证租户之间的公平性并且尽可能使底层物理资源被高效利用。
2 安全服务调度设计本章基于最大最小公平算法[17],结合Fair Scheduler调度器为每一个租户的资源池加入最小共享量的概念,并设计了安全服务资源分配算法,之后考虑不同租户间的资源抢占和租户内部的任务调度问题,提出安全服务调度设计方案。
2.1 最大最小公平算法最大最小公平算法的基本含义是公平地将资源分配给每个用户想要的最小需求,然后将没有使用的资源集中起来均匀分配给需要“大资源”用量的用户。
最大最小公平算法的形式化定义如下:用户总是按照递增的顺序获得资源;每个用户不可能获得比自己需求的资源更多的资源;当某个用户的需求不能够被满足时总是会等价地对过剩的资源进行公平分享。
最大最小公平算法在本文场景中的描述如下:当前安全服务节点的安全服务资源总量为C,当前存在的租户总数为T,分别为{T1,T2,…,Tn},每一个租户Ti(i=1,2,…,n)对资源的需求量为Ri,当前所有租户需求的资源总量为R={R1,R2,…,Rn},可以获得的公平共享资源量为Ci,根据上面的形式化定义,有如下的形式约束:
对于任意一个租户Ti均有:0≤Ci≤Ri;
当前所有租户的资源综合要小于安全服务节点的服务能力:$\sum\limits_{i=1}^{n}{{{C}_{i}}}\le C$。
在上述约束条件下通过函数:Cmin=F(C,T,R)获得每个租户的最小的公平量。
2.2 安全服务资源分配算法在结合上述最大最小公平算法的基础上,考虑到云环境下按需付费使用的特性,本文参考Fair Scheduler的最小共享量的定义,为每一个租户Ti定义了他的最小共享量为mi(0≤mi≤Ri),安全服务资源分配算法保证了当0≤Ri时:
$0\le \min ({{R}_{i}},{{m}_{i}})\le {{C}_{i}}$ | (1) |
即最终给租户提供的公平共享量应该大于他的最小共享量(如果他的资源需求量小于最小共享量时,公平共享量只需要满足他的资源需求量即可)。
安全服务资源分配算法的伪代码如下,其中:Ri和mi分别为租户i的资源需求量和最小共享量,Ts表示当前请求服务的租户集合,C表示当前安全服务节点资源总量;最终求{C1,C2,…,CS}为当前Ts中每一个租户的公平共享量。
1) M=C; //当前未被分配的资源
2) sc=0; //当前已经被分配资源的租户
3) sa=Ts; //当前等待分配资源的租户
//首先为资源需求量比最小共享量还小的用户分配资源
4) for(i∈sa) do
5) if(Ri<mi) then
//由于资源需求量小于最小共享量,因此必须保证式(1) 成立,
//直接分配资源,此时总资源量变少
6) Ci=Ri;M-=Ri;
//此时租户Ti的公平共享量Ci和剩余资源量M的变化
7) sa=sa-{Ti};sc=sc∪{Ti};
8) End if
9) End for
//为所有剩下的租户分配至少满足其最小共享量的资源
10) for(i∈sa) do
11) Ci=mi;M-=mi;
12) End for
//然后需要判断资源C是否已经分配完毕,如果已经分配完毕,
//则当前待分配集合中的租户都应该变成已分配
13) if(M=0) then
14) for(i∈sa) do
15) sa=sa-{Ti};sc=sc∪{Ti};
16) End for
17) End if
//如果满足所有人最小共享量后此时还有资源剩余,
//则将剩下的资源进行分配
//定义Rmin为当前sa中租户需求量的最小值
//定义Cmin为当前sa中租户公平共享量的最小值
//定义Tmin为公平共享量为Cmin的租户集合
//定义Cnext为当前sa中租户公平共享量的次小值
18) while(((sa)≠0) and (M>0) ) then
19) //满足租户间公平的剩余资源分配方法
ΔC=min(Cnext-Cmin,M/count(Tmin),Rmin-Cmin)
20) for(i∈Tmin) do
21) Ci+=ΔC;M-=ΔC;
22) sa=sa-{Ti};sc=sc∪{Ti};
23) End for
24) End while
以下通过图 3~6对以上代码逻辑进行解释,整个安全服务资源分配算法分为三个步骤:
图 3为初始分配状态,其中虚线代表租户的资源需求量Ri,实线代表租户的自最小共享量mi,90代表安全服务节点的资源总量,柱状图内数值代表当前租户的公平共享量。
首先对资源需求量比最小共享量小的租户A进行资源分配,分配后如图 4。
然后要给剩余租户进行资源分配,保证每个租户分配的资源满足其最小共享量,进行资源分配后的情况如图 5。
此时资源池中依然还有资源为4,并且每个租户都分配了自己的最小共享量(A租户直接分配到了资源需求量,因为它的资源需求量比最小共享量要小,所以可以直接满足),剩余的资源将会被尽可能公平地分配到B、C、D三个租户当中,应该满足如下准则:
1) 租户之间的公平共享量应该保持大致的公平,这是公平算法首先要保证的;
2) 每一个当前拥有相同共享公平量的租户都应该平等地获得资源;
3) 在相同共享公平量的前提下如果还有剩余资源则应该尽可能足某个租户的需求。
本文中使用逻辑:ΔC=min(Cnext-Cmin,M/count(Tmin),Rmin-Cmin)对资源分配进行定义。其中:Cnext-Cmin保证准则1) ,将会让当前公平共享量最小的租户尽可能增加资源,使之缩小与其他租户的差距达到公平;M/count(Tmin)则会保证当前相同公平共享量的租户在被分配资源时可以平等;Rmin-Cmin则保证了当公平共享量相同时可以优先满足某个租户的需求。
按照上述逻辑计算可得ΔC=4,此时将剩下的资源分配给队列B,如图 6。
此时资源分配工作完成,在四个租户中达到了安全服务资源分配的相对公平合理。
2.3 任务优先级和资源抢占按照上述安全服务资源分配算法将资源分配给租户后,租户需要将自己的任务形成任务队列来使用安全服务资源,本章将介绍租户任务队列中任务的优先级以及租户间的抢占算法。
2.3.1 租户任务优先级由1.2节可知每个租户都拥有自己的虚拟资源池,当资源分配完毕后,根据租户队列内任务的紧急程度为每个任务添加优先级属性,队列内的任务按照优先级的顺序进行调度,整个租户队列任务调度示意图如图 7。
新任务根据所属租户加入到对应租户的队列当中,每当租户虚拟资源池中有资源时,总是执行优先级较高的任务,当新到任务优先级较高但是租户资源池中已无资源时,总是先抢占其他租户队列中优先级低任务的资源,关于资源抢占将在2.3.2节中进行介绍。
2.3.2 资源抢占在上述的任务队列中,当新任务到来时,假如当前租户资源未满足最小共享量时,会触发租户间抢占。上文中提到的租户最小共享量和公平共享量,根据上文定义(Ci和mi分别为租户的公平共享量和最小共享量)给出“超额占用”定义:
$exces{{s}_{i}}={{C}_{i}}-{{m}_{i}}$ |
当租户的超额占用过大时,代表租户实际获得的资源量大于它的最小共享量,此时租户获得的超额资源(除租户购买的最小共享量以外的资源)过多,当其他租户有抢占需求时,此租户需要将自己的部分资源释放。但是与Fair Scheduler调度思想不同的是,当此租户释放掉自己的资源后,其任务会挂起并等待资源获得后继续运行而并不是直接关闭租户的任务。
2.4 安全服务调度框架根据前面介绍的在安全服务调度中不同租户的资源分配和抢占,以及同一租户内部任务的调度方式,提出安全服务调度框架如图 8所示。
从图 8可以看到整个调度过程分为两个部分:一部分是通过租户请求计算公平共享量并将请求的任务入队;另一部分是使用安全服务资源执行租户任务然后出队。两个部分异步进行,共同完成在云环境下安全服务的调度,保证了安全服务物理资源高效率利用和不同租户之间的大致公平。
3 测试与分析 3.1 测试环境本文研究基于云计算中的IaaS模式,底层Overlay网络使用VxLAN进行封装,计算节点采用华为服务器,配置为E5-2609和8 GB内存;网络节点、控制节点和安全服务节点均使用普通PC,配置为i3-3220和8 GB内存,操作系统均为CentOS6.5。IaaS云平台选用开源OpenStack的IceHouse版本,虚拟网络设备为Open vSwitch 2.0.1 ,安全服务为OpenVAS7提供的漏洞扫描服务,将其部署在SVM上。实验平台的具体架构如图 9所示。
IaaS平台实验架构中主要包括控制节点:主要部署OpenStack控制台完成OpenStack基本功能和软件定义网络(Software Defined Network)/网络功能虚拟化 (SDN/NFV)控制器完成安全服务的相关调用;安全服务节点目前主要是承载SVM,为租户提供安全服务;计算节点为IaaS提供计算资源;网络节点主要为IaaS提供网络连接,包括服务租户的动态主机配置协议(Dynamic Host Configuration Protocol,DHCP)服务和路由服务等,其中数据网络主要完成数据交互,包括计算节点的业务数据、安全服务节点的安全检测数据等;控制网络主要传递控制信息如配置信息、安全服务调度信息等;公共网络主要是虚拟机和宿主机连接互联网的链路。
3.2 任务调度测试与分析由于本文2.2节中提出的安全资源分配算法借用了Fair Scheduler算法思想,因此将两者进行对比;此外还对比了先进先出(First In First Out,FIFO)算法和基于匹配规则的MapReduce任务调度模型。
实验创建10个租户,并且随机地为租户生成最小共享量/资源需求量,为了尽可能模拟在实际环境中租户需求紧张/空闲的情况,这些安全资源请求其中包括租户需求量大于最小共享量,同时也包括租户需求量小于最小共享量的情况。
表 1为一个样本的测试数据,其中包括10个租户、随机生成每个租户的最小共享量和资源需求量,每个测试样本的资源总量固定为100。总测试样本总量为20组,测试得出的不同算法的资源利用效率平均值如表 2。从表 2可以看到,由于本文提出的安全服务资源分配算法和Fair Scheduler方法都允许租户使用其他租户空闲的资源,因此物理资源利用率与单纯的FIFO算法相比具有明显优势;基于匹配规则的MapReduce 任务调度模型由于充分利用了物理机计算资源,因此在效率上比传统FIFO提升了19.97%,但是由于其应用场景下租户依然不能抢占其他租户的资源,因此在实际实验中其资源利用率还是略低于安全服务资源分配算法和FairScheduler方法。由于本文的安全服务资源分配算法基于Fair Scheduler思想,因此这两者之间的物理资源利用率大致接近,但由于本文优化了Fair Scheduler算法中的参数,使其适用于单一任务的资源分配,因此效率有了小幅的提升。
作业执行效率反映的是租户从提交任务到获得安全服务,以及最后得到结果的全过程耗时,其直接影响到租户的工作效率,本文对上述四种算法的作业执行效率进行了测试,作业内容为使用OpenVAS对不同租户子网内的几台虚拟机进行漏洞扫描。三种算法测试样本如表 3,表明云环境下a、b、c三个租户中分别有5、0、1台虚拟机请求漏洞扫描服务,三个租户购买的漏洞扫描服务资源为2、1、2台,最终测试结果如表 4。
本文的安全调度过程相比FIFO和Fair Scheduler以及MapReduce任务调度模型在作业效率上都有提升,一方面是由于租户空闲资源的再使用使租户任务执行的并行度获得了提高,同时执行更多的租户任务,尽可能减少了检测任务的等待时间;另一方面是因为采用了租户任务暂停而不是将其直接杀死的方式,因此当暂停的任务再次获得资源时可以有效利用暂停前的状态而无需让任务再次重新启动,因此也减少了计算资源的浪费,提升了作业效率。
4 结语针对云环境下多租户共享安全资源时,由于资源不均导致的安全服务效率降低的问题,本文结合IaaS云平台特征改进了Fair Scheduler算法,实现了云环境下安全服务调度框架,通过实验验证了改进算法在系统资源利用率和作业效率上均优于原Fair Scheduler算法。在下一步工作中一方面将更加注重针对不同类型安全服务(如漏洞扫描、防火墙等)的不同分配策略,以进一步提高内存、CPU等物理资源利用率;另一方面考虑到安全服务动态性和安全服务资源的动态伸缩,需要对算法进行进一步改进,使之可以应用到更加复杂的安全服务资源调度场景。
[1] | VARIA J, MATHEW S. Overview of Amazon Web services[EB/OL].[2015-01-21]. http://docs.aws.amazon.com/gettingstarted/latest/awsgsg-intro/intro.html. |
[2] | MELL P M, GRANCE T. The NIST definition of cloud computing, SP 800-145[R]. Gaithersburg, MD:National Institute of Standards & Technology, 2011. |
[3] | MURRAY S. IDC forecasts[EB/OL].[2015-11-20]. http://www.idc.com/getdoc.jsp?containerId=prUS25797415. |
[4] | ZISSIS D, LEKKAS D. Addressing cloud computing security issues[J]. Future Generation computer systems, 2012, 28 (3) : 583-592. doi: 10.1016/j.future.2010.12.006 |
[5] | 亚马逊EC2云计算服务遭到僵尸网络攻击引发故障[EB/OL].[2016-06-13]. http://www.2cto.com/News/200912/43369.html. ( The EC2 of Amazon was attacked by botnet[EB/OL].[2016-06-13]. http://www.2cto.com/News/200912/43369.html. ) |
[6] | 阿里云9月1日云盾升级故障真相[EB/OL].[2015-09-11]. http://www.infoq.com/cn/news/2015/09/aliyun-yundun?isappinstalled=0. ( The truth of the malfunction which is occur in Aliyun at Sep.1[EB/OL].[2015-09-11]. http://www.infoq.com/cn/news/2015/09/aliyun-yundun?isappinstalled=0. ) |
[7] | JANSEN W, GRANCE T. Guidelines on security and privacy in public cloud computing, SP 800-144[R]. Gaithersburg, MD:National Institute of Standards & Technology, 2011. |
[8] | 阿里云安全白皮书V1.2[EB/OL].(2014-03). http://www.chinacloud.cn/show.aspx?id=15308&cid=29. ( The white paper of Aliyun security system[EB/OL]. (2014-03). http://www.chinacloud.cn/show.aspx?id=15308&cid=29. ) |
[9] | The VMware NSX network virtualization platform[EB/OL]. (2015-07)[2016-03-16]. http://www.vmware.com/cn/products/nsx/. |
[10] | ETSI. Network Functions Virtualisation (NFV); architectural framework[EB/OL].[2016-03-16]. http://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.01.01_60/gs_NFV002v010101p.pdf. |
[11] | ETSI. Network Functions Virtualisation (NFV); virtual network functions architecture[EB/OL].[2016-03-16]. http://www.etsi.org/deliver/etsi_gs/NFV-SWA/001_099/001/01.01.01_60/gs_nfv-swa001v010101p.pdf. |
[12] | 王永贵, 韩瑞莲. 基于改进蚁群算法的云环境任务调度研究[J]. 计算机测量与控制, 2011, 19 (5) : 1203-1204. ( WANG Y G, HAN R L. Study on cloud computing task schedule strategy based on MACO algorithm[J]. Computer Measurement & Control, 2011, 19 (5) : 1203-1204. ) |
[13] | 王祺元, 闫宏印. 基于改进RM算法的云环境任务调度研究[J]. 计算机测量与控制, 2013, 21 (6) : 1612-1614. ( WANG Q Y, YAN H Y. Study on cloud computing task scheduling strategy based on RM algorithm[J]. Computer Measurement & Control, 2013, 21 (6) : 1612-1614. ) |
[14] | 金伟健, 王春枝. 基于匹配规则的MapReduce任务调度模型[J]. 计算机应用, 2014, 34 (4) : 1010-1013. ( JIN W J, WANG C Z. MapReduce tasks scheduling model based on matching rules[J]. Journal of Computer Applications, 2014, 34 (4) : 1010-1013. ) |
[15] | ZAHARIA M, BORTHAKUR D, SARMA J S, et al. Job scheduling for multi-user mapreduce clusters, EECS-2009-55[R]. Berkley:University of California, EECS Department, 2009. |
[16] | 吴吉红.基于服务质量的多租户资源调度方法研究[D].沈阳:辽宁大学, 2012:21-48. ( WU J H. Multi-tenant resource scheduling method based on the quality of service[D]. Shenyang:Liaoning University, 2012:21-48. ) |
[17] | MARBACH P. Priority service and max-min fairness[J]. IEEE/ACM Transactions on Networking, 2003, 11 (5) : 733-746. doi: 10.1109/TNET.2003.818196 |