现有OpenStack架构的基础上增加了一个资源池调度处理逻辑(以下简称调度逻辑)，该调度逻辑具体是增加在OpenStack控制器中，负责接收上层应用程序编程接口(Applicat1n Programming Interface, API)调用，根据预设调度策略灵活、动态的为用户分配最合理资源节点。
[0053]具体地，该调度逻辑接收用户的输入消息；该输入消息可以包括业务的创建请求，甚至可以包括对业务的性能要求。例如，用户可以通过输入消息申请一个防火墙服务，要求该防火墙业务的处理性能为lGbbp/s。
[0054]当该调度逻辑收到用户的输入消息时，可以为该用户创建对应的业务以及分配合理的资源节点，并在为用户决策出最优的资源节点时，将决策结果返回给该用户。
[0055]具体地，该调度逻辑可以对资源池内各资源节点的不同性能参数进行周期性的探测，以实时监测资源池内各资源节点的负载以及运行状态。例如，通用的OpenStack架构中，通常包括FWaaS、VPNaaS以及LBaaS等为用户提供网络安全解决方案的业务模块，因此可以对资源池内与各资源节点的不同性能参数进行周期性的探测，从而达到实时监测资源池内各资源节点的负载与运行状态的目的。
[0056]其中，在对资源池内各资源节点的不同性能参数进行周期性的探测时，该性能参数可以是预先配置的性能参数，也可以是根据输入消息中用户对业务资源的具体性能要求而得出的性能参数，在本实施例中不进行特别限定，本领域技术人员可以结合实际的用户需求灵活选择。
[0057]例如，在本实施例示出的一种优选方案中，该性能参数可包括资源节点的CPU使用率、内存使用率以及其他可以表征资源节点的资源可利用度的业务性能参数；该业务性能参数，可以是业务流量大小、业务响应时间等参数，在具体实现时，业务流量较小以及业务响应时间较短的资源节点资源可利用度更高。
[0058]在本实施例中，该调度逻辑根据周期性的探测结果，确定出各资源节点中的可分配资源节点；当确定出各资源节点中的可分配资源节点后，该调度逻辑再结合预设的资源调度策略从可分配资源节点中为用户分配合理的资源节点。
[0059]具体地，该调度逻辑首先判断各资源节点的CPU使用率和/或内存使用率是否大于预设阈值，通过对各资源节点的CPU使用率和/或内存使用率进行阈值化处理，可将各资源节点划分为可分配资源节点和不可分配资源节点。
[0060]对于CPU使用率和/或内存使用率大于预设阈值的资源节点，为不可分配资源节点，将不再进行分配；对于CPU使用率和/或内存使用率低于预设阈值的资源节点，为可分配资源节点，将由该调度逻辑在收到用户的业务请求时，结合各资源节点的优先级以及业务性能参数，或者其他对业务有直接影响的性能参数，动态灵活的为该用户进行分配。
[0061]其中，所述阈值的大小在本实施例中不进行特别限定，可根据实际的用户需求进行设置。例如，如果用户想要申请一个处理性能为lGbbp/s的防火墙服务，假设资源节点的CHJ使用率高于70%时，该资源节点的处理性能将不能满足lGbbp/s的需求，那么此时可以将所述阈值设置为70%。
[0062]进一步地，该调度逻辑在对可分配资源节点进行分配时，可以首先比较各资源节点的优先级，将优先级最高的资源节点作为最优资源节点分配给用户。当可分配资源节点中，包括多个优先级相同的最优资源节点时，则进一步比较该多个优先级相同的最优资源节点的业务性能参数，分别得出资源可利用度，以决策出为用户分配的最优资源节点。
[0063]具体地，当可分配资源节点中，包括多个优先级相同的最优资源节点时，可以进一步比较该多个优先级相同的最优资源节点的业务流量大小，选择该多个优先级相同的最优资源节点中业务流量较小的资源节点分配给该用户。
[0064]如果该多个优先级相同的最优资源节点中业务流量也相同，还可以进一步比较该多个优先级相同的最优资源节点的业务响应时间，选择业务响应时间较短的资源节点分配给该用户。
[0065]如果该多个优先级相同的最优资源节点中业务响应时间仍然相同，该调度逻辑还可以在资源节点随机为该用户分配一个，或者选择其他可以表征业务资源可利用度的性能参数继续进行比较，直到选择出合适的资源节点分配给该用户。
[0066]值得说明的是，以上实施例示出的预设调度策略仅为示例性的较佳实施例，在具体实现时本领域技术人员可以根据用户的实际需求制定具体的调度策略，在本实施例中不再进行列举。
[0067]由以上描述可知，本实施例示出的OpenStack架构中，通过对各资源节点性能参数进行实时监测，并结合预设的调度策略给用户分配合理的资源节点，可以优化OpenStack架构中业务资源的分配，灵活、动态的进行资源调度，提高了资源的利用率，而且不会造成某一资源节点超负荷运转，而其他一些资源节点却闲置的现象。
[0068]以下通过一个具体的应用实例，来详细描述本发明。
[0069]请继续参见图3,假设当前资源池中有个4个Firewalls资源节点，分别为A、B、C、D ;某用户通过输入以下消息来申请一个处理性能为lGbbp/s的防火墙服务:
[0070]Firewalls Request (请求获得一个防火墙服务):
[0071]GET/v2.0/fw/firewalls.json
[0072]User-Agent:python-neutronclient
[0073]Accept: applicat1n/json
[0074]当该调度逻辑接收上层的API调用，获得这一输入消息后，通过预设调度策略为该用户分配合理的资源节点。
[0075]具体地，该调度逻辑实时监测各Firewalls资源节点的CPU使用率、内存使用率、业务流量大小、业务响应时间等性能参数，并根据监测结果确定出可分配的资源节点后，从可分配的资源节点中为该用户分配合理的资源节点。
[0076]假设CPU使用率和内存使用率均高于70%时，各Firewalls资源节点的处理性能将不能满足lGbbp/s的要求，因此可以使用阈值70%将各Firewalls资源节点划分为可分配Firewalls资源节点和不可分配Firewalls资源节点。假设资源池中Firewalls资源节点A的CPU使用率和内存使用率均高于70%，Firewalls资源节点B、C、D的CPU使用率和内存使用率均低于70%,那么Firewalls资源节点A为不可分配资源节点,FirewalIs资源节点B、C、D为可分配资源节点。
[0077]当划分完成后，该调度逻辑在可分配Firewalls资源节点B、C、D中为该用户分配最优的Firewalls资源节点。
[0078]该调度逻辑首先比较Firewalls资源节点B、C、D的优先级,选择优先级最高的Firewalls资源节点分配给该用户。
[0079]假如FirewalIs资源节点B、C、D的优先级分别为1、2、2，那么该调度逻辑将Firewalls资源节点B分配给该用户(优先级取值越小优先级越高)。
[0080]假如Firewalls资源节点B、C、D的优先级分别为1、1、2，那么该调度逻辑再进一步比较资源节点B和C的业务流量大小；如果此时资源节点B的业务流量较小，那么该调度逻辑将资源节点B分配给该用户。
[0081]如果此时资源节点B和C的业务流量仍然相同，那么再进一步比较资源节点B和C的业务响应时间，如果此时资源节点B的业务响应时间更短，那么该调度逻辑将资源节点B分配给该用户。
[0082]如果所述资源节点B和C的业务响应时间仍然相同，该调度逻辑还可以在资源节点B和C中随机为该用户分配一个，或者选择其他可以表征业务资源可利用度的性能参数继续进行比较，直到选择出合适的资源节点分配给该用户。
[0083]当该调度逻辑最终为该用户决策出最优的资源节点时，将该资源节点的相关信息返回给该用户。
[0084]例如，假如该调度逻辑最终将资源节点B分配给了该用户，此时返回的防火墙服务信息如下:
[0085]Firewalls:Response
[0086]"firewalls":
[0087]//admin_state_up//: true,
[0088]"descript1n":"",
[0089]〃fi