CN116775214A - 资源管理方法、装置及相关设备 - Google Patents
资源管理方法、装置及相关设备 Download PDFInfo
- Publication number
- CN116775214A CN116775214A CN202310740026.9A CN202310740026A CN116775214A CN 116775214 A CN116775214 A CN 116775214A CN 202310740026 A CN202310740026 A CN 202310740026A CN 116775214 A CN116775214 A CN 116775214A
- Authority
- CN
- China
- Prior art keywords
- service cluster
- average
- monitoring period
- current monitoring
- load
- 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.)
- Pending
Links
- 238000007726 management method Methods 0.000 title claims abstract description 43
- 238000012544 monitoring process Methods 0.000 claims abstract description 89
- 230000008602 contraction Effects 0.000 claims description 46
- 238000000034 method Methods 0.000 claims description 23
- 238000004891 communication Methods 0.000 claims description 6
- 238000012545 processing Methods 0.000 description 14
- 238000004364 calculation method Methods 0.000 description 10
- 238000004458 analytical method Methods 0.000 description 6
- 238000010586 diagram Methods 0.000 description 6
- 230000008569 process Effects 0.000 description 4
- 238000012217 deletion Methods 0.000 description 3
- 230000037430 deletion Effects 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000012935 Averaging Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Landscapes
- Debugging And Monitoring (AREA)
Abstract
本发明提供一种资源管理方法、装置及相关设备，属于云计算技术领域。该资源管理方法包括：获取当前监控周期下所述业务集群内的单个CPU核的平均负载；获取所述当前监控周期下的所述单个CPU核所能承载的平均任务数；在所述平均负载满足预设负载指标的情况下，基于所述平均任务数和所述当前监控周期下所述业务集群的总任务数，确定所述业务集群的伸缩策略所需的第一待扩缩的CPU核的数量。
Description
技术领域
本发明实施例涉及云计算技术领域，尤其涉及一种资源管理方法、装置及相关设备。
背景技术
基础设施云(Infrastructure as a Service，IAAS)可以为用户提供虚拟的计算资源、存储资源和网络资源。为了更高效、合理的分配和使用这些资源，基础设施云的管理员需要对这些资源的负载情况进行实时监控，且用户也需要了解其所得的虚拟资源的负载状态，比如当随负载升高增加资源，随负载降低减少资源，以满足不同场景业务需求。其中，弹性伸缩是一种可以根据用户的业务需求和预设策略，自动调整计算、存储以及网络资源来满足不同场景业务需求的计算资源管理服务。
目前，现有的弹性伸缩扩容策略大多是通过对虚拟机的中央处理器(CentralProcessing Unit，CPU)与内存利用率进行监控来实现。比如，当CPU与内存利用率达到设定阈值后，对伸缩组所管理的虚拟机扩容或缩容指定数量。在扩容或缩容指定数量的节点后，若CPU或内存利用率仍未达到目标阈值，则会继续扩容或缩容指定数量的节点，直至监控项达到指定阈值。
可见，现有的伸缩策略的扩缩容过程中，可能会需要多次进行扩缩容动作，进而影响伸缩策略的调整效率。
发明内容
本发明实施例提供一种资源管理方法、装置及相关设备，以解决相关技术中的伸缩策略存在的调整效率低的问题。
为解决上述问题，本发明是这样实现的：
第一方面，本发明实施例提供了一种资源管理方法，用于包括业务集群的终端，所述方法包括：
获取当前监控周期下所述业务集群内的单个CPU核的平均负载；
获取所述当前监控周期下的所述单个CPU核所能承载的平均任务数；
在所述平均负载满足预设负载指标的情况下，基于所述平均任务数和所述当前监控周期下所述业务集群的总任务数，确定所述业务集群的伸缩策略所需的第一待扩缩的CPU核的数量。
第二方面，本发明实施例提供了一种资源管理装置，用于包括业务集群的终端，所述装置包括：
第一获取模块，用于获取当前监控周期下所述业务集群内的单个CPU核的平均负载；
第二获取模块，用于获取所述当前监控周期下的所述单个CPU核所能承载的平均任务数；
第一确定模块，用于在所述平均负载满足预设负载指标的情况下，基于所述平均任务数和所述当前监控周期下所述业务集群的总任务数，确定所述业务集群的伸缩策略所需的第一待扩缩的CPU核的数量。
第三方面，本发明实施例提供一种终端，包括收发机和处理器，
所述处理器，用于：获取当前监控周期下业务集群内的单个CPU核的平均负载；在所述平均负载满足预设负载指标的情况下，获取所述当前监控周期下的所述单个CPU核所能承载的平均任务数；基于所述平均任务数和所述当前监控周期下所述业务集群的总任务数，确定所述业务集群的伸缩策略所需的第一待扩缩的CPU核的数量。
第四方面，本发明实施例还提供一种通信设备，包括：收发机、存储器、处理器及存储在所述存储器上并可在所述处理器上运行的程序；所述处理器，用于读取存储器中的程序实现如前述第一方面所述方法中的步骤。
第五方面，本发明实施例还提供一种可读存储介质，用于存储程序，所述程序被处理器执行时实现如前述第一方面所述方法中的步骤。
在本发明实施例中，通过获取当前监控周期下所述业务集群内的单个CPU核的平均负载；获取所述当前监控周期下的所述单个CPU核所能承载的平均任务数；在所述平均负载满足预设负载指标的情况下，基于所述平均任务数和所述当前监控周期下所述业务集群的总任务数，确定所述业务集群的伸缩策略所需的第一待扩缩的CPU核的数量。这样可以基于业务集群的总任务数和单个CPU核所能承载的平均任务数确定出业务集群的伸缩策略所需的第一待扩缩的CPU核的数量，从而实现伸缩策略所需的第一待扩缩的CPU核的数量的精确获取，以便可以通过一次精确的扩缩容将业务集群的CPU负载保持在指定负载的指定偏离范围内，减少扩缩容次数，达到提高伸缩策略的调整效率的目的。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本发明实施例提供的资源管理方法的流程示意图；
图2是本发明实施例提供的资源管理系统的结构图；
图3是本发明实施提供的资源管理装置的结构图；
图4是本发明实施提供的终端的结构图；
图5是本发明实施提供的通信设备的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
本发明实施例中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。此外，本发明中使用“和/或”表示所连接对象的至少其中之一，例如A和/或B和/或C，表示包含单独A，单独B，单独C，以及A和B都存在，B和C都存在，A和C都存在，以及A、B和C都存在的7种情况。
在本发明实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本发明实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
请参见图1，图1是本发明实施例提供的资源管理方法的流程示意图。图1所示的资源管理方法可以由终端执行，该终端包括业务集群。
其中，终端也可以称作用户设备(User Equipment，UE)，在实际应用中，终端可以是手机、平板电脑(Tablet Personal Computer)、膝上型电脑(Laptop Computer)、个人数字助理(Personal Digital Assistant，PDA)、移动上网装置(Mobile Internet Device，MID)、可穿戴式设备(Wearable Device)或车载设备等。
如图1所示，资源管理方法可以包括以下步骤：
步骤101、获取当前监控周期下所述业务集群内的单个CPU核的平均负载。
上述业务集群可以理解为将虚拟机封装为弹性伸缩管理的节点进行管理形成的业务集群模块，并可以通过对虚拟机进行标记来形成逻辑集群，从而方便对终端的计算资源进行弹性伸缩管理。
上述业务集群可以对多个虚拟机进行管理，每个虚拟机可以理解为一个节点，即上述业务集群可以对多个节点进行管理。
其中，每个节点可以包括一个或者多个CPU核，CPU核可以理解为一个中央处理器内部的处理核心，且一个中央处理器的内部可以包括一个或者多个处理核心。比如，四核处理器包括4个处理核心，八核处理器包括8个处理核心。
比如，业务集群中的第一节点的处理器为四核处理器，可以理解为第一节点的处理器包括4个处理器核心，即第一节点的处理器包括4个CPU核；相应地，业务集群中的第二节点的处理器为双核处理器，可以理解为第二节点的处理器包括2个处理器核心，即第二节点的处理器包括2个CPU核。
在步骤101之前，可以对业务集群内每个CPU的负载进行周期性监控，以便获取每个节点的负载，即获取业务集群内的包括的多个节点中的每个节点的负载。
可以理解的是，本发明中的负载可以理解为CPU的工作量，其反映了CPU正在执行的任务数量和复杂度；且负载越高，意味着CPU需要更多的计算资源来处理任务。
其中，在获取到每个节点的负载后，可以基于业务集群包括的节点数量以及每个节点所包括的CPU核的数量，计算得到业务集群内的单个CPU核的平均负载。
示例性地，可以通过公式(1)计算得到业务集群内的单个CPU核的平均负载；
其中，L表示业务集群内的单个CPU核的平均负载，Ln表示每个节点的负载，Nn表示每个节点的CPU核的数量，n表示业务集群中包括的节点的数量。
比如，业务集群包括第一节点、第二节点和第三节点，第一节点包括4个CPU核，第二节点包括2个CPU核，第三节点包括8个CPU核，且在当前监控周期内，第一节点的负载为L1，第二节点的负载为L2，第三节点的负载为L3，则业务集群内的单个CPU核的平均负载即可以得到业务集群内的单个CPU核的平均负载为/>
步骤102、获取所述当前监控周期下的所述单个CPU核所能承载的平均任务数。
上述平均负载满足预设负载指标可以理解为业务集群内的单个CPU核的平均负载超出预设指标范围，比如业务集群内的单个CPU核的平均负载超出预设的基准偏离值。
其中，可以基于业务集群的单个CPU核的平均负载确定单个CPU核所能承载的平均任务数。
比如，可以通过当前监控周期下的单个CPU核的平均负载以及历史监控周期下的单个CPU核的平均负载，计算得到当前监控周期下的业务集群内的单个CPU核所能承载的平均任务数。
步骤103、在所述平均负载满足预设负载指标的情况下，基于所述平均任务数和所述当前监控周期下所述业务集群的总任务数，确定所述业务集群的伸缩策略所需的第一待扩缩的CPU核的数量。
在平均负载满足预设负载指标的情况下，则可以确定需要对业务集群进行扩缩容处理以满足对业务集群的平均负载的要求。
其中，可以基于当前监控周期下的业务集群的监控信息，获取当前监控周期下的业务集群的总任务数，然后基于总任务数和单个CPU核所能承载的平均任务数确定业务集群的伸缩策略所需的第一待扩缩的CPU核的数量，从而实现伸缩策略所需的第一待扩缩的CPU核的数量的精确获取。
比如，单个CPU核所能承载的平均任务数与当前监控周期下的业务集群的总任务数在不改变业务集群的业务总数的情况下，可以将所有任务按照指定负载分配到各个节点，则可以确定出业务集群的伸缩策略所需的第一待扩缩的CPU核的数量。
示例性地，可以基于待扩缩的CPU核的数量计算公式： 其中，Naction表示业务集群的伸缩策略所需的第一待扩缩的CPU核的数量，Ttotal表示当前监控周期下的业务集群的总任务数，Texcept表示当前监控周期下的业务集群内的单个CPU核所能承载的平均任务数，Ncore表示当前监控周期下的业务集群内的CPU核的数量。
本实施方式中，可以基于业务集群的总任务数和单个CPU核所能承载的平均任务数确定出业务集群的伸缩策略所需的第一待扩缩的CPU核的数量，从而实现伸缩策略所需的第一待扩缩的CPU核的数量的精确获取，以便可以通过一次精确的扩缩容将业务集群的CPU负载保持在指定负载的指定偏离范围内，减少扩缩容次数，达到提高伸缩策略的调整效率的目的。
可选地，所述确定所述业务集群的伸缩策略所需的第一待扩缩的CPU核的数量之后，所述方法还包括：
基于所述第一待扩缩的CPU核的数量，确定待扩缩的节点的数量；
基于所述待扩缩的节点的数量，执行扩缩容伸缩策略，所述扩缩容伸缩策略是基于所述待扩缩的节点的数量确定的。
上述节点可以理解为不同规格(Flavor)云主机、磁盘等。
上述扩缩容伸缩策略包括扩缩荣时的节点创建与删除策略，具体可以包括成本优化策略、多可用区均衡、优先策略、删除策略等。
本实施方式中，可以基于前述步骤确定的第一待扩缩的CPU核的数量，通过对比每个节点包括的CPU核的数量，确定出待扩缩的节点的数量，从而实现节点的数量准确扩缩容，相对于现有的伸缩策略，有效的减少了扩缩容次数，并达到了提高伸缩策略的调整效率的目的。
比如，前述步骤中确定的第一待扩缩的CPU核的数量为16个，且Flavor中设置的每个节点包括的CPU核的数量为4个，则确定待扩缩的节点的数量为即待扩缩的节点的数量为4个，即在执行对应的扩缩容伸缩策略，需要扩容或者缩容4个节点，以满足不同场景业务需求的计算资源管理服务。
可选地，所述基于所述第一待扩缩的CPU核的数量，确定待扩缩的节点的数量，包括：
在历史扩缩容记录中包括与所述当前监控周期下对应的目标扩缩容记录的情况下，获取所述目标扩缩容记录中的第二待扩缩的CPU核的数量；
基于所述第一待扩缩的CPU核的数量和所述第二待扩缩的CPU核的数量，确定目标待扩缩的CPU核的数量；
基于所述目标待扩缩的CPU核的数量，确定待扩缩的节点的数量。
本实施方式中，可以基于第一待扩缩的CPU核的数量和目标扩缩容记录中的第二待扩缩的CPU核的数量，来确定目标待扩缩的CPU核的数量，以提高确定得到的目标待扩缩的CPU核的数量准确性，进而达到提高待扩缩的节点的数量的准确性的目的。
一些实施方式中，可以通过去平均值的方式，确定与第一待扩缩的CPU核的数量和目标扩缩容记录中的第二待扩缩的CPU核的数量对应的目标待扩缩的CPU核的数量。比如，在第一待扩缩的CPU核的数量为8个，目标扩缩容记录中的第二待扩缩的CPU核的数量为4个的情况下，则可以确定目标待扩缩的CPU核的数量为即确定目标待扩缩的CPU核的数量为6个。
可以理解的是，在历史扩缩容记录中未包括与当前监控周期下的扩缩容场景对应的目标扩缩容记录的情况下，则可以直接将第一待扩缩的CPU核的数量确定为目标待扩缩的CPU核的数量。
所述获取当前监控周期下所述业务集群内的单个CPU核的平均负载之后，所述获取所述当前监控周期下的所述单个CPU核所能承载的平均任务数之前，所述方法还包括：
在预设时间内，所述平均负载与预设负载的差值大于预设偏离值的次数超过预设次数的情况下，则确定所述平均负载满足预设负载指标。
本实施方式中，通过基于次数判定的方式，确定平均负载是否满足预设负载指标，可以降低偶尔因素对业务集群的伸缩策略的干扰影响。
具体地，在平均负载与预设负载的差值大于预设偏离值时，且预设时间内差值大于预设偏离值的次数大于预设次数，比如10次，则可以确定当前监控周期内的平均负载满足预设负载指标，并需要通过扩缩容的方式将业务集群的CPU负载保持在指定负载的指定偏离范围内，以满足不同场景业务需求的计算资源管理服务。
比如，在|L-Lexcept|＞x的情况下，则可以平均负载与预设负载的差值大于预设偏离值，其中，L表示平均负载，即业务集群内的单个CPU核的平均负载；Lexcept表示预设负载，x表示预设偏离值。
可以理解的是，上述Lexcept和x可以基于用户需求进行设定。
可选地，所述获取所述当前监控周期下的所述单个CPU核所能承载的平均任务数，包括：
获取上一个监控周期下所述业务集群内的单个CPU核的平均负载，并标记为第一平均负载；
将所述当前监控周期下所述业务集群内的单个CPU核的平均负载标记为第二平均负载；
基于所述第一平均负载、所述第二平均负载及衰减因子确定所述当前监控周期下的所述单个CPU核所能承载的平均任务数。
本实施方式中，可以基于第一平均负载和第二平均负载确定在当前监控周期下的单个CPU核所能承载的平均任务数。
比如，在Linux操作系统下，可以基于CPU负载计算公式：Li＝Li-1*e+Ti(1-e)，即通过Li、Li-1和e，计算得到Ti，从而实现当前监控周期下的单个CPU核所能承载的平均任务数的计算。其中，Li表示当前监控周期下的单个CPU核的平均负载；Li-1表示监控周期下的单个CPU核的平均负载；e表示衰减因子，且不同操作系统实际值不同；Ti表示当前监控周期下的单个CPU核所能承载的平均任务数。
本发明实施例提供的资源管理方法，可以手动设定业务集群的预设负载和预设偏离值，且在当前监控周期内的单核CPU的平均负载与预设负载的差值大于预设偏离值的情况下，可以通过CPU负载及当前CPU核内队列中排队的任务进行计算，并可以根据1，5，15分钟等多种时间段内CPU的平均负载评估出将当前监控周期内的业务集群的平均CPU负载调整到对应值所需要调整的任务数，并将任务数转换为需要调整的CPU核数进行记录。
另外，可以针对特定的业务集群进行记录与学习后估算出业务集群需要调整的节点数量，从而对业务集群通过一次精确的扩缩容来满足对业务集群平均负载的要求。
本发明实施例提供的资源管理方法，通过获取当前监控周期下所述业务集群内的单个CPU核的平均负载；获取所述当前监控周期下的所述单个CPU核所能承载的平均任务数；在所述平均负载满足预设负载指标的情况下，基于所述平均任务数和所述当前监控周期下所述业务集群的总任务数，确定所述业务集群的伸缩策略所需的第一待扩缩的CPU核的数量。这样可以基于业务集群的总任务数和单个CPU核所能承载的平均任务数确定出业务集群的伸缩策略所需的第一待扩缩的CPU核的数量，从而实现伸缩策略所需的第一待扩缩的CPU核的数量的精确获取，以便可以通过一次精确的扩缩容将业务集群的CPU负载保持在指定负载的指定偏离范围内，减少扩缩容次数，达到提高伸缩策略的调整效率的目的。
请参见图2，图2是本发明实施例提供的资源管理系统的结构图。如图2所示，该资源管理系统包括业务集群模块21、负载管理模块22和告警处理模块23。
业务集群模块21可以理解为将虚拟机封装为弹性伸缩管理的节点进行管理形成的业务集群模块，通过对虚拟机进行标记来形成逻辑集群，方便弹性伸缩管理。
负载管理模块22包括负载监控子模块、阈值计算子模块和告警触发子模块，其中：
负载监控子模块，用于对业务集群内节点每个CPU的负载进行周期性监控，并向阈值计算子模块发送监控数据，由阈值计算子模块对接收到的监控数据进行初步处理；
阈值计算子模块，用于收到来自负载监控子模块的监控数据后，根据业务集群的实际情况，判断是否进行告警。判断是否告警的具体计算方法如下：根据集群内CPU核数与节点数量计算集群内单个CPU核的平均负载。当单个CPU核的平均负载超出预设指标范围(CPU负载最大值与最小值)N次时，向负载分析模块发出分析请求，请求中包括每台节点的CPU核数、每台节点的每个CPU的负载等信息；
告警触发子模块，用于在阈值计算子模块判断确实需要进行告警时，就会通过该子模块对负载分析模块发出告警请求。
告警处理模块23包括告警记录子模块、负载分析子模块和节点伸缩子模块，其中：
告警记录子模块，用于记录告警触发时某个比例负载调整的节点数量，为负载分析子模块提供计算依据；
负载分析子模块，主要用于对告警数据进行处理、分析，并对伸缩的节点数进行计算。首先是判断业务集群是否可以执行业务集群节点的伸缩操作，若可以继续进行伸缩操作，那么开始计算伸缩的节点数；
节点伸缩子模块，涉及伸缩配置和伸缩策略两个单元；
其中，伸缩配置单元，用于为伸缩组创建节点的模板，支持创建多种规格的云主机、磁盘，支持多种节点登录方式、安全配置等等信息；伸缩策略单元，用于为伸缩组扩缩容时的节点创建与删除策略，包括成本优化策略、多可用区均衡、优先策略、删除策略等。
本发明实施例提供的资源管理方法，通过计算业务集群内CPU核数的调整，再配合伸缩配置与伸缩策略，通过一次精确的扩缩容始终将业务集群的CPU负载保持在指定负载的指定偏离范围内，减少扩缩容次数，在短时间内满足业务指标，降低使用者的成本。业务集群内节点数量调整次数少，并且精确。
此外，本发明中的涉及的节点数量调整算法及告警触发逻辑可以被用在弹性负载均衡器的健康监控功能中，也可以被用在其他类似弹性伸缩的业务集群的监控管理方法中。
本发明实施例中介绍的多种可选的实施方式，在彼此不冲突的情况下可以相互结合实现，也可以单独实现，对此本发明实施例不作限定。
参见图3，图3是本发明实施例提供的资源管理装置的结构图。如图3所示，资源管理装置300包括：
第一获取模块301，用于获取当前监控周期下所述业务集群内的单个CPU核的平均负载；
第二获取模块302，用于获取所述当前监控周期下的所述单个CPU核所能承载的平均任务数；
第一确定模块303，用于在所述平均负载满足预设负载指标的情况下，基于所述平均任务数和所述当前监控周期下所述业务集群的总任务数，确定所述业务集群的伸缩策略所需的第一待扩缩的CPU核的数量。
可选地，所述资源管理装置300还包括：
第二确定模块，用于基于所述第一待扩缩的CPU核的数量，确定待扩缩的节点的数量；
执行模块，用于基于所述待扩缩的节点的数量，执行扩缩容伸缩策略，所述扩缩容伸缩策略是基于所述待扩缩的节点的数量确定的。
可选地，所述第二确定模块，包括：
获取单元，用于在历史扩缩容记录中包括与所述当前监控周期下对应的目标扩缩容记录的情况下，获取所述目标扩缩容记录中的第二待扩缩的CPU核的数量；
第一确定单元，用于基于所述第一待扩缩的CPU核的数量和所述第二待扩缩的CPU核的数量，确定目标待扩缩的CPU核的数量；
第二确定单元，用于基于所述目标待扩缩的CPU核的数量，确定待扩缩的节点的数量。
可选地，所述资源管理装置300还包括：
第三确定模块，用于在预设时间内，所述平均负载与预设负载的差值大于预设偏离值的次数超过预设次数的情况下，则确定所述平均负载满足预设负载指标。
可选地，所述第二获取模块302，包括：
第一标记单元，用于获取上一个监控周期下所述业务集群内的单个CPU核的平均负载，并标记为第一平均负载；
第二标记单元，用于将所述当前监控周期下所述业务集群内的单个CPU核的平均负载标记为第二平均负载；
第三确定单元，用于基于所述第一平均负载、所述第二平均负载及衰减因子确定所述当前监控周期下的所述单个CPU核所能承载的平均任务数。
资源管理装置300能够实现本发明实施例中图1方法实施例的各个过程，以及达到相同的有益效果，为避免重复，这里不再赘述。
具体的，参见图4，本发明实施例还提供了一种电子设备，包括总线401、收发机402、天线403、总线接口404、处理器405和存储器406。
其中，所述处理器405，用于：获取当前监控周期下业务集群内的单个CPU核的平均负载；获取所述当前监控周期下的所述单个CPU核所能承载的平均任务数；在所述平均负载满足预设负载指标的情况下，基于所述平均任务数和所述当前监控周期下所述业务集群的总任务数，确定所述业务集群的伸缩策略所需的第一待扩缩的CPU核的数量。
可选地，所述处理器405，用于：基于所述第一待扩缩的CPU核的数量，确定待扩缩的节点的数量；基于所述待扩缩的节点的数量，执行扩缩容伸缩策略，所述扩缩容伸缩策略是基于所述待扩缩的节点的数量确定的。
可选地，所述处理器405，用于：在历史扩缩容记录中包括与所述当前监控周期下对应的目标扩缩容记录的情况下，获取所述目标扩缩容记录中的第二待扩缩的CPU核的数量；基于所述第一待扩缩的CPU核的数量和所述第二待扩缩的CPU核的数量，确定目标待扩缩的CPU核的数量；基于所述目标待扩缩的CPU核的数量，确定待扩缩的节点的数量。
可选地，所述处理器405，用于：在预设时间内，所述平均负载与预设负载的差值大于预设偏离值的次数超过预设次数的情况下，则确定所述平均负载满足预设负载指标。
可选地，所述处理器405，用于：获取上一个监控周期下所述业务集群内的单个CPU核的平均负载，并标记为第一平均负载；将所述当前监控周期下所述业务集群内的单个CPU核的平均负载标记为第二平均负载；基于所述第一平均负载、所述第二平均负载及衰减因子确定所述当前监控周期下的所述单个CPU核所能承载的平均任务数。
在图4中，总线架构(用总线401来代表)，总线401可以包括任意数量的互联的总线和桥，总线401将包括由处理器405代表的一个或多个处理器和存储器406代表的存储器的各种电路链接在一起。总线401还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口404在总线401和收发机402之间提供接口。收发机402可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器405处理的数据通过天线403在无线介质上进行传输，进一步，天线403还接收数据并将数据传送给处理器405。
处理器405负责管理总线401和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器406可以被用于存储处理器405在执行操作时所使用的数据。
可选的，处理器405可以是中央处理器(Central Processing Unit，CPU)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程逻辑门阵列(Field Programmable Gate Array，FPGA)或复杂可编程逻辑器件(Complex ProgrammableLogic Device，CPLD)。
本发明实施例还提供一种通信设备。请参见图5，通信设备可以包括处理器501、存储器502及存储在存储器502上并可在处理器501上运行的程序5021。
在通信设备为终端的情况下，程序5021被处理器501执行时可实现图1对应的方法实施例中的任意步骤及达到相同的有益效果，此处不再赘述。
本领域普通技术人员可以理解实现上述实施例方法的全部或者部分步骤是可以通过程序指令相关的硬件来完成，所述的程序可以存储于一可读取介质中。
本发明实施例还提供一种可读存储介质，所述可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时可实现上述图1对应的方法实施例中的任意步骤，且能达到相同的技术效果，为避免重复，这里不再赘述。
所述的存储介质，如只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等。
以上所述是本发明实施例的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明所述原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。
Claims (10)
1.一种资源管理方法，用于包括业务集群的终端，其特征在于，所述方法包括：
获取当前监控周期下所述业务集群内的单个CPU核的平均负载；
获取所述当前监控周期下的所述单个CPU核所能承载的平均任务数；
在所述平均负载满足预设负载指标的情况下，基于所述平均任务数和所述当前监控周期下所述业务集群的总任务数，确定所述业务集群的伸缩策略所需的第一待扩缩的CPU核的数量。
2.根据权利要求1所述的方法，其特征在于，所述确定所述业务集群的伸缩策略所需的第一待扩缩的CPU核的数量之后，所述方法还包括：
基于所述第一待扩缩的CPU核的数量，确定待扩缩的节点的数量；
基于所述待扩缩的节点的数量，执行扩缩容伸缩策略，所述扩缩容伸缩策略是基于所述待扩缩的节点的数量确定的。
3.根据权利要求2所述的方法，其特征在于，所述基于所述第一待扩缩的CPU核的数量，确定待扩缩的节点的数量，包括：
在历史扩缩容记录中包括与所述当前监控周期下对应的目标扩缩容记录的情况下，获取所述目标扩缩容记录中的第二待扩缩的CPU核的数量；
基于所述第一待扩缩的CPU核的数量和所述第二待扩缩的CPU核的数量，确定目标待扩缩的CPU核的数量；
基于所述目标待扩缩的CPU核的数量，确定待扩缩的节点的数量。
4.根据权利要求1至3中任一项所述的方法，其特征在于，所述获取当前监控周期下所述业务集群内的单个CPU核的平均负载之后，所述获取所述当前监控周期下的所述单个CPU核所能承载的平均任务数之前，所述方法还包括：
在预设时间内，所述平均负载与预设负载的差值大于预设偏离值的次数超过预设次数的情况下，则确定所述平均负载满足预设负载指标。
5.根据权利要求1至3中任一项所述的方法，其特征在于，所述获取所述当前监控周期下的所述单个CPU核所能承载的平均任务数，包括：
获取上一个监控周期下所述业务集群内的单个CPU核的平均负载，并标记为第一平均负载；
将所述当前监控周期下所述业务集群内的单个CPU核的平均负载标记为第二平均负载；
基于所述第一平均负载、所述第二平均负载及衰减因子确定所述当前监控周期下的所述单个CPU核所能承载的平均任务数。
6.一种资源管理装置，用于包括业务集群的终端，其特征在于，所述装置包括：
第一获取模块，用于获取当前监控周期下所述业务集群内的单个CPU核的平均负载；
第二获取模块，用于获取所述当前监控周期下的所述单个CPU核所能承载的平均任务数；
第一确定模块，用于在所述平均负载满足预设负载指标的情况下，基于所述平均任务数和所述当前监控周期下所述业务集群的总任务数，确定所述业务集群的伸缩策略所需的第一待扩缩的CPU核的数量。
7.根据权利要求6所述的装置，其特征在于，所述装置还包括：
第二确定模块，用于基于所述第一待扩缩的CPU核的数量，确定待扩缩的节点的数量；
执行模块，用于基于所述待扩缩的节点的数量，执行扩缩容伸缩策略，所述扩缩容伸缩策略是基于所述待扩缩的节点的数量确定的。
8.一种终端，其特征在于，包括收发机和处理器，
所述处理器，用于：获取当前监控周期下业务集群内的单个CPU核的平均负载；在所述平均负载满足预设负载指标的情况下，获取所述当前监控周期下的所述单个CPU核所能承载的平均任务数；基于所述平均任务数和所述当前监控周期下所述业务集群的总任务数，确定所述业务集群的伸缩策略所需的第一待扩缩的CPU核的数量。
9.一种通信设备，包括：收发机、存储器、处理器及存储在所述存储器上并可在所述处理器上运行的程序；其特征在于，所述处理器，用于读取存储器中的程序实现如权利要求1至5中任一项所述的资源管理方法中的步骤。
10.一种可读存储介质，用于存储程序，其特征在于，所述程序被处理器执行时实现如权利要求1至5中任一项所述的资源管理方法中的步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310740026.9A CN116775214A (zh) | 2023-06-21 | 2023-06-21 | 资源管理方法、装置及相关设备 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310740026.9A CN116775214A (zh) | 2023-06-21 | 2023-06-21 | 资源管理方法、装置及相关设备 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116775214A true CN116775214A (zh) | 2023-09-19 |
Family
ID=87987397
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310740026.9A Pending CN116775214A (zh) | 2023-06-21 | 2023-06-21 | 资源管理方法、装置及相关设备 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116775214A (zh) |
-
2023
- 2023-06-21 CN CN202310740026.9A patent/CN116775214A/zh active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108924221B (zh) | 分配资源的方法和装置 | |
| US10289973B2 (en) | System and method for analytics-driven SLA management and insight generation in clouds | |
| JP5218390B2 (ja) | 自律制御サーバ、仮想サーバの制御方法及びプログラム | |
| CN107247651B (zh) | 云计算平台监测预警方法和系统 | |
| US9354938B2 (en) | Sequential cooperation between map and reduce phases to improve data locality | |
| WO2017128980A1 (zh) | 云平台中管理资源的方法和装置 | |
| CN111478857B (zh) | 一种接口限流控制方法、装置以及电子设备 | |
| CN104901989B (zh) | 一种现场服务提供系统及方法 | |
| CN109981744B (zh) | 数据的分发方法、装置、存储介质及电子设备 | |
| CN112689007B (zh) | 资源分配方法、装置、计算机设备和存储介质 | |
| JP2023511327A (ja) | モデル訓練方法および装置 | |
| CN108540568B (zh) | 计算能力共享方法及智能设备 | |
| CN111431996B (zh) | 用于资源配置的方法、装置、设备和介质 | |
| CN109831524A (zh) | 一种负载均衡处理方法及装置 | |
| US20160080267A1 (en) | Monitoring device, server, monitoring system, monitoring method and program recording medium | |
| US11750711B1 (en) | Systems and methods for adaptively rate limiting client service requests at a blockchain service provider platform | |
| EP3499818B9 (en) | Method and device for load processing | |
| CN114500339B (zh) | 一种节点带宽监测方法、装置、电子设备及存储介质 | |
| CN116225696B (zh) | 用于流处理系统的算子并发度调优方法及装置 | |
| CN114780244A (zh) | 容器云资源弹性分配方法、装置、计算机设备及介质 | |
| CN113934545A (zh) | 一种视频数据调度方法、系统、电子设备及可读介质 | |
| CN113032410A (zh) | 数据处理方法、装置、电子设备及计算机存储介质 | |
| US20230060623A1 (en) | Network improvement with reinforcement learning | |
| US9501321B1 (en) | Weighted service requests throttling | |
| CN116841753A (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 |