首页> 中国专利> 一种虚拟化环境下动态实时CPU调度系统

一种虚拟化环境下动态实时CPU调度系统

摘要

本发明公开了一种虚拟化环境下动态实时CPU调度系统,属于计算系统虚拟化技术领域。本发明包括网络包监控模块、信息收集模块以及实时CPU调度模块,无需用户设置虚拟机类型及调度参数,能够通过分析虚拟机发送或接收的网络包的方式动态识别虚拟机的类型以及获取虚拟机所需的调度参数。本发明可以根据动态获取的信息及时的调度实时虚拟机,从而保证运行于虚拟机内的实时应用的性能。本发明与现有技术相比,消除了用户管理虚拟机所带来的开销,减轻了用户的负担,不会出现配置错误的情况,能够更好的应用于虚拟化系统中且灵活性更高。

著录项

  • 公开/公告号CN104123174A

    专利类型发明专利

  • 公开/公告日2014-10-29

    原文格式PDF

  • 申请/专利权人 华中科技大学;

    申请/专利号CN201410385611.2

  • 发明设计人 吴松;金海;周理科;

    申请日2014-08-06

  • 分类号G06F9/455;G06F9/50;

  • 代理机构华中科技大学专利中心;

  • 代理人梁鹏

  • 地址 430074 湖北省武汉市洪山区珞喻路1037号

  • 入库时间 2023-12-17 01:39:31

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2017-06-16

    授权

    授权

  • 2014-12-03

    实质审查的生效 IPC(主分类):G06F9/455 申请日:20140806

    实质审查的生效

  • 2014-10-29

    公开

    公开

说明书

技术领域

本发明属于计算系统虚拟化技术领域,更具体地,涉及一种虚拟化环 境下动态实时CPU调度系统。

背景技术

随着虚拟化技术的发展,越来越多的应用程序运行于虚拟机之中,其 中很多应用程序都具有实时需求,例如流媒体服务器、VoIP服务器、实时 流处理系统、云游戏等。与计算密集型应用程序及Web服务程序等相比, 这类实时应用程序具有一个重要的特征:实时应用程序具有任务截止时间。 频繁的错误任务截止时间会严重影响实时应用程序的性能。

现有的虚拟机管理器(例如Xen、VMWare等)及技术方案并没有很好 的在虚拟化环境下支持实时应用程序,其主要原因如下:

第一,尽管现有的虚拟机管理器能够很好的支持计算密集型应用程序 及Web服务程序等,但并没有考虑实时应用的需求;第二,运行于虚拟机 内的实时应用程序的特征通常比较复杂,在不同的时期可能会表现不同特 征,现有的技术方案并不能适应这种变化;第三,尽管现有的技术方案优 化了虚拟机管理器以支持实时应用程序,但是都需要用户或管理员手动指 定虚拟机类型以及调度参数。因此,现有技术方案需要用户或管理员对虚 拟机内运行的实时应用有足够的了解。此外,当虚拟机实时应用的需求随 着时间变化时,现有的技术方案将不再有效。所以,现有的技术方案存在 灵活性低、操作不方便、易导致错误配置等问题。

发明内容

针对现有技术的以上缺陷或改进需求,本发明提供一种虚拟化环境下 动态实时CPU调度系统,使得虚拟机监控器能够在不需要用户或管理员进 行任何设置的情况下支持实时应用程序,并能有效满足实时应用程序需求 的变化。

本发明提供一种虚拟化环境下动态实时CPU调度系统,包括:

网络包监控模块,采用混合识别机制来分析虚拟机发送或接收的网络 包的头部并判定所述虚拟机是否为实时虚拟机,其中所述混合识别机制由 端口识别机制和协议识别机制共同完成,当所述网络包监控模块监测到某 个虚拟机为实时虚拟机时,就通过超级调用告知所述信息收集模块,其中, 所述超级调用包含的信息为所述实时虚拟机的ID号以及事件类型,所述事 件类型包括发送事件和接收事件;

信息收集模块,响应所述网络包监控模块发出的所述超级调用并根据 所述事件类型计算所述实时虚拟机的期望调度延时;

实时CPU调度模块,根据所述实时虚拟机的所述期望调度延时对所述 实时虚拟机的实时虚拟CPU进行管理并及时的调度所述实时虚拟CPU。

总体而言,通过本发明所构思的以上技术方案与现有技术相比,本发 明具有以下有益效果:

(1)本发明弥补了Xen默认的Credit调度算法缺少对实时程序的支 持,通过优化抢占机制以及根据动态获取的调度参数采用周期性调度策略 来及时的调度虚拟机,从而良好的支持实时应用程序。

(2)本发明能够动态的识别虚拟机的类型以及获取虚拟机所需的调度 参数。因此,本发明不会出现配置错误的情况,能够更好的应用于虚拟化 系统中且灵活性更高;

(3)本发明无需用户设置虚拟机类型及调度参数,消除了用户管理虚 拟机所带来的开销,减轻了用户的负担;

(4)本发明为非侵入式方法,无需修改客户操作系统和应用程序代码。 现有的应用程序都可以直接运行,消除了应用程序或操作系统的移植开销。

附图说明

图1为本发明虚拟化环境下动态实时CPU调度系统的结构示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图 及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体 实施例仅仅用以解释本发明,并不用于限定本发明。此外,下面所描述的 本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可 以相互组合。

以下首先对本发明中的一些技术术语进行定义和解释:

实时虚拟机:运行实时应用的虚拟机。

非实时虚拟机:运行非实时应用的虚拟机。

实时虚拟CPU:实时虚拟机的虚拟CPU。

非实时虚拟CPU:非实时虚拟机的虚拟CPU。

实时网络包:网络包的源点或终点是运行于实时虚拟机内的实时应用, 即该网络包是由其他机器发送给实时应用或由实时应用发送给其他机器的 网络包。

Domain0:Xen虚拟化平台上一个特殊的虚拟机。运行于Xen上的虚拟 机有两种:Domain0和DomainU。DomainU是提供给普通用户使用的虚拟机。 Domain0负责管理DomainU以及辅助DomainU完成具体的I/O操作。

运行队列:每个物理CPU具有一个运行队列。运行队列中包含当前物 理CPU上所有可运行的虚拟CPU。这些虚拟CPU在物理CPU上以优先级从高 到低进行排序。

信用值(credits):信用值是Xen的Credit调度器中虚拟CPU可运 行的额度。随着虚拟CPU的运行,其信用值会不断减少。Credit调度器会 周期性的为虚拟CPU补充信用值。

图1所示为本发明虚拟化环境下动态实时CPU调度系统的结构示意图, 包括三个模块:网络包监控模块1、信息收集模块2和实时CPU调度模块3。

网络包监控模块1位于Domain0中,采用混合识别机制来分析虚拟机 发送或接收的网络包的头部并判定该虚拟机是否为实时虚拟机。混合识别 机制由端口识别机制和协议识别机制共同完成。端口识别机制和协议识别 机制分别由端口识别子模块11和协议识别子模块12实现。当网络包监控 模块1监测到某个虚拟机为实时虚拟机时,就通过超级调用告知信息收集 模块2。其中,超级调用包含的信息为该实时虚拟机的ID号以及事件类型。 在本发明实施例中,事件类型分为两类:发送事件和接收事件。当监测到 实时虚拟机发送的网络包为实时网络包时,事件类型就为发送事件;当监 测的网络包是其他机器(可以是虚拟机或非虚拟机)发送给实时虚拟机的 实时网络包时,事件类型为接收事件。

网络包监控模块1包括端口识别子模块11和协议识别子模块12。网络 包监控模块1为每个虚拟机维护一个端口列表,端口列表所包含的端口号 都与各实时应用相对应。例如实时应用常用的RTSP协议使用的是554端口, 远程桌面VNC常用的端口号是5900+N。由于每个虚拟机最多可以使用65536 (216)个端口,端口列表最多包含65536个端口。端口列表的端口可以由 管理员或协议识别子模块12添加或删除。

由于端口识别开销更小,对于每个网络包,网络包监控模块1优先使 用端口识别子模块11进行识别。端口识别子模块11根据发送或接收网络 包的虚拟机ID获取该虚拟机对应的端口列表,然后提取网络包头部的端口 号并与该端口列表中的端口号进行比较。在本发明实施例中,对发送的网 络包比较其源端口,对接收的网络包比较其目的端口。下文中如无特殊说 明,端口指的是发送网络包的源端口或接收网络包的目的端口。当该端口 号等于端口列表中的某个端口号时,发送/接收该网络包的虚拟机就是实时 虚拟机。只有当端口识别子模块11失效时,即网络包的端口不与端口列表 中的任何端口号相符时,网络包监控模块1才使用协议识别子模块12来进 一步识别网络包是否属于某个实时虚拟机,该策略可有效降低端口识别产 生的开销。此外,通过优化对发送网络包的识别可以进一步降低端口识别 产生的开销:用一个变量来保存当前活跃端口,即最近一段时间内(例如 最近1秒内)被识别出来的实时网络包的端口。如果当前活跃端口已被设 置(即非0值),端口识别子模块11仅比较发送网络包的源端口是否与当 前活跃端口相等,而不会查询端口列表,其本质等于抽样。否则,继续与 端口列表中的端口比对或使用协议识别子模块12来进一步识别网络包。如 果一段时间内(例如1秒内)网络包中并未出现当前活跃端口,那么变量 内保存的当前活跃端口会被清零。

协议识别子模块12用来补充端口识别子模块11。因为并不是所有的实 时应用都使用周知端口或已知的默认端口。此外,即便实时应用程序的默 认端口是周知端口或已知的端口,系统管理员可能由于安全等原因修改默 认端口,这将导致端口识别子模块11失效。由于应用层协议通常具有较为 明显的特征,协议识别子模块12通过应用层协议的特征来识别某个网络包 是否属于实时虚拟机。例如RTSP协议的头部包含字符串RTSP,用于在网络 上实时传输音频和视频的RTP协议表现出很强的规律性,易于识别。当协 议识别子模块12通过应用层协议特征识别出某个网络包是实时网络包时, 该网络包的端口将被添加到端口列表中。在本发明实施例中,添加的端口 超过一定时间(例如1秒)未出现在网络包中将被清除。

信息收集模块2位于虚拟机监控器中,响应网络包监控模块1发出的 超级调用并根据事件类型做不同的处理。信息收集模块2包括信息管理子 模块21和参数计算子模块22。

信息管理子模块21根据不同类型的事件产生不同的行为。如果事件类 型为接收事件,则说明此时有个实时网络包发送给实时应用,实时应用应 该立即进行响应。例如,用户在虚拟桌面上点击鼠标或云游戏客户端中点 击怪物进行攻击,服务器程序都要及时进行响应,否则会严重影响用户体 验。信息管理子模块21会根据超级调用传递的虚拟机ID设置相应的虚拟 机为实时虚拟机,并通知实时CPU调度模块3提升该虚拟机的虚拟CPU的 优先级。如果事件类型为发送事件,信息管理子模块21会为每个实时虚拟 机维护一个时间信息列表,记录前面N(N≥2)次事件类型为发送事件的超 级调用发生的时间。其中,超级调用的一个参数就是虚拟机ID。因此,针 对不同的虚拟机ID,超级调用发生的时间会添加到不同的列表中。

参数计算子模块22根据信息管理子模块21维护的时间信息列表采用 指数加权移动平均的方法计算各实时虚拟机的调度参数,即期望调度延时, 期望调度延时的计算主要依赖于以下事实:实时应用例如VoIP服务器、流 媒体服务器、VNC服务器等通常需要周期性的发送网络包给客户端,从而保 证良好的用户体验。期望调度延时的具体计算方法如下公式(1)所示:

Pt=(1-ω)×Pt-1+ω×I   (1)

其中,Pt表示某实时虚拟机的期望调度延时;Pt-1表示上一次计算出来 的该实时虚拟机的期望调度延时,每当信息收集模块2响应网络包监控模 块1发出的超级调用时,就根据超级调用传递的虚拟机ID计算该虚拟机的 Pt;ω表示指数加权移动平均的加权程度,介于0到1之间;I表示该虚拟 机ID对应的时间信息列表中最近两次超级调用的时间间隔。

实时CPU调度模块3位于虚拟机监控器中,根据实时虚拟机的调度参 数对实时虚拟CPU进行管理并及时的调度实时虚拟CPU。实时CPU调度模块 3包括虚拟CPU管理子模块31、虚拟CPU调度子模块32和负载均衡子模块 33。

虚拟CPU管理子模块31根据虚拟机的类型进行管理。与现有的Credit 调度算法相比,本发明实施例增加了一个实时虚拟CPU队列。所有的实时 虚拟CPU根据信息收集模块2计算的期望调度延时插入到实时虚拟CPU队 列中,同时也会按照原Credit调度算法管理队列的方式插入到运行队列中。 即实时虚拟CPU会同时出现在实时虚拟CPU队列和运行队列中。实时虚拟 CPU队列中的虚拟CPU根据实时虚拟CPU的截止时间(deadline)进行排序, 截止时间最早的实时虚拟CPU位于队首,截止时间最晚的实时虚拟CPU位 于队尾。其中,截止时间为实时虚拟CPU插入到实时虚拟CPU队列时的系 统时间加上其期望调度延时。因此,当一个实时虚拟CPU插入到实时虚拟 CPU队列时,需要根据其截止时间插入到适当的位置。然后,根据实时虚拟 CPU队首的截止时间创建一个定时器。当该虚拟CPU的截止时间到达时,定 时器就会被触发,从而调用虚拟CPU调度子模块32来调度该实时虚拟CPU。 因此,当一个虚拟实时CPU插入到运行队列时,其同时需要被插入到实时 虚拟CPU队列;当一个虚拟实时CPU被移除出运行队列时,虚拟CPU管理 子模块31需要同时将其从实时虚拟CPU队列中移除。而对于非实时虚拟CPU, 虚拟CPU插入和移除操作都不需要涉及到实时虚拟CPU队列。

虚拟CPU调度子模块32通过三种调度模式来完成实时虚拟CPU的调度。 第一种调度模式是对原Credit调度算法的继承,即每次都调度运行队列队 首的实时虚拟CPU运行,调度完成后再根据其优先级将其插入到运行队列 中,具体来说是插入到运行队列中第一个优先级更低的虚拟CPU之前。因 此,如果整个系统中不存在实时虚拟机,那么实时CPU调度模块3将退化 为原Credit调度器。第二种调度模式为定时器触发模式,由虚拟CPU管理 子模块31创建的定时器所触发。此模式被激活说明实时虚拟CPU队首的实 时虚拟CPU的截止时间已到,需要立即调度该虚拟CPU运行。为了及时的 调度实时虚拟CPU,虚拟CPU调度子模块32引入了实时优先级(当前最高 优先级)。当定时器已到时,实时虚拟CPU队列队首实时虚拟CPU的优先 级会被提升到实时优先级,然后从运行队列中移除并重新插入到运行队列 中(通常会插入到运行队列队首)。之后虚拟CPU调度子模块32的第一种 调度模式被激活并立即调度该实时虚拟CPU运行。当实时虚拟CPU运行完 之后,其需要被重新插入到运行队列。如果是实时虚拟CPU,则在插入到运 行队列之前需要根据剩余的信用值(credits)降低其优先级。第三种调度 模式为接收事件触发模式,由信息管理子模块21根据超级调用的事件类型 所触发。当该模式被激活时,说明有事件发送给实时应用,实时应用应该 立即响应该事件。此时,采用与第二种调度模式相同的做法,将发生接收 事件的实时虚拟CPU的优先级提升到实时优先级并重新插入运行队列,由 第一种调度模式完成具体调度动作。实时虚拟CPU调度完成之后同样需要 降低其优先级。后两种调度模式都复用了第一种调度模式,而第三种调度 模式也复用了第二种调度模式部分内容。这种复用可有效降低实现的复杂 度,减少代码出错的机会。

负载均衡子模块33的主要功能是让实时虚拟CPU尽量均匀的分散到不 同的物理CPU之上。负载均衡子模块33通过虚拟CPU迁移的方式周期性的 进行负载均衡。进行负载均衡时需要考虑两个目标:(1)尽量让不同的物 理CPU上有相同数量的实时虚拟CPU;(2)尽量将同一个虚拟机的不同实 时虚拟CPU分散到不同的物理CPU之上。

本领域的技术人员容易理解,以上所述仅为本发明的较佳实施例而已, 并不用以限制本发明,凡在本发明的精神和原则之内所作的任何修改、等 同替换和改进等,均应包含在本发明的保护范围之内。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号