CN110109733A - 面向不同老化场景的虚拟机工作队列和冗余队列更新方法 - Google Patents

面向不同老化场景的虚拟机工作队列和冗余队列更新方法 Download PDF

Info

Publication number
CN110109733A
CN110109733A CN201910354679.7A CN201910354679A CN110109733A CN 110109733 A CN110109733 A CN 110109733A CN 201910354679 A CN201910354679 A CN 201910354679A CN 110109733 A CN110109733 A CN 110109733A
Authority
CN
China
Prior art keywords
virtual machine
queue
scene
redundancy
work
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201910354679.7A
Other languages
English (en)
Other versions
CN110109733B (zh
Inventor
郭军
王馨悦
张斌
刘晨
侯帅
侯凯
李薇
柳波
王嘉怡
刘文凤
张瀚铎
张娅杰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Northeastern University China
Original Assignee
Northeastern University China
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Northeastern University China filed Critical Northeastern University China
Priority to CN201910354679.7A priority Critical patent/CN110109733B/zh
Priority to PCT/CN2019/090870 priority patent/WO2020220436A1/zh
Publication of CN110109733A publication Critical patent/CN110109733A/zh
Application granted granted Critical
Publication of CN110109733B publication Critical patent/CN110109733B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061Partitioning or combining of resources
    • G06F9/5077Logical partitioning of resources; Management or configuration of virtualized resources
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/546Message passing systems or structures, e.g. queues
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45595Network integration; Enabling network access in virtual machine instances
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/54Indexing scheme relating to G06F9/54
    • G06F2209/548Queue

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Hardware Redundancy (AREA)

Abstract

本发明提供一种面向不同老化场景的虚拟机工作队列和冗余队列更新方法,涉及云计算技术领域。该方法首先根据虚拟机的生存时间和负载的波动情况划分不同的软件老化场景,然后采用基于岭回归的虚拟机工作队列动态更新的方法,动态地调整工作虚拟机副本的数目和顺序;最后基于二元决策图动态更新虚拟机的冗余队列。本发明提供的面向不同老化场景的虚拟机工作队列和冗余队列更新方法,通过选择和切换策略平衡虚拟机的服务质量和资源成本,保证系统的服务质量,即使工作虚拟机出现服务失效,冗余虚拟机能在短时间内切换状态,完全替代服务失效虚拟机。

Description

面向不同老化场景的虚拟机工作队列和冗余队列更新方法
技术领域
本发明涉及云计算技术领域,尤其涉及一种面向不同老化场景的虚拟机工作队列和冗余队列更新方法。
背景技术
随着云计算技术的广泛应用,云环境更加复杂且难以掌控,云服务供应商一方面需要尽最大努力保证系统的服务质量,减少服务协议的违反次数;另一方面需要提高资源利用率,降低服务成本。为了达到上述目标,实时地监测云环境变化,动态地调整云资源是最有效的途径。在云资源调整过程中,虚拟机的软件老化和业务并发访问量是两个不能被忽视的因素。云服务系统中软件老化问题严重影响着服务的性能和可靠性,在24小时*7天持续、高并发的业务访问下虚拟机的各种老化因素不断累积,导致虚拟机可用资源逐渐减少,内部软件运行变慢,失败请求数和请求响应时间增加。
早期的云资源调整方法主要使用对云环境实时监控和预定规则触发的调整机制,这类调整方法也是目前应用比较成熟的一类;而最近几年许多研究通过机器学习等一些流行技术对系统的业务并发量预测,再根据业务并发量计算工作虚拟机的数目,提前进行虚拟机的调整。在上述这些云资源调整方法中,仍存在一些欠缺,前人提出的调整方法在评估云服务性能时,往往假设工作虚拟机的运行状态不发生改变,缺乏对虚拟机软件老化的充分考虑,显然这类评估方法较为粗略,尤其在一些长期运行的云服务系统中可能产生较大偏差;另外,前人方法一般通过设定静态阈值应对软件老化,只对高于老化阈值的虚拟机采取防范措施,而其他工作虚拟机一旦服务失效,则云服务系统无法立即做出调整,进而影响用户的正常访问,无法持续保障云服务系统服务的可靠性。而且前人提出的云资源调整方法在选择调整目标虚拟机时缺乏对软件老化的考虑,无法保证软件老化程度高的虚拟机被及时地重启,这极大地降低系统的性能和可靠性,增加了系统的运营成本。
综上分析,前人提出的云资源调整方法缺乏对软件老化的考虑,有可能造成调整效果差,服务质量无法保证等问题。
发明内容
本发明要解决的技术问题是针对上述现有技术的不足,提供一种面向不同老化场景的虚拟机工作队列和冗余队列更新方法,实现对虚拟机的工作队列和冗余队列进行更新。
为解决上述技术问题,本发明所采取的技术方案是:面向不同老化场景的虚拟机工作队列和冗余队列更新方法,包括以下步骤:
步骤1:根据虚拟机的生存时间和负载的波动情况划分不同的软件老化场景,具体方法为:
步骤1.1:将云服务系统中在一段时间内所有虚拟机都处于健康状态的场景划分为虚拟机生存时间短的场景,也称为场景一;
步骤1.2:将虚拟机长期不间断地运转,软件老化因素随着业务访问不断累积,导致一些虚拟机已经处于非健康的状态,但通过增广迪基-福勒检验(Augmented DickeyFuller Test,即ADF)方法判断云服务系统总业务并发量变化平稳,不会造成工作虚拟机故障的场景划分为虚拟机生存时间长且业务并发量平稳的场景,也称为场景二;
步骤1.3:将外部负载波动大,造成虚拟资源的频繁调整,并且在调整过程中云服务系统处于过载状态,即通过ADF方法判断云服务系统总业务并发量非平稳变化,而且已经存在部分虚拟机处于非健康的状态的场景划分为虚拟机生存时间长且业务并发量非平稳的场景,也称为场景三;
步骤2:采用基于岭回归的虚拟机工作队列动态更新的方法,动态地调整工作虚拟机副本的数目和顺序;
步骤2.1:在忽略软件老化因素的前提下,将虚拟机的业务并发量看作自变量,把CPU、内存、磁盘IO和网络IO看作因变量,对云服务系统建立岭回归模型,从而由业务的并发量计算出云服务系统所需的资源量;
步骤2.1.1:判断虚拟机的软件老化场景;
步骤2.1.2:从新启动的工作虚拟机上采集各类数据,把业务并发访问量和CPU及内存数据代入岭回归模型中;
云服务系统所需的CPU、内存、磁盘IO或网络IO的资源量的计算方法如下公式所示:
z=α1*x12*x2+...+αk*xk1*y12*y23*y34*y4+ε (1)
其中,xj表示云服务系统中第j类业务的并发量,j=1,...,k,k为虚拟机所支持的业务类型数,y1、y2、y3、y4分别表示期望的CPU、内存、磁盘IO以及网络IO的使用率,z表示云服务系统所需的CPU或内存或磁盘IO或网络IO的资源量,αj为第j类业务的并发量在资源计算中的影响权重,β1、β2、β3、β4分别表示在资源计算过程中对CPU、内存、磁盘IO以及网络IO性能期望的权重,ε为误差常量;
步骤2.1.3:使用最小二乘法迭代求解岭回归模型的损失函数,使岭回归模型的损失函数Loss最小,如下公式所示:
其中,n表示工作虚拟机上采集到的各类业务并发量的数目,Zi表示实际的资源需求量,表示由模型得到的资源需求量,λ表示正则项系数;
步骤2.1.4:使岭回归模型的损失函数Loss最小,确定参数α1,...,αk、β1、β2和ε,当参数的偏导值为零解出Loss函数的极小值,如下公式所示:
步骤2.1.5:按公式3和4求解由所有参数构成的方程,并代入采集到的业务并发量、资源利用率和CPU、内存、磁盘IO以及网络IO的资源量,求解得到岭回归模型的2k+6个参数,从而确定各类业务与CPU、内存、磁盘IO以及网络IO之间的关系;
步骤2.1.6:将云服务系统的业务并发量代入公式1,获得云服务系统所需的各类资源量;
步骤2.2:根据云服务系统所需的各类资源量确定所需工作虚拟机的数量,具体方法为:
步骤2.2.1:根据不同场景确定虚拟机的损耗;
步骤2.2.1.1:对于场景二和场景三,软件老化程度不同的工作虚拟机存在不同的内存资源损耗,在统计现有云资源时根据软件老化度对每台虚拟机的内存资源折算,同时服务已经失效的虚拟机不再计入可用资源;
步骤2.2.1.2:场景一中的工作虚拟机全部处于健康状态,在该场景下忽略老化的损耗;
步骤2.2.2:现有f台工作虚拟机,则下一段时间所需的工作虚拟机数目Numwork由如下公式计算,Numwork的最小取值为一:
Rescpu=f*vmcpu (6)
其中,Rescpu、Resmem分别表示云服务系统CPU和内存可用的资源量,zcpu_h、zcpu_l分别为根据虚拟机性能的期望范围求得的CPU资源的上界和资源下界,zmem_h、zmem_l分别为根据虚拟机性能的期望范围求得的内存资源的上界和资源下界,vmcpu、vmmem表示一个虚拟机副本的CPU核数和内存大小,s为虚拟机的软件老化度,p表示软件老化度s在资源评估中的影响比重,在场景二和场景三中0<ρ≤1,在场景一中ρ=0;
步骤2.3:对已经宕机或者服务失效的工作虚拟机进行处理,具体方法为:
步骤2.3.1:替换已经宕机的虚拟机;
如果虚拟机冗余队列不为空,立即从冗余队列尾部选取虚拟机进行替换,并将宕机虚拟机重启转入冗余队列尾部;
如果虚拟机冗余队列为空,直接重启宕机虚拟机,重启后放入工作队列尾部;
步骤2.3.2:替换服务失效的虚拟机;
步骤2.3.2.1:如果虚拟机冗余队列不为空,立即从冗余队列尾部选取虚拟机进行替换,并将宕机虚拟机重启转入冗余队列尾部;
步骤2.3.2.2:如果虚拟机冗余队列为空,直接重启宕机虚拟机,重启后放入工作队列尾部;
步骤2.4:根据计算的所需工作虚拟机数目Numwork增删工作虚拟机,更新虚拟机工作队列,具体方法为:
步骤2.4.1:增加工作虚拟机;
步骤2.4.1.1:从虚拟机冗余队列尾部选择虚拟机补充到虚拟机工作队列,如果没有足够的冗余虚拟机,创建一台虚拟机并启动加入到工作队列尾部;
步骤2.4.1.2:将工作队列中所有虚拟机按软件老化度从大到小排序;
步骤2.4.2:释放工作虚拟机,从虚拟机工作队列队首删除虚拟机,放入虚拟机冗余队列;
步骤3:基于二元决策图动态更新虚拟机的冗余队列,具体方法为:
步骤3.1:根据云服务系统当前的软件老化场景及云服务系统老化情况,决定冗余虚拟机使用情况;
若云服务系统当前处于场景一,不考虑冗余虚拟机;
若云服务系统当前处于场景二,对重度软件老化的工作虚拟机冗余,并且最少冗余一台;
若云服务系统当前处于场景三,利用二元决策图对场景三下的虚拟机冗余队列进行动态更新计算冗余虚拟机的数目;
步骤3.2:使用二元决策图(Binary Decision Diagram,即BDD)动态更新场景三下的虚拟机冗余队列,具体方法为:
步骤3.2.1:以字符’#’初始化决策图BDD,初始化‘0’叶子节点,初始化‘1’叶子节点,再以字符‘#’初始化BDD中其他节点;
步骤3.2.2:计算虚拟机的服务失效概率,选定韦伯分布拟合工作虚拟机的服务失效时间样本,累积韦伯分布函数F(t),如下公式所示:
其中,F(t)表示虚拟机在0~t的工作时间内服务失效的概率,冗余虚拟机在休眠状态下不处理任何业务请求,服务失效率近似为0,λ>0为比例参数,β>0为形状参数;
步骤3.2.3:计算冗余虚拟机的数量;
步骤3.2.3.1:根据步骤2,计算得到工作虚拟机的需求量为n′台;
步骤3.2.3.2:二元决策图中每个圆圈代表一个虚拟机节点,‘1’边和‘0’边分别代表虚拟机的正常、服务失效状态,矩形代表整个云服务系统的状态;所有到达‘1’矩形框的路径含义为:该路径中已经有k’台工作虚拟机处于正常状态,无论其他工作虚拟机是否正常,系统均能正常工作;而到达‘0’矩形框的路径含义为:该路径中已经有n′-k’+1台工作虚拟机已经服务失效,无论其他虚拟机是否正常,系统都无法保证用户的服务性能;
步骤3.2.3.3:生成二元决策图时,采用全局二维矩阵存储;虚拟机vx+y+1的下标记为(x,y),根节点v1的下标为(0,0);云服务系统的可靠性通过计算根到所有‘1’矩形框的路径概率和表示,以虚拟机vx+y+1为根节点的决策图的概率由如下公式计算:
P(BDD[x][y])=(1-Rx+y+1)P(BDD[x+1][y])+Rx+y+1P(BDD[x][y+1]) (9)
其中,Rx+y+1表示虚拟机vx+y+1服务失效的概率,BDD[x+1][y]、BDD[x][y+1]分别表示与虚拟机vx+y+1的‘1’边、‘0’边相连的子决策图;
由于冗余虚拟机的数量未知,则k’的大小不确定;若按照传统的二元决策图计算方法,则k’从1到n分别取值计算概率,直到冗余虚拟机数目m达到所要求的概率;
步骤3.2.3.5:根据所有工作虚拟机的平均软件老化度设置冗余虚拟机数目m的初始值,计算k’,得出m;
步骤3.2.4:根据冗余虚拟机数目m,调整虚拟机的冗余队列;
增加冗余虚拟机时,新建并启动虚拟机,放入虚拟机冗余队列尾部;
释放冗余虚拟机时,从虚拟机冗余队列首部删除虚拟机。
采用上述技术方案所产生的有益效果在于:本发明提供的面向不同老化场景的虚拟机工作队列和冗余队列更新方法,不同的工作场景下软件老化对虚拟机性能和可靠性的影响效果不同,划分不同的老化场景有针对性地进行云资源调整,既能够有效降低软件老化的影响,又能节省一定的资源成本,也能通过选择和切换策略平衡虚拟机的服务质量和资源成本;基于岭回归的虚拟机工作队列动态更新算法用于动态地调整工作虚拟机副本的数目和顺序,保证系统的服务质量;基于二元决策图的虚拟机冗余队列动态更新算法用于即使工作虚拟机出现服务失效,冗余虚拟机能在短时间内切换状态,完全替代服务失效虚拟机。
附图说明
图1为本发明实施例提供的飞机在线订购系统的实例拓扑图;
图2为本发明实施例提供的面向不同老化场景的虚拟机工作队列和冗余队列更新方法的流程图;
图3为本发明实施例提供的二元决策图结构示意图;
图4为本发明实施例提供的不同调整方法下失败请求数的示意图;
图5为本发明实施例提供的不同调整方法下的平均响应时间的示意图;
图6为本发明实施例提供的不同调整方法下的平均内存利用率的示意图;
图7为本发明实施例提供的不同调整方法下的平均CPU利用率的示意图。
图中,1、客户端;2、负载均衡;3、交换机;4、业务数据库。
具体实施方式
下面结合附图和实施例,对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明,但不用来限制本发明的范围。
本实施例以某飞机票在线订购系统模拟PC端用户应用,在曙光服务器上搭建该服务系统,通过对飞机票在线订购系统加压模拟真实的业务并发场景,并采集不同的业务并发量数据为例,使用本发明的面向不同老化场景的虚拟机工作队列和冗余队列更新方法对该虚拟机的工作队列和冗余队列进行更新。实验总共使用三台曙光服务器,其中一台服务器负责负载均衡,同时用作采集分析虚拟机数据,制定调整方案等,其他用于创建多台虚拟机,每台虚拟机分配4个CPU、4G内存和20G磁盘,并安装带有老化缺陷的飞机票在线订购应用。实验中的调整方法由Python、Shell语言实现。实例拓扑图如图1所示。
面向不同老化场景的虚拟机工作队列和冗余队列更新方法,如图2所示,包括以下步骤:
步骤1:根据虚拟机的生存时间和负载的波动情况划分不同的软件老化场景,具体方法为:
步骤1.1:将云服务系统中在一段时间内所有虚拟机都处于健康状态的场景划分为虚拟机生存时间短的场景,也称为场景一;
该场景下云服务系统所有虚拟机的创建时间较晚,持续工作时间较短,所以在一段时间内所有虚拟机都处于健康状态,即软件老化度在0~0.2之间,另外这些虚拟机可能在较短时间内被释放掉,因此该场景下软件老化对虚拟机的影响较小,从节省成本方面考虑,在调整云资源时可以暂时忽略软件老化因素。
步骤1.2:将虚拟机长期不间断地运转,软件老化因素随着业务访问不断累积,导致一些虚拟机已经处于非健康的状态,但通过增广迪基-福勒检验(Augmented DickeyFuller Test,即ADF)方法判断云服务系统总业务并发量变化平稳,不会造成工作虚拟机故障的场景划分为虚拟机生存时间长且业务并发量平稳的场景,也称为场景二;
该场景下云服务系统中虚拟机长期不间断地运转,软件老化因素随着业务访问不断累积,导致一些虚拟机已经处于非健康的状态,即软件老化度大于0.2,但由于业务并发量变化较为平稳,一般不会造成工作虚拟机故障。通过ADF方法判断云服务系统总业务并发量的平稳性,如果不存在单位根则说明业务并发量变化平稳。
步骤1.3:将外部负载波动大,造成虚拟资源的频繁调整,并且在调整过程中云服务系统处于过载状态,即通过ADF方法判断云服务系统总业务并发量非平稳变化,而且已经存在部分虚拟机处于非健康的状态的场景划分为虚拟机生存时间长且业务并发量非平稳的场景,也称为场景三;
该场景下云服务系统的外部负载波动较大,造成虚拟资源的频繁调整,并且在调整过程中系统可能处于过载状态,从而加速了老化过程;另一方面系统中已经存在部分虚拟机处于非健康的状态,此时系统对每台虚拟机的可靠性要求较高,因此有必要增加冗余虚拟机来确保系统的服务质量。
步骤2:采用基于岭回归的虚拟机工作队列动态更新的方法,动态地调整工作虚拟机副本的数目和顺序;
步骤2.1:在忽略软件老化因素的前提下,将虚拟机的业务并发量看作自变量,把CPU、内存、磁盘IO和网络IO看作因变量,对云服务系统建立岭回归模型,从而由业务的并发量计算出云服务系统所需的资源量;
步骤2.1.1:判断虚拟机的软件老化场景;
步骤2.1.2:从新启动的工作虚拟机上采集各类数据,把业务并发访问量和CPU及内存数据代入岭回归模型中;
云服务系统所需的CPU、内存、磁盘IO或网络IO的资源量的计算方法如下公式所示:
z=α1*x12*x2+...+αk*xk1*y12*y23*y34*y4+ε (1)
其中,xj表示云服务系统中第j类业务的并发量,j=1,...,k,k为虚拟机所支持的业务类型数,y1、y2、y3、y4分别表示期望的CPU、内存、磁盘IO以及网络IO的使用率,z表示云服务系统所需的CPU或内存或磁盘IO或网络IO的资源量,αj为第j类业务的并发量在资源计算中的影响权重,β1、β2、β3、β4分别表示在资源计算过程中对CPU、内存、磁盘IO以及网络IO性能期望的权重,ε为误差常量;
步骤2.1.3:使用最小二乘法迭代求解岭回归模型的损失函数,使岭回归模型的损失函数Loss最小,如下公式所示:
其中,n表示工作虚拟机上采集到的各类业务并发量的数目,Zi表示实际的资源需求量,表示由模型得到的资源需求量,λ表示正则项系数;
步骤2.1.4:使岭回归模型的损失函数Loss最小,确定参数α1,...,αk、β1、β2和ε,当参数的偏导值为零解出Loss函数的极小值,如下公式所示:
步骤2.1.5:按公式3和4求解由所有参数构成的方程,并代入采集到的业务并发量、资源利用率和CPU、内存、磁盘IO以及网络IO的资源量,求解得到岭回归模型的2k+6个参数,从而确定各类业务与CPU、内存、磁盘IO以及网络IO之间的关系;
步骤2.1.6:将云服务系统的业务并发量代入公式1,获得云服务系统所需的各类资源量;
步骤2.2:根据云服务系统所需的各类资源量确定所需工作虚拟机的数量,具体方法为:
步骤2.2.1:根据不同场景确定虚拟机的损耗;
步骤2.2.1.1:对于场景二和场景三,软件老化程度不同的工作虚拟机存在不同的内存资源损耗,在统计现有云资源时根据软件老化度对每台虚拟机的内存资源折算,同时服务已经失效的虚拟机不再计入可用资源;
步骤2.2.1.2:场景一中的工作虚拟机全部处于健康状态,在该场景下忽略老化的损耗;
步骤2.2.2:现有f台工作虚拟机,则下一段时间所需的工作虚拟机数目Numwork由如下公式计算,Numwork的最小取值为一:
Rescpu=f*vmcpu (6)
其中,Rescpu、Resmem分别表示云服务系统CPU和内存可用的资源量,zcpu_h、zcpu_l分别为根据虚拟机性能的期望范围求得的CPU资源的上界和资源下界,zmem_h、zmem_l分别为根据虚拟机性能的期望范围求得的内存资源的上界和资源下界,vmcpu、vmmem表示一个虚拟机副本的CPU核数和内存大小,s为虚拟机的软件老化度,ρ表示软件老化度s在资源评估中的影响比重,在场景二和场景三中0<ρ≤1,在场景一中ρ=0;
步骤2.3:对已经宕机或者服务失效的工作虚拟机进行处理,具体方法为:
步骤2.3.1:替换已经宕机的虚拟机;
如果虚拟机冗余队列不为空,立即从冗余队列尾部选取虚拟机进行替换,并将宕机虚拟机重启转入冗余队列尾部;
如果虚拟机冗余队列为空,直接重启宕机虚拟机,重启后放入工作队列尾部;
步骤2.3.2:替换服务失效的虚拟机;
步骤2.3.2.1:如果虚拟机冗余队列不为空,立即从冗余队列尾部选取虚拟机进行替换,并将宕机虚拟机重启转入冗余队列尾部;
步骤2.3.2.2:如果虚拟机冗余队列为空,直接重启宕机虚拟机,重启后放入工作队列尾部;
步骤2.4:根据计算的所需工作虚拟机数目Numwork增删工作虚拟机,更新虚拟机工作队列,具体方法为:
步骤2.4.1:增加工作虚拟机;
步骤2.4.1.1:从虚拟机冗余队列尾部选择虚拟机补充到虚拟机工作队列,如果没有足够的冗余虚拟机,创建一台虚拟机并启动加入到工作队列尾部;
步骤2.4.1.2:将工作队列中所有虚拟机按软件老化度从大到小排序;
步骤2.4.2:释放工作虚拟机,从虚拟机工作队列队首删除虚拟机,放入虚拟机冗余队列;
步骤3:基于二元决策图动态更新虚拟机的冗余队列,具体方法为:
步骤3.1:根据云服务系统当前的软件老化场景及云服务系统老化情况,决定冗余虚拟机使用情况;
若云服务系统当前处于场景一,不考虑冗余虚拟机;
若云服务系统当前处于场景二,对重度软件老化的工作虚拟机冗余,并且最少冗余一台;
若云服务系统当前处于场景三,利用二元决策图对场景三下的虚拟机冗余队列进行动态更新计算冗余虚拟机的数目;
步骤3.2:使用如图3所示的二元决策图(Binary Decision Diagram,即BDD)动态更新场景三下的虚拟机冗余队列,具体方法为:
步骤3.2.1:以字符’#’初始化决策图BDD,初始化‘0’叶子节点,初始化‘1’叶子节点,再以字符‘#’初始化BDD中其他节点;
步骤3.2.2:计算虚拟机的服务失效概率,选定韦伯分布拟合工作虚拟机的服务失效时间样本,累积韦伯分布函数F(t),如下公式所示:
其中,F(t)表示虚拟机在0~t的工作时间内服务失效的概率,冗余虚拟机在休眠状态下不处理任何业务请求,服务失效率近似为0,λ>0为比例参数,β>0为形状参数;
步骤3.2.3:计算冗余虚拟机的数量;
步骤3.2.3.1:设定根据步骤2,计算得到工作虚拟机的需求量为n′台;
步骤3.2.3.2:二元决策图中每个圆圈代表一个虚拟机节点,‘1’边和‘0’边分别代表虚拟机的正常、服务失效状态,矩形代表整个云服务系统的状态;所有到达‘1’矩形框的路径含义为:该路径中已经有k’台工作虚拟机处于正常状态,无论其他工作虚拟机是否正常,系统均能正常工作;而到达‘0’矩形框的路径含义为:该路径中已经有n′-k’+1台工作虚拟机已经服务失效,无论其他虚拟机是否正常,系统都无法保证用户的服务性能;
步骤3.2.3.3:生成二元决策图时,采用全局二维矩阵存储;虚拟机vx+v+1的下标记为(x,y),根节点v1的下标为(0,0);云服务系统的可靠性通过计算根到所有‘1’矩形框的路径概率和表示,以虚拟机vx+v+1为根节点的决策图的概率由如下公式计算:
P(BDD[x][y])=(1-Rx+y+1)P(BDD[x+1][y])+Rx+y+1P(BDD[x][y+1]) (9)
其中,Rx+y+1表示虚拟机vx+y+1服务失效的概率,BDD[x+1][y]、BDD[x][y+1]分别表示与虚拟机vx+y+1的‘1’边、‘0’边相连的子决策图;
由于冗余虚拟机的数量未知,则k’的大小不确定;若按照传统的二元决策图计算方法,则k’从1到n分别取值计算概率,直到冗余虚拟机数目m达到所要求的概率;
步骤3.2.3.5:根据所有工作虚拟机的平均软件老化度设置冗余虚拟机数目m的初始值,计算k’,得出m;
步骤3.2.4:根据冗余虚拟机数目m,调整虚拟机的冗余队列;
增加冗余虚拟机时,新建并启动虚拟机,放入虚拟机冗余队列尾部;
释放冗余虚拟机时,从虚拟机冗余队列首部删除虚拟机。
本实施例将本发明方法与以下两种未考虑虚拟机软件老化的资源调整方法对比:基于监测的被动调整方法(记为对照方法一)和基于ARIMA预测的调整方法(记为对照方法二)对比,使用每小时的失败请求数、平均响应时间、平均资源利用率作为分析各调整方法性能的指标。
对照方法一通过监测系统性能来调整虚拟机数量,设置当系统的平均CPU或内存资源利用率持续5分钟大于80%时增加两台工作虚拟机,持续10分钟小于30%时减少两台工作虚拟机,对照方法二通过ARIMA预测CPU和内存资源需求量来调整虚拟机。本实施例按照表1中参数使用LoadRunner依次模拟本发明中的三类老化场景,在各场景下分别进行三次实验测试各调整方法:第一次采用本发明的方法,第二次测试对照方法一,第三次测试对照方法二,最后从失败请求数、平均响应时间和平均资源利用率对比各方法的性能,其中失败请求数是指服务端未返回响应的请求个数。
表1参数
参数 参数设置
一次实验总时长 36个小时
每台VM平均软件老化时长 10个小时
每台服务器上最大虚拟机数 8台
方法执行间隔 5分钟
场景一的模拟时间 前12个小时
场景二的模拟时间 第12个小时至第24个小时
场景三的模拟时间 第24个小时至第36个小时
场景一下系统业务并发量范围 每秒0~3000个并发请求
场景二下系统业务并发量范围 每秒3000~4000个并发请求
场景三下系统业务并发量范围 每秒2000~6000个并发请求
表2记录了三种资源调整方法下的服务质量,从表中可以看出,当采用对照方法一调整虚拟机时两项服务指标最高,这是由于通过监测性能的方式静态地调整虚拟机,调整动作存在延迟造成的;采用对照方法二后虽然失败请求数比对照方法一有所减少,但是仍具有较长的请求响应时间;而当使用本发明方法调整虚拟机时服务质量最优,每小时的平均失败请求数是24,平均响应时间为0.361s,这是因为本发明方法可以在各老化场景下通过冗余虚拟机保证工作虚拟机的正常运行。
表2各调整方法下的整体服务质量对比
三类老化场景中使用三种方法调整后的情况如图4和图5所示,从图中可以看出在36个小时内三种方法得到的两项服务指标大致表现为递增趋势,说明场景三中的虚拟机较其他场景中的虚拟机受软件老化影响大,因此场景三下需要更多的冗余保障工作虚拟机的性能和可靠性。另外对照方法二与本文方法在场景一和场景二中的效果较为接近,但是在场景三下的失败请求数和响应时间突增,说明在并发量波动大、老化积累严重的场景下,基于时间序列预测的传统调整方法无法较好地保证服务质量。
为了进一步研究虚拟机资源的利用情况,本实施例将各调整方法下系统每小时的平均资源利用率进行对比,如图6和图7所示,从图中可以看出,相比两个对照方法,施加本发明方法时系统的平均资源利用率最低,这是因为在调整过程中设置了部分冗余资源,但整体来看,资源利用率的降低幅度在可接受范围之内,在36个小时内本发明调整方法下虚拟机的平均资源使用率都在50%至70%之间,相对来说比较稳定;对照方法一下的平均资源利用率波动较大,由于被动调整的延迟性导致一些资源空闲和资源紧张的情况出现;而对照方法二在场景三下存在资源利用率过低和过高的情况,这是因为负载波动导致资源频繁调整,一些老化严重的工作虚拟机性能急剧下降。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明权利要求所限定的范围。

Claims (6)

1.一种面向不同老化场景的虚拟机工作队列和冗余队列更新方法,其特征在于:包括以下步骤:
步骤1:根据虚拟机的生存时间和负载的波动情况划分不同的软件老化场景,具体方法为:
步骤1.1:将云服务系统中在一段时间内所有虚拟机都处于健康状态的场景划分为虚拟机生存时间短的场景,也称为场景一;
步骤1.2:将虚拟机长期不间断地运转,软件老化因素随着业务访问不断累积,导致一些虚拟机已经处于非健康的状态,但通过增广迪基-福勒检验方法判断云服务系统总业务并发量变化平稳,不会造成工作虚拟机故障的场景划分为虚拟机生存时间长且业务并发量平稳的场景,也称为场景二;
步骤1.3:将外部负载波动大,造成虚拟资源的频繁调整,并且在调整过程中云服务系统处于过载状态,即通过ADF方法判断云服务系统总业务并发量非平稳变化,而且已经存在部分虚拟机处于非健康的状态的场景划分为虚拟机生存时间长且业务并发量非平稳的场景,也称为场景三;
步骤2:采用基于岭回归的虚拟机工作队列动态更新的方法,动态地调整工作虚拟机副本的数目和顺序;
步骤2.1:在忽略软件老化因素的前提下,将虚拟机的业务并发量看作自变量,把CPU、内存、磁盘IO和网络IO看作因变量,对云服务系统建立岭回归模型,从而由业务的并发量计算出云服务系统所需的资源量;
步骤2.2:根据云服务系统所需的各类资源量确定所需工作虚拟机的数量;
步骤2.3:对已经宕机或者服务失效的工作虚拟机进行处理;
步骤2.4:根据计算的所需工作虚拟机数目Numwork增删工作虚拟机,更新虚拟机工作队列;
步骤3:基于二元决策图动态更新虚拟机的冗余队列,具体方法为:
步骤3.1:根据云服务系统当前的软件老化场景及云服务系统老化情况,决定冗余虚拟机使用情况;
若云服务系统当前处于场景一,不考虑冗余虚拟机;
若云服务系统当前处于场景二,对重度软件老化的工作虚拟机冗余,并且最少冗余一台;
若云服务系统当前处于场景三,利用二元决策图对场景三下的虚拟机冗余队列进行动态更新计算冗余虚拟机的数目;
步骤3.2:使用二元决策图动态更新场景三下的虚拟机冗余队列。
2.根据权利要求1所述的面向不同老化场景的虚拟机工作队列和冗余队列更新方法,其特征在于:所述步骤2.1的具体方法为:
步骤2.1.1:判断虚拟机的软件老化场景;
步骤2.1.2:从新启动的工作虚拟机上采集各类数据,把业务并发访问量和CPU及内存数据代入岭回归模型中;
云服务系统所需的CPU、内存、磁盘IO或网络IO的资源量的计算方法如下公式所示:
z=α1*x12*x2+...+αk*xk1*y12*y23*y34*y4+ε (1)
其中,xj表示云服务系统中第j类业务的并发量,j=1,...,k,k为虚拟机所支持的业务类型数,y1、y2、y3、y4分别表示期望的CPU、内存、磁盘IO以及网络IO的使用率,z表示云服务系统所需的CPU或内存或磁盘IO或网络IO的资源量,αj为第j类业务的并发量在资源计算中的影响权重,β1、β2、β3、β4分别表示在资源计算过程中对CPU、内存、磁盘IO以及网络IO性能期望的权重,ε为误差常量;
步骤2.1.3:使用最小二乘法迭代求解岭回归模型的损失函数,使岭回归模型的损失函数Loss最小,如下公式所示:
其中,n表示工作虚拟机上采集到的各类业务并发量的数目,Zi表示实际的资源需求量,表示由模型得到的资源需求量,λ表示正则项系数;
步骤2.1.4:使岭回归模型的损失函数Loss最小,确定参数α1,…,αk、β1、β2和ε,当参数的偏导值为零解出Loss函数的极小值,如下公式所示:
步骤2.1.5:按公式3和4求解由所有参数构成的方程,并代入采集到的业务并发量、资源利用率和CPU、内存、磁盘IO以及网络IO的资源量,求解得到岭回归模型的2k+6个参数,从而确定各类业务与CPU、内存、磁盘IO以及网络IO之间的关系;
步骤2.1.6:将云服务系统的业务并发量代入公式1,获得云服务系统所需的各类资源量。
3.根据权利要求2所述的面向不同老化场景的虚拟机工作队列和冗余队列更新方法,其特征在于:所述步骤2.2的具体方法为:
步骤2.2.1:根据不同场景确定虚拟机的损耗;
步骤2.2.1.1:对于场景二和场景三,软件老化程度不同的工作虚拟机存在不同的内存资源损耗,在统计现有云资源时根据软件老化度对每台虚拟机的内存资源折算,同时服务已经失效的虚拟机不再计入可用资源;
步骤2.2.1.2:场景一中的工作虚拟机全部处于健康状态,在该场景下忽略老化的损耗;
步骤2.2.2:现有f台工作虚拟机,则下一段时间所需的工作虚拟机数目Numwork由如下公式计算,Numwork的最小取值为一:
Rescpu=f*vmcpu (6)
其中,Rescpu、Resmem分别表示云服务系统CPU和内存可用的资源量,zcpu_h、zcpu_l分别为根据虚拟机性能的期望范围求得的CPU资源的上界和资源下界,zmem_h、zmem_l分别为根据虚拟机性能的期望范围求得的内存资源的上界和资源下界,vmcpu、vmmmem表示一个虚拟机副本的CPU核数和内存大小,s为虚拟机的软件老化度,ρ表示软件老化度s在资源评估中的影响比重,在场景二和场景三中0<ρ≤1,在场景一中ρ=0。
4.根据权利要求3所述的面向不同老化场景的虚拟机工作队列和冗余队列更新方法,其特征在于:所述步骤2.3的具体方法为:
步骤2.3.1:替换已经宕机的虚拟机;
如果虚拟机冗余队列不为空,立即从冗余队列尾部选取虚拟机进行替换,并将宕机虚拟机重启转入冗余队列尾部;
如果虚拟机冗余队列为空,直接重启宕机虚拟机,重启后放入工作队列尾部;
步骤2.3.2:替换服务失效的虚拟机;
步骤2.3.2.1:如果虚拟机冗余队列不为空,立即从冗余队列尾部选取虚拟机进行替换,并将宕机虚拟机重启转入冗余队列尾部;
步骤2.3.2.2:如果虚拟机冗余队列为空,直接重启宕机虚拟机,重启后放入工作队列尾部。
5.根据权利要求4所述的面向不同老化场景的虚拟机工作队列和冗余队列更新方法,其特征在于:所述步骤2.4的具体方法为:
步骤2.4.1:增加工作虚拟机;
步骤2.4.1.1:从虚拟机冗余队列尾部选择虚拟机补充到虚拟机工作队列,如果没有足够的冗余虚拟机,创建一台虚拟机并启动加入到工作队列尾部;
步骤2.4.1.2:将工作队列中所有虚拟机按软件老化度从大到小排序;
步骤2.4.2:释放工作虚拟机,从虚拟机工作队列队首删除虚拟机,放入虚拟机冗余队列。
6.根据权利要求5所述的面向不同老化场景的虚拟机工作队列和冗余队列更新方法,其特征在于:所述步骤3.2的具体方法为:
步骤3.2.1:以字符’#’初始化决策图BDD,初始化‘0’叶子节点,初始化‘1’叶子节点,再以字符‘#’初始化BDD中其他节点;
步骤3.2.2:计算虚拟机的服务失效概率,选定韦伯分布拟合工作虚拟机的服务失效时间样本,累积韦伯分布函数F(t),如下公式所示:
其中,F(t)表示虚拟机在0~t的工作时间内服务失效的概率,冗余虚拟机在休眠状态下不处理任何业务请求,服务失效率近似为0,λ>0为比例参数,β>0为形状参数;
步骤3.2.3:计算冗余虚拟机的数量;
步骤3.2.3.1:根据步骤2,计算得到工作虚拟机的需求量为n′台;
步骤3.2.3.2:二元决策图中每个圆圈代表一个虚拟机节点,‘1’边和‘0’边分别代表虚拟机的正常、服务失效状态,矩形代表整个云服务系统的状态;所有到达‘1’矩形框的路径含义为:该路径中已经有k’台工作虚拟机处于正常状态,无论其他工作虚拟机是否正常,系统均能正常工作;而到达‘0’矩形框的路径含义为:该路径中已经有n′-k’+1台工作虚拟机已经服务失效,无论其他虚拟机是否正常,系统都无法保证用户的服务性能;
步骤3.2.3.3:生成二元决策图时,采用全局二维矩阵存储;虚拟机vx+y+1的下标记为(x,y),根节点v1的下标为(0,0);云服务系统的可靠性通过计算根到所有‘1’矩形框的路径概率和表示,以虚拟机vx+y+1为根节点的决策图的概率由如下公式计算:
P(BDD[x][y])=(1-Rx+y+1)P(BDD[x+1][y])+Rx+y+1P(BDD[x][y+1]) (9)
其中,Rx+y+1表示虚拟机vx+y+1服务失效的概率,BDD[x+1][y]、BDD[x][y+1]分别表示与虚拟机vx+y+1的‘1’边、‘0’边相连的子决策图;
由于冗余虚拟机的数量未知,则k’的大小不确定;若按照传统的二元决策图计算方法,则k’从1到n分别取值计算概率,直到冗余虚拟机数目m达到所要求的概率;
步骤3.2.3.5:根据所有工作虚拟机的平均软件老化度设置冗余虚拟机数目m的初始值,计算k’,得出m;
步骤3.2.4:根据冗余虚拟机数目m,调整虚拟机的冗余队列;
增加冗余虚拟机时,新建并启动虚拟机,放入虚拟机冗余队列尾部;
释放冗余虚拟机时,从虚拟机冗余队列首部删除虚拟机。
Rescpu=f*vmcpu (6)
其中,Rescpu、Resmem分别表示云服务系统CPU和内存可用的资源量,zcpu_h、zcpu_l分别为根据虚拟机性能的期望范围求得的CPU资源的上界和资源下界,zmem_h、zmem_l分别为根据虚拟机性能的期望范围求得的内存资源的上界和资源下界,vmcpu、vmmem表示一个虚拟机副本的CPU核数和内存大小,s为虚拟机的软件老化度,ρ表示软件老化度s在资源评估中的影响比重,在场景二和场景三中0<ρ≤1,在场景一中ρ=0。
CN201910354679.7A 2019-04-29 2019-04-29 面向不同老化场景的虚拟机工作队列和冗余队列更新方法 Active CN110109733B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201910354679.7A CN110109733B (zh) 2019-04-29 2019-04-29 面向不同老化场景的虚拟机工作队列和冗余队列更新方法
PCT/CN2019/090870 WO2020220436A1 (zh) 2019-04-29 2019-06-12 面向不同老化场景的虚拟机工作队列和冗余队列更新方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910354679.7A CN110109733B (zh) 2019-04-29 2019-04-29 面向不同老化场景的虚拟机工作队列和冗余队列更新方法

Publications (2)

Publication Number Publication Date
CN110109733A true CN110109733A (zh) 2019-08-09
CN110109733B CN110109733B (zh) 2022-06-24

Family

ID=67487401

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910354679.7A Active CN110109733B (zh) 2019-04-29 2019-04-29 面向不同老化场景的虚拟机工作队列和冗余队列更新方法

Country Status (2)

Country Link
CN (1) CN110109733B (zh)
WO (1) WO2020220436A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111274111A (zh) * 2020-01-20 2020-06-12 西安交通大学 一种用于微服务老化的预测与抗衰方法
CN111369160A (zh) * 2020-03-12 2020-07-03 苏州随身玩信息技术有限公司 一种讲解器的均衡分配方法、机柜及服务器
CN116155695A (zh) * 2023-04-19 2023-05-23 杭州美创科技股份有限公司 集群多节点管理方法、装置、计算机设备及存储介质

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114803391B (zh) * 2022-05-12 2023-11-03 北京华能新锐控制技术有限公司 一种智慧燃料系统斗轮机无人值守自动取料方法
CN115001896B (zh) * 2022-06-28 2024-01-19 中国人民解放军海军工程大学 一种冗余通道的自适应切换方法
CN116680062B (zh) * 2023-08-03 2023-12-01 湖南博创高新实业有限公司 一种基于大数据集群的应用调度部署方法及存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5175679A (en) * 1990-09-28 1992-12-29 Xerox Corporation Control for electronic image processing systems
US8261268B1 (en) * 2009-08-05 2012-09-04 Netapp, Inc. System and method for dynamic allocation of virtual machines in a virtual server environment
CN102662763A (zh) * 2012-04-11 2012-09-12 华中科技大学 基于服务质量的虚拟机资源调度方法
CN103605567A (zh) * 2013-10-29 2014-02-26 河海大学 面向实时性需求变化的云计算任务调度方法
US20170185435A1 (en) * 2015-12-24 2017-06-29 Prashant Dewan Fast switching between virtual machines without interrupt virtualization for high-performance, secure trusted-execution enviornment
CN107589980A (zh) * 2017-08-01 2018-01-16 佛山市深研信息技术有限公司 一种云计算资源的调度方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104598298A (zh) * 2015-02-04 2015-05-06 上海交通大学 基于虚拟机当前工作性质以及任务负载的虚拟机调度算法
CN107992353B (zh) * 2017-07-31 2022-03-18 南京邮电大学 一种基于最小迁移量的容器动态迁移方法及系统
CN108595250B (zh) * 2018-05-02 2021-05-28 南京大学 一种面向IaaS云平台的资源调度效率优化方法及系统

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5175679A (en) * 1990-09-28 1992-12-29 Xerox Corporation Control for electronic image processing systems
US8261268B1 (en) * 2009-08-05 2012-09-04 Netapp, Inc. System and method for dynamic allocation of virtual machines in a virtual server environment
CN102662763A (zh) * 2012-04-11 2012-09-12 华中科技大学 基于服务质量的虚拟机资源调度方法
CN103605567A (zh) * 2013-10-29 2014-02-26 河海大学 面向实时性需求变化的云计算任务调度方法
US20170185435A1 (en) * 2015-12-24 2017-06-29 Prashant Dewan Fast switching between virtual machines without interrupt virtualization for high-performance, secure trusted-execution enviornment
CN107589980A (zh) * 2017-08-01 2018-01-16 佛山市深研信息技术有限公司 一种云计算资源的调度方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
张斌 等: "考虑虚拟机间性能互扰基于排队网的多层Web应用性能分析模型", 《计算机科学》 *
李焱 等: "云环境下老化感知的任务调度和运行管理框架", 《高技术通讯》 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111274111A (zh) * 2020-01-20 2020-06-12 西安交通大学 一种用于微服务老化的预测与抗衰方法
CN111369160A (zh) * 2020-03-12 2020-07-03 苏州随身玩信息技术有限公司 一种讲解器的均衡分配方法、机柜及服务器
CN116155695A (zh) * 2023-04-19 2023-05-23 杭州美创科技股份有限公司 集群多节点管理方法、装置、计算机设备及存储介质

Also Published As

Publication number Publication date
WO2020220436A1 (zh) 2020-11-05
CN110109733B (zh) 2022-06-24

Similar Documents

Publication Publication Date Title
CN110109733A (zh) 面向不同老化场景的虚拟机工作队列和冗余队列更新方法
US11966788B2 (en) Predictive autoscaling and resource optimization
WO2020237729A1 (zh) 一种基于模式转移的虚拟机混合备用动态可靠性评估方法
Xiong et al. Intelligent management of virtualized resources for database systems in cloud environment
US20050154576A1 (en) Policy simulator for analyzing autonomic system management policy of a computer system
US7581052B1 (en) Approach for distributing multiple interrupts among multiple processors
CN106776288B (zh) 一种基于Hadoop的分布式系统的健康度量方法
US7945657B1 (en) System and method for emulating input/output performance of an application
CN102123061B (zh) 一种确定Web服务器性能的方法
CN108701060A (zh) 用于计算系统自动调整的方法
WO2022016808A1 (zh) 一种kubernetes集群资源动态调整方法及电子设备
CN105279087A (zh) 应用在测试软件中的测试方法和测试系统
US20140196054A1 (en) Ensuring performance of a computing system
Zhao et al. A comprehensive approach to optimal software rejuvenation
US20110035753A1 (en) Mechanism for continuously and unobtrusively varying stress on a computer application while processing real user workloads
CN111130842B (zh) 一种反映网络多维资源的动态网络图谱数据库构建方法
CN110297743B (zh) 一种负载测试方法、装置和存储介质
CN114780233A (zh) 基于微服务链路分析和强化学习的调度方法及装置
US8910189B2 (en) Methods and systems for automatically determining configuration parameters
WO2020220437A1 (zh) 一种基于AdaBoost-Elman的虚拟机软件老化预测方法
Du et al. Cost-effective strong consistency on scalable geo-diverse data replicas
Rybina et al. Estimating energy consumption during live migration of virtual machines
Samir et al. Autoscaling recovery actions for container‐based clusters
CN111061618B (zh) 云平台仿真系统、云平台性能测试方法和计算机设备
CN110909023B (zh) 一种查询计划的获取方法、数据查询方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
EE01 Entry into force of recordation of patent licensing contract
EE01 Entry into force of recordation of patent licensing contract

Application publication date: 20190809

Assignee: Shenyang Zhizhi Technology Co.,Ltd.

Assignor: Northeastern University

Contract record no.: X2023210000209

Denomination of invention: Virtual Machine Work Queue and Redundant Queue Update Methods for Different Aging Scenarios

Granted publication date: 20220624

License type: Common License

Record date: 20231127