CN114265671A - 虚拟机房的混合式扩展方法 - Google Patents
虚拟机房的混合式扩展方法 Download PDFInfo
- Publication number
- CN114265671A CN114265671A CN202210203851.0A CN202210203851A CN114265671A CN 114265671 A CN114265671 A CN 114265671A CN 202210203851 A CN202210203851 A CN 202210203851A CN 114265671 A CN114265671 A CN 114265671A
- Authority
- CN
- China
- Prior art keywords
- virtual machine
- workload
- machine room
- virtual
- administrator
- 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
Links
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
虚拟机房的混合式扩展方法,属于虚拟机配置技术领域,包括以下步骤:步骤S1,建立虚拟机房架构:在云端虚拟机房运行OpenStack系统;OpenStack系统内设有Nova元件、Heat元件、Ceilometer元件;Nova元件、Heat元件、Ceilometer元件执行OpenStack系统的反应式自动扩展机制;同时,OpenStack系统新增:管理员元件、预测员元件和处理者元件;步骤S2,每隔固定时间同时执行预测式扩展机制和OpenStack系统的反应式自动扩展机制,并作出决策。本方案,同时执行预测式扩展机制和OpenStack系统的反应式自动扩展两种方式,为云端机房的工作负载进行妥善的资源分配。
Description
技术领域
本发明属于虚拟机配置技术领域,具体涉及虚拟机房的混合式扩展方法。
背景技术
在IT业,机房普遍指的是电信、网通、移动、双线、电力以及政府或者企业等,存放服务器的,为用户以及员工提供IT服务的地方。在虚拟技术尚未发展起来之前,机房功能或者算力的配置,主要通过实体服务器的增减来实现的。
随着虚拟化技术的发展,虚拟化能使用户在一台服务器上同时运行多个操作系统。一般来说,服务器系统可配置有多个节点,且每一个节点同时运行多个虚拟机器(VirtualMachine,VM),借以提供给每一使用者独立的运作环境。因此,传统的实体机房,慢慢地转型为虚拟机房。虚拟机房通过虚拟机提供计算服务。当虚拟机房面临计算请求的突然增加时,会采用新增虚拟机器来分担计算负荷,从而增加实体主机的使用率,降低采购机器的成本。
虚拟化技术建置的云端机房,其虚拟主机数量通常远大于由实体主机组成的传统机房,若要通过人力来管理几乎是不可行。传统的方法,是采用OpenStack的自动扩展方法,去检查系统资源使用是否超过预定的数值,然后进行资源调整。
如公开号为CN112000459A的中国专利,公开了一种用于服务的扩缩容的方法,计算设备在预测出服务在下一个周期的状态之后,可以快速准确的选出服务在该状态下对应的Q值最大的动作,从而确定出实例扩缩策略。也就是说,现有的方案是根据历史工作负,预估的未来工作负载,并提前在工作负载到达之前,通过自动扩展方法新增或是减少虚拟资源的数量,以期能对即将到来的工作负载做最优化的处理。
然而,一方面,预测式扩展机制的行为仰赖于历史工作负载,而历史工作负载需要经过一段时间才能收集完成,收集的样本数不足则无法进行预测,如此云端虚拟机房便将无法预先准备好资源满足使用者需求。另一方面,预测式扩展机制,无法非常精确的预估未来工作负载,使得预先准备好的资源有可能过多或是过少。准备过少的资源可能不满足服务水平协议的承诺,准备过多的资源造成服务提供商成本的增加。
OpenStack系统提供了反应式自动扩展机制,这种方式虽然不用耗费系统额外的计算资源,去定期预测未来的工作负载,但由于其特性是等到系统负载已经达到临界值时才做处理,所以往往处理的时间点都已经太晚,而降低处理使用者需求的效率。
发明内容
鉴于上述现有技术的不足之处,本发明的目的在于提供虚拟机房的混合式扩展方法。
为了达到上述目的,本发明采取了以下的技术方案。
虚拟机房的混合式扩展方法,包括以下步骤:
步骤S1,建立虚拟机房架构:在云端虚拟机房运行OpenStack系统;OpenStack系统内设有Nova元件、Heat元件、Ceilometer元件;Nova元件、Heat元件、Ceilometer元件执行OpenStack系统的反应式自动扩展机制;同时,OpenStack系统新增:管理员元件、预测员元件和处理者元件;
管理员元件:是核心元件,负责向Nova 元件取得云端虚拟机房中所有虚拟机实例的监控记录列表后,再向Ceilometer元件请求取得每一个虚拟机实例的监控记录列表,然后把监控记录列表传送给预测员元件进行预测并且接收来自预测员元件的预测结果,接着再将预测结果传送给处理者元件进行是否自动扩增、自动缩减的决策,从而完成了整个工作负载预测与自动扩展的流程;
预测员元件:负责接收管理员元件所传送的虚拟机实例的监控记录列表,进行工作负载的预测,如果监控记录的数量不足,则此时间间隔不予预测工作负载,如果监控记录的数量足够则进行工作负载预测,则将结果传回给处理者元件;
处理者元件:按照事先定义好的扩展临界值,决定是否扩增或是缩减虚拟机实例,然后对Heat元件的模板进行内容更新,最后通过Heat元件重新读取更新过后的模板,更新集合Stack里面的可用资源;
步骤S2,每隔固定时间同时执行预测式扩展机制和OpenStack系统的反应式自动扩展机制:如果预测式扩展机制先做出决策,则OpenStack系统的反应式自动扩展机制检查目前系统的工作负载,如果超出事先定义的临界值则扩展云端的虚拟机房,否则缩小云端的虚拟机房;如果OpenStack系统的反应式自动扩展机制先做出决策,则预测式扩展机制预测未来工作负载,如果超出事先定义的临界值则扩展云端的虚拟机房,否则缩小云端的虚拟机房。
进一步,步骤S2,包括以下步骤:
步骤S201,管理员元件,向Nova元件请求读取在云端虚拟机房中所有虚拟实例的监控记录列表。
步骤S202,Nova元件,接收到来自管理员元件的请求后,查询并传回虚拟实例的监控记录列表。
步骤S203,管理员元件,将收到的虚拟实例的监控记录列表当做输入,传送给负责监控的Ceilometer元件,请求查询系统中每一个虚拟实例的监控记录。
步骤S204,Ceilometer元件,查询到监控记录后,回传记录给管理员元件。
步骤S205,管理员元件,将收到的记录当做输入,传送给预测员元件,从而预测未来工作负载。
步骤S206,预测员元件,进行未来工作负载预测完成后,将结果回传给管理员元件。
步骤S207,管理员元件,将工作负载预测结果当做输入,传送给处理者元件。
步骤S208,处理者元件,根据工作负载预测的结果,决定是否要扩增或是缩小云端虚拟机房的规模,并更新Heat元件模板的内容。
步骤S209,处理者元件,通知Heat元件更新虚拟资源实例集合Stack中的内容。
步骤S2010,Heat元件,读取更新后的Heat元件模板的内容。
步骤S2011,Heat元件,通知Nova元件更新虚拟资源实例集合Stack中的内容。
步骤S2012,Nova元件,收到来自Heat元件的通知后,进行虚拟资源实例集合Stack的扩展或缩减。
步骤S206,还包括:对系统中虚拟主机CPU使用率进行观测,每5分钟观测一次;预估工作负载采用以下公式:
Ft=Ft-1+α(At-1–Ft-1);
其中,Ft为第t期的预估工作负载;Ft-1为第t-1期的预估工作负载;At-1为第t-1期的真实工作负载;α为平滑系数,范围为0~1,由资料变化趋势决定最佳值,默认值为0.8。
本方案,将预测式扩展机制和OpenStack系统的反应式自动扩展机制相互结合,形成虚拟机房的混合式扩展方法,同时执行预测式扩展机制和OpenStack系统的反应式自动扩展机制两种方式,使 OpenStack 具备预测工作负载及自动扩展的功能,为云端机房的工作负载进行妥善的资源分配。
附图说明
图1是本发明步骤2的流程示意图;
图2是实验的部署架构图;
图3是OpenStack系统的反应式自动扩展机制的流程图。
具体实施方式
下面结合附图,对本发明作进一步详细说明。
OpenStack系统为一开源(OpenSource)云端作业系统,自2010年开始被逐渐广泛应用于云端运算,支持反应式自动扩展。即,OpenStack采用事先监控系统数值的上、下限的方式,并通过实时监控信息来决定是否进行自动扩展。具体的,OpenStack内设有Nova、Heat、Ceilometer元件。首先假设云端虚拟机房中的资源堆栈(Stack)已经建立完成(所谓资源堆栈就是一组虚拟资源的集合,通常会提供某种服务,如:公司官方网页的服务器丛集),然后通过Ceilometer元件监控系统状态,如果达到临界值则发出告警通知Heat元件,要求其更新资源堆栈内的资源,Heat元件收到Ceilometer元件传来的告警后,通知管理计算资源的Nova元件,为资源堆栈新增或是删除指定的虚拟资源。但OpenStack不具备预测式自动扩展方法,所有自动扩展行为都是人为事先定义好规则后,当系统工作负载过大时才会启动。
Heat元件,为OpenStack中提供计算服务的元件,负责管理一切有关虚拟机实例的事情,不论是虚拟机实例摆放的排程、虚拟储存空间的分配或是其他虚拟资源的分配、新增虚拟实例、删除虚拟实例及与底层hypervisor的沟通与协调都是由本元件提供服务。
Heat元件,通过模板(Template)档案的概念,对欲管理的虚拟资源内容进行描述,最后通过Heat引擎来执行模板内所定义的内容;Heat元件读取模板内容之后,所产生的一组虚拟资源实例的集合Stack。
Ceilometer元件,负责监控效能以及资源的使用率,使云端平台能通过这些监控信息得知系统的状态,并可向使用者进行计费或是自动扩展管理等用途。
虚拟机房的混合式扩展方法,包括以下步骤:
步骤S1,建立虚拟机房架构:在云端虚拟机房运行OpenStack系统;OpenStack系统内设有Nova元件、Heat元件、Ceilometer元件;Nova元件、Heat元件、Ceilometer元件执行OpenStack系统的反应式自动扩展机制;同时,OpenStack系统新增:管理员元件、预测员元件和处理者元件;
管理员元件:是核心元件,负责向Nova 元件取得云端虚拟机房中所有虚拟机实例的监控记录列表后,再向Ceilometer元件请求取得每一个虚拟机实例的监控记录列表,然后把监控记录列表传送给预测员元件进行预测并且接收来自预测员元件的预测结果,接着再将预测结果传送给处理者元件进行是否自动扩增、自动缩减的决策,从而完成了整个工作负载预测与自动扩展的流程。
预测员元件:负责接收管理员元件所传送的虚拟机实例的监控记录列表,进行工作负载的预测,如果监控记录的数量不足,则此时间间隔不予预测工作负载,如果监控记录的数量足够则进行工作负载预测,则将结果传回给处理者元件。
处理者元件:按照事先定义好的扩展临界值,决定是否扩增或是缩减虚拟机实例,然后对Heat元件的模板进行内容更新,最后通过Heat元件重新读取更新过后的模板,更新集合Stack里面的可用资源。
步骤S2,每隔固定时间同时执行预测式扩展机制和OpenStack系统的反应式自动扩展:如果预测式扩展机制先做出决策,则OpenStack系统的反应式自动扩展机制检查目前系统的工作负载,如果超出事先定义的临界值则扩展云端的虚拟机房,否则缩小云端的虚拟机房;如果OpenStack系统的反应式自动扩展机制先做出决策,则预测式扩展机制预测未来工作负载,如果超出事先定义的临界值则扩展云端的虚拟机房,否则缩小云端的虚拟机房。
在本申请中,预测式扩展机制和OpenStack系统的反应式自动扩展机制,两种机制同时执行,先决策完毕的机制会影响还在执行的机制的结果。如图1所示,具体如下:
步骤S201,管理员元件,向Nova元件请求读取在云端虚拟机房中所有虚拟实例的监控记录列表。
步骤S202,Nova元件,接收到来自管理员元件的请求后,查询并传回虚拟实例的监控记录列表。
步骤S203,管理员元件,将收到的虚拟实例的监控记录列表当做输入,传送给负责监控的Ceilometer元件,请求查询系统中每一个虚拟实例的监控记录。
步骤S204,Ceilometer元件,查询到监控记录后,回传记录给管理员元件。
步骤S205,管理员元件,将收到的记录当做输入,传送给预测员元件,从而预测未来工作负载。
步骤S206,预测员元件,进行未来工作负载预测完成后,将结果回传给管理员元件。
预测工作负载就是希望能早先了解云端虚拟机房中,下一个时间周期到来时可能的工作负载量,使系统能够提早进行处理,确保使用者的需求能够被满足。
对系统中虚拟主机CPU使用率进行观测,每5分钟观测一次,24小时共记录288笔资料。
Ft=Ft-1+α(At-1–Ft-1);
其中,Ft为第t期的预估工作负载;Ft-1为第t-1期的预估工作负载;At-1为第t-1期的真实工作负载;α为平滑系数,范围为0~1,由资料变化趋势决定最佳值,默认值为0.8。
步骤S207,管理员元件,将工作负载预测结果当做输入,传送给处理者元件。
步骤S208,处理者元件,根据工作负载预测的结果,决定是否要扩增或是缩小云端虚拟机房的规模,并更新Heat元件模板的内容。
步骤S209,处理者元件,通知Heat元件更新虚拟资源实例集合Stack中的内容。
步骤S2010,Heat元件,读取更新后的Heat元件模板的内容。
步骤S2011,Heat元件,通知Nova元件更新虚拟资源实例集合Stack中的内容。
步骤S2012,Nova元件,收到来自Heat元件的通知后,进行虚拟资源实例集合Stack的扩展或缩减。
本方案,将预测式扩展机制和OpenStack系统的反应式自动扩展机制相互结合,形成虚拟机房的混合式扩展方法,同时执行预测式扩展机制和OpenStack系统的反应式自动扩展两种方式,为云端机房的工作负载进行妥善的资源分配。
本方案,不但具备预测工作负载的能力,又能实时反应系统资源开启过多或者过少的情况,实作一个主动式的自动扩展方法,并说明运作方式。
实验目标:将OpenStack实验环境建立于实体主机之上,并通过实验的方式取得结果,最后通过实验数据的分析,分析传统的OpenStack系统的反应式自动扩展机制和本申请的策略效率。
OpenStack系统的反应式自动扩展机制,如图3所示,包括以下步骤:
步骤1,Ceilometer元件监控来自虚拟资源实例集合Stack传送来的监控记录。
步骤2,假设警告发生,Ceilometer元件传送警告信息通知Heat元件。
步骤3,Heat元件接收到来自Ceilometer元件传送的警告信息,根据在Heat元件模板定义好的警告处理策略,对警告进行处理并通知Nova元件。
步骤4,Nova元件收到来自Heat元件的通知后进行虚拟资源实例集合Stack的扩展或缩减。
如图2所示,本次实验共通过5台个人计算机进行,由4台个人计算机组成OpenStack云端平台,并在OpenStack上新增虚拟主机建立网页服务器丛集,1台个人计算机(测试主机)负责执行压力测试。
实验步骤:
(1)撰写网页服务器丛集template,其中包含虚拟机建立、虚拟机建立后要安装的软件、网络设定、负载均衡器设定、自动扩展告警条件定义、自动扩展条件触发定义…等。
(2)由Heat元件读取template新增PHP网页服务器丛集。
(3)由测试主机执行Httperf对PHP网页服务器丛集进行压力测试,得到实验结果。
实验以Httperf压力测试软件作为测试工具,在2种不同扩展方式及资源不受限的环境上分别建立PHP网页服务器丛集发送10000个使用者请求,观察其成功完成数。表1包含6种使用者请求发送模式,分别为:每秒0.5个、0.9个、1.3个、随机、高至低与低至高。
表1为6种使用者请求发送模式的压力测试汇总表。
使用者需求发送速率(个每秒) | OpenStack系统的反应式自动扩展机制 | 本申请 | 没有资源限制 |
0.5 | 9378 | 9480 | 10000 |
0.9 | 7578 | 8316 | 10000 |
1.3 | 3389 | 7065 | 10000 |
随机 | 7590 | 8838 | 10000 |
高至低 | 4591 | 5764 | 10000 |
低至高 | 7577 | 9409 | 10000 |
如表1所示,如果在使用者请求发送速率为每秒0.5个的情况下,本申请的方法与OpenStack系统的反应式自动扩展机制比较,只有不到1%之提升,这是由于系统中可用资源已接近满足工作负载所需的量,故自动扩展的效能提升较不明显。使用者请求速率为每秒0.9及1.3的情况下,本申请,相对于OpenStack系统的反应式自动扩展机制,分别得到9%、108%的提升,这说明了本申请的方案为系统新增了足够资源,使得其与传统OpenStack相比效能有大幅提升。使用者请求速率为随机、高至低、低至高的情况下,本申请,相对于反应式自动扩展方法,分别得到16%、24%、26%的效能提升。
由此验证,使用者请求发送速率高与变动频繁的服务,使用本申请提出的方法有机会大幅提升效能。
实验过程中记录了负责执行预测程序的controller的CPU使用率记录,每5分钟记录一次,本申请的方法平均CPU使用率仅为3%,而其他方式则为2%,足以说明此机制几乎不造成系统额外CPU负担。
可以理解的是,对本领域普通技术人员来说,可以根据本发明的技术方案及其发明构思加以等同替换或改变,而所有这些改变或替换都应属于本发明所附的权利要求的保护范围。
Claims (3)
1.虚拟机房的混合式扩展方法,其特征在于,包括以下步骤:
步骤S1,建立虚拟机房架构:在云端虚拟机房运行OpenStack系统;OpenStack系统内设有Nova元件、Heat元件、Ceilometer元件;Nova元件、Heat元件、Ceilometer元件执行OpenStack系统的反应式自动扩展机制;同时,OpenStack系统新增:管理员元件、预测员元件和处理者元件;
管理员元件:是核心元件,负责向Nova元件取得云端虚拟机房中所有虚拟机实例的监控记录列表后,再向Ceilometer元件请求取得每一个虚拟机实例的监控记录列表,然后把监控记录列表传送给预测员元件进行预测并且接收来自预测员元件的预测结果,接着再将预测结果传送给处理者元件进行是否自动扩增、自动缩减的决策,从而完成了整个工作负载预测与自动扩展的流程;
预测员元件:负责接收管理员元件所传送的虚拟机实例的监控记录列表,进行工作负载的预测,如果监控记录的数量不足,则此时间间隔不予预测工作负载,如果监控记录的数量足够则进行工作负载预测,则将结果传回给处理者元件;
处理者元件:按照事先定义好的扩展临界值,决定是否扩增或是缩减虚拟机实例,然后对Heat元件的模板进行内容更新,最后通过Heat元件重新读取更新过后的模板,更新集合Stack里面的可用资源;
步骤S2,每隔固定时间同时执行预测式扩展机制和OpenStack系统的反应式自动扩展机制:如果预测式扩展机制先做出决策,则OpenStack系统的反应式自动扩展机制检查目前系统的工作负载,如果超出事先定义的临界值则扩展云端的虚拟机房,否则缩小云端的虚拟机房;如果OpenStack系统的反应式自动扩展机制先做出决策,则预测式扩展机制预测未来工作负载,如果超出事先定义的临界值则扩展云端的虚拟机房,否则缩小云端的虚拟机房。
2.根据权利要求1所述的虚拟机房的混合式扩展方法,其特征在于,步骤S2,包括以下步骤:
步骤S201,管理员元件,向Nova元件请求读取在云端虚拟机房中所有虚拟实例的监控记录列表;
步骤S202,Nova元件,接收到来自管理员元件的请求后,查询并传回虚拟实例的监控记录列表;
步骤S203,管理员元件,将收到的虚拟实例的监控记录列表当做输入,传送给负责监控的Ceilometer元件,请求查询系统中每一个虚拟实例的监控记录;
步骤S204,Ceilometer元件,查询到监控记录后,回传记录给管理员元件;
步骤S205,管理员元件,将收到的记录当做输入,传送给预测员元件,从而预测未来工作负载;
步骤S206,预测员元件,进行未来工作负载预测完成后,将结果回传给管理员元件;
步骤S207,管理员元件,将工作负载预测结果当做输入,传送给处理者元件;
步骤S208,处理者元件,根据工作负载预测的结果,决定是否要扩增或是缩小云端虚拟机房的规模,并更新Heat元件模板的内容;
步骤S209,处理者元件,通知Heat元件更新虚拟资源实例集合Stack中的内容;
步骤S2010,Heat元件,读取更新后的Heat元件模板的内容;
步骤S2011,Heat元件,通知Nova元件更新虚拟资源实例集合Stack中的内容;
步骤S2012,Nova元件,收到来自Heat元件的通知后,进行虚拟资源实例集合Stack的扩展或缩减。
3.根据权利要求2所述的虚拟机房的混合式扩展方法,其特征在于,步骤S206,还包括:对系统中虚拟主机CPU使用率进行观测,每5分钟观测一次;预估工作负载采用以下公式:
Ft=Ft-1+α(At-1–Ft-1);
其中,Ft为第t期的预估工作负载;Ft-1为第t-1期的预估工作负载;At-1为第t-1期的真实工作负载;α为平滑系数,范围为0~1,由资料变化趋势决定最佳值,默认值为0.8。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210203851.0A CN114265671B (zh) | 2022-03-03 | 2022-03-03 | 虚拟机房的混合式扩展方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210203851.0A CN114265671B (zh) | 2022-03-03 | 2022-03-03 | 虚拟机房的混合式扩展方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN114265671A true CN114265671A (zh) | 2022-04-01 |
CN114265671B CN114265671B (zh) | 2022-06-07 |
Family
ID=80834016
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210203851.0A Active CN114265671B (zh) | 2022-03-03 | 2022-03-03 | 虚拟机房的混合式扩展方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114265671B (zh) |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103533063A (zh) * | 2013-10-18 | 2014-01-22 | 北京华胜天成科技股份有限公司 | 一种可实现web应用资源动态扩展的方法及装置 |
US20160094410A1 (en) * | 2014-09-30 | 2016-03-31 | International Business Machines Corporation | Scalable metering for cloud service management based on cost-awareness |
CN106961367A (zh) * | 2017-05-19 | 2017-07-18 | 济南浪潮高新科技投资发展有限公司 | 基于openstack的云资源监控系统和方法 |
CN107247651A (zh) * | 2017-05-09 | 2017-10-13 | 中国电子产品可靠性与环境试验研究所 | 云计算平台监测预警方法和系统 |
CN110677499A (zh) * | 2019-10-30 | 2020-01-10 | 北京普瑞华夏国际教育科技有限公司 | 一种云资源管理应用系统 |
CN111221655A (zh) * | 2020-01-08 | 2020-06-02 | 山东汇贸电子口岸有限公司 | 管理OpenStack平台的资源的方法及装置 |
WO2020158452A1 (ja) * | 2019-01-29 | 2020-08-06 | 日本電信電話株式会社 | 仮想化基盤および仮想化基盤のスケーリング管理方法 |
CN112527448A (zh) * | 2020-08-31 | 2021-03-19 | 中国银联股份有限公司 | 基于openstack的动态负载调整方法及其系统 |
-
2022
- 2022-03-03 CN CN202210203851.0A patent/CN114265671B/zh active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103533063A (zh) * | 2013-10-18 | 2014-01-22 | 北京华胜天成科技股份有限公司 | 一种可实现web应用资源动态扩展的方法及装置 |
US20160094410A1 (en) * | 2014-09-30 | 2016-03-31 | International Business Machines Corporation | Scalable metering for cloud service management based on cost-awareness |
CN107247651A (zh) * | 2017-05-09 | 2017-10-13 | 中国电子产品可靠性与环境试验研究所 | 云计算平台监测预警方法和系统 |
CN106961367A (zh) * | 2017-05-19 | 2017-07-18 | 济南浪潮高新科技投资发展有限公司 | 基于openstack的云资源监控系统和方法 |
WO2020158452A1 (ja) * | 2019-01-29 | 2020-08-06 | 日本電信電話株式会社 | 仮想化基盤および仮想化基盤のスケーリング管理方法 |
CN110677499A (zh) * | 2019-10-30 | 2020-01-10 | 北京普瑞华夏国际教育科技有限公司 | 一种云资源管理应用系统 |
CN111221655A (zh) * | 2020-01-08 | 2020-06-02 | 山东汇贸电子口岸有限公司 | 管理OpenStack平台的资源的方法及装置 |
CN112527448A (zh) * | 2020-08-31 | 2021-03-19 | 中国银联股份有限公司 | 基于openstack的动态负载调整方法及其系统 |
Non-Patent Citations (8)
Title |
---|
M.SCHARF ET AL.: "Network-Aware Instance Scheduling in OpenStack", 《2015 24TH INTERNATIONAL CONFERENCE ON COMPUTER COMMUNICATION AND NETWORKS》 * |
M.SCHARF ET AL.: "Network-Aware Instance Scheduling in OpenStack", 《2015 24TH INTERNATIONAL CONFERENCE ON COMPUTER COMMUNICATION AND NETWORKS》, 5 October 2015 (2015-10-05), pages 1 - 6 * |
廉震: "面向网络优化的云系统虚拟机调度机制研究", 《中国优秀硕士学位论文全文数据库-信息科技辑》 * |
廉震: "面向网络优化的云系统虚拟机调度机制研究", 《中国优秀硕士学位论文全文数据库-信息科技辑》, vol. 2020, no. 2, 15 February 2020 (2020-02-15), pages 137 - 22 * |
张乔: "基于OpenStack的业务云平台负载均衡策略的研究与实现", 《中国优秀硕士学位论文全文数据库-信息科技辑》 * |
张乔: "基于OpenStack的业务云平台负载均衡策略的研究与实现", 《中国优秀硕士学位论文全文数据库-信息科技辑》, vol. 2015, no. 4, 15 April 2015 (2015-04-15), pages 139 - 224 * |
文婷婷等: "基于OpenStack虚拟化网络管理平台的设计与实现", 《电子制作》, no. 10, 15 May 2019 (2019-05-15) * |
陆江东等: "基于云平台的虚拟化机房管理系统", 《四川兵工学报》, no. 12, 25 December 2013 (2013-12-25) * |
Also Published As
Publication number | Publication date |
---|---|
CN114265671B (zh) | 2022-06-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Yu et al. | Stochastic load balancing for virtual resource management in datacenters | |
CN108804227B (zh) | 基于移动云计算的计算密集型任务卸载和最佳资源配置的方法 | |
Zhang et al. | Energy-efficient workload allocation and computation resource configuration in distributed cloud/edge computing systems with stochastic workloads | |
US8843929B1 (en) | Scheduling in computer clusters | |
CN112579194B (zh) | 基于时延和事务吞吐量的区块链共识任务卸载方法及装置 | |
WO2005062533A1 (en) | System and method predicting and managing network capacity requirements | |
Adhikary et al. | Quality of service aware cloud resource provisioning for social multimedia services and applications | |
Li | An adaptive overload threshold selection process using Markov decision processes of virtual machine in cloud data center | |
JPWO2004092971A1 (ja) | サーバ割当制御方法 | |
Nie et al. | Energy-aware multi-dimensional resource allocation algorithm in cloud data center | |
Lu et al. | On the performance-driven load distribution for heterogeneous computational grids | |
Mohammadi Bahram Abadi et al. | Self-adaptive architecture for virtual machines consolidation based on probabilistic model evaluation of data centers in Cloud computing | |
Monshizadeh Naeen et al. | Adaptive Markov‐based approach for dynamic virtual machine consolidation in cloud data centers with quality‐of‐service constraints | |
Melhem et al. | Selection process approaches in live migration: A comparative study | |
CN108769253A (zh) | 一种分布式系统访问性能优化的自适应预取控制方法 | |
Rahmani et al. | Burst‐aware virtual machine migration for improving performance in the cloud | |
Saravanakumar et al. | A novel load balancing algorithm for computational grid | |
EP4068092A1 (en) | Managing computer workloads across distributed computing clusters | |
Zheng et al. | Dynamic load balancing and pricing in grid computing with communication delay | |
Durga et al. | Context-aware adaptive resource provisioning for mobile clients in intra-cloud environment | |
Zhang et al. | A Multi-Agent based load balancing framework in Cloud Environment | |
CN114265671B (zh) | 虚拟机房的混合式扩展方法 | |
Chatterjee et al. | A new clustered load balancing approach for distributed systems | |
Zhang et al. | An advanced load balancing strategy for cloud environment | |
CN115484167B (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 |