CN107835089A - 管理资源的方法和装置 - Google Patents

Abstract

本申请提供一种管理资源的方法，能够提高硬件资源管理的效率。该方法应用于由至少一个硬件资源组成的服务器，该至少一个硬件资源与至少一个基板管理控制器BMC一一对应连接；配置文件记录有该至少一个硬件资源与该至少一个BMC的对应关系；该至少一个BMC包括第一BMC和第二BMC，第二BMC对应连接该至少一个硬件资源中的目标硬件资源；该方法包括：第一BMC接收资源访问请求，资源访问请求中携带目标硬件资源的标识，资源访问请求用于请求获取目标硬件资源的数据；第一BMC根据配置文件，确定目标硬件资源的标识对应的第二BMC；第一BMC通过第二BMC获取目标硬件资源的数据。

Description

管理资源的方法和装置

技术领域

本申请涉及信息技术领域，更具体地，尤其涉及一种管理资源的方法和装置。

背景技术

随着信息技术(Information Technology，IT)的快速发展，各类IT技术系统中的数据量越来越大。例如，一些应用于企业关键业务的服务器，由于这些业务处于企业应用中的核心地位，这就决定了服务器处理的数据和信息都是用户核心的商业数据和信息，对可靠性要求非常高，使得服务器的设计越来越复杂。而这类服务器的硬件种类和数量都比普通服务器多出很多。

基板管理控制器(Baseboard Management Controller,BMC)作为一个单板控制器，通常用于管理组成服务器的各个硬件，从而对服务器进行管理。但是由于BMC的规格和硬件总线链路信号等限制，一个BMC无法管理太多的硬件。例如，一条I2C(Inter-Integrated Circuit)总线上无法挂载太多的I2C的从设备。并且，对于柜机服务器或者跨柜机的服务器来说，柜内框的数量按需求分配，一个框和另一个框可能相隔一定的距离，传统的低速总线，例如，I2C总线、通用入口出口总线(General Purpose Input Output,GPIO)、局部总线(Local Bus)等由于速率较低、数据量少且总线长度不能太长，因此无法满足需求。

因此，面对服务器内部硬件资源更加复杂、服务器管理的数据量越来越大的变化，如何更高效率地实现硬件资源的管理成为一个急需解决的问题。

发明内容

本申请提供一种管理资源的方法和装置，能够提高硬件资源管理的效率。

第一方面，本申请提供了一种管理资源的方法，应用于由至少一个硬件资源组成的服务器；该至少一个硬件资源与至少一个基板管理控制器BMC一一对应连接；配置文件记录有该至少一个硬件资源与该至少一个BMC的对应关系；该至少一个BMC包括第一BMC和第二BMC，第二BMC对应连接该至少一个硬件资源中的目标硬件资源；该方法包括：第一BMC接收资源访问请求，资源访问请求中携带目标硬件资源的标识，资源访问请求用于请求获取目标硬件资源的数据；第一BMC根据配置文件，确定目标硬件资源的标识对应的第二BMC；第一BMC通过第二BMC获取目标硬件资源的数据。

结合第一方面，在第一方面的某些实现方式中，第一BMC通过第二BMC获取目标硬件资源的数据，包括：第一BMC与第二BMC建立套接字；第一BMC通过套接字向第二BMC发送数据请求消息；第一BMC从第二BMC接收响应消息，响应消息中携带目标硬件资源的数据。

结合第一方面，在第一方面的某些实现方式中，第一BMC与第二BMC建立套接字，包括：第一BMC根据配置文件，确定目标硬件资源的标识对应的芯片的类实例；第一BMC确定该芯片的类实例对应的总线的类实例；第一BMC根据总线的类实例，确定第二BMC的标识和端口；第一BMC基于第二BMC的标识和端口，与第二BMC建立套接字。

结合第一方面，在第一方面的某些实现方式中，该方法还包括：第一BMC获取通过该至少一个BMC中部分或全部BMC获取至少一个硬件资源中部分或全部硬件资源的数据；第一BMC根据获取到的硬件资源的数据，调整该至少一个硬件资源的工作来组合实现对服务器的状态控制。

结合第一方面，在第一方面的某些实现方式中，该资源访问请求是第一BMC从访问设备接收的，该资源访问请求是该访问设备在确定第二BMC的访问队列的长度大于或等于预设队列长度的情况下发送给第一BMC的。

第二方面，本申请提供了一种管理资源的方法，应用于由至少一个硬件资源组成的服务器；该至少一个硬件资源与至少一个基板管理控制器BMC一一对应连接；配置文件记录有该至少一个硬件资源和该至少一个BMC的对应关系；该至少一个BMC包括第一BMC和第二BMC，第二BMC对应接连该至少一个硬件资源中的目标硬件资源；该方法包括：第二BMC接收第一BMC发送的数据请求消息，数据请求消息用于请求获取目标硬件资源的数据，数据请求消息中携带有目标硬件资源的标识；第二BMC获取目标硬件资源的数据；第二BMC向第一BMC发送响应消息，响应消息中携带目标硬件资源的数据。

结合第二方面，在第二方面的某些实现方式中，第二BMC接收第一BMC发送的数据请求之前，该方法还包括：第二BMC与所述第一BMC建立套接字；以及，第二BMC接收第一BMC发送的数据请求消息，包括：第二BMC接收第一BMC通过套接字发送的数据请求消息。

第三方面，本申请提供一种管理资源的装置，该装置具有实现第一方面的管理资源的方法的功能。这些功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的单元。

第四方面，本申请提供一种管理资源的装置，该装置具有实现第二方面的管理资源的方法的功能。这些功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的单元。

第五方面，本申请提供一种通信设备，该通信设备包括存储器、通信接口和处理器，存储器、通信接口和处理器耦合。其中，存储器用于存储计算机可执行程序代码；存储器所存储的程序代码包括指令，当处理器执行所述指令时，使得通信设备执行上述第一方面或第二方面的任意一种可能的设计中第一BMC所执行的方法。

第六方面，本申请提供一种通信设备，该通信设备包括存储器、通信接口和处理器，存储器、通信接口和处理耦合。其中，存储器用于存储计算机可执行程序代码；存储器所存储的程序代码包括指令，当处理器执行所述指令时，使通信装置执行上述第一方面或第二方面的任意一种可能的设计中第二BMC所执行的方法。

第七方面，本申请提供计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述第一方面中第一BMC执行的方法。

第八方面，提供了一种计算机可读介质，所述计算机可读介质存储有程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述第二方面中第一BMC执行的方法。

第九方面，本申请提供了一种芯片系统，该芯片系统包括处理器，用于实现上述第一方面中的方法，例如，接收或处理上述第一方面的方法中所涉及的数据和/或信息。

在一种可能的设计中，该芯片系统还包括存储器，该存储器用于保存实现第一方面中的方法的程序指令和数据。该芯片系统，可以由芯片构成，也可以包括芯片和其它分立器件。

第十方面，本申请提供计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述第二方面中第二BMC执行的方法。

第十一方面，提供了一种计算机可读介质，所述计算机可读介质存储有程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述第二方面中第二BMC执行的方法。

第十二方面，本申请提供了一种芯片系统，该芯片系统包括处理器，用于实现上述第二方面中的方法，例如，接收、处理或发送上述第二方面的方法中所涉及的数据和/或信息。

在一种可能的设计中，该芯片系统还包括存储器，该存储器用于保存实现第二方面中的方法的程序指令和数据。该芯片系统，可以由芯片构成，也可以包括芯片和其它分立器件。

在本申请的技术方案中，通过将组成服务器的全部硬件资源抽象化(或者说，资源池化)，使得管理组成服务器的硬件资源的任意一个BMC，都可以访问资源池内任意一个硬件资源，不再受到硬件资源所处位置的限制，能够提高硬件资源的管理效率。

附图说明

图1为本申请实施例的BMC访问硬件资源的示意图。

图2为本申请实施例的管理资源的方法100的流程图。

图3为本申请提供的管理资源的示意图。

图4是访问侧BMC访问代理侧BMC的硬件资源的交互图。

图5示出了访问侧BMC和代理侧BMC的内部处理流程的示意图。

图6示出了管理框的BMC本地控制柜机内全部硬件资源的示意图。

图7是管理软件实现柜机内BMC负载均衡的示意图。

图8为本申请实施例的管理资源的装置500的示意性框图。

图9为本申请实施例的管理资源的装置600的示意性框图。

图10为本申请实施例提供的管理资源的设备700的示意性结构图。

图11为本申请实施例提供的管理资源的设备800的示意性结构图。

具体实施方式

下面将结合附图，对本申请中的技术方案进行描述。

为了便于理解，首先对本申请实施例涉及的相关技术作简单介绍。

服务器，是提供计算服务的设备，通常由多个硬件(或者说，部件)组成，例如，处理器、硬盘、内存、系统总线、风扇、电源等。而随着信息技术(Information Technology，IT)的快速发展，各类IT系统中的数据量越来越大，因此也对服务器在计算速度、可靠度、安全性等方面提出了更高的要求，这使得服务器的内部结构的设计也越来越复杂，服务器所包含的硬件的数量和种类也越来越多。

在现阶段，人们通常通过基板管理控制器(Baseboard Management Controller,BMC)对服务器的各个硬件进行管理。而BMC作为一个单板管理控制器，由于其受到芯片规格和硬件总线链路信号等限制，一个BMC无法管理太多的硬件。

而随着服务器所包含的硬件数量和种类的不断增加，如果一个BMC仍然仅管理很少数量的硬件，那么管理效率就比较低。在一个机房中有多个服务器，甚至是柜机服务器或者跨柜机服务器的情况下，管理效率就更低，这样的管理效率将不再满足对服务器的管理需求。

为此，本申请提出一种管理资源的方法，通过将组成服务器的全部硬件资源抽象化(或者说，资源池化)，使得应用感知不到硬件资源所处位置的差异。任意一个BMC都可以访问资源池内任意一个硬件资源，从而可以提高对服务器的管理效率。

除此之外，本申请的技术方案也在服务器的其它性能方面也有所提升，例如，具有负载均衡能力、容错性能增强、对硬件资源的管理更加合理等。

下面对本申请提供的管理资源的方法作详细说明。

本申请的技术方案，可以应用于需要管理大量硬件资源的场景。例如，一个服务器由于包括的硬件太多，或者由于多硬分区的要求，而需要配置多个BMC来管理这些硬件的情况。以下各实施例，以管理一个服务器的多个硬件资源作为示例，对本申请的技术方案进行详细说明。

参见图1，图1为本申请实施例的BMC访问硬件资源的示意图。在图1中，一个服务器包括4个硬件资源，分别记作硬件资源1、硬件资源2、硬件资源3和硬件资源4。这4个硬件资源分别和BMC1、BMC2、BMC3和BMC4通过总线连接。在本申请实施例中，一个硬件资源对应连接的BMC，是指通过总线和这个硬件资源直接连接的BMC。或者，也可以说，和一个BMC通过总线直接连接的硬件资源是这个BMC的本地硬件资源。

此外，BMC之间可以通过局域网(Local Area Network，LAN)、总线和接口标准(Peripheral Component Interface Express，PCIE)、通用串行总线(Universal SerialBus，USB)等连接。本申请实施例中主要以局域网为例进行说明。

现有技术中，一个BMC通常只能管理本地的硬件资源，而不能管理远程的硬件资源。以图1为例，BMC1只能访问硬件资源1，而不能访问硬件资源2、硬件资源3和硬件资源4。BMC2、BMC3和BMC4也是类似的。

而在本申请提供的技术方案中，通过将硬件资源1、硬件资源2、硬件资源3和硬件资源4资源池化，使得任意一个BMC都可以访问资源池内的全部硬件资源。继续以图1为例，BMC1不仅可以访问本地的硬件资源1，还可以访问远程的硬件资源2、硬件资源3和硬件资源4。

参见图2，图2为本申请实施例的管理资源的方法100的流程图。方法100主要包括步骤110-130，可以由管理硬件资源的任意一个BMC执行。下面分别对步骤110-130进行详细说明。

首先需要说明的是，组成服务器的至少一个(通常为多个)硬件资源与至少一个BMC一一对应连接。硬件资源与BMC的连接情况参见上文的图1所示。每个BMC上存储有配置文件，配置文件记录有该至少一个硬件资源与该至少一个BMC的对应关系。

本申请实施例中出现的编号“第一”、“第二”是为了区分不同的描述对象，例如，为了区分不同的BMC、硬件资源等。因此，以下实施例中描述的第一BMC和第二BMC，仅是作为管理服务器的硬件资源的多个BMC中的任意两个的示例。

此外，在本申请实施例中，目标硬件资源是指用户请求访问的硬件资源。

110、第一BMC接收资源访问请求。

其中，资源访问请求中携带目标硬件资源的标识，资源访问请求用于请求获取目标硬件资源的数据。

在本申请实施例中，需要管理的硬件资源有多个，每个硬件资源与一个BMC连接。将一个硬件资源和与它连接的BMC看作是对应的，那么，这多个硬件资源与多个BMC一一对应。

在本申请实施例中，第一BMC是这多个BMC中的任意一个。

另外，第一BMC接收到的资源访问请求，可以是通过外部的通信接口接收到的，或者，也可是第一BMC通过内部的通信接口接收到的。

当资源访问请求是第一BMC通过外部通信接口接收到的情况下，该资源访问请求可以来自一个与第一BMC相互分离的一个独立的设备(下面称作访问设备)。

例如，访问设备可以是运行有管理软件的设备，用户通过在访问设备上操作管理软件，向第一BMC发送资源访问请求，请求获取任意一个硬件资源的数据，进而可以查看各个硬件资源的数据。

可以理解的是，访问设备可以包括但不限于各种终端设备，例如，个人计算机(Personal Computer，PC)、手机、平板等。

资源访问请求中携带请求访问的硬件资源的标识，一个硬件资源的标识可以在这多个硬件资源中唯一地标识这个硬件资源。

120、第一BMC根据配置文件，确定目标硬件资源的标识对应的第二BMC。

在本申请实施例中，配置文件可以是预先配置，且存储在第一BMC上的。其中，配置文件中记录了硬件资源的标识和BMC的对应关系。

这样，第一BMC接收到一个资源访问请求，根据配置文件，第一BMC可以获知资源访问请求中携带的硬件资源的标识对应的BMC是哪一个。

本申请实施例对配置文件的具体形式不作任何限定。可以理解的是，为了实现任意一个BMC都可以访问任意一个硬件资源，配置文件可以存储在每个BMC上。这样，无论是哪个BMC接收到资源访问请求，都可以根据该配置文件，获知资源访问请求中携带的目标硬件资源的标识对应的BMC，进而通过该目标硬件资源对应的BMC，获取该目标硬件资源的数据。

130、第一BMC通过第二BMC获取目标硬件资源的数据。

第一BMC通过配置文件，确定了目标硬件资源的标识对应的第二BMC，后续就可以从第二BMC获取目标硬件资源的数据。

从本申请的技术方案可以看出，通过将硬件资源抽象化(或者说，资源池化)，任意一个BMC不仅可以访问本地硬件资源，也可以访问资源池中的其它任意一个硬件资源，而不再受到硬件资源位置的限制，提高了硬件资源管理的效率。

下面结合图3至图7，对本申请的技术方案作进一步的说明。

参见图3，图3为本申请提供的管理资源的示意图。继续以一个服务器包括硬件资源1、硬件资源2、硬件资源3和硬件资源4为例。

在本申请实施例中，每个BMC都可以接收来自上层应用的资源访问请求。每个BMC上可以运行一个代理(Proxy)，这个Proxy可以接收其它BMC通过LAN、PCIE、USB等传输通道发送的数据请求消息，Proxy基于数据请求消息访问所管理区域内的硬件资源，再将获取到的硬件资源的数据返回给其它BMC。再由其它BMC返回给应用。

应理解，图3中的BMC1作为一个访问侧的BMC，BMC1上也可以运行有Proxy，图3中未示出。

参见图4，图4是访问侧BMC访问代理侧BMC的硬件资源的交互图。

以下实施例中出现的访问侧BMC作为第一BMC的示例，代理侧BMC作为第二BMC的示例。

301、用户通过Web查询I/O板上的LM75的数据。访问侧BMC接收资源访问请求。

应理解，LM75是温度传感器。这里作为访问侧BMC需要访问的硬件资源的示例。

其中，资源访问请求中会携带LM75的ID。

302、访问侧BMC访问ACCESSOR层。

在本申请实施例中，将ACCESSOR层设计为硬件抽象层，用于屏蔽硬件资源的位置差异。换句话说，应用通过ACCESSOR层感知到一个硬件资源的资源池，并不区分资源池中的硬件资源是本地硬件还是其它BMC管理的远端硬件。

具体地，ACCESSOR层由两部分组成，配置文件和硬件抽象层。

配置文件，用于将资源池中的硬件资源的访问路径详细地描述下来。

例如，通过哪条I2C总线访问，访问什么类型的I2C器件，访问哪个I2C器件，访问的内容位于I2C器件内部的哪个寄存器。

硬件抽象层对资源池中硬件资源的访问进行抽象，对上层应用提供统一的应用程序编程接口(Application Programming Interface，API)，使上层应用感知不到硬件的差异。

例如，上层应用想要获取一个单板的标识信息，有些单板的标识信息放在复杂可编程逻辑器件(Complex Programmable Logic Device，CPLD)内部，而有些单板的标识信息放在一个单独的I2C芯片里。这些单板的标识信息只会在配置文件里体现差异，在硬件抽象层的处理流程都是一致的。

硬件抽象层的访问流程是：

(1)先从配置文件中获取需要访问的硬件资源所属的芯片的类型。

由于不同类型的芯片，其内部的寄存器结构和访问协议各不相同，因此，首先需要明确请求访问的硬件资源所属的芯片的类型，再实例化这个芯片的类实例。最后使用该芯片类的操作方法来访问这个芯片。

(2)再从配置文件中获取需要访问的这个芯片的总线类型。

由于不同总线的访问协议也各不相同，因此，先实例化出一个总线的类实例后，再使用该总线类的操作方法来访问这个芯片。

(3)实例化出正确的芯片的类实例和总线的类实例后，再根据配置文件中记录的芯片地址和请求访问的内容的寄存器偏移，调用芯片类和总线类的操作方法来访问具体的内容。

其中，实例化一个类实例是指在面向对象的编程中用类创建对象的过程。

在本申请实施例中，实例化一个类实例的具体过程可以是，从预先定义好的芯片类的类定义库中找到对应芯片的类定义，再实例化这个芯片的类实例；从预先定义好的总线类的类定义库中找到对应总线的类定义，再实例化这个总线的类实例。

例如，芯片类的类定义库中包括可以被访问的多个芯片的类定义。每个芯片的类定义包括访问这个芯片的方法，例如这个芯片的访问协议是什么，这个芯片的存储器结构及其寄存器的偏移等。

303、访问侧BMC根据配置文件获取到LM75的I2C总线连接的从设备的地址。

304、访问侧BMC通过配置文件路由到I2C类实例。

根据上文介绍可知，配置文件中记录了硬件资源的标识与BMC的对应关系，即，任意给出一个硬件资源的标识，都可以根据该配置文件唯一地确定出与该硬件资源的标识对应的BMC。

在具体实现中，该配置文件可以包括硬件资源的标识与芯片的类实例的对应关系(记作第一对应关系)以及芯片的类实例与总线的类实例的对应关系(记作第二对应关系)。

换句话说，根据第一对应关系，首先可以确定目标硬件资源的标识对应的芯片的类实例，再根据第二对应关系，可以确定出该芯片的类实例对应的总线的类实例。而在总线的类实例中配置有代理侧BMC的标识和端口，这样，第一BMC可以根据第二对应关系确定的总线的类实例，最终确定出目标硬件资源对应的BMC的标识和端口，从而可以唯一地确定出代理侧BMC(即，第二BMC)。

访问侧BMC可以预先存储配置文件，配置文件中记录了硬件资源的标识与芯片、总线的对应关系。其中，配置文件可以人工配置或者自动生成。

访问侧基于资源访问请求中携带的LM75的标识，根据配置文件可以路由到LM75的标识对应的芯片(Chip)和总线(BUS)的类实例。

305、访问侧BMC获取I2C类实例里配置的代理侧BMC的IP和端口(Port)，进而与代理侧BMC建立套接字(Socket)连接。

306、访问侧BMC向代理侧BMC发送基于I2C驱动的请求包。

307、代理侧BMC接收请求包并解析。

308、代理侧BMC调用I2C驱动接口，获取I/O板上LM75的数据。

309、代理侧BMC向访问侧BMC返回响应包。

其中，响应包中携带有LM75的数据。

310、访问侧BMC将LM75的数据返回给应用。

也即，访问侧BMC将LM75的数据返回给应用，应用在Web上显示LM75的数据。

以上图4示出了访问侧BMC和代理侧BMC的交互过程。

下面图5示出了访问侧BMC和代理侧BMC的内部处理流程的示意图。参见图5，访问侧BMC接收APP的资源访问请求，资源访问请求用于请求访问LM75的灯板(记作LedBoard_LM75)。

代理侧BMC的ACCESSOR层通过配置文件，将访问请求分别路由到对应的芯片(Chip)的类实例，再由芯片的类实例路由到对应的总线的类实例。

例如，将请求访问LM75的访问流路由到LM75芯片和I2C总线。将请求访问LedBoard_LM75的访问流路由到LM75芯片，再路由至I2C总线/GPIO总线/局部总线。将请求访问Board_ID的访问流路由到V系列复杂可编程逻辑器件(Complex Programmable LogicDevice，CPLD)芯片，再路由至I2C总线/GPIO总线/局部总线。

局部总线通常也写成Local Bus。

进一步地，访问侧BMC根据配置文件，获取总线的类实例中配置的代理侧BMC的IP和端口，进而与代理侧BMC建立套接字连接。

参见图5，代理侧BMC运行有Proxy，Proxy和访问侧BMC建立传输控制协议(Transmission Control Protocol，TCP)套接字服务(Socket service)。后续，Proxy接收访问侧BMC基于I2C、GPIO总线/局部总线发送的数据请求消息，数据请求消息中携带有请求访问的硬件设备(以下记作，目标硬件设备)的标识。代理侧BMC基于目标硬件设备的标识，获取目标硬件设备的数据，并通过套接字连接向访问侧BMC返回响应包，其中，响应包中携带了目标硬件设备的相关数据。

从本申请的技术方案可以看出，通过将硬件资源抽象化(或者说，资源池化)，任意一个BMC不仅可以访问本地硬件资源，也可以访问资源池中的其它硬件资源，而不再受到硬件资源位置的限制，提高了硬件资源管理的效率。

下面结合本申请技术方案在实际中的应用，对本申请的技术方案进行举例说明。

应用1

风扇调速

对于服务器而言，温度和风扇的转速通常是比较重要的工作参数。根据现有的BMC管理服务器各个硬件的原理，一个BMC仅能管理本地硬件，而不能管理其它远程硬件。因此，即使一个跨柜机的服务器组成非常复杂，包括诸多硬件，那么如果要检测各个柜内框的温度或者风扇的转速，也只能在一些(或者全部)柜内框设置温度检测点和风扇转速的检测点。后续，通过一个BMC，也仅能获取这个BMC所管理的区域内设置的温度检测点和风扇转速的检测点的数据。对于这个BMC管理区域之外的温度检测点和风扇转速的检测点，只能通过对应的BMC获取，而不能通过这个BMC获取。因此，如果要获取所有温度检测点和/或风扇转速检测点的数据，就需要向所有温度检测点和风扇转速检测点的所在区域的BMC获取数据。在服务器的组成部件众多，甚至需要管理一个机房内的多个服务器的情况下，管理流程复杂、繁琐。

下面结合图6，说明本申请的技术方案在此种情况下的管理流程。

参见图6，图6示出了管理框的BMC本地控制柜机内全部硬件资源的示意图。

从所有的柜内框中，预先设定一个管理框，并将其它的柜内框作为计算框。其中，温度检测点和风扇转速的检测点可以分布在管理框和各个(或者一部分)计算框上。

如图6所示，管理框对应的BMC(以下记作管理框BMC)接收调速应用的数据请求消息，在这些数据请求消息中，一些请求获取本地温度传感器LM75的数据，一些请求获取局域网_1(对应图6中的LAN_1)中的LM75的数据，一些请求获取局域网_2(对应图6中的LAN_2)中的LM75的数据，还有一些请求获取本地风扇(例如图5中所示的风扇_1,风扇_2,风扇_n)的转速。

管理框BMC根据ACCESSOR层的配置文件，将这些访问流分别路由到对应的芯片(Chip)和总线(Bus)，并基于各自的总线类实例中配置的计算框BMC的IP和端口，与对应的计算框BMC建立套接字连接。建立套接字连接之后，管理框BMC通过套接字连接，向各个计算框BMC发送与每个计算框BMC对应的数据请求消息。

每个计算框BMC上运行有Proxy。每个计算框上的Proxy接收管理框BMC发送的数据请求消息，获取对应硬件的数据。

最后，各计算框BMC将这些硬件的数据返回给管理框BMC。

由此，管理框BMC可以获取到所有温度检测点和风扇转速检测点的数据。

后续，管理框BMC可以根据各个温度检测点的数据，合理控制对应位置上风扇的转速，从而在柜内温度和噪声上达到平衡。

以上图5和图6中出现的“accessor”或“ACCESSOR”都是指ACCESSOR层。

可见，采用本申请实施例的技术方案，应用不需要区分温度检测点的位置，通过ACCESSOR硬件抽象层即可直接获取各个温度检测点的数据。进一步地，就可以根据调速策略，控制本地风扇和远端风扇的和远端风扇的转速。可以简化调速模块设计的复杂度。

也即，一个服务器包括多个硬件资源的情况下，该多个硬件资源与多个BMC一一对应连接。该多个BMC中的任意一个BMC(记作第一BMC)，通过该多个BMC中的部分或全部BMC，可以获取到组成该服务器的多个硬件资源中的部分或全部硬件资源的数据，进而根据获取到的硬件资源的数据，调整该部分或全部硬件资源的工作，来实现服务器的控制状态。

应理解，本申请实施例中所说的服务器的控制状态，也可以称作服务器的工作状态。具体地，服务器的工作状态可以通过多个参数进行衡量，例如，温度、风扇的转速、电压、功耗等等。举例来说，

第一BMC通过部分或全部BMC，获取部分或全部硬件资源的数据，进而可以了解到服务器的工作状态。后续，将组成服务器的多个硬件资源作为一个整体，通过调整部分或全部硬件资源的工作，实现对服务器的工作状态的控制，使服务器达到一个理想的工作状态。例如，将服务器的工作温度从30摄氏度调整为25摄氏度，可以认为控制状态(或者说，工作状态)发生了变化。

应用2

负载均衡

当一个机房里的服务器达到一定数量，通过BMC作单机管理，已经无法满足客户及机房管理员的要求，他们需求一个管理软件作为单一入口来管理这个机房里的全部服务器。

下面说明本申请的技术方案在此种情况下的应用。

如果是柜机服务器，首先需要将柜内全部的BMC与该管理软件对接。

假定，客户需要在管理软件上实时查看每个计算框的入风口和出风口的温度曲线。

按照现有的技术方案，管理软件通过直接访问每个计算框的BMC，获取该计算框的入风口和出风口的温度。但可能存在这么一种场景，例如当正在获取的这个计算框的入风口和出风口的温度时，另一个客户也需要管理这个计算框。这样就可能会出现这个计算框的BMC对外接收队列中存在太多的访问请求，导致数据无法及时返回。

而采用本申请的技术方案，将柜机服务内的全部硬件资源池化后，柜内任何一个BMC都可以直接访问资源池内所有的硬件资源。在某个计算框的BMC对外接收队列存在太多访问请求的情况下，管理软件可以通过访问柜内其它的BMC(例如，管理框的BMC或者其它计算框的BMC)来访问这个计算框的BMC，再通过内网访问这个计算框的BMC来获取这个计算框的入风口和出风口的温度值，从而将将这个被访问的计算框的BMC的对外接口的压力转移到柜内其它BMC，以起到柜内负载均衡的作用。

参见图7，图7是管理软件实现柜机内的BMC负载均衡的示意图。如图7中(1)所示为按照现有的技术方案，管理软件访问硬件资源的情况。如(1)中所示，管理软件分别通过计算框1的BMC和计算框2的BMC，获取计算框1内的硬件的数据和计算框2内的硬件的数据。即使计算框1的BMC对外接收队列较长，管理软件也只能通过计算框1的BMC来获取计算框1内的硬件的数据，访问延迟较大。计算框2也是类似的，不再赘述。

而图7中的(2)和(3)所示为采用本申请的技术方案时，管理软件访问硬件资源的情况。如(2)所示，在计算框1的BMC繁忙时，管理软件可以通过访问计算框2的BMC，再通过内网访问计算框1的BMC。同样地，在计算框2的BMC繁忙时，管理软件可以通过访问计算框1的BMC，再通过内网访问计算框2的BMC。可见，上层的管理软件可以分析各个BMC的繁忙程度，选择一些相对空闲的BMC来获取数据，可以实现整个柜机内BMC的负载均衡。

也就是说，任意一个BMC(记作第一BMC)接收到的资源访问请求，可以是访问设备在确定其它BMC的访问队列长度等于或大于预设队列长度的请求下发送给该第一BMC的。

可以理解的是，预设队列长度可以作为衡量一个BMC的繁忙程度的指标。例如，如果一个BMC的访问队列的长度小于该预设队列长度，则认为该BMC是相对空闲的，访问设备可以通过该BMC访问任意一个或多个硬件资源。如果一个BMC的访问队列的长度等于或者大于该预设队列长度，则认为该BMC比较繁忙。此时，访问设备可以通过访问其它BMC，起到为该BMC减轻负载的作用。

此外，本申请技术方案的容错性能提升。例如，在现有的技术方案中，如果某个BMC的对外网络出现故障，那么这个BMC管理的全部硬件的数据将无法返回给管理软件。而在本申请的技术方案中，对于任意一个BMC，只要该BMC上的运行的Proxy进程和驱动正常，且内网正常，则管理软件就可以通过其它BMC来进行访问，对于单点故障的容错性能提升。

以上结合图1至图7，对本申请提供的管理资源的方法作了详细说明。下面说明本申请实施例的管理资源的装置。

图8为本申请实施例的管理资源的装置500的示意性框图。参见图8，管理资源的装置500包括接收单元510和处理单元520。其中。装置500可以配置在由至少一个硬件资源组成的服务器，该至少一个硬件资源与至少一个基板管理控制器BMC一一对应连接，配置文件记录有该一个硬件资源与该至少一个BMC的对应关系；该至少一个BMC包括装置500和第二BMC，第二BMC对应连接该至少一个硬件资源中的目标硬件资源。

接收单元510，用于接收资源访问请求，资源访问请求中携带目标硬件资源的标识，资源访问请求用于请求获取目标硬件资源的数据；

处理单元520，用于根据配置文件，确定目标硬件资源的标识对应的第二BMC；

处理单元520，还用于通过第二BMC获取目标硬件资源的数据。

应理解，管理资源的装置500可以对应上述实施例中描述的第一BMC。

本申请实施例的装置500中的各单元和上述其它操作或功能分别为了实现管理资源的方法中由第一BMC执行的相应流程。为了简洁，此处不再赘述。

图9为本申请实施例的管理资源的装置600的示意性框图。参见图9，管理资源的装置600包括接收单元610、处理单元620和发送单元630。其中，装置600可以配置在由至少一个硬件资源组成的服务器；该至少一个硬件资源与至少一个基板管理控制器BMC一一对应连接；配置文件记录有该至少一个硬件资源与该至少一个BMC的对应关系；该至少一个BMC包括第一BMC和装置600，装置600对应连接该至少一个硬件资源中的目标硬件资源。

接收单元610，用于接收第一BMC发送的数据请求消息，数据请求消息请求获取目标硬件资源的数据，数据请求消息中携带有目标硬件资源的标识；

处理单元620，用于获取目标硬件资源的数据；

发送单元630，用于向第一BMC发送响应消息，响应消息中携带有目标硬件资源的数据。

类似地，管理资源的装置600可以对应上述实施例中描述的第二BMC。

本申请实施例的装置600中的各单元和上述其它操作或功能分别为了实现管理资源的方法中由第二BMC执行的相应流程。为了简洁，此处不再赘述。

图10为本申请实施例提供的管理资源的设备700的示意性结构图。如图10所示，设备700包括：一个或多个处理器701，一个或多个存储器702，一个或多个通信接口703。该处理器701用于控制通信接口703收发信号，该存储器702用于存储计算机程序，该处理器701用于从存储器702中调用并运行该计算机程序，使得该设备700执行管理资源的方法实施例中由第一BMC执行的相应流程和/或操作。为了简洁，此处不再赘述。

需要说明的是，图8中所示的装置500可以通过图10所示的设备700实现。例如，接收单元510可以由图10中的收发器703实现。处理单元520可以由处理器701实现等。

图11为本申请实施例提供的管理资源的设备800的示意性结构图。如图11所示，设备800包括：一个或多个处理器801，一个或多个存储器802，一个或多个通信接口803。该处理器801用于控制通信接口803收发信号，该存储器802用于存储计算机程序，该处理器801用于从存储器802中调用并运行该计算机程序，使得设备800执行管理资源的方法实施例中由第二BMC执行的相应流程和/或操作。为了简洁，此处不再赘述。

类似地，图9中所示的装置600可以通过图11中所示的设备800实现。例如，图9中的接收单元610可以由图11中的通信接口703实现。处理单元620可以由处理器801实现。发送单元630可以由通信接口703实现。

需要说明的是，当图10中的通信接口703为设备700的外部接口的情况下，通信接口703也可以为收发器。类似地，当图11中的通信接口803位设备800的外部接口的情况下，通信接口803也可以为收发器。

此外，本申请还提供一种供计算机程序产品，该计算机程序产品包括计算机程序代码，当该计算机程序代码在计算机上运行时，使得计算机执行管理资源的方法实施例中第一BMC执行的相应流程和/或操作。

此外，本申请还提供一种计算机可读介质，该计算机可读介质存储有程序代码，当程序代码在计算机上运行时，使得计算机执行管理资源的方法实施例中第一BMC执行的相应流程和/或操作。

此外，本申请还提供一种芯片系统，该芯片系统包括处理器，用于实现上述管理资源的方法中第一BMC执行的相应流程和/或操作。

在一种可能的设计中，该芯片系统还包括存储器，该存储器用于存储实现第一BMC执行的相应流程和/或操作的程序指令和数据。该芯片系统，可以由芯片构成，也可以包括芯片和其它分立器件。

此外，本申请还提供一种供计算机程序产品，该计算机程序产品包括计算机程序代码，当该计算机程序代码在计算机上运行时，使得计算机执行管理资源的方法实施例中第二BMC执行的相应流程和/或操作。

此外，本申请还提供一种计算机可读介质，该计算机可读介质存储有程序代码，当程序代码在计算机上运行时，使得计算机执行管理资源的方法实施例中第二BMC执行的相应流程和/或操作。

此外，本申请还提供一种芯片系统，该芯片系统包括处理器，用于实现上述管理资源的方法中第二BMC执行的相应流程和/或操作。

在一种可能的设计中，该芯片系统还包括存储器，该存储器用于存储实现第二BMC执行的相应流程和/或操作的程序指令和数据。该芯片系统，可以由芯片构成，也可以包括芯片和其它分立器件。

以上实施例中，处理器可以为中央处理器(Central Processing Unit，CPU)、微处理器、特定应用集成电路(Application-Specific Integrated Circuit，ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路等。例如，处理器可以包括数字信号处理器设备、微处理器设备、模数转换器、数模转换器等。处理器可以根据这些设备各自的功能而在这些设备之间分配移动设备的控制和信号处理的功能。此外，处理器可以包括操作一个或多个软件程序的功能，软件程序可以存储在存储器中。

处理器的所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。

存储器可以是只读存储器(Read-Only Memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(Random Access Memory，RAM)或者可存储信息和指令的其他类型的动态存储设备。也可以是电可擦可编程只读存储器(ElectricallyErasable Programmable Read-Only Memory，EEPROM)、只读光盘(Compact Disc Read-Only Memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

可选的，上述的存储器与存储器可以是物理上相互独立的单元，或者，存储器也可以和处理器集成在一起。

结合前面的描述，本领域的技术人员可以意识到，本文实施例的方法，可以通过硬件(例如，逻辑电路)，或者软件，或者硬件与软件的结合来实现。这些方法究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

当上述功能通过软件的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。在这种情况下，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(RandomAccess Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (14)

1.一种管理资源的方法，其特征在于，应用于由至少一个硬件资源组成的服务器；所述至少一个硬件资源与至少一个基板管理控制器BMC一一对应连接，配置文件记录有所述至少一个硬件资源与所述至少一个BMC的对应关系；所述至少一个BMC包括第一BMC和第二BMC，所述第二BMC对应连接所述至少一个硬件资源中的目标硬件资源；所述方法包括：

所述第一BMC接收资源访问请求，所述资源访问请求中携带目标硬件资源的标识，所述资源访问请求用于请求获取所述目标硬件资源的数据；

所述第一BMC根据所述配置文件，确定所述目标硬件资源的标识对应的第二BMC；

所述第一BMC通过所述第二BMC获取所述目标硬件资源的数据。

2.根据权利要求1所述的方法，其特征在于，所述第一BMC通过所述第二BMC获取所述目标硬件资源的数据，包括：

所述第一BMC与所述第二BMC建立套接字；

所述第一BMC通过所述套接字向所述第二BMC发送数据请求消息；

所述第一BMC从所述第二BMC接收响应消息，所述响应消息中携带所述目标硬件资源的数据。

3.根据权利要求2所述的方法，其特征在于，所述第一BMC与所述第二BMC建立套接字，包括：

所述第一BMC根据所述配置文件，确定所述目标硬件资源的标识对应的芯片的类实例；

所述第一BMC确定所述芯片的类实例对应的总线的类实例；

所述第一BMC根据所述总线的类实例，确定所述第二BMC的标识和端口；

所述第一BMC基于所述第二BMC的标识和端口，与所述第二BMC建立套接字。

4.根据权利要求1至3中任一项所述的方法，其特征在于，所述方法还包括：

所述第一BMC通过所述至少一个BMC中部分或全部BMC获取所述至少一个硬件资源中部分或全部硬件资源的数据；

所述第一BMC根据获取到的硬件资源的数据，调整所述至少一个硬件资源的工作来组合实现对所述服务器状态控制。

5.根据权利要求1至4中任一项所述的方法，其特征在于，所述资源访问请求是所述第一BMC从访问设备接收的，所述资源访问请求是所述访问设备在确定所述第二BMC的访问队列的长度大于或等于预设队列长度的情况下发送给所述第一BMC的。

6.一种管理资源的方法，其特征在于，应用于由至少一个硬件资源组成的服务器；所述至少一个硬件资源与至少一个基板管理控制器BMC一一对应连接，所示至少一个BMC包括第一BMC和第二BMC，所述第二BMC对应连接所述至少一个硬件资源中的目标硬件资源，所述方法包括：

所述第二BMC接收第一BMC发送的数据请求消息，所述数据请求消息用于请求获取所述目标硬件资源的数据，所述数据请求消息中携带有所述目标硬件资源的标识；

所述第二BMC获取所述目标硬件资源的数据；

所述第二BMC向所述第一BMC发送响应消息，所述响应消息中携带所述目标硬件资源的数据。

7.根据权利要求6所述的方法，其特征在于，所述第二BMC接收所述第一BMC发送的数据请求之前，所述方法还包括：

所述第二BMC与所述第一BMC建立套接字；

以及，所述第二BMC接收第一BMC发送的数据请求消息，包括：

所述第二BMC接收所述第一BMC通过所述套接字发送的所述数据请求消息。

8.一种管理资源的装置，其特征在于，配置于由至少一个硬件资源组成的服务器；所述至少一个硬件资源与至少一个基板管理控制器BMC一一对应连接，配置文件记录有所述一个硬件资源与所述至少一个BMC的对应关系；所述至少一个BMC包括所述装置和第二BMC，所述第二BMC对应连接所述至少一个硬件资源中的目标硬件资源；所述装置包括：

接收单元，用于接收资源访问请求，所述资源访问请求中携带所述目标硬件资源的标识，所述资源访问请求用于请求获取所述目标硬件资源的数据；

处理单元，用于根据所述配置文件，确定所述目标硬件资源的标识对应的第二BMC；

所述处理单元，还用于通过所述第二BMC获取所述目标硬件资源的数据。

9.根据权利要求8所述的装置，其特征在于，所述处理单元具体用于：

与所述第二BMC建立套接字；

以及，所述装置还包括发送单元，所述发送单元用于通过所述套接字向所述第二BMC发送数据请求消息；

以及，所述接收单元还用于从所述第二BMC接收响应消息，所述响应消息中携带所述目标硬件资源的数据。

10.根据权利要求9所述的装置，其特征在于，所述处理单元具体用于：

根据所述配置文件，确定所述目标硬件资源的标识对应的芯片的类实例；

确定所述芯片的类实例对应的总线的类实例；

根据所述总线的类实例，确定所述第二BMC的标识和端口；

基于所述第二BMC的标识和端口，与所述第二BMC建立套接字。

11.根据权利要求8至10中任一项所述的装置，其特征在于，所述处理单元还用于：

通过所述至少一个BMC中部分BMC或全部BMC获取所述至少一个硬件资源中部分或全部硬件资源的数据；

根据获取到的硬件资源的数据，调整所述至少一个硬件资源的工作来组合实现对所述服务器的状态控制。

12.根据权利要求8至11中任一项所述的装置，其特征在于，所述资源访问请求是所述第一BMC从访问设备接收的，所述资源访问请求是所述访问设备在确定所述第二BMC的访问队列的长度大于或等于预设队列长度的情况下发送给所述第一BMC的。

13.一种管理资源的装置，配置于由至少一个硬件资源组成的服务器；所述至少一个硬件资源与至少一个基板管理控制器BMC一一对应连接；配置文件记录有所述至少一个硬件资源与所述至少一个BMC的对应关系；所述至少一个BMC包括第一BMC和所述装置，所述装置对应连接所述至少一个硬件资源中的目标硬件资源；所述装置包括：

接收单元，用于接收第一BMC发送的数据请求消息，所述数据请求消息用于请求获取所述目标硬件资源的数据，所述数据请求消息中携带有所述目标硬件资源的标识；

处理单元，用于获取所述目标硬件资源的数据；

发送单元，用于向所述第一BMC发送响应消息，所述响应消息中携带所述目标硬件资源的数据。

14.根据权利要求13所述的装置，其特征在于，所述处理单元还用于与所述第一BMC建立套接字；

以及，所述接收单元具体用于接收所述第一BMC通过所述套接字发送的所述数据请求消息。