CN104598298A - 基于虚拟机当前工作性质以及任务负载的虚拟机调度算法 - Google Patents

Abstract

本发明公开了基于虚拟机当前工作性质以及任务负载的虚拟机调度算法。其中，中断监控模块负责监控虚拟机当前的中断频率，用于判断虚拟机的工作性质是CPU密集型还是I/O密集型。CPU监控模块负责监控虚拟机当前的CPU使用率，用于监控虚拟机的任务负载，根据当前的任务负载以及一定时间范围内的历史信息计算出虚拟机的调度时间片，并且通知调度器更新时间片。调度器模块则是修改了信用值调度器，使调度器根据中断监控模块和CPU监控模块提供的信息，对于不同工作性质的虚拟机应用不同的调度时间片，在降低I/O请求延迟的同时提供足够的时间处理I/O请求，并且引入较小的额外开销。这三个模块的修改都发生在虚拟机监控器中，因此具有良好的可适性。

Description

基于虚拟机当前工作性质以及任务负载的虚拟机调度算法

技术领域

本发明涉及***虚拟化、虚拟机中断检测、虚拟机CPU使用率检测和虚拟机调度器设计领域。具体地，涉及基于虚拟机当前工作性质以及任务负载的虚拟机调度算法，用于解决由虚拟机调度器设计缺陷引起的I/O响应延迟、无法动态适应虚拟机负载变化以及I/O性能较低的问题。

背景技术

虚拟化技术已经以各种不同的形式存在了50多年。抽象的说，虚拟化是各种可用资源的逻辑表示，可以不受物理条件的限制。具体一点就是，虚拟化技术在***中添加了一层虚拟化层，能够把下层的物理资源抽象成虚拟资源，供上层的应用使用。它既可以从单个物理资源中划分出多个虚拟资源，也可以把多个物理资源整合成一个虚拟资源。

虚拟机监控器(Virtual Machine Monitor，VMM)是虚拟化技术中最重要的一部分。它处于硬件层和虚拟机之间，运行在最高的特权级别。它的主要功能是抽象底层硬件资源，使之成为虚拟资源，并提供给上层创建的虚拟机使用。虚拟机监控器的主要功能包括虚拟环境的管理和物理资源的管理。

目前业界主流的虚拟机监控器包括Xen、KVM、VirtualBox、Hyper-V、VMware等等。其中Xen作为主流的开源虚拟机监控器，在实际应用以及学术研究中占有很重要的地位。Xen默认的调度算法为信用值调度算法(Credit Scheduler)。信用值调度算法把分配的时间视为信用值，在每个信用值分配周期会为所有VCPU分配信用值，VCPU每运行一段时间就会扣除与其运行时间相对应的信用值，信用值小于0后在这个调度周期内便不再运行。

由于虚拟机监控器的引入，原本在传统操作***中已经解决的问题会出现新的变化，同时还会出现一些传统操作***中不会出现的问题。其中一个很重要的问题就是I/O响应延迟的问题。在传统操作***中，当一个I/O请求来临时，操作***会感知到这个请求，并调度他的接收者，使其抢占当前运行的进程，处理I/O请求，从而使得I/O请求的延迟变小。然而在虚拟化环境中，所有的I/O请求会由虚拟机监控器接收，然后转发给对应的虚拟机，操作***无法感知到具体哪个虚拟机是I/O请求的接收者，因此无法进行抢占。当几个虚拟机共享一个物理CPU的时候，一个虚拟机就不得不等待其他的虚拟机使用完分配给他们的时间之后才能处理自己的I/O请求。当有很多虚拟机共享同一个物理CPU的时候，延迟会变得非常高，这么高的延迟对于一个I/O密集型的虚拟机来说是不可接受的。

传统的调度器把调度的公平性放在第一位，把I/O任务和CPU任务等同对待，会导致I/O任务效率低下。为了解决I/O效率低下的问题，学术界提出了多种优化方法，将I/O任务与CPU任务区别对待，但是比较极端的把虚拟机分成两类：纯I/O操作和纯CPU计算，并没有考虑分配给I/O请求足够的CPU时间去处理，没有考虑混合型的虚拟机，因此也会影响I/O任务的效率。另一方面，以往的部分研究中虚拟机的类型只能在***启动时手动指定，一个I/O密集型的虚拟机在***运行时也可能会改变成为CPU密集型，当一个没有被标注为I/O密集型的虚拟机接收到大量I/O请求时，调度器无法改变调度时间片，使得I/O响应的延迟无法降低。因此这些方法在实际的***当中有局限性。

综上所述，传统的调度器中存在着I/O响应延迟较大的问题，现有的研究提出的方法虽然能在一定程度上减少延迟，但是不能适应虚拟机负载动态的变化并且没有考虑为I/O请求提供充足的时间进行处理，同样也会影响I/O请求的性能。因此，本领域的技术人员致力于开发一种基于虚拟机当前工作性质以及任务负载的虚拟机调度算法，解决这一问题。

发明内容

有鉴于现有技术的上述缺陷，本发明所要解决的技术问题是提供基于虚拟机当前工作性质以及任务负载的虚拟机调度算法，在保证I/O请求能够被及时响应的同时，又有足够的CPU时间用于处理I/O请求，权衡时间片的大小，使I/O性能最大化，在提升I/O性能的同时，又对CPU密集型的虚拟机带来最少的额外开销。

为实现上述目的，本发明提供了基于虚拟机当前工作性质以及任务负载的虚拟机调度算法，该算法包含了中断监控模块，CPU监控模块和调度器模块这三个模块：

中断监控模块运行在虚拟机监控器中，从事件通道获取虚拟机接收的中断请求。根据中断请求携带的信息，识别出包括domainU发送请求，domainU接收请求，domain0发送回复，domain0接收回复等操作在内的I/O操作，监控所有虚拟机的中断频率，用于判断各个虚拟机的工作性质是CPU密集型还是I/O密集型。

CPU监控模块运行在虚拟机监控器中，监控虚拟机CPU的忙闲比，并计算出CPU使用率，根据虚拟机的CPU使用率计算出虚拟机所需的调度时间片。在计算时间片时，CPU监控模块会把CPU利用率从0％到100％映射到时间片的1ms到20ms区间内，为了保持时间片的变化的稳定，减少性能的颠簸，只有在连续几个周期CPU使用率都处于某个范围的时候才会修改时间片大小。该模块在计算CPU使用率时利用了老化算法，将一定时间范围内的历史信息结合到当前的信息中进行计算。

调度器模块在CREDIT调度器的基础上进行修改，修改调度器的数据结构使之能够存储中断监控模块和CPU监控模块所反馈的信息。调度器算法中会维护两个队列，分别称之为A队列和B队列。根据中断监控模块反馈的信息，将不同工作性质的虚拟机放到不同的队列中。CPU密集型的虚拟机存放在A队列中，I/O密集型的虚拟机存放在B队列中，在每个调度周期开始时，调度器会选取其中一个队列的队首元素作为下一个要运行的虚拟机，具体的选取方法如下：

步骤1、首先从B队列选取队首作为下一个要运行的虚拟机，然后将现在调度结束的虚拟机***与其工作性质类型相对应的队列的队尾。

步骤2、直到B队列中所有的虚拟机都运行过一次或者B队列为空之后，挑选A队列的队首作为下一个要运行的虚拟机。

步骤3、重复步骤1和2，直到所有虚拟机用完了它们在这个周期所分配的时间片。

步骤4、重新分配信用值和时间片，回到步骤1。

在获取了下一个要运行的虚拟机之后，调度函数会从domain结构中取出中断监控模块和CPU监控模块更新的信息，根据中断监控模块的信息对不同类型的虚拟机应用不同的调度策略。根据CPU监控模块的信息，获得不同的时间片大小，并用这个时间片来设置计时器，进行虚拟机的调度。

基于虚拟机当前工作性质以及任务负载的虚拟机调度算法具有以下有益的技术效果：

(1)中断监控模块会监控事件通道内的所有事件，截获domain0和domainU之间的通信事件，统计各个虚拟机的中断频率，用作区分虚拟机类型的依据。该模块提供了虚拟机工作性质的信息，将虚拟机划分为I/O密集型和CPU密集型两种类型，调度器会根据不同的类型应用不同的调度算法。CPU密集型的虚拟机采用默认的Credit调度算法，I/O密集型的虚拟机采用本发明提供的调度算法。

(2)CPU监控模块会统计一定时间周期内虚拟机的忙闲次数，用忙次数与总调度次数之间的比值作为虚拟机的CPU使用率。根据监测出的CPU使用率计算对于I/O密集型虚拟机采用的调度算法所需的时间片。在时间片的计算中采用了线性映射，避免了时间片的颠簸，还采用了老化算法，让一定时间范围内的CPU使用率对当前周期内的时间片计算提供信息，使计算更加准确。

(3)调度器模块在原有的Credit调度器上进行修改，在一个调度周期内让CPU密集型虚拟机运行较大的时间片，让I/O密集型虚拟机运行多个较小的时间片，同时优先调度I/O密集型虚拟机，尽量减少I/O响应的延迟。I/O密集型的虚拟机所需的时间片由CPU监控模块计算得来，尽量保证有足够的时间来处理I/O请求，进一步提升I/O性能。另一方面，所有虚拟机在一个调度周期内获得的时间片是相等的，保证了调度的公平性。

(4)以上模块都是实现在虚拟机监控器中，不需要修改客户机的代码，与具体的客户机操作***无关，因此可以适用于所有的客户机操作***，具有极强的可适性。

(5)在实现上述模块的过程中，对于I/O密集型虚拟机采用较短的时间片，而对于CPU密集型虚拟机采用Credit调度器默认的时间片，对于CPU密集型的虚拟机的性能造成的影响较小，***引入的额外开销较小。

以下将结合附图对本发明的构思、具体结构及产生的技术效果作进一步说明，以充分地了解本发明的目的、特征和效果。

附图说明

图1是本发明所述方法的调度模型框架；

图2是Xen处理中断的流程；

图3是本发明所述调度方法的实施例。

具体实施方式

下面结合附图对本发明的实施例作详细说明：本实施例在以本发明技术方案为前提下进行实施，给出了详细的实施方式和具体的操作过程，但本发明的保护范围不限于下述的实施例。

图1是本发明的调度模型框架。本发明在原有的调度模型中增加了两个新的模块，分别是中断监控模块和CPU监控模块。中断监控模块会截获事件通道中传递的信息，根据中断号和虚拟机的id统计各个虚拟机的中断频率。CPU监控模块会监控所有虚拟机的调度信息，统计出一定周期内虚拟机的CPU使用率。这两个模块会监控虚拟机当前的运行状态，提供运行信息给调度器，使调度器能够动态的改变调度策略。

图2是Xen处理中断的流程。在处理中断之前首先需要把中断号和事件通道绑定起来。当一个虚拟机被创建时，它首先会调用get_free_port函数向虚拟机监控器发送一个超级调用来申请空闲的事件通道端口，然后调用grant_table_create函数申请一些空闲的页表供I/O环使用。这些空闲的页表会通过授权表的方式与宿主机共享，每个授权表都会有一个授权引用。在虚拟机启动后，申请的空闲的端口号和I/O环的授权引用会通过XenStore传递给domain0。XenStore主要用来使各个domain之间在建立事件通道和授权表之前能够通信。在domain0收到domainU发来的端口号和授权引用后，它会把端口和中断请求(Interrupt Request，IRQ)绑定，这样Xen就知道该把中断发到哪个domainU里。然后domain0会把共享的页表映射到自己的地址空间里，完成前后端驱动的连接操作。在一个中断到来的时候，Xen会首先进入一个名为common_interrupt的中断处理公共入口。common_interrupt对中断现场进行保存之后，调用do_IRQ对中断进行具体处理。对于客户机注册的中断，do_IRQ会调用__do_guest_IRQ进行处理。__do_guest_IRQ最终会对所有注册了这个中断的domainU调用send_guest_pirq，在其中设置对应VCPU的event channel的pending位

图3是一个用来描述调度算法的例子。在图3a中，假定VM1是I/O密集型虚拟机，在Credit调度器中，一个周期它只能被调度一次，运行30ms之后等待下一次分配时间片，这时候的I/O请求延迟最高可以达到90ms。在本发明的调度器中，我们把这30ms划分成若干个更小的时间片，划分依据来自CPU监控模块(图中以10ms为例)。在图3b中，VM1和VM2是I/O密集型的虚拟机，算法在调度的时候会首先让VM1运行10ms，然后***回调度队列，然后VM2运行10ms，并***回队列，继续调度VM3，依次这样循环直到运行完整个调度周期。通过示意图可以看出，在一个调度周期内I/O密集型虚拟机运行的总时间并没有变，但是调度的频率增加了，因此在保证公平性的前提下，对于I/O请求的响应变得更快了。

本发明基于虚拟机当前工作性质以及任务负载的虚拟机调度算法的具体内容包括：中断监控模块，CPU监控模块和调度器模块。

中断监控模块运行在虚拟机监控器中，从事件通道获取虚拟机接收的中断请求。根据中断请求携带的信息，识别出包括domainU发送请求，domainU接收请求，domain0发送回复，domain0接收回复等操作在内的I/O操作，监控所有虚拟机的中断频率，用于判断各个虚拟机的工作性质是CPU密集型还是I/O密集型。在Xen当中，当有I/O事件到达时，前端驱动和后端驱动会通过事件通道来通知对方。I/O数据的传输则是通过I/O环来实现。Xen中用来描述一个虚拟机的结构体为struct domain，主要结构如下所示：

其中struct evtchn表示事件通道的结构，一个domain最多可以拥有1024个事件通道。每个事件通道都有一个pending位，用来表示有中断需要处理。当一个虚拟机被创建时，它会调用get_free_port函数向虚拟机监控器发送超级调用来申请空闲的事件通道端口，然后调用grant_table_create函数申请一些空闲的页表供I/O环使用。这些空闲的页表会通过授权表的方式与宿主机共享，每个授权表都会有一个授权引用。

具体的中断发送过程如图2所示，最终会调用send_guest_pirq函数通知对应的虚拟机来处理中断请求。本发明的中断监控模块首先在虚拟机启动时记录了它所使用的事件通道的端口号。在虚拟机运行的时候，对整个事件通道进行监控，获得具体的中断信息，包括domainU发送请求，domain0接收请求，domain0发送回复，domainU接收回复等操作的信息。然后在evtchn\_send函数中做了一些修改，在每次domain之间通信的时候进行中断的统计，具体的算法如下列伪代码所示：

CPU监控模块运行在虚拟机监控器中，监控虚拟机CPU的忙闲比，并计算出CPU使用率，根据虚拟机的CPU使用率计算出虚拟机所需的调度时间片。在计算时间片时，CPU监控模块会把CPU利用率从0％到100％映射到时间片的1ms到20ms区间内，为了保持时间片的变化的稳定，减少性能的颠簸，只有在连续几个周期CPU使用率都处于某个范围的时候才会修改时间片大小。该模块在计算CPU使用率时利用了老化算法，将一定时间范围内的历史信息结合到当前的信息中进行计算。

在计算CPU使用率时可以利用一段时间内VCPU被调度时非idle的次数与被调度的总次数的比值作为CPU使用率。由于VCPU的调度次数统计周期为10ms，在某一个10ms周期内，若VCPU空闲则可认为它在这10ms内没有运行，同样的，若非空闲则可认为在这个周期里VCPU一直在运行，所以这个比值在理论上可以认为是CPU的使用率，也就是说CPU的使用率可以由一段时间内VCPU被调度时非idle的次数与被调度的总次数的比值来体现。具体的统计算法由下列伪代码所示：

得到CPU使用率之后需要根据CPU使用率来计算调度所需的时间片。Xen调度的时间片默认情况下是30ms，这个时间片对于CPU密集型的任务来说是一个很不错的时间片，可以满足CPU资源的需求。但是对于I/O密集型的虚拟机来说并不合适，它会造成I/O响应的延迟。1ms的时间片可以很好的满足I/O响应速度的要求，但是由于时间片的减少，上下文切换的消耗也会变高，会造成CPU处理效率变差，无法及时处理一些需要计算资源的I/O请求。本发明采用了动态调节时间片的方法，根据虚拟机的实时负载修改调度时间片。本发明把CPU利用率从0％到100％映射到时间片的1ms到20ms区间内。在实际实验过程中发现，CPU使用率虽然在一段时间内相对稳定，但是在相邻的几个统计周期内会不停的变化，如果不停的改变时间片的大小也会造成性能的颠簸。所以只有在连续几个周期CPU使用率都处于某个范围的时候才会修改时间片大小。另一方面，CPU监控模块内记录的是某一个检测周期内的CPU使用率，在实际运行当中，这一检测周期之前一段时间的CPU使用率也应该纳入考虑范围，这样可以减少CPU使用率突变带来的误差。这里使用了老化算法来获取CPU使用率。具体的计算方法如下列伪代码所示：

以上详细描述了本发明的较佳具体实施例。应当理解，本领域的普通技术无需创造性劳动就可以根据本发明的构思作出诸多修改和变化。因此，凡本技术领域中技术人员依本发明的构思在现有技术的基础上通过逻辑分析、推理或者有限的实验可以得到的技术方案，皆应在由权利要求书所确定的保护范围内。

Claims (5)

1.一种基于虚拟机当前工作性质以及任务负载的虚拟机调度算法，其特征在于，包括中断监控模块、CPU监控模块和调度器模块，

所述中断监控模块运行在虚拟机监控器中，从事件通道获取虚拟机接收的中断请求；并根据所述中断请求，识别出domainU发送请求，domainU接收请求，domain0发送回复，domain0接收回复的I/O操作；监控所有虚拟机的中断频率；判断各个虚拟机的工作性质是CPU密集型还是I/O密集型；

所述CPU监控模块运行在虚拟机监控器中，监控虚拟机CPU的忙闲比，并计算CPU使用率；根据所述CPU使用率计算虚拟机所需的调度时间片；

所述调度器模块能够存储所述中断监控模块和所述CPU监控模块所反馈的信息；所述调度器模块根据所述中断监控模块反馈的信息，将不同工作性质的虚拟机放到不同的队列中；在每个调度周期开始时，所述调度器模块会选取其中一个队列的队首元素作为下一个要运行的虚拟机，然后从domain结构中取出所述中断监控模块和所述CPU监控模块更新的信息；根据所述中断监控模块的信息对不同类型的虚拟机应用不同的调度策略；根据所述CPU监控模块的信息，获得不同的所述调度时间片，并用所述调度时间片来设置计时器。

2.如权利要求1所述的虚拟机调度算法，其特征在于，在计算所述调度时间片时，所述CPU监控模块把CPU利用率从0％到100％映射到所述调度时间片的1ms到20ms区间内。

3.如权利要求2所述的虚拟机调度算法，其特征在于，在连续三个周期所述CPU使用率都处于预定范围的时候，修改所述调度时间片的大小。

4.如权利要求1所述的虚拟机调度算法，其特征在于，所述CPU监控模块在计算所述CPU使用率时利用老化算法。

5.如权利要求1所述的虚拟机调度算法，其特征在于，CPU密集型的虚拟机存放在A队列中，I/O密集型的虚拟机存放在B队列中，所述下一个要运行的虚拟机选取方法如下，

步骤1、首先从B队列选取队首作为下一个要运行的虚拟机，然后将现在调度结束的虚拟机***与其工作性质类型相对应的队列的队尾；

步骤2、直到B队列中所有的虚拟机都运行过一次或者B队列为空之后，挑选A队列的队首作为下一个要运行的虚拟机；

步骤3、重复所述步骤1和所述步骤2，直到所有虚拟机用完了在这个周期所分配的时间片；

步骤4、重新分配信用值和所述时间片，回到所述步骤1。