具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。
实施例一
本申请实施例提供的方案可应用于任何具有数据传输和处理能力的系统,例如网络服务器等等。图1为本申请实施例提供的资源性能预估方案的应用场景示意图,图1所示的场景仅仅是本申请的技术方案可以应用的场景的示例之一。
随着云技术的发展,越来越多应用实例可以在运行在由多个单机通过互联网连接而构成的云服务器上,特别是在云服务器上的各种虚拟机上来运行。在这样的情况下,为用户提供云服务的单机的硬件规格就成为影响实际运行用户的应用程序的计算任务的主要因素。为此,为了满足日益增加的云计算需求,云服务提供商也需要不断的更新单机的硬件设备,但是由于硬件的更新不仅仅是指标数值上的增加,更是性能上的提升,为此,云服务系统,尤其是云服务的管理软件也需要相应地更新以能够匹配新硬件的性能,尤其是需要了解硬件配置或规格上的变化情况,从而软件层面能够在执行硬件调度时进行相应的调整以避免硬件资源浪费或性能受损的情况。
现有技术中已经提出了在各个服务器上设置有硬件情况采集模块,来在操作系统层面采集系统运行状况,从而获得硬件的使用情况,例如处理器占用率和/或存储空间占用率等,但是这样的使用情况的数据只能在一定程度上反映服务器的硬件情况,或者说使用情况,而无法使得服务器基于系统的硬件规格而真正了解硬件的使用情况,因此在服务器根据这样的使用情况进行硬件资源调度时就无法根据真实的实际硬件规格来充分利用硬件的性能。
具体地,现有技术中通常通过在线采集实时的系统信息,来获取例如处理器占用率和/或存储空间占用率等数据,从而通过调度来提升当前硬件的利用率,但是这样的方案由于并非是基于硬件的真实规格性能而做出的,因此,这样的方案只适合于当前的硬件环境,尤其是当硬件规格发生变化或者新增硬件时,这样方案就无法适配硬件的变化或新硬件的演进。
例如,在云计算的场景下,传统的固定规格的虚拟机,例如4核8GB存储空间,已经逐渐演变为规格不确定的灵活配比的实例。例如,单实例可以为0.5甚至0.25核,以满足日益多样化的云计算任务的需求。在这样的情况下,单服务器上的虚拟机部署密度就有可能达到200或甚至更高,为此,云服务提供商就需要以非常精确而且灵活的方式来实施服务器的硬件资源的调度。
为此,如图1中所示,在由两个服务器A和B构成的云服务系统中,现有技术中在每个服务器上都设置有硬件画像模块,用于通过例如系统层面的采集方式来获取服务器的硬件画像,即在系统层面采集硬件的使用率,例如处理器占用率和/或内存或存储空间占用率等,以便于提供给BMC(BaseboardManagerController,基板管理控制器)进行硬件资源的调度分配。但是现有技术中由于只能通过软件在操作系统层面进行画像采集,其只能反映资源占用率,并不能够采集到实际的性能规格,并且特别是在新增加服务器B导致引入了不同的硬件型号时,BMC无法基于真实的硬件规格数据结合当前的占用率来例如计算服务器的单机容量。
例如,当在当前服务器系统中设置有服务器A和服务器B,并且服务器A为2018年的服务器规格,并且服务器B为新购置的2020年的服务器规格,因此,在硬件配置上存在着较大的差异。因此,当在2020年新增了服务器B之后例如为了规划调度方案而进行服务器系统的容量估计时,在现有技术中只能够通过手动或实际测试的方式来通过测试数据推断出硬件规格或状况,或者如图1中所示,通过设置在服务器中的画像模块来对硬件规格进行画像,实际上也是从操作系统层面来获取硬件的使用率,从而从侧面了解硬件的状况,进而基于这样获取的硬件状况来进行容量估计等操作。
但是这样的现有技术的方案由于都无法获取真正的硬件规格或者说实际的硬件规格,而只能从侧面通过硬件的运行数据来推测或了解硬件的规格,因此难以准确地确定硬件的规格,从而在基于这样推测获得的硬件规格或使用情况来确定的资源调度方案或容量估计就也难以准确。
为此,如图1中所示的场景中,本申请实施例中的资源性能预估方案,在服务器A和服务器B中均设置有硬件性能采集模块,并且在服务器A和服务器B的BMC中内置的存储空间中存储该服务器的性能数据以及评估策略表。例如,性能数据可以是该服务器的硬件规格信息,例如,服务器A的性能数据可以为,第六代8核CPU、16GB的内存空间,并且服务器B的性能数据可以为,第八代16核CPU、32GB的内存空间。因此,在服务器A和B的BMC的存储空间中可以预先存储有该数据,例如,该数据可以是在服务器A和服务器B出厂时就预先写入。此外,评估策略可以是描述服务器上的硬件以及各种负载对于性能的消耗情况的数据。例如,由负载类型、负载描述、负载指标和/或负载性能消耗,例如CPU/内存等资源消耗指标等。当图1中所示的服务器B被新加入到图1中所示的云服务系统中时,在现有技术中只能够通过手动测试的方式来在系统层面采集硬件的使用情况,从而推断服务器B的硬件规格以及相应的评估策略。
但是如上所述,这样的手动测试采集的方案不仅需要耗费资源来进行测试,更重要的是这样的方案由于只能够通过采集服务器B在例如作为测试的实际使用时的系统层面的资源情况来获得对于服务器B的性能的了解,并且将这样的测试数据作为服务器B的硬件性能规格来进行系统性能的评估,例如,容量评估等。但是这样的间接数据只能在一定程度上反映服务器B的性能而并不能够准确地让系统了解服务器B的真实硬件规格,从而这样的间接数据势必导致基于其进行的系统性能或者容量的评估不准确。
在本申请实施例中,通过在服务器中的预定空间中预先写入服务器的硬件规格信息,并且在该服务器在系统上线或者上线之前就可以通过访问该空间来直接获取到最准确的系统性能,尤其是系统的规格,从而系统就可以基于这样的直接反映系统性能规格指标的数据来进行系统评估。例如,系统可以采用各种预定的评估方案或策略来确定新加入服务器之后的系统的性能指标。
例如,在如图1中所示的场景中,当包括服务器A和新加入的服务器B的系统需要进行容量估计时,由于在本申请实施例中,服务器A和服务器B中可以提供一个预设的存储空间,例如,可以在服务器的BMC(BaseboardManagerController,基板管理控制器)中预设这样一个存储空间来存储服务器的性能规格(例如,CPU、内存的规格)以及针对该服务器的一些评估策略,例如容量估计策略。这些性能规格和评估策略可以在该服务器出厂时预先写入,或者也可以在服务器被购买后由系统服务商在初始化该服务器时写入。特别是针对该服务器的各种评估策略由于涉及该服务器的实际使用,因此可以由服务器的生厂商在出厂时预置一些通用的评估策略,并且还可以在服务器由服务提供商购买之后,由服务提供商根据该服务器的实际使用目的和系统的当前状况而写入符合自己使用实际的评估策略。
此外,在本申请实施例中,服务器中还预置有评估代理模块。该评估代理模块可以在系统运行需要进行评估时,从上述预置的存储空间中获取服务器A和服务器B的性能规格数据,例如,可以获取到服务器A的性能数据为,第六代8核CPU、16GB的内存空间,并且服务器B的性能数据为,第八代16核CPU、32GB的内存空间,并且还可以相应地分别获取服务器A和服务器B的上述空间中预先存储的评估策略,例如,容量策略。从而云服务系统的调度服务器可以分别与服务器A和服务器B的该评估代理模块A1和B1进行通信以获取对应的性能规格数据和评估策略,并且从而该调度服务器可以使用云服务系统当前的评估算法,例如,在评估容量时可以使用容量估计算法来根据当前服务器A和服务器B以及负载情况确定新的调度方案,并且根据该新的调度方案来确定新的容量估计结果。
此外,在本申请实施例中,在根据服务器的实际性能数据来评估资源性能的情况下,还能够进一步生成服务器性能调整方案,并且输出给相关管理方,以便于管理方能够根据本申请的方案所生成的性能调整方案来进行硬件补充,例如,在上述服务器A和服务器B的评估过程中,本申请方案除了给出服务器A和服务器B的调度方案之外,还可以生成对于服务器A的性能调整建议,例如,增加服务器A的内存控件至32GB,或者更换服务器A的CPU为第七代或第八代CPU,从而以实现整体性能的提升。此外,根据本申请的性能评估方案由于可以根据服务器的实际性能以及负载情况来进行服务器容量的实时评估,因此可以在这样的实时评估的基础上定期生成服务器性能调整建议方案,并且输出给服务器管理方或者计算服务的运营方来参考,从而实现服务器性能的定期更新。
因此,根据本申请实施例的资源性能预估方案,可以直接获取多个服务器的实际性能数据,并且根据获取到的实际性能数据来进行资源性能预估结果的计算,从而确定调度方案,因此大大提高了资源性能预估的准确性和效率。
上述实施例是对本申请实施例的技术原理和示例性的应用框架的说明,下面通过多个实施例来进一步对本申请实施例具体技术方案进行详细描述。
实施例二
图2为本申请提供的资源性能预估方法一个实施例的流程图,该方法的执行主体可以为具有资源性能评估能力的各种终端或服务器设备,也可以为集成在这些设备上的装置或芯片。如图2所示,该资源性能预估方法包括如下步骤:
S201,获取多个服务器中至少一个目标服务器的资源信息。
在本申请实施例中,资源性能预估方法可以用于预计或估计由多个服务器构成的服务器系统的性能,或者也可以用于估计或预计由多个计算单元通过数据线或其他通信方式连接在一起而构成的计算装置或系统的性能。在本申请实施例中,以估计由多个服务器构成的服务器系统作为示例来阐述本申请的技术构思。当然,对于本领域技术人员来说能够理解的是,本申请的资源性能预估方法不限于本申请实施例中示出的服务器系统或者计算装置,其可以应用于各种由多个硬件单元构成的系统或装置。
在本申请实施例的资源性能评估方法中,可以首先在步骤S201中获取服务器系统中的多个服务器中的至少一个目标服务器的资源信息。在本申请实施例中,目标服务器可以是构成服务器系统的多个服务器中的一个,并且特别地可以是该服务器系统中相对于其他服务器较新的一个,或者是新加入到该服务器系统中的服务器。换言之,在服务器系统的运行过程中,服务器系统的调度模块或调度中心需要根据构成该系统的各个服务器的硬件规格和使用情况来进行资源调度,通常这样的资源调度是通过基于服务器的硬件规格和使用情况的历史数据而对未来一段时间内硬件资源使用情况的预估而制定出多个资源分配策略。例如,在调度中心或调度模块中可以存储有这样的策略表,其中可以预先指定对于何种类型的计算任务应该分配多少数量的计算资源,更具体地可以预先指定采用多个服务器的何种组合来实现所需数量的计算资源。
因此,在实际运行时,当检测到预定类型的计算负载时,或者服务器系统的任务负载达到了策略中预先指定的阈值之后,就可以及时按照策略中制定的分配方案来进行资源的调配。但是这样的调度策略由于是预先制定的,因此,当例如如上所述新增了服务器或者新对某个服务器的硬件配置进行了升级时,预先制定的调度策略的依据就发生了变化,例如,在新增了服务器的情况下,可供调度的硬件资源变多并且服务器整体性能也变得更高,因此,在面对同样的负载的情况下,之前如果需要两个服务器协作才能实现所需的资源量,那么可能仅适用新增的服务器单独就可以实现。因此,就需要根据资源信息的变化来确定这样的策略,即对策略进行更新。因此,在本申请实施例中,可以在步骤S201中先从目标服务器获取在该服务器的预定存储空间中存储的资源信息。例如,可以在该服务器的BMC(BaseboardManagerController,基板管理控制器)中提供该存储空间来存储资源信息,当然也可以以其他方式来提供该存储空间以存储资源信息,只要该存储空间能够是针对各个服务器独立服务的。例如,在本申请实施例中,可以在相对于服务器独立的存储介质,例如外接存储器(闪存或USB存储装置)上提供该存储空间。
此外,在本申请实施例中,资源信息可以至少包括有该服务器的性能规格信息,例如,该服务器的硬件信息,例如CPU频率及核数、内存性能及规格等等。并且这些信息可以是在服务器出厂时由设备制造方写入到该服务器的预定存储空间中,或者也可以在由服务系统的运营方在购买了该服务器之后例如在将该服务器上线时写入到该存储空间中。
S202,根据服务器系统的任务负载和与硬件性能规格数据对应的使用量数据确定任务负载与资源性能的变化关系。
在步骤S201中获取到了服务器的资源信息之后,可以在步骤S202中进一步根据该资源信息,尤其是该资源信息中的性能规格信息,即硬件信息对应的使用量数据,来确定任务负载与资源性能的对应关系,即性能估计算法。例如,在根据资源信息确定了性能规格之后,就可以通过与该性能规格对应的使用量数据,例如,在何种负载的情况下消耗多少的硬件资源。从而根据负载情况与使用量数据来挑选适合于步骤S201中获取到的性能规格的性能估计算法。
S203,使用变化关系生成针对目标服务器的资源性能在预定的预估时间内的变化的预估结果。
在步骤S203中可以使用步骤S202中所确定的变化关系,即估计算法来生成未来一定时间,即预估时间内的资源性能随负载的变化情况,从而生成预估结果。该预估结果可以是对未来一段时间内硬件资源使用情况的预估而制定出的多个资源分配策略。例如,在调度中心或调度模块中可以存储有这样的策略表,其中可以预先指定对于何种类型的计算任务应该分配多少数量的计算资源,更具体地可以预先指定采用多个服务器的何种组合来实现所需数量的计算资源。因此,在实际运行时,当检测到预定类型的计算负载时,或者服务器系统的任务负载达到了策略中预先指定的阈值之后,就可以及时按照策略中制定的分配方案来进行资源的调配。
因此,本申请实施例提供的根据本申请实施例的资源性能预估方案,可以直接获取多个服务器的实际性能数据,并且根据获取到的实际性能数据来进行资源性能预估结果的计算,从而确定调度方案,因此大大提高了资源性能预估的准确性和效率。
实施例三
图3为本申请提供的资源性能预估方法另一个实施例的流程图,该方法的执行主体可以为具有资源性能预估能力的各种终端或服务器设备,也可以为集成在这些设备上的装置或芯片。如图3所示,该资源性能预估方法包括如下步骤:
S301,获取多个服务器中至少一个目标服务器的资源信息。
S302,获取目标服务器运行时在目标服务器上运行的任务所使用的资源的使用量数据。
在本申请实施例中,资源性能预估方法可以用于预计或估计由多个服务器构成的服务器系统的性能,或者也可以用于估计或预计由多个计算单元通过数据线或其他通信方式连接在一起而构成的计算装置或系统的性能。在本申请实施例中,以估计由多个服务器构成的服务器系统作为示例来阐述本申请的技术构思。当然,对于本领域技术人员来说能够理解的是,本申请的资源性能预估方法不限于本申请实施例中示出的服务器系统或者计算装置,其可以应用于各种由多个硬件单元构成的系统或装置。
在本申请实施例中,目标服务器可以是构成服务器系统的多个服务器中的一个,并且特别地可以是该服务器系统中相对于其他服务器较新的一个,或者是新加入到该服务器系统中的服务器。在服务器系统的运行过程中,服务器系统的调度模块或调度中心需要根据构成该系统的各个服务器的硬件规格和使用情况来进行资源调度。
因此,在本申请实施例的资源性能评估方法中,可以首先在步骤S301中获取服务器系统中的多个服务器中的至少一个目标服务器的资源信息。并且可以在步骤S302中获取目标服务器运行时其上运行的任务所使用的资源的使用量数据。
从而服务器系统可以通过基于步骤S301中获取的服务器的硬件规格和步骤S302获取的使用情况的历史数据而对未来一段时间内硬件资源使用情况的预估而制定出多个资源分配策略。例如,在调度中心或调度模块中可以存储有这样的策略表,其中可以预先指定对于何种类型的计算任务应该分配多少数量的计算资源,更具体地可以预先指定采用多个服务器的何种组合来实现所需数量的计算资源。因此,在实际运行时,当检测到预定类型的计算负载时,或者服务器系统的任务负载达到了策略中预先指定的阈值之后,就可以及时按照策略中制定的分配方案来进行资源的调配。但是这样的调度策略由于是预先制定的,因此,当例如如上所述新增了服务器或者新对某个服务器的硬件配置进行了升级时,预先制定的调度策略的依据就发生了变化,例如,在新增了服务器的情况下,可供调度的硬件资源变多并且服务器整体性能也变得更高,因此,在面对同样的负载的情况下,之前如果需要两个服务器协作才能实现所需的资源量,那么可能仅适用新增的服务器单独就可以实现。因此,就需要根据资源信息的变化来确定这样的策略,即对策略进行更新。
特别地,在本申请实施例中,步骤S301中获取的资源信息可以额外包括性能估计信息,例如,性能估计信息可以至少包括目标服务器的任务负载、时间节点、任务性能需求、硬件规格。
因此,在本申请实施例中,可以在步骤S301中先从目标服务器获取在该服务器的预定存储空间中存储的资源信息。例如,可以在该服务器的BMC(BaseboardManagerController,基板管理控制器)中提供该存储空间来存储包括性能规格以及性能估计信息的资源信息,当然也可以以其他方式来提供该存储空间以存储资源信息,只要该存储空间能够是针对各个服务器独立服务的。例如,在本申请实施例中,可以在相对于服务器独立的存储介质,例如外接存储器(闪存或USB存储装置)上提供该存储空间。此外,在本申请实施例中,资源信息可以至少包括有该服务器的性能规格信息,例如,该服务器的硬件信息,例如CPU频率及核数、内存性能及规格等等。并且这些信息可以是在服务器出厂时由设备制造方写入到该服务器的预定存储空间中,或者也可以在由服务系统的运营方在购买了该服务器之后例如在将该服务器上线时写入到该存储空间中。
S303,根据服务器系统的任务负载和与硬件性能规格数据对应的使用量数据,确定任务负载与资源性能的变化关系。
在步骤S301中获取到了服务器的资源信息并且在步骤S302中获取到使用量数据之后,可以在步骤S303中进一步根据该资源信息,尤其是该资源信息中的性能规格信息,即硬件信息对应的使用量数据,来确定任务负载与资源性能的对应关系,即性能估计算法。例如,在根据资源信息确定了性能规格之后,就可以通过与该性能规格对应的使用量数据,例如,在何种负载的情况下消耗多少的硬件资源。从而根据负载情况与使用量数据来挑选适合于步骤S301中获取到的性能规格的性能估计算法。
S304,使用变化关系,生成针对目标服务器的资源性能在预定的预估时间内的变化的预估结果。
在步骤S304中可以使用步骤S303中所确定的变化关系,即估计算法来生成未来一定时间,即预估时间内的资源性能随负载的变化情况,从而生成预估结果。该预估结果可以是对未来一段时间内硬件资源使用情况的预估而制定出的多个资源分配策略。例如,在调度中心或调度模块中可以存储有这样的策略表,其中可以预先指定对于何种类型的计算任务应该分配多少数量的计算资源,更具体地可以预先指定采用多个服务器的何种组合来实现所需数量的计算资源。因此,在实际运行时,当检测到预定类型的计算负载时,或者服务器系统的任务负载达到了策略中预先指定的阈值之后,就可以及时按照策略中制定的分配方案来进行资源的调配。
此外,在步骤S304确定的资源性能的变化的基础上,本申请实施例还可以进一步根据该变化生成资源性能的调整方案。换言之,在本申请实施例中,一方面可以根据当前的硬件性能规格信息来给出适合的资源性能使用方案,来提高当前资源的使用率,另一方面,如上所述,由于本申请所针对的技术问题是由于新增硬件带来的系统整体硬件的性能不平衡而导致的,因此,本申请实施例还可以基于步骤S304中确定的性能之间的变化来生成硬件性能规格调整建议方案。例如,根据步骤S304中确定在未来一周内硬件资源使用将达到峰值,并且根据调度策略已经确定需要对现有的服务器A和B的核心进行组合才能满足未来的计算需求,那么在本申请实施例中,还可以进一步根据这样的预估来给出性能调整建议方案,例如,由于在步骤S301中已经了解到系统中的服务器的实际性能规格,例如已经了解到服务器A是具有较旧或较低的性能规格的服务器,因此在步骤S304的同时或之后,可以建议在未来一周内或者更早,建议调整服务器A的硬件规格,例如,在步骤S301中了解到服务器A的内存为16G,而新增的服务器B的内存为32G,因此,在步骤S304确定未来需要的内存量在48G左右时,就可以进一步建议在未来的这一周内增加服务器A的内存,例如增加至32G,以便于满足可能进一步增加的计算性能需求,并且因此可以将该该建议发送给系统的管理方或者提供该计算服务的运营方,从而运营方可以根据该建议方案来安排购买和替换。因此,通过基于服务器实际性能规格与计算任务评估的未来的资源配置方案来进一步给出性能规格的调整或改进建议方案,可以在提高系统硬件资源的利用率的基础上实现硬件规格在适合的时间并且以适合的方案进行升级,实现了成本-效率的平衡。
因此,本申请实施例提供的根据本申请实施例的资源性能预估方案,可以直接获取多个服务器的实际性能数据,并且根据获取到的实际性能数据来进行资源性能预估结果的计算,从而确定调度方案,因此大大提高了资源性能预估的准确性和效率,并且还可以根据资源性能预估结果来进一步给出与性能预估使用匹配的性能调整方案,从而使得硬件管理方或者服务运营方能够及时地根据硬件资源的使用情况进行硬件升级或调整,实现了硬件成本与计算效率的均衡。
实施例四
图4为本申请提供的资源性能预估装置实施例的结构示意图,可用于执行如图2和图3所示的方法步骤。如图4所示,该资源性能预估装置可以包括:第一获取模块41、确定模块42和预估模块43。
第一获取模块41可以用于获取多个服务器中至少一个目标服务器的资源信息。
在本申请实施例中,资源性能预估装置可以用于预计或估计由多个服务器构成的服务器系统的性能,或者也可以用于估计或预计由多个计算单元通过数据线或其他通信方式连接在一起而构成的计算装置或系统的性能。在本申请实施例中,以估计由多个服务器构成的服务器系统作为示例来阐述本申请的技术构思。当然,对于本领域技术人员来说能够理解的是,本申请的资源性能预估方法不限于本申请实施例中示出的服务器系统或者计算装置,其可以应用于各种由多个硬件单元构成的系统或装置。
在本申请实施例中,资源性能预估装置可以设置在服务器系统中的调度服务器上,也可以设置在多个服务器中用于执行资源调度任务的服务器中,或者也可以作为单独的预估服务器设置在服务器系统中。目标服务器可以是构成服务器系统的多个服务器中的一个,并且特别地可以是该服务器系统中相对于其他服务器较新的一个,或者是新加入到该服务器系统中的服务器。在服务器系统的运行过程中,服务器系统的调度模块或调度中心需要根据构成该系统的各个服务器的硬件规格和使用情况来进行资源调度。
因此,在本申请实施例的资源性能评估装置,可以首先通过第一获取模块41来获取服务器系统中的多个服务器中的至少一个目标服务器的资源信息。并且资源性能评估装置可以进一步包括第二获取模块44。第二获取模块44可以用于获取目标服务器运行时在目标服务器上运行的任务所使用的资源的使用量数据。因此可以通过第二获取模块44来获取目标服务器运行时其上运行的任务所使用的资源的使用量数据。
从而服务器系统可以通过基于第一获取模块41获取的服务器的硬件规格和第二获取模块44获取的使用情况的历史数据而对未来一段时间内硬件资源使用情况的预估而制定出多个资源分配策略。例如,在调度中心或调度模块或者在该资源性能评估装置中可以存储有这样的策略表,其中可以预先指定对于何种类型的计算任务应该分配多少数量的计算资源,更具体地可以预先指定采用多个服务器的何种组合来实现所需数量的计算资源。因此,在实际运行时,当检测到预定类型的计算负载时,或者服务器系统的任务负载达到了策略中预先指定的阈值之后,就可以及时按照策略中制定的分配方案来进行资源的调配。但是这样的调度策略由于是预先制定的,因此,当例如如上所述新增了服务器或者新对某个服务器的硬件配置进行了升级时,预先制定的调度策略的依据就发生了变化,例如,在新增了服务器的情况下,可供调度的硬件资源变多并且服务器整体性能也变得更高,因此,在面对同样的负载的情况下,之前如果需要两个服务器协作才能实现所需的资源量,那么可能仅适用新增的服务器单独就可以实现。因此,就需要根据资源信息的变化来确定这样的策略,即对策略进行更新。
特别地,在本申请实施例中,第一获取模块41获取的资源信息可以额外包括性能估计信息,例如,性能估计信息可以至少包括目标服务器的任务负载、时间节点、任务性能需求、硬件规格。
因此,在本申请实施例中,第一获取模块41可以先从目标服务器获取在该服务器的预定存储空间中存储的资源信息。例如,可以在该服务器的BMC(BaseboardManagerController,基板管理控制器)中提供该存储空间来存储包括性能规格以及性能估计信息的资源信息,当然也可以以其他方式来提供该存储空间以存储资源信息,只要该存储空间能够是针对各个服务器独立服务的。例如,在本申请实施例中,可以在相对于服务器独立的存储介质,例如外接存储器(闪存或USB存储装置)上提供该存储空间。此外,在本申请实施例中,资源信息可以至少包括有该服务器的性能规格信息,例如,该服务器的硬件信息,例如CPU频率及核数、内存性能及规格等等。并且这些信息可以是在服务器出厂时由设备制造方写入到该服务器的预定存储空间中,或者也可以在由服务系统的运营方在购买了该服务器之后例如在将该服务器上线时写入到该存储空间中。
确定模块42可以用于根据服务器系统的任务负载和与硬件性能规格数据对应的使用量数据确定任务负载与资源性能的变化关系。
第一获取模块41获取到了服务器的资源信息并且第二获取模块44获取到使用量数据之后,确定模块42可以进一步根据该资源信息,尤其是该资源信息中的性能规格信息,即硬件信息对应的使用量数据,来确定任务负载与资源性能的对应关系,即性能估计算法。例如,在根据资源信息确定了性能规格之后,就可以通过与该性能规格对应的使用量数据,例如,在何种负载的情况下消耗多少的硬件资源。从而根据负载情况与使用量数据来挑选适合于步骤S301中获取到的性能规格的性能估计算法。
预估模块43可以用于使用变化关系生成针对目标服务器的资源性能在预定的预估时间内的变化的预估结果。
预估模块43可以使用确定模块42所确定的变化关系,即估计算法来生成未来一定时间,即预估时间内的资源性能随负载的变化情况,从而生成预估结果。该预估结果可以是对未来一段时间内硬件资源使用情况的预估而制定出的多个资源分配策略。例如,在调度中心或调度模块中可以存储有这样的策略表,其中可以预先指定对于何种类型的计算任务应该分配多少数量的计算资源,更具体地可以预先指定采用多个服务器的何种组合来实现所需数量的计算资源。因此,在实际运行时,当检测到预定类型的计算负载时,或者服务器系统的任务负载达到了策略中预先指定的阈值之后,就可以及时按照策略中制定的分配方案来进行资源的调配。
此外,预估模块43确定了资源性能的变化的基础上,本申请实施例还可以进一步根据该变化生成资源性能的调整方案并且发送给例如服务器系统的管理方或者计算服务器的运营方来进行参考或者指导其调整服务器硬件规格。换言之,在本申请实施例中,一方面预估模块43可以根据当前的硬件性能规格信息来给出适合的资源性能使用方案,来提高当前资源的使用率,另一方面,如上所述,由于本申请所针对的技术问题是由于新增硬件带来的系统整体硬件的性能不平衡而导致的,因此,本申请实施例还可以根据预估模块43确定的性能之间的变化来生成硬件性能规格调整建议方案。例如,预估模块43确定在未来一周内硬件资源使用将达到峰值,并且根据调度策略已经确定需要对现有的服务器A和B的核心进行组合才能满足未来的计算需求,那么在本申请实施例中,还可以进一步根据这样的预估来给出性能调整建议方案,例如,由于第一获取模块41已经获取到系统中的服务器的实际性能规格,例如已经了解到服务器A是具有较旧或较低的性能规格的服务器,因此可以建议在未来一周内或者更早,建议调整服务器A的硬件规格,例如,第一获取模块41了解到服务器A的内存为16G,而新增的服务器B的内存为32G,因此,预估模块43确定未来需要的内存量在48G左右时,就可以进一步建议在未来的这一周内增加服务器A的内存,例如增加至32G,以便于满足可能进一步增加的计算性能需求,并且因此可以将该该建议发送给系统的管理方或者提供该计算服务的运营方,从而运营方可以根据该建议方案来安排购买和替换。因此,通过基于服务器实际性能规格与计算任务评估的未来的资源配置方案来进一步给出性能规格的调整或改进建议方案,可以在提高系统硬件资源的利用率的基础上实现硬件规格在适合的时间并且以适合的方案进行升级,实现了成本-效率的平衡。
因此,本申请实施例提供的根据本申请实施例的资源性能预估方案,可以直接获取多个服务器的实际性能数据,并且根据获取到的实际性能数据来进行资源性能预估结果的计算,从而确定调度方案,因此大大提高了资源性能预估的准确性和效率,并且还可以根据资源性能预估结果来进一步给出与性能预估使用匹配的性能调整方案,从而使得硬件管理方或者服务运营方能够及时地根据硬件资源的使用情况进行硬件升级或调整,实现了硬件成本与计算效率的均衡。
实施例五
图5为本申请提供的服务器系统的实施例的系统示意图,在该系统中可以应用如图2和图3所示的方法步骤。如图5所示,该服务器系统可以包括多个服务器51以及资源调度中心52。
多个服务器51中的每一个可以设置有预定的存储空间511,用于存储该服务器51的资源信息。在本申请实施例中,服务器51可以在其BMC(BaseboardManagerController,基板管理控制器)中提供存储空间511来存储资源信息,当然也可以以其他方式来提供该存储空间511以存储资源信息,只要该存储空间511能够是针对服务器51独立服务的。
例如,在本申请实施例中,可以在相对于服务器51独立的存储介质,例如外接存储器(闪存或USB存储装置)上提供该存储空间511。此外,在本申请实施例中,资源信息可以至少包括有该服务器的性能规格信息,例如,该服务器的硬件信息,例如CPU频率及核数、内存性能及规格等等。并且这些信息可以是在服务器出厂时由设备制造方写入到该服务器的预定存储空间中,或者也可以在由服务系统的运营方在购买了该服务器之后例如在将该服务器上线时写入到该存储空间中。
资源调度中心52可以与每一个服务器51通信连接,并且从多个服务器51中的至少一个目标服务器51获取该服务器51所存储的资源信息。
例如,该资源调度中心52可以用于
获取多个服务器中至少一个目标服务器的资源信息。
获取目标服务器运行时在目标服务器上运行的任务所使用的资源的使用量数据。
在本申请实施例中,目标服务器51可以是构成服务器系统的多个服务器51中的一个,并且特别地可以是该服务器系统中相对于其他服务器较新的一个,或者是新加入到该服务器系统中的服务器。在服务器系统的运行过程中,资源调度中心52可以根据构成该系统的各个服务器的硬件规格和使用情况来进行资源调度。
例如,资源调度中心52可以获取服务器系统中的多个服务器中的至少一个目标服务器51的资源信息以及该目标服务器51运行时其上运行的任务所使用的资源的使用量数据。
资源调度中心52可以通过基于获取的服务器的硬件规格和使用情况的历史数据而对未来一段时间内硬件资源使用情况的预估而制定出多个资源分配策略。例如,在资源调度中心52中可以存储有这样的策略表,其中可以预先指定对于何种类型的计算任务应该分配多少数量的计算资源,更具体地可以预先指定采用多个服务器的何种组合来实现所需数量的计算资源。因此,在实际运行时,当检测到预定类型的计算负载时,或者服务器系统的任务负载达到了策略中预先指定的阈值之后,就可以及时按照策略中制定的分配方案来进行资源的调配。但是这样的调度策略由于是预先制定的,因此,当例如如上所述新增了服务器或者新对某个服务器的硬件配置进行了升级时,预先制定的调度策略的依据就发生了变化,例如,在新增了服务器的情况下,可供调度的硬件资源变多并且服务器整体性能也变得更高,因此,在面对同样的负载的情况下,之前如果需要两个服务器协作才能实现所需的资源量,那么可能仅适用新增的服务器单独就可以实现。因此,就需要根据资源信息的变化来确定这样的策略,即对策略进行更新。
特别地,在本申请实施例中,资源调度中心52获取的资源信息可以额外包括性能估计信息,例如,性能估计信息可以至少包括目标服务器的任务负载、时间节点、任务性能需求、硬件规格。
此外,资源调度中心52还可以用于根据服务器系统的任务负载和与硬件性能规格数据对应的使用量数据确定任务负载与资源性能的变化关系。
在获取到了服务器的资源信息和使用量数据之后,资源调度中心52可以进一步根据该资源信息,尤其是该资源信息中的性能规格信息,即硬件信息对应的使用量数据,来确定任务负载与资源性能的对应关系,即性能估计算法。例如,在根据资源信息确定了性能规格之后,就可以通过与该性能规格对应的使用量数据,例如,在何种负载的情况下消耗多少的硬件资源。从而根据负载情况与使用量数据来挑选适合于获取到的性能规格的性能估计算法。
此外,资源调度中心52还可以使用变化关系生成针对目标服务器的资源性能在预定的预估时间内的变化的预估结果。
例如,资源调度中心52可以使用所确定的变化关系,即估计算法来生成未来一定时间,即预估时间内的资源性能随负载的变化情况,从而生成预估结果。该预估结果可以是对未来一段时间内硬件资源使用情况的预估而制定出的多个资源分配策略。例如,在资源调度中心52中可以存储有这样的策略表,其中可以预先指定对于何种类型的计算任务应该分配多少数量的计算资源,更具体地可以预先指定采用多个服务器的何种组合来实现所需数量的计算资源。因此,在实际运行时,当检测到预定类型的计算负载时,或者服务器系统的任务负载达到了策略中预先指定的阈值之后,就可以及时按照策略中制定的分配方案来进行资源的调配。
此外,在本申请实施例中,服务器51中可以设置有资源预估代理模块512,其可以用于将该服务器的预定的存储空间511中存储的资源信息发送给资源调度中心52来执行上述处理,并且可以在资源调度中心52生成了调度策略之后,可以从调度中心52接收该调度策略来更新存储空间511中存储的性能估计信息。
此外,资源调度中心52确定了资源性能的变化的基础上,本申请实施例资源调度中心52还可以进一步根据该变化生成资源性能的调整方案并且发送给例如服务器系统的管理方或者计算服务器的运营方来进行参考或者指导其调整服务器硬件规格。换言之,在本申请实施例中,一方面资源调度中心52可以根据当前的硬件性能规格信息来给出适合的资源性能使用方案,来提高当前资源的使用率,另一方面,如上所述,由于本申请所针对的技术问题是由于新增硬件带来的系统整体硬件的性能不平衡而导致的,因此,本申请实施例还可以资源调度中心52确定的性能之间的变化来生成硬件性能规格调整建议方案。例如,资源调度中心52确定在未来一周内硬件资源使用将达到峰值,并且根据调度策略已经确定需要对现有的服务器A和B的核心进行组合才能满足未来的计算需求,那么在本申请实施例中,资源调度中心52还可以进一步根据这样的预估来给出性能调整建议方案,例如,由于资源调度中心52中已经了解到系统中的服务器的实际性能规格,例如已经了解到服务器A是具有较旧或较低的性能规格的服务器,因此可以建议在未来一周内或者更早,建议调整服务器A的硬件规格,例如,资源调度中心52了解到服务器A的内存为16G,而新增的服务器B的内存为32G,因此,资源调度中心52确定未来需要的内存量在48G左右时,就可以进一步建议在未来的这一周内增加服务器A的内存,例如增加至32G,以便于满足可能进一步增加的计算性能需求,并且因此可以将该该建议发送给系统的管理方或者提供该计算服务的运营方,从而运营方可以根据该建议方案来安排购买和替换。因此,通过基于服务器实际性能规格与计算任务评估的未来的资源配置方案来进一步给出性能规格的调整或改进建议方案,可以在提高系统硬件资源的利用率的基础上实现硬件规格在适合的时间并且以适合的方案进行升级,实现了成本-效率的平衡。
因此,本申请实施例提供的根据本申请实施例的服务系统,由于在服务器中提供存储空间来存储资源信息,并且资源调度中心可以从服务器直接获取多个服务器的实际性能数据,并且根据获取到的实际性能数据来进行资源性能预估结果的计算,从而确定调度方案,因此大大提高了资源性能预估的准确性和效率,并且还可以根据资源性能预估结果来进一步给出与性能预估使用匹配的性能调整方案,从而使得硬件管理方或者服务运营方能够及时地根据硬件资源的使用情况进行硬件升级或调整,实现了硬件成本与计算效率的均衡。
实施例五
以上描述了资源性能预估装置的内部功能和结构,该装置可实现为一种电子设备。图6为本申请提供的电子设备实施例的结构示意图。如图6所示,该电子设备包括存储器61和处理器62。
存储器61,用于存储程序。除上述程序之外,存储器61还可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令,联系人数据,电话簿数据,消息,图片,视频等。
存储器61可以由任何类型的易失性或非易失性存储设备或者它们的组合实现,如静态随机存取存储器(SRAM),电可擦除可编程只读存储器(EEPROM),可擦除可编程只读存储器(EPROM),可编程只读存储器(PROM),只读存储器(ROM),磁存储器,快闪存储器,磁盘或光盘。
处理器62,不仅仅局限于中央处理器(CPU),还可能为图形处理器(GPU)、现场可编辑门阵列(FPGA)、嵌入式神经网络处理器(NPU)或人工智能(AI)芯片等处理芯片。处理器62,与存储器61耦合,执行存储器61所存储的程序,该程序运行时执行上述实施例二和三的资源性能预估方法。
进一步,如图6所示,电子设备还可以包括:通信组件63、电源组件64、音频组件65、显示器66等其它组件。图6中仅示意性给出部分组件,并不意味着电子设备只包括图6所示组件。
通信组件63被配置为便于电子设备和其他设备之间有线或无线方式的通信。电子设备可以接入基于通信标准的无线网络,如WiFi,3G、4G或5G,或它们的组合。在一个示例性实施例中,通信组件63经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中,所述通信组件63还包括近场通信(NFC)模块,以促进短程通信。例如,在NFC模块可基于射频识别(RFID)技术,红外数据协会(IrDA)技术,超宽带(UWB)技术,蓝牙(BT)技术和其他技术来实现。
电源组件64,为电子设备的各种组件提供电力。电源组件64可以包括电源管理系统,一个或多个电源,及其他与为电子设备生成、管理和分配电力相关联的组件。
音频组件65被配置为输出和/或输入音频信号。例如,音频组件65包括一个麦克风(MIC),当电子设备处于操作模式,如呼叫模式、记录模式和语音识别模式时,麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器61或经由通信组件63发送。在一些实施例中,音频组件65还包括一个扬声器,用于输出音频信号。
显示器66包括屏幕,其屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板,屏幕可以被实现为触摸屏,以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界,而且还检测与所述触摸或滑动操作相关的持续时间和压力。
本领域普通技术人员可以理解:实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时,执行包括上述各方法实施例的步骤;而前述的存储介质包括:ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上各实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述各实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。