由于虚拟化技术能对多个服务有效隔离避免其相互间干扰而得到广泛应用。对于需要多个服务协同工作的大型应用，传统虚拟机监控器调度时忽视了虚拟机间的协同性，降低了虚拟机间并行工作的可能性，从而影响了服务质量。对虚拟机的协同调度进行研究，分析了调度对虚拟机协同性及服务质量的影响，提出了一种虚拟机协同调度算法。实验表明，协同调度使虚拟化平台服务器响应时间降低了1/3，且没有对调度的公平性造成明显影响。
2011,47(6) Computer Engineering and Applications计算机工程与应用 3协同调度算法 如果VCPU在 CO-group中,首先设置本地fag状态标识为正在 31协同调度的原理 协同工作无协同请求,然后查看此 co-group中其他没有运行的 当计算机系统存在多个 CPU/core时,虚拟机的调度涉及VCPU所在物理 CPU flag状态,若为非协同工作且无协同请求 到 CPU/core的时间调度和空间调度两个方面。其中空间调度就向其发送通知事件并把nag标识为有协同请求;如果vcPU 决定运行虚拟机的具体 CPU/core,时间调度决定运行虚拟机不在 co-group中,设置本地ag标识此物理CPU正非协同工作 的具体运行时间。此时,调度功能·般通过两级调度实现。无协同请求:返回下周期将要运行的VCPU,调度结束 种比较简单的调度功能划分方式,如Xen(htt:www.xen. Start org),为山全局调度器负责进行空间调度,基本确定虚拟机和 CPU/core之间的对应关系;出各个CPU/core的局部调度器负 有协同请求 <、检测na状态 责确定分配到其上的各个虚拟机的具体运行时机。局部调度 器的另外一个功能是进行CPU/cr之间的负载平衡,以避免 单纯依靠全局调度器岀现负载不均衠。在此种两级调度模型 中,需要协同的虛拟机能否并行运行取决于:(1)这些虚拟机 原调度顺序 优先调度co- group成员 是否被分配到不同的 CPU/core上;(2)局部调度器能否协作, YE 同时调度这些虚拟机运行。 ≤被调度vcpu是否在co- group 为将协同的虚拟机分配到不同的 CPUicore上,定义了虚 设置nag标识本cpu正 拟机协同组(co- group)。用户通过协同组声明虚拟机间的协 设置nag标识本cpu正运行 同关系。全局调度器接收到协同组虚拟机的请求后,尽力将 非co- group成员 通知同组 co-group成员 同一个协同组内的多个虚拟机分配在不同物理 CPU/core上运 行,运行中也山局部调度器调节 返回被调度vepu 为使得位于不同 CPU/core上需协同的虚拟机在相近的时 图3co- credit算法流程图 间段获得执行,当协同组中某虚拟机被调度时,局部调度器根 co- credit算法会使得OVER状态的ⅤCPU得到调度,这在 据一定条件向组中其他成员所在物理 CPU/Cor发送一个通知局部上会造成不公平,但在全局上并不会影响CPU公平分配 事件,其他CPU/core会发生调度事件,同时优先运冇这一协同 组虚拟机,这样保证了协同虚拟机运行的同步、并行 上面描述可知,当物理CPU接到调度事件时会检查fag状态 中3.2 co-credit协同调度 如果此时有协同请求会优先调度cg0op中WM。此时也许4 VM的 credit值已经用完,处于OVFR状态,可能抢占了其他高 3.21Xen中cred调度算法 优先级VM运行机会,这种破坏了原有公平性的行为,称之为 credit scheduler是一种公平调度器。在Xen中VCPU(虚 局部不公平性。由于VM处于over状态,系统会继续扣除其 拟CPU)是调度基本单位,每个VCPU属于一个VM,一个VM credit值,让它变成负值。那么此VM从OⅤER恢复到 UNDER 可以有多个VCPU。VMM为每个ⅤCPU分配一定量 credit值 的速度就会变慢,未来调度机会减少 并按照 credit值公平调度各个VCPU。VCPU有两种状态,UN DER和OVER。Ⅴ CPU credit值用完公进入OEⅤER状态,UN DER表示 credit值还有剩余。在进行调度时,调度器只关心虚 4实验测试分析 拟机所处的状态,而不关心其剩余的crdt值多少,处于UN41实验设计 DER状态的虚拟机优先于OVER状态的虚拟机被调度,处于 在Ⅹen中,虚拟机称为域( domain),其中一个域为驱动域 相同状态的虚拟机按照先进先出的方式运行。系统每隔一定用 domain0表示,其他域用 domainU表示。 domain0中有物理 时间触发一次调度中断,当前正在运行的虚拟机会被减掉 机硬件驱动程序可以直接访问计算机硬件,其他虚拟机(do- 定量 credit值。 mainU)访问硬件需要 domaint0提供驱动服务。 VCPu credit值的分配与VM中cap、 weight参数有关。 domainu与外界网络通信需通过物理网卡,这就需要通过 weight影响其相对值分配,如有两个虚拟机vm、Vm,wm1、wm: domain0完成。 domainu发送信息流程: domainU先把信息传 的 weight1值分别为m、w,系统总的 credit值为7。则vm1分配递给 domaino,在 domain0运行时会把收到的信息通过网卡发 的cit值为7xw/(w+n2),m的所有ⅤCPU平分这些cret送出去: domainU接收信息的流程为:外界发送给 domainu的 值。cap影响VM绝对值。如vml的cap值为50,那么wm1最 信息先到达网卡由 domaino接收, donain0再把信息传递给相 多获得系统 credit值的50%,即vm1最多占有系统总CPU的应 domainu,最后 domainu运行时会接收到信息。这样do 50%资源。 mainU与外界通信过程存在和 domain0的协同关系。 3.2.2co- credit协同调度算法 在一个 domain中配置 A pache服务器。另外一台物理计 本文为每个CPU/core定义了一个nag其状态反映如下信算机通过网络访问服务器测试协同调度与非协同凋度情况 息:是否正在协同工作、有无协同请求。 下Web服务器的响应时间。 具体工作流程如图3所示:调度开始,调度器首先检查标42实验平台搭建 志位fag状态,如果有协同请求则优先调度被请求VCPU以便 虚拟机运行在一台Dell机器上,配置为:266 Ghz Core 它们协同工作,否则按原cred调度顺序选择下个要运行的Quad9550四核处理器、4GB内存。软件系统为Xεn3.1.0平 vCPU;选择岀下一个要运行的vCPU,检查ⅤCPU协同属性;台,搭建8个虚拟机,虚拟机运行 CentOs5.5,每个虚拟机设置 常建忠,刘晓建:虛拟机协同调度问题研究 2011,47(6 41 品 piche看 nckeasehedulingl Apht Bench(non tcachtdutint serwer softwar Apache/113 scheleR LEncuTTEs LEEI Tire taken tox est: 2200,433 seconds ITire taken for tesh 3318317verrnds Complete raquet 1000000 Comrie gumti tENNO Fasd musts WHe erni won-lxa respone: 100nN wetl Imean Hon. K ISPONE wuss pe ienbnd a54: 46 het limean Tenets per secondi 290. 01 Crec] imean Ime pe requet 2204m(mn 进研Ee上 37惠3Im(me Time per rennet: 2ND msl (meail, atm all TepF印u3.378【mtm的na denouement requests C!包Qus ncTm邮 Commotion nmn fm? min menn+/-ld medim mIx mimm: menn[+rd medim mat ConnectGI11 24 Connect oI P12191014113313 Procesing32371240.42B213s whiting01题1151ts40197489 a1104787.6279124793 lth:1.20191s4213214 2181240,428本一18器 Pettmtage af e tasts sitvelnihtn a tertain Hime imi tag nf the m its gered within a cetlin timin (ms) 当 图 114 73 5333 80甲 80 6 14 90333 95417 L004 112314(longest reest 图4 Apache服务器响应时间测试结果 个VCPU; domainu内存为455MB,剩余内存分配给 domain05结束语 和Xen监控程序; domain 1上运行 Apache服务器,其他 domainu 现在虚拟化技术广泛应用于集群、服务器整合等领域,越 运行加法运算,保持这些虚拟机始终处于忙状态。另一台物来越多的应用服务运行在虚拟化平台上,原本需要协同工作 中理机器作为m运行Ap基准测试工具a,从外界通过局的应用服务由于虚拟机粗粒度调度非均匀步进、调度周期铰 域网测试 domain1web服务器响应时间。 长、独立性等原因降低了它们的合作工作能力。应用各异的 在 Apache基准测试中,发送任务的并发数为100,总的发服务运行在虚拟化平合上,带来了不尽相同的协同类型如:通 送服务请求数为100万。图4左边显示 co-credit情况下的测试信密集型、并行计算型等,这给虚拟机间协同工作的研究带来 结果,共用时2200433,其平均响应时间为:200m;图4右了挑战 边显示Ken原 credit算法测试结果,共用时3378317s,平均响 针对多虚拟机协同计算的需求,分析了协同调度对于多 应时间为:3.378ms。平均响应时间缩短了3487%。 虚拟机系统协同工作的影响,并结合Xen平台提出一个协同 对其他虚拟机公平性影响测试:在其他虚拟机上运行加调度算法。在开源Xen项目中实现协同调度器。实验结果显 法运算,测试23-1次加法运算的时间。图5显示了两种情况,该调度器能很好地提高虚拟机间合作完成工作的能力,降 下的运行结果。 coscheduling代装 co-credit,其运算平均时间低事件延退时间,改善虚拟环境下多服务器协同计算情形下 为2303315089ms。 non-coscheduling代表Xen原 credit算服务质量,且对调度公平性影响不大。 法,其运算平均时间为21377278.38msco- credit情况下加 法运算时间上比原来增加775% 参考文献 [1] Govindan S, Nath A R, Das A, ct al.Xcn and Co. Communica LiDn-aware CPU scheduling for consolidated Xen-based hosting coscheduling 匚 non-coscheduling platforms[C]//VEE 07, June 13 15, 2007, San Diego, California USA,2007. 20 [2] Urgaonkar B, Pacifici G, Shenoy P, et al. An analytical model for multi-tier Internet services and its applications[C]//Proceedings of thc acm International confcrcncc on mcasurcment and mod Compuler SysteIns( SIGMETRICS 2005), Banff, Canad 0 4 June 2005 13 Ongaro D, Cox A L, Rixner SScheduling lO in virtual ma- 图5加法运算时间 chine monitors[C]// 08, Seattle, Washington, USA, 2008 实验结果显示协同调度情况响应时间50%在42ms内, [4] Papazachos Z C, Karatza H D The impact of task service time variability on gang scheduling performance in a two-cluster 95%在254ms内;而非协同情况响应时间50%在283ms内, systen[]. Simulation Modelling Practice and Theory, 2009, 27 95%在417ns内。协同调度显著降低了响应时间,提高了服 1276-1289 务器的服务质量 (卜转48页)