CN104144183A - 数据中心系统及数据中心系统的管理方法 - Google Patents

Abstract

本发明提供一种数据中心系统和数据中心系统的管理方法。在由通信网络连续用户、多个数据中心站点、指令部、多个站点代理部而构成的数据中心系统中，当用户向指令部发送应用请求时，指令部根据所有种类的应用所需的资源估算运行用户请求的应用所需的资源，根据各数据中心站点的资源使用状态和估算的所需的资源计算在各个数据中心站点运行用户请求的应用的电力成本和带宽成本，指令部向运行用户请求的应用的电力成本与带宽成本之和最低的数据中心站点的站点代理部发送应用运行请求，接收到应用运行请求的站点代理部将请求运行的应用分配给该站点代理部管理的服务器。由此避免了分别优化电力成本或带宽成本产生的不平衡，从而减少了数据中心的总运营成本。

Description

数据中心系统及数据中心系统的管理方法

技术领域

本发明涉及数据中心，特别是涉及数据中心系统及数据中心系统的管理方法。

背景技术

数据中心作为高速发展的云计算产业的基础设施，对成本管理有高度要求。特别是随着IT设备计算能力和设备密度的增长，初期建设成本和设备购置成本在数据中心的总体成本中的比重逐渐下降，而运营成本、特别是电力成本正在不断增加，并且达到了和设备购置成本相近的比重。因此数据中心的运营成本正在受到越来越多的关注，并产生了一些能降低数据中心运营成本的方法和技术。

例如，在公知技术US 2011/0191773 A1中，公开了一种数据中心能耗管理的系统和方法。所述方法包括，对多个数据中心中的每一个都至少部分地根据在各个数据中心执行应用所需的电力来判定在各个数据中心执行应用相关的成本。所述方法还包括根据在各个数据中心执行应用相关的成本来从多个数据中心中选择一个来执行应用，并且在所选的数据中心执行应用。

该方法通过优化负载（也就是所述的应用，下文中统称为负载）在多个数据中心中的分配来最小化作为一个整体考虑的所述多个数据中心的电力成本，从而降低了所述多个数据中心的运营成本。但是数据中心的运营成本除了电力成本通常还包括固定资产折旧、人工费、以及带宽成本。其中固定资产折旧和人工费通常为固定费用支出，而带宽成本和电力成本一样，属于可以优化的费用支出。特别是在中国，和其他国家相比，带宽较贵而电价较低，导致带宽成本成为影响数据中心总运营成本的重要因素。例如，根据中国联通在2009年的报告，带宽成本占其数据中心总运营成本的29%，而电力成本占28%。

此外，在中国目前大多数省市执行的电价是分季节和峰平谷分时段的电价，还没有实现逐时或逐分实时电价，这使得不同地区以及不同时间的电价变化相对较小，部分的局限了公知技术中的优化效果。同时，中国不同地区的网络建设差异较大，带宽定价较为灵活，使得不同地区的单位带宽价格差异较大，具有潜在的优化可能性。例如，根据发明人的调研，在中国不同城市的带宽价格的变异系数（CV）是0.32，而电力价格的变异系数是0.12。也就是说，对于中国的数据中心，在不同地区执行负载所需要的带宽成本的差异要超过电力成本的差异。因此，如果使用公知技术来进行数据中心管理，可能无法得到最佳总运营成本。

此外，公知技术通过用基准测试得到的预设数据来估计给定负载的电力消耗。这不能处理不包含在基准测试中的新类型的负载。

发明内容

为了解决上述问题，本发明通过优化负载在多个数据中心中的分配来最小化所述多个数据中心的电力成本和带宽成本之和，从而降低了所述多个数据中心的总运营成本。此外，本发明对数据中心状态进行实时监测，并基于历史监测数据来在线估计在不同站点执行负载所需的电力和带宽消耗。

本发明的第一方面的数据中心系统包括：多个数据中心站点，每个数据中心站点包括一个以上用于处理用户的应用的服务器；指令部，其管理上述多个数据中心站点，并向用户提供应用服务；多个站点代理部，其对应上述多个数据中心站点的每一个而设置，管理各自的数据中心站点的状态并将应用分配给服务器运行；和通信网络，其连接用户、上述多个数据中心站点、上述指令部和上述站点代理部，上述指令部具有计算各个数据中心站点运行应用的、至少包括电力成本和带宽成本的运行成本的成本计算器，当用户向上述指令部发送应用请求时，上述指令部根据所有种类的应用所需的资源估算运行用户请求的应用所需的资源，上述成本计算器根据各数据中心站点的资源使用状态和估算的所需的资源计算在各个数据中心站点运行用户请求的应用的电力成本和带宽成本，上述指令部向运行用户请求的应用的电力成本与带宽成本之和最低的数据中心站点的站点代理部发送应用运行请求，接收到上述应用运行请求的站点代理部将请求运行的应用分配给该站点代理部管理的服务器。

本发明的第二方面的数据中心系统的管理方法，上述数据中心系统通过通信网络联接用户、多个数据中心站点、指令部和站点代理部而构成，上述多个数据中心站点的每一个都包括一个以上的服务器，上述数据中心系统的管理方法包括：上述指令部接收来自用户的应用请求，根据所有种类的应用所需的资源估算运行用户请求的应用所需的资源的步骤；根据各个数据中心站点的状态和估算的所需的资源计算在各个数据中心站点运行用户请求的应用的、至少包括电力成本和带宽成本的运行成本的步骤；上述指令部向运行用户请求的应用的电力成本与带宽成本之和最低的数据中心站点的站点代理部发送应用运行请求的步骤；和接收到上述应用运行请求的站点代理部将请求运行的应用分配给该站点代理部管理的服务器的步骤。

根据本发明的数据中心系统及数据中心系统的管理方法，同时考虑了数据中心总运营成本中的电力成本和带宽成本的优化，避免了分别优化电力成本或带宽成本产生的不平衡，从而减少了数据中心的总运营成本。本发明还可以处理任何类型的负载，而不需要预先设定的基准测试。

附图说明

根据以下结合附图对本发明非限制实施例的详细描述，本发明的以上和其他目的、特征和优点将变得更加清楚，其中：

图1表示具有全局负载均衡的多站点数据中心系统结构。

图2表示指令器的结构。

图3表示运行在虚拟机上的站点代理的结构。

图4表示处理流类型需求的时序。

图5表示处理MapReduce类型需求的时序。

图6表示选择第二低成本站点的时序。

图7表示为业务选择站点失败的时序。

图8表示指令器选择具有优化成本的站点的流程图。

图9是表示站点代理为从指令器来的负载请求选择服务器的流程图。

图10是表示指令器为业务需求估计资源需求并生成负载描述的流程图。

图11是表示站点代理在业务资源增量表中记录流类型负载的业务运行时资源消耗的流程图。

图12是表示站点代理在业务资源增量表中记录MapReduce类型负载的业务运行时资源消耗的流程图。

图13是表示站点代理分析站点状态并发送站点状态消息的流程图。

图14是表示站点代理调节开机中的服务器和上联带宽的数量的流程图。

图15是表示指令器从站点代理收到站点状态消息并更新站点状态表和业务资源需求表的流程图。

图16表示全局负载列表的格式。

图17表示站点状态表的格式。

图18表示业务资源需求表的格式。

图19（a）表示了站点11的本地负载列表的格式；图19（b）表示了站点12的本地负载列表的格式。

图20表示站点11的服务器状态表的格式。

图21表示站点11的业务资源增量表的格式。

图22表示站点状态消息的格式。

图23表示负载请求消息的格式。

具体实施方式

下面参照附图说明本发明的实施方式。图中相同的符号代表相同的部件。

图1表示了具有全局负载均衡的多站点数据中心系统结构。图中的三个数据中心11、12、13（以下也称数据中心站点或站点）由指令器20进行管理，并通过IP核心网40向位于局域网50的客户51提供服务。所述数据中心站点11包括用于执行计算任务的服务器111、112、113；用于连接服务器111、112、113和转发业务数据的交换机114；用于连接交换机114和IP核心网40的边缘路由器115；用于存储数据的存储117、118、119；用于连接存储117、118、119和服务器111、112、113的交换机116；以及用于管理数据中心站点11并具有本地负载列表301、服务器状态表302和业务资源增量表303的站点代理30。站点12和13具有和站点11类似的结构，图中省去站点12和13的具体结构。所述指令器20用于站点11、12、13的集中管理，包括全局负载列表201、站点状态表202和业务资源需求表203。指令器20和站点代理30均为逻辑功能模块，在实现方式上，可以作为独立设备存在，通过网络和各站点相连接，也可以作为一个或多个软件，运行在数据中心站点内的一台或多台服务器上。特别是指令器20，在逻辑上是集中式管理模块，在物理上既可以是集中的方式也可以是分布的方式，例如分布运行在位于站点11、12、13的某些服务器上。所述IP核心网40连接业务的提供方和使用方，对业务数据进行转发，包括分别用于连接数据中心站点11、12、13的边缘路由器44、43、36，连接局域网50的边缘路由器41，以及中间路由器42、45。局域网50除了具有客户51，还可以有其他客户，都通过边缘路由器52和IP核心网40相连接。

客户51产生的业务需求61首先通过局域网50和IP核心网40发送到指令器20，经过指令器20的处理得到相关负载的描述且记录到全局负载列表201中后，发送负载请求63到例如站点11（或者其他站点），使得站点11的站点代理30把相关负载记录到本地负载列表301中，并通过站点11中的服务器和存储等设备向客户51提供业务。同时，站点11、12、13监测自身状态，例如站点代理30通过监测信息60把服务器111、112、113的状态记录到服务器状态表302中，把正在运行的业务的状态记录到业务资源增量表303中，并通过站点状态62向指令器20定期报告自身状态，使得指令器20把各站点的状态记录到站点状态表202和业务资源需求表203中，在处理业务需求61的时候能以此作为依据。

图2表示了指令器20的结构。指令器20用于站点11、12、13的集中管理，包括用于记录所有负载的描述信息的全局负载列表201，用于记录所有数据中心站点的资源使用情况的站点状态表202，用于记录所有种类的业务的资源消耗情况的业务资源需求表203，用于给每一个业务需求61选择成本最优的执行站点的全局均衡器204，用于计算对某个给定负载在各个站点可能会消耗的电力成本和带宽成本的成本计算器205，用于给业务需求61估计可能要消耗的计算资源和带宽资源的需求处理器206，用于向站点代理30、209、210发送负载请求63并从所述站点代理接收站点状态62的消息接口207，以及用于运行或存储以上模块的虚拟机或虚拟机集群208。所述站点代理209、210分别位于数据中心站点12、13并管理所在站点。如前所述，指令器20在实现方式上，可以作为独立设备存在，通过网络和各站点相连接，也可以作为一个或多个软件，运行在数据中心站点内的一台或多台服务器上。也就是说，指令器20的虚拟机或虚拟机集群208可以运行在一个位于站点11、12、13之外的例如服务器的独立设备上，也可以运行在位于站点11、12、13的一个或多个的一个或多个服务器上。

类似的，站点代理30也可以作为独立设备存在，或者作为一个或多个软件，运行在数据中心站点11内的一台或多台服务器上。在本实施例中，站点代理30作为虚拟机312运行在服务器111上。图3表示了运行在虚拟机111上的站点代理30的结构。站点代理30用于管理数据中心站点11，包括用于记录分配给站点11的负载的描述信息的本地负载列表301、用于记录站点11的服务器111、112、113的资源使用情况的服务器状态表302、用于记录在站点11的所有种类的业务的资源消耗情况的业务资源增量表303、用于给每一个负载请求63选择执行服务器的本地均衡器304、用于监测和控制基础设施330的基础设施控制接口305、用于监测和控制例如交换机115的网络设备的网络控制接口306、用于监测和控制各服务器上运行的管理器（Hypervisor）的控制接口307、用于从指令器20接收负载请求63并向指令器20发送站点状态62的消息接口308、以及用于运行或存储以上模块的虚拟机操作系统309。

站点代理30所在的物理服务器111使用虚拟机技术运行包括站点代理30在内的多个虚拟机。具体的，物理服务器111包括具有处理器320、内存321、存储322、电源323和物理网卡324的物理资源319，具有硬件监控器317和虚拟机监控器318并把物理资源319虚拟化后提供给虚拟机的管理器316，以及运行在管理器316之上并提供实际业务的虚拟机310、311、312。其中管理器316可以通过硬件监控器317和虚拟机监控器318分别对物理资源319和虚拟机310、311、312进行监控，向管理器控制接口307报告监测到的状态信息，以及从管理器控制接口307接收例如关闭虚拟机和迁移虚拟机的控制信息。虚拟机310、311、312分别通过虚拟机网卡313、314、315和管理器316中的虚拟交换机（未示出）相连接，并进一步经过物理网卡324和交换机115和其他连接到网络上的设备进行通信。当然，虚拟机310、311、312也可以互相通信。此外，电源323和基础设施330相连接获得供电，而基础设施330在从基础设施控制接口305收到例如断开电源和接通电源的控制信息时，可以对电源323进行断开或接通，从而控制服务器111的断开或接通。基础设施330除了供电设施，还包括空调、照明、水循环等系统，在本实施例中没有涉及，因此未示出。

在本实施例中，将数据中心需要提供的业务分为两类，一类是流类型的业务，其中使用业务的客户和提供业务的一个服务器之间建立会话和连接，另一类是MapReduce类型的业务，其中把使用业务的客户提交的业务拆分成若干任务并分发给多个服务器来执行。下面在图4和图5中分别对处理这两种业务的时序进行描述。

图4表示了处理流类型需求的时序。首先由客户51向指令器20发送业务需求61（步骤401）。指令器20的需求处理器206在判断此业务需求61为流类型的业务后，为该业务生成负载描述并添加到全局负载列表201中（参考图10的流程图），然后指令器20的全局均衡器204和成本计算器205从所有数据中心站点中选择一个对于执行所述负载具有最低成本的站点（参考图8的流程图），例如站点11（步骤402），并通过消息接口207向所选站点11的站点代理30发送负载请求63来通知所选站点11执行所述负载（步骤403）。当所选站点11的站点代理30通过消息接口308收到所述负载请求63时，站点代理30的本地均衡器304从站点11的服务器中选择一个合适的服务器（参考图9的流程图），例如服务器111，将选择结果和所述负载的描述信息一起添加到本地负载列表301中（步骤404），并向指令器20返回接受来确认执行负载（步骤405），使得指令器20从全局负载列表201中移除所述负载（步骤406）并向客户51返回所述业务的响应，例如包括站点11的IP地址（步骤407）。同时站点代理30还向包括交换机115的站点11的网络120发送增加新条目的消息来通知网络120（步骤408），使得网络120更新自己的流表（步骤409），从而为所述负载将会产生的数据流添加一条网络路径，以保证数据流可以正常的到达所选服务器111。当客户51收到来自指令器20的响应后，发起和服务器111之间的会话连接，开始从服务器111向客户提供服务（步骤410）。在业务结束后，例如客户51或服务器111结束了会话连接，站点代理30从本地负载列表301中移除所述负载（步骤411），同时通知网络120拆除相应的网络路径（未示出）。

图5表示了处理MapReduce类型需求的时序。首先由客户51向指令器20发送业务需求61（步骤501）。指令器20的需求处理器206在判断此业务需求61为MapReduce类型的业务后，将该业务拆分（Map）成多个任务（Task），为该业务生成负载描述，并添加到全局负载列表201中（参考图10的流程图），然后指令器20的全局均衡器204和成本计算器205从所有数据中心站点中选择一个对于执行所述负载具有最低成本的站点（参考图8的流程图），例如站点11（步骤502），并通过消息接口207向所选站点11的站点代理30发送负载请求63来通知所选站点11执行所述负载（步骤503）。当所选站点11的站点代理30通过消息接口308收到所述负载请求63时，站点代理30的本地均衡器304从站点11的服务器中选择一个或多个合适的服务器（参考图9的流程图），例如服务器111，将选择结果和所述负载的描述信息一起添加到本地负载列表301中（步骤504），并向指令器20返回接受来确认执行负载（步骤505），使得指令器20将所述多个任务的例如输入数据的信息发送到站点代理30（步骤506）后从全局负载列表201中移除所述负载（步骤507）。站点代理30在收到任务后分别转发给所选的一个或多个服务器，例如服务器111（步骤508）。然后所选的一个或多个服务器，例如服务器111，各自执行从站点代理30收到的任务（步骤509）。执行结果作为输出经过站点代理30转发到指令器20（步骤510），并在指令器20对来自一个或多个服务器的输出进行合并（Reduce）（步骤512）。期间站点代理30在转发输出后从本地负载列表301中移除所述负载（步骤511）。最后指令器20使用合并后的结果向客户51发送包含最终执行结果的响应（步骤513）。

在某些情况下，图4和图5中选择的最低成本的站点可能会拒绝执行任务，例如站点的总可用资源大于业务的资源需求，但是单个服务器的最大可用资源小于业务的资源需求，或者站点状态62的传输和处理延时造成站点状态表202和实际上的站点状态之间存在差异。在这种情况下，指令器20需要顺序选择成本次优的站点。

图6表示了选择第二低成本站点的时序。首先由客户51向指令器20发送业务需求61（步骤601）。指令器20为该业务生成负载描述并添加到全局负载列表201中（参考图10的流程图），然后指令器20的全局均衡器204和成本计算器205从所有数据中心站点中选择一个对于执行所述负载具有最低成本的站点（参考图8的流程图），例如站点11（步骤602），并通过消息接口207向所选站点11的站点代理30发送负载请求63来通知所选站点11执行所述负载（步骤603）。当所选站点11的站点代理30通过消息接口308收到所述负载请求63时，站点代理30的本地均衡器304进行站点内服务器的选择失败（参考图9的流程图，步骤604），并向指令器20返回拒绝来拒绝执行负载（步骤605）。指令器20收到拒绝消息后，继续从除了站点11之外的数据中心站点中选择一个对于执行所述负载具有最低成本的站点，也就是在所有数据中心站点中具有第二低成本的站点（参考图8的流程图），例如站点12（步骤606），并通过消息接口207向所选站点12的站点代理209发送负载请求63来通知所选站点12执行所述负载（步骤607）。当所选站点12的站点代理209收到所述负载请求63时，站点代理209从站点12的服务器中选择一个合适的服务器（参考图9的流程图），将选择结果和所述负载的描述信息一起添加到站点代理209的本地负载列表中（步骤608），并向指令器20返回接受来确认执行负载（步骤609），使得指令器20从全局负载列表201中移除所述负载（步骤610）并向客户51返回所述业务的响应（步骤611），或者执行类似图5中步骤506-步骤513的对MapReduce类业务的后继处理（未示出）。

图7表示了为业务选择站点失败的时序。首先由客户51向指令器20发送业务需求61（步骤701）。指令器20为该业务生成负载描述并添加到全局负载列表201中（参考图10的流程图），然后指令器20的全局均衡器204和成本计算器205从所有数据中心站点中选择一个对于执行所述负载具有最低成本的站点（参考图8的流程图），例如站点11（步骤702），并通过消息接口207向所选站点11的站点代理30发送负载请求63来通知所选站点11执行所述负载（步骤703）。

当所选站点11的站点代理30通过消息接口308收到所述负载请求63时，站点代理30的本地均衡器304进行站点内服务器的选择失败（参考图9的流程图，步骤704），并向指令器20返回拒绝来拒绝执行负载（步骤705）。指令器20收到拒绝消息后，继续从除了站点11之外的数据中心站点中选择一个对于执行所述负载具有最低成本的站点，也就是在所有数据中心站点中具有第二低成本的站点（参考图8的流程图），例如站点12（步骤706），并通过消息接口207向所选站点12的站点代理209发送负载请求63来通知所选站点12执行所述负载（步骤707）。

当所选站点12的站点代理209收到所述负载请求63时，站点代理209进行站点内服务器的选择失败（参考图9的流程图，步骤708），并向指令器20返回拒绝来拒绝执行负载（步骤709）。指令器20收到拒绝消息后，继续从除了站点11、12之外的数据中心站点中选择一个对于执行所述负载具有最低成本的站点，也就是在所有数据中心站点中具有第三低成本的站点（参考图8的流程图），例如站点13（步骤710），并通过消息接口207向所选站点13的站点代理210发送负载请求63来通知所选站点13执行所述负载（步骤711）。

当所选站点13的站点代理210收到所述负载请求63时，站点代理210进行站点内服务器的选择失败（参考图9的流程图，步骤712），并向指令器20返回拒绝来拒绝执行负载（步骤713）。指令器20收到拒绝消息后，发现对于所述负载的可用站点为空，因此判定为所述业务选择站点失败（参考图8的流程图），从全局负载列表201中移除所述负载（步骤714），并向客户51返回失败来拒绝客户的业务需求61（步骤715）。

下面结合具体的流程图对图4-图7中涉及的指令器20和站点代理30的处理过程进行说明。在图8-图23中所使用的用字母表示的序号指代含义为，i表示某个数据中心站点，n表示站点内的某个服务器，j表示某个具体的业务或负载，k表示某个业务类型，p表示MapReduce类业务或负载拆分得到的某个任务。

图8表示了指令器20选择具有优化成本的站点的流程图。如图4-图7中所述，当指令器20收到第j个（例如，j=2）业务需求61时（步骤801），指令器20的需求处理器206根据业务资源需求表203估计第j个业务需求61的处理器资源需求R_CPU(j,t)和带宽资源需求R_bw(j,t),产生第j个需求对应的负载描述（参考图10的流程图，步骤802）,并把产生的第j个负载添加到全局负载列表201中（参考图16的表格式，步骤803）。然后指令器20的成本计算器205根据所述资源需求R_CPU(j,t),R_bw(j,t)和站点状态表202依次计算在第i个（i=1,2,3）站点执行第j个负载时可能消耗的电力成本（步骤804）：

$C_{\mathrm{elc}}(j,i)={\∫}_{t=t_0}^{t_j}{R}_{\mathrm{CPU}}(j,t)*N_{\mathrm{elc}}(i,t_0)/\mathrm{PUE}(i,t_0)*\mathrm{dt}$

其中，C_elc(j,i)是第i个站点执行第j个负载时可能消耗的电力成本，N_elc(i,t₀)是第i个站点在当前时间t₀的电力系数，PUE(i,t₀)是第i个站点在当前时间t₀的电源使用效率（Power Usage Effectiveness），t_j是第j个负载可能执行的时长。既然负载的可能执行时长对每一个数据中心站点是不变的，并不影响最后的优化结果，因此t_j可以设定为单位时长，例如1秒。

类似的，指令器20的成本计算器205根据所述资源需求R_CPU(j,t),R_bw(j,t)和站点状态表202依次计算在第i个（i=1,2,3）站点执行第j个负载时可能消耗的带宽成本（步骤805）：

$C_{\mathrm{bw}}(j,i)={\∫}_{t=t_0}^{t_j}{R}_{\mathrm{bw}}(j,t){*N}_{\mathrm{bw}}(i,t_0)*\mathrm{dt}$

其中，C_bw(j,i)是第i个站点执行第j个负载时可能消耗的带宽成本，N_bw(i,t₀)是第i个站点在当前时间t₀的带宽系数，t_j是第j个负载可能执行的时长，例如1秒。

在成本计算器205完成对所有站点的成本计算后，把中间计算结果C_elc(j,i)和C_bw(j,i)发送给全局均衡器204，并由全局均衡器204选择具有最小电力成本及带宽成本之和（即Min(Sum(C_elc(j,i),C_bw(j,i)))的站点，例如站点11（步骤806）。然后全局均衡器204检查站点状态表202中所选站点对应条目中的站点忙碌标识来判断所选站点是否忙碌（参考图17的表格式，步骤807）。如果步骤807的判断结果为否，则通过消息接口207向所选站点11的站点代理30发送负载请求63来通知所选站点11执行所述负载（步骤808）。发出负载请求63的指令器20的全局均衡器204需要等待所选站点11的答复来判断所选站点11是否接受所述负载请求63（步骤809）。如果步骤809中收到接受消息，则把全局负载列表201的执行站点项更新为所选站点11的名称（例如PEK，步骤810），并响应客户51（参考图4、图5的时序图），最后把第j个负载从全局负载列表201中移除。如果步骤807的判断结果为是，或者如果步骤809中收到拒绝消息（判断结果为否），或者如果步骤809中等待答复超时（判断结果为否），则全局均衡器204把所选站点（例如站点11）从第j个负载的可用站点列表中移除（步骤813），检查对于第j个负载是否还有可用站点（步骤814）。如果步骤814的判断结果为是，则返回步骤806继续选择次优成本的站点。全局均衡器204可能会重复步骤806-步骤814的循环，直到某个选中的站点接受所述负载请求63，响应客户（步骤811），或者尝试完所有站点，在步骤814的判断结果为否，向客户发送失败（步骤815）。最后无论第j个负载的处理是成功还是失败，都将其从全局负载列表201中移除并进入下一个业务需求的处理（步骤812）。

图9表示了站点代理30为从指令器来的负载请求63选择服务器的流程图。如图4-图7中所述，当所选站点11的站点代理30通过消息接口308收到第j个负载产生的负载请求63时（步骤901），站点代理30的本地均衡器304从站点11的服务器中选择一个合适的服务器，或者选择服务器失败，并向答复指令器20是否接受所述负载请求63。在以上处理过程中，站点代理30的本地均衡器304首先检查负载请求63中的业务类型（参考图23的消息格式），判断所接收到的负载是否为流类型业务（步骤902）。如果步骤902的判断结果为是，则从负载请求63中读出第j个负载的处理器资源需求R_CPU(j,t)和带宽资源需求R_bw(j,t),将其设为选择一个服务器的算法的输入（步骤903），然后调用例如网络感知的负载均衡算法（参照中国专利申请CN201210033677.6）来根据R_CPU(j,t)、R_bw(j,t)和服务器状态表302从站点11的所有开机中的服务器中选择一个满足资源需求的服务器，例如服务器112（步骤904）。如果步骤902的判断结果为否，表示MapReduce业务，则从负载请求63中读出第j个负载的处理器资源需求R_CPU(j,t)、带宽资源需求R_bw(j,t)和任务数，将处理器资源需求R_CPU(j,t)和带宽资源需求R_bw(j,t)除以任务数后设为选择一个服务器的算法的输入（步骤905），然后调用例如网络感知的负载均衡算法（参照中国专利申请CN201210033677.6）来根据所述输入和服务器状态表302从站点11的所有开机中的服务器中为所述负载的下一个任务选择一个满足资源需求的服务器，例如服务器111（步骤906）。

运行完选择一个服务器的算法后，本地均衡器304查看运行结果是否包含可用的服务器和从边缘路由器115到达所述服务器的路径（步骤907）。如果步骤907的判断结果为是，则检查负载请求63中的业务类型和任务列表来判断是否完成负载请求63的处理（步骤908），步骤908具体包括如果步骤903-步骤906处理的是一个流类型负载或者是一个MapReduce负载的最后一个任务则判断结果为是，否则如果步骤903-步骤906处理的是一个MapReduce负载的最后一个任务之前的任务则判断结果为否。如果步骤908的判断结果为是，则本地均衡器304把负载和所选的一个或多个服务器{P(j,n)}加入到本地负载列表301（参考图19的表格式，步骤910），并通过消息接口308向指令器发送接受负载的答复消息（步骤911）。如果步骤908的判断结果为否，则返回步骤902继续处理MapReduce负载的下一个任务。对于流类型的负载，本地均衡器304只需要执行一遍步骤902-步骤907。而对于MapReduce负载，本地均衡器304需要重复步骤902-步骤907的循环，直到处理完该负载的所有任务。

如果步骤907的判断结果为否，表示当前无可用服务器或路径，则本地均衡器304检查站点11的服务器状态表302（参考图20的表格式）来判断在站点11中是否还有关机中的服务器（步骤912）。如果步骤912的判断结果为是，则通过基础设施控制接口305向站点11的基础设施330发送控制命令为一个随机选中的或根据空调运行状况及服务器物理位置选中的关机中的服务器的电源323接通，通过管理器控制接口307向所述服务器发送控制命令来产生一个新的虚拟机，以及通过网络控制接口306向包括交换机115的网络120发送控制命令来连接所述服务器和虚拟机，从而使一个关机中的服务器进入开机状态（步骤913），然后返回步骤902重新进行步骤902-步骤907的循环来选择服务器。如果步骤912的判断结果为否，则表示站点11无法再增加开机中的服务器的数量来增加资源，因此本地均衡器304通过消息接口308向指令器发送拒绝负载的答复消息（步骤911）。

图10表示了指令器20为业务需求61估计资源需求并生成负载描述的流程图，即图8中的步骤802的详细流程。在估计资源需求时，首先指令器20的需求处理器206从收到的业务需求61的IP包头中读取包括目的IP地址和目的端口号的目标套接字地址（步骤1001），并通过和已知的作业服务器（JobTracker）的地址进行比较来判断所述业务需求61的目标套接字地址是否为作业服务器（步骤1002）。注意这里的术语作业服务器并不一定是一个物理服务器，而只是MapReduce构架中负责作业拆分和分配的一个功能模块。如果步骤1002的判断结果为否，则把业务类型设为流（参考图16的表格式，步骤1003），从业务需求61的IP包头中读取协议类型（如TCP、UDP）和目的端口号并设置到负载描述中相应的协议类型和端口号（步骤1004），以及把不是用于描述流类型业务的任务数和任务列表的指针设为空（步骤1005）。如果步骤1002的判断结果为是，则把业务类型设为MapReduce（参考图16的表格式，步骤1006），调用作业服务器的JobTacker.submitJob()方法来初始化业务需求61的任务列表，得到任务数，并设置到负载描述中相应的任务列表和任务数（步骤1007），以及把不是用于描述MapReduce类型业务的协议类型和端口号设为空（步骤1008）。

完成步骤1005或步骤1008后，需求处理器206根据从业务需求61得到的信息{业务类型，协议类型，端口号}搜索业务资源需求表203中的匹配业务（步骤1009），并检查是否存在匹配记录（步骤1010）。如果步骤1010的判断结果为是，则根据找到的匹配记录（例如第k条记录）来估计所述业务需求的资源需求。具体包括，判断业务类型是否为流类型（步骤1012）。如果步骤1012的判断结果为是，则把匹配记录中处理器资源需求和带宽资源需求对站点i和时间t的平均值分别设为当前的第j个业务需求61的处理器资源需求和带宽资源需求，即

$R_{\mathrm{CPU}}(j,t){|}_{t=t_0}=\frac{1}{I{*t}_0}\underset{i=(\mathrm{1,2},..I),t<t_0}{\mathrm{\&Sigma;}}\left[R_{\mathrm{CPU}}(i,k,t)\right]$

$R_{\mathrm{bw}}(j,t){|}_{t=t_0}=\frac{1}{I{*t}_0}\underset{i=(\mathrm{1,2},..I),t<t_0}{\mathrm{\&Sigma;}}\left[R_{\mathrm{bw}}(i,k,t)\right]$

其中第j个业务和第k条记录具有相同的{业务类型，协议类型，端口号}，I是数据中心站点数，t₀是当前时间（步骤1013）。如果步骤1012的判断结果为否，则把匹配记录中处理器资源需求和带宽资源需求对站点i和时间t的平均值乘以任务数后分别设为当前的第j个业务需求61的处理器资源需求和带宽资源需求，即

$R_{\mathrm{CPU}}(j,t){|}_{t=t_0}=\frac{1}{I{*t}_0}\underset{i=(\mathrm{1,2},..I),t<t_0}{\mathrm{\&Sigma;}}\left[R_{\mathrm{CPU}}(i,k,t)\right]$

$R_{\mathrm{bw}}(j,t){|}_{t=t_0}=\frac{1}{I{*t}_0}\underset{i=(\mathrm{1,2},..I),t<t_0}{\mathrm{\&Sigma;}}\left[R_{\mathrm{bw}}(i,k,t)\right]$

其中第j个业务和第k条记录具有相同的{业务类型，协议类型，端口号}，I是数据中心站点数，t₀是当前时间，N_j是第j个业务的任务数（步骤1014）。或者如果步骤1010的判断结果为否，表示所述业务请求61的业务类型为未知类型，则把预设的默认值（例如1）设为当前的第j个业务需求61的处理器资源需求和带宽资源需求（步骤1011）。最后程序返回业务需求61的负载描述（步骤1015），以便需求处理器206可以将其加入到全局负载列表201中。

在图8-图10中使用到的站点状态表202和业务资源需求表203是指令器20进行负载分配的重要数据，下面将结合图11-图15的流程图说明指令器20和站点代理30监测站点状态和业务运行状态来收集并分析生成站点状态表202和业务资源需求表203的方法。

在这个过程中，每个站点的站点代理首先要监测其所在站点内执行的负载的运行状态，并生成站点内的业务资源增量表。图11和图12分别说明监测分析流类型和MapReduce类型两种业务的过程。

图11表示了站点代理30在业务资源增量表303中记录流类型负载的业务运行时资源消耗的流程图。当站点代理30通过消息接口308从指令器20收到流类型的负载请求63后（步骤1101），站点代理30的本地均衡器304为负载选择服务器（参考图9的流程，步骤1102）。如果选择服务器失败，则向指令器发送拒绝（步骤1103），并进入等待下一个负载请求63的状态（步骤1104）。如果选择服务器成功，则得到所选的一个或多个服务器{P(j,n)}作为选择结果（参考图9的流程）。在业务为流类型时，选择结果应该是单个服务器，即P(j,1)。得知所选服务器P(j,1)后，本地均衡器304停止记录分配到所选服务器P(j,1)的上一个流业务或MapReduce任务的处理器和带宽利用率增量（步骤1105），根据{业务类型，协议类型，端口号}搜索读取业务资源增量表303（参考图21的表格式）中的匹配业务（步骤1106），并判断业务资源增量表303中是否存在和当前负载业务类型相同的匹配记录，例如第k条记录（步骤1107）。如果步骤1107的判断结果为否，则根据当前负载的{业务类型，协议类型，端口号}创建一个新条目并加入业务资源增量表303中（步骤1108），否则直接进入下一步。

获得匹配记录或者新建条目（下面统称匹配记录）后，站点代理30的本地均衡器304从服务器状态表302中读取所选服务器P(j,1)的当前平均处理器利用率和平均带宽利用率U_CPU-Avg(i,n,t₀),U_bw-Avg(i,n,t₀)，其中i=1，n=P(j,1)，t₀是当前时间（步骤1109）。其中服务器状态表302（参考图20的表格式）由站点代理30通过管理器控制接口307周期性（例如每隔1毫秒）从站点11的每个服务器读取，例如通过服务器111的管理器316读取其硬件监控器317的监控数据。接下来本地均衡器304从服务器状态表302中读取所选服务器P(j,1)的当前瞬时处理器利用率和瞬时带宽利用率U_CPU(i,n,t₀),U_bw(i,n,t₀)（其中i=1，n=P(j,1)，t₀是当前时间），并将所述瞬时利用率和所述平均利用率的归一化差值作为利用率增量的采样值记录到所述业务资源增量表303的匹配记录中（例如第k条记录，步骤1110）。处理器利用率增量和带宽利用率增量的定义分别是：

ΔU_CPU(i,k,t)=[U_CPU(i,n,t)-U_CPU-Avg(i,n,t₀)]*F_svr(i,n)/F_std

ΔU_bw(i,k,t)=[U_bw(i,n,t)-U_bw-Avg(i,n,t₀)]*B_svr(i,n)/B_std

其中i=1，n=P(j,1)，t₀是记录起始时间，F_svr(i,n)是所述服务器的处理器内核数和主频的乘积（例如4*2.8GHz），F_std是预设的标准处理器主频（例如1GHz），B_svr(i,n)是所述服务器的网口数和网口带宽的乘积（例如4*1Gbit/s），B_std是预设的标准带宽（例如1Gbit/s）。这里本地均衡器304将保持固定的时间间隔对所选服务器进行持续记录直到下一个负载被分配到所选服务器使其在步骤1105中终止所述记录为止。所述时间间隔可以是和通过管理器控制接口307读取信息并更新服务器状态表302的周期一样（例如每隔1毫秒），每次记录一组数据即一个采样点，也可以设定成通过管理器控制接口307读取信息并更新服务器状态表302的周期的整数倍（例如每隔1秒），每次记录多组数据即多个采样点（例如1000组/个）。

图12表示了站点代理30在业务资源增量表303中记录MapReduce类型负载的业务运行时资源消耗的流程图。当站点代理30通过消息接口308从指令器20收到MapReduce类型的负载请求63后（步骤1201），站点代理30的本地均衡器304为负载选择服务器（参考图9的流程，步骤1202）。如果选择服务器失败，则向指令器发送拒绝（步骤1203），并进入等待下一个负载请求63的状态（步骤1204）。如果选择服务器成功，则得到所选的一个或多个服务器{P(j,n)}作为选择结果（参考图9的流程）。在业务为MapReduce类型时，选择结果应该是多个服务器，即{P(j,1),P(j,2)…,P(j,N)}。得知所选服务器{P(j,1),P(j,2)…,P(j,N)}后，本地均衡器304停止记录分配到所选服务器{P(j,1),P(j,2)…,P(j,N)}中的每一个服务器的上一个流业务或MapReduce任务的处理器和带宽利用率增量（步骤1205），根据{业务类型，协议类型，端口号}搜索读取业务资源增量表303（参考图21的表格式）中的匹配业务（步骤1206），并判断业务资源增量表303中是否存在和当前负载业务类型相同的匹配记录，例如第k条记录（步骤1207）。如果步骤1207的判断结果为否，则根据当前负载的{业务类型，协议类型，端口号}创建一个新条目并加入业务资源增量表303中（步骤1208），否则直接进入下一步。

获得匹配记录或者新建条目（下面统称匹配记录）后，站点代理30的本地均衡器304从服务器状态表302中读取所选服务器{P(j,1),P(j,2)…,P(j,N)}的当前平均处理器利用率和平均带宽利用率U_CPU-Avg(i,n,t₀),U_bw-Avg(i,n,t₀)，其中i=1，n={P(j,1),P(j,2)…,P(j,N)}，t0是当前时间（步骤1209）。接下来本地均衡器304从服务器状态表302中读取所选服务器{P(j,1),P(j,2)…,P(j,N)}的当前瞬时处理器利用率和瞬时带宽利用率U_CPU(i,n,t₀),U_bw(i,n,t₀)（其中i=1，n={P(j,1),P(j,2)…,P(j,N)}，t₀是当前时间），并将所述瞬时利用率和所述平均利用率的归一化差值作为利用率增量的采样值记录到所述业务资源增量表303的匹配记录中（例如第k条记录，步骤1210）。处理器利用率增量和带宽利用率增量的定义分别是：

${\mathrm{\&Delta;U}}_{\mathrm{CPU}}(i,k,t)=\frac{1}{N}\underset{n\&Element;\{P(j,1),P(j,2),...,P(j,N)\}}{\mathrm{\&Sigma;}}\left\{\right[U_{\mathrm{CPU}}(i,n,t)-U_{\mathrm{CPU}-\mathrm{Avg}}(i,n,t_0)]*F_{\mathrm{svr}}(i,n)/F_{\mathrm{std}}\}$ ${\mathrm{\&Delta;U}}_{\mathrm{bw}}(i,k,t)=\frac{1}{N}\underset{n\&Element;\{P(j,1),P(j,2),...,P(j,N)\}}{\mathrm{\&Sigma;}}\left\{\right[U_{\mathrm{bw}}(i,n,t)-U_{\mathrm{bw}-\mathrm{Avg}}(i,n,t_0)]*B_{\mathrm{svr}}(i,n)/B_{\mathrm{std}}\}$

其中n={P(j,1),P(j,2)…,P(j,N)}，其它参数和图11中所述的一样。这里本地均衡器304将保持固定的时间间隔对所选服务器进行持续记录直到下一个负载被分配到所选服务器使其在步骤1205中终止所述记录为止。所述时间间隔可以是和通过管理器控制接口307读取信息并更新服务器状态表302的周期一样（例如每隔1毫秒），每次记录一组数据即一个采样点，也可以设定成通过管理器控制接口307读取信息并更新服务器状态表302的周期的整数倍（例如每隔1秒），每次记录多组数据即多个采样点（例如1000组/个）。

图13表示了站点代理30分析站点11的状态并发送站点状态消息62的流程图。站点代理30的本地均衡器304预设的计时器周期性触发这个流程，例如每隔10分钟（步骤1301）。然后本地均衡器304读取业务资源增量表303（参考图21的表格式）并判断业务资源增量表303中的下一条记录（例如第k条记录，k=1,2,…）是否为空（步骤1302）。如果步骤1302的判断结果为否，则通过对下一条记录中的处理器资源需求增量和带宽资源需求增量求平均来计算下一个业务的处理器资源需求和带宽资源需求（步骤1303），其计算公式分别为：

$R_{\mathrm{CPU}}(i,k,t){|}_{t=t_1}=\frac{1}{(t_1-t_k)}{\&Integral;}_{t=t_k}^{t_1}\mathrm{\&Delta;}{U}_{\mathrm{CPU}}(i,k,t)*\mathrm{dt}$

$R_{\mathrm{bw}}(i,k,t){|}_{t=t_1}=\frac{1}{(t_1-t_k)}{\&Integral;}_{t=t_k}^{t_1}\mathrm{\&Delta;}{U}_{\mathrm{bw}}(i,k,t)*\mathrm{dt}$

其中i=1，t₁是当前时间，t_k是第k条记录的记录起始时间。计算结果将在后继步骤复制到站点状态62的业务资源需求中（参考图22的消息格式）。

步骤1303的计算完成后，返回步骤1302并重复步骤1302-步骤1303的循环直到完成业务资源增量表303中所有记录的计算，即步骤1302的判断结果为是，则进入下一步流程，从服务器状态表302中读取所有开机中的服务器的当前平均处理器利用率和平均带宽利用率U_CPU-Avg(i,n,t₁,),U_bw-Avg(i,n,t₁)，其中i=1，n={1,2,…}，t₁是当前时间（步骤1304）。另外还要通过基础设施控制接口305从基础设施330读取当前所有开机中的服务器功耗POW_svr(i,n,t₁)（例如n=1,2,…），站点电力使用效率PUE(i,t₁)和单位电价UP_elc(i,t₁)（步骤1305），以及通过网络控制接口306从包括交换机115的网络120中读取站点上联带宽BW_site(i,t₁)和带宽总价TP_bw(i,t₁)（步骤1306）。获取步骤1304-步骤1306中的信息后，本地均衡器304根据所述信息计算单位处理器资源需求所消耗的服务器电力成本和单位带宽资源需求所消耗的带宽成本，并将其设为站点11当前时间的电力系数N_elc(i,t₁)和带宽系数N_bw(i,t₁)（步骤1307）：

N_bw(i,t₁)=TP_bw(i,t₁)/BW_site(i,t₁)

其中i=1，t1是当前时间，Δt是单位电价中的单位时间（例如1小时），F_svr(i,n)是第n个服务器的处理器内核数和主频的乘积（例如4*2.8GHz），F_std是预设的标准处理器主频（例如1GHz）。计算得到的电力系数N_elc(i,t₁)和带宽系数N_bw(i,t₁)和步骤1305中读取的站点电力使用效率PUE(i,t₁)将在后继步骤复制到站点状态62的相应字段中（参考图22的消息格式）。

然后本地均衡器304对站点11中正在使用的服务器和带宽资源进行优化，调节开机中服务器和按需（on-demand）上联带宽的数量来释放掉闲置资源和降低站点11的运营成本，并根据调节结果设定站点11的站点忙碌标识（参考图14的流程图，步骤1308）。完成调节后，本地均衡器304生成一个空站点状态消息62，把站点名称设为自己的名称（步骤1309）。然后将步骤1302计算得到的业务资源需求R_CPU(i,k,t₁)和R_bw(i,k,t₁)，步骤1307计算得到的电力系数N_elc(i,t₁)和带宽系数N_bw(i,t₁)，步骤1305中读取得到的站点电力使用效率PUE(i,t₁)，以及步骤1308中设定的站点忙碌标识复制到所述站点状态62的相应字段中（参考图22的消息格式）。同时清空站点11的业务资源增量表303（步骤1310），最后通过消息接口308向指令器发送所述站点状态62。

图14表示了站点代理30调节开机中的服务器和上联带宽的数量的流程图。如图13的步骤1308所述，站点代理30的本地均衡器304需要周期性（例如每隔10分钟）对站点11中正在使用的服务器和带宽资源进行优化，使得站点11的资源使用状态能随着负载在不同时间的变化而变化，从而降低站点11的运营成本。相对于图8中描述的指令器20在全局范围内的运营成本优化，所述站点代理30的工作是在本地范围内的运营成本优化。在此过程中，本地均衡器304首先要根据本地负载列表301和服务器状态表302执行虚拟机集中算法（参照Wang Meng,Xiaoqiao Meng,and Li Zhang,“Consolidating virtualmachines with dynamic bandwidth demand in data centers”,INFOCOM,2011Proceedings IEEE,2011”,INFOCOM,2011Proceedings IEEE,2011），从而把正在执行的负载集中到较少数量的服务器上（步骤1401）。完成负载集中后，根据更新后的本地负载列表301和服务器状态表302判断是否有空闲服务器，即服务器开关机状态为开机且服务器任务列表为空的服务器（步骤1402）。如果步骤1402的判断结果为是，则通过管理器控制接口307向管理器316发送关闭所述空闲服务器的控制信息，并且通过基础设施控制接口305向基础设施330发送对所述空闲服务器的电源323进行断开的控制信息，来关掉所述空闲服务器（步骤1403）。关掉空闲服务器之后，或者如果步骤1402的判断结果为否，则进一步根据更新后的服务器状态表302判断是否站点11的所有服务器都处于开机中的状态（步骤1404）。如果步骤1404的判断结果为是，则把站点11的站点忙碌标识设为真（步骤1405）。

设置完站点忙碌标识之后，或者如果步骤1404的判断结果为否，则进入后继步骤调节带宽资源，通过计算站点11的所有开机中的服务器使用的带宽之和和站点11具有的上联带宽的比率得到站点11的当前站点上联带宽利用率U_uplink(i,t)（步骤1406）：

$U_{\mathrm{uplink}}(i,t)=\underset{n}{\mathrm{\&Sigma;}}[U_{\mathrm{bw}}(i,n,t)*B_{\mathrm{svr}}(i,n)]/{\mathrm{BW}}_{\mathrm{site}}(i,t)$

其中i=1，n={1,2,…}，t=t₁是当前时间，B_svr(i,n)是第n个服务器的网口数和网口带宽的乘积（例如4*1Gbit/s），BW_site(i,t)是通过网络控制接口306从包括交换机115的网络120中读取的站点11的上联带宽。然后根据计算得到的上联带宽利用率U_uplink(i,t)判断站点11的带宽资源使用状态（步骤1407）。如果上联带宽利用率小于第一预设带宽利用率阈值Th₁（例如10%），则通过网络控制接口306向包括交换机115的网络120发送释放一半按需上联带宽的控制信息（步骤1408）。如果上联带宽利用率大于第二预设带宽利用率阈值Th₂（例如75%），则通过网络控制接口306向包括交换机115的网络120发送申请更多按需上联带宽的控制信息（步骤1409）。发送完控制信息后，或者如果上联带宽利用率介于第一预设带宽利用率阈值Th₁和第二预设带宽利用率阈值Th₂之间，则结束本次调节程序（步骤1410）。

图15表示了指令器20从站点代理30收到站点状态消息62并更新站点状态表202和业务资源需求表203的流程图。当指令器20通过消息接口207从站点代理30收到站点状态消息62（步骤1501），指令器20的全局均衡器204从站点状态62中读取发送站点名称（参考图22的消息格式，步骤1502），并根据所述站点名称在站点状态列表202中搜索发送站点的记录（步骤1503），判断是否有匹配记录，例如第i条记录（步骤1504）。如果步骤1504的判断结果为否，则根据当前站点状态62的站点名称创建一个新条目并加入站点状态列表202中（步骤1505），否则直接进入下一步。

获得匹配记录或者新建条目（下面统称匹配记录）后，全局均衡器204首先从站点状态62中读取电力系数N_elc(i,t)、带宽系数N_bw(i,t)、电力使用效率PUE(i,t)和站点忙碌标识，并复制到所述匹配记录（例如第i条记录）的相应域中（步骤1506）。然后还需要从站点状态62中读取下一条业务资源需求（步骤1507），并判断所述下一条业务资源需求记录是否为空（步骤1508）。如果步骤1508的判断结果为否，则进一步从所述下一条业务资源需求记录中读取业务类型信息{业务类型，协议类型，端口号}（步骤1509），并根据得到的{业务类型，协议类型，端口号}在业务资源需求表203中搜索该类型业务的记录（步骤1510），判断是否有匹配记录，例如第k条记录（步骤1511）。如果步骤1511的判断结果为是，则通过复制站点状态62中的所述下一条业务资源需求记录的处理器资源需求和带宽资源需求R_CPU(i,k,t)和R_bw(i,k,t)来更新业务资源需求表203中的所述匹配记录，例如第k条记录（步骤1512）。如果步骤1511的判断结果为否，则根据站点状态62中的所述下一条业务资源需求记录的{业务类型，协议类型，端口号}创建一个新条目，把所述下一条业务资源需求记录的处理器资源需求和带宽资源需求R_CPU(i,k,t)和R_bw(i,k,t)复制到所述新条目的相应域中，并把所述新条目加入到业务资源需求表203中（步骤1513），然后返回步骤1508。全局均衡器204重复步骤1508-步骤1513的循环，直到处理完站点状态62中的全部业务资源需求记录，即步骤1508的判断结果为是，则完成对当前站点状态62的处理，进入等待下一个站点状态消息62的状态（步骤1514）。

图16表示了全局负载列表201的格式。指令器20的全局负载列表201用于记录所有负载的描述信息，包括记录负载编号的负载索引j，记录负载业务类型（例如流类型）的业务类型，记录负载协议类型（例如TCP和UDP）的协议类型，记录负载的目的端口号（例如目的TCP端口号）的端口号，记录负载所产生的任务的数量的任务数N_j，记录指向负载所产生的任务的描述信息的指针的任务列表{P_tsk(j,p)}，记录估计的负载可能消耗的处理器资源的标准化使用率的CPU需求R_CPU(j,t)，记录估计的负载可能消耗的带宽资源的标准化使用率的带宽需求R_bw(j,t)，以及记录指令器20为负载选择的执行站点名称的执行站点。本实施例中，其中CPU需求R_CPU(j,t)和带宽需求R_bw(j,t)的时间参数t在各条记录中为常数，即各个负载到达指令器20的时间，表示估计的负载在单位时间（例如1秒钟）内可能消耗的标准化资源（如1GHz单核处理器）的利用率。但在其他优选实施例中所述CPU需求R_CPU(j,t)和带宽需求R_bw(j,t)也可能是变量，表示估计的负载在单位时间（例如1秒钟）内的每个时间片（例如1毫秒）可能消耗的标准化资源（如1GHz单核处理器）的利用率随时间的变化。

图17表示了站点状态表202的格式。指令器20的站点状态表202用于记录所有数据中心站点的资源使用情况，包括记录站点编号的站点索引i，记录站点名称的站点名称，记录站点的全部服务器当前是否都为开机状态的站点忙碌标识，记录单位处理器资源需求所消耗的服务器电力成本的电力系数N_elc(i,t)，记录单位带宽资源需求所消耗的带宽成本的带宽系数N_bw(i,t)，以及记录站点总能耗和所有服务器能耗之和的比值的电力使用效率PUE(i,t)。其中时间t表示数据的采样时间点，其周期由站点状态62的触发周期决定，例如每隔10分钟。

图18表示了业务资源需求表203的格式。指令器20的业务资源需求表203用于记录所有种类的业务的资源消耗情况，包括记录业务种类编号的业务索引k，记录各种业务的业务类型（例如流类型）的业务类型，记录各种业务的协议类型（例如TCP和UDP）的协议类型，记录各种业务的目的端口号（例如目的TCP端口号）的端口号，记录监测到的各种业务在各个站点消耗的处理器资源的标准化使用率的CPU需求R_CPU(i,k,t)，以及记录监测到的各种业务在各个站点消耗的带宽资源的标准化使用率的带宽需求R_bw(i,k,t)。其中CPU需求R_CPU(i,k,t)和带宽需求R_bw(i,k,t)的时间参数t表示数据的采样时间点，其周期由站点状态62的触发周期决定，例如每隔10分钟。而每个采样点表示估计的负载在单位时间（例如1秒钟）内可能消耗的标准化资源（如1GHz单核处理器）的利用率。所述采样周期和所述单位时间并不需要相同。

图19(a)表示了站点11的本地负载列表301的格式。站点代理30的本地负载列表301用于记录分配给站点11的负载的描述信息，包括记录负载在站点11的本地编号的负载索引j，记录负载业务类型（例如流类型）的业务类型，记录负载协议类型（例如TCP和UDP）的协议类型，记录负载的目的端口号（例如目的TCP端口号）的端口号，记录负载所产生的任务的数量的任务数N_j，记录指向负载所产生的任务的描述信息的指针的任务列表{P_tsk(j,p)}，记录估计的负载可能消耗的处理器资源的标准化使用率的CPU需求R_CPU(j,t)，记录估计的负载可能消耗的带宽资源的标准化使用率的带宽需求R_bw(j,t)，以及记录站点代理30为负载选择的一个或多个执行服务器的服务器索引的执行服务器。其中时间参数t的含义和图16中所述的一样。

图19(b)表示了站点12的本地负载列表的格式。所述本地负载列表用于记录分配给站点12的负载的描述信息，格式和图19(a)的一样，此处略去相关描述。

图20表示了站点11的服务器状态表302的格式。站点代理30的服务器状态表302用于记录站点11的服务器111、112、113的资源使用情况，包括记录服务器编号的服务器索引n，记录服务器开关机状态的开关机，记录指向分配到服务器的所有负载或任务的{负载索引，任务索引}信息（对流类型负载任务索引都设为1）的服务器任务列表{P(n,p)}，记录监测到的服务器处理器的时间平均资源使用率的CPU平均利用率U_CPU-Avg(i,n,t)，记录监测到的服务器处理器资源使用率的CPU利用率U_CPU(i,n,t)，记录监测到的服务器带宽的时间平均资源使用率的带宽平均利用率U_bw-Avg(i,n,t)，以及记录监测到的服务器带宽资源使用率的带宽利用率U_bw(i,n,t)。其中时间参数t表示数据的采样时间点，其周期由管理器316的硬件监控器317的采样周期决定，例如每隔1毫秒。而每个采样点表示服务器在采样周期内正在使用的资源利用率。另外，所述时间平均资源使用率的时间窗口长度也由管理器316的硬件监控器317决定，例如100毫秒。

图21表示了站点11的业务资源增量表303的格式。站点代理30的业务资源增量表303用于记录在站点11的所有种类的业务的资源消耗情况，包括记录业务种类编号的业务索引k，记录各种业务的业务类型（例如流类型）的业务类型，记录各种业务的协议类型（例如TCP和UDP）的协议类型，记录各种业务的目的端口号（例如目的TCP端口号）的端口号，记录监测到的各种业务在各个服务器上运行时造成的处理器资源使用率的增量的CPU资源增量ΔU_CPU(i,k,t),以及记录监测到的各种业务在各个服务器上运行时造成的带宽资源使用率的增量的带宽资源增量ΔU_bw(i,k,t)。其中CPU资源增量ΔU_CPU(i,k,t)和带宽资源增量ΔU_bw(i,k,t)的时间参数t表示数据的采样时间点，对某个特定的服务器其采样周期等同于图20中所述的服务器的采样周期（例如1毫秒）。但在图21中，由于业务资源增量表303记录了站点11内各种业务在所有服务器的资源消耗情况，有可能存在对某种业务同时在多个服务器上采样记录的情况，因此所述时间参数t并不具有特定的采样周期，相邻两个数据点的时间间隔应小于等于图20中所述的服务器的采样周期（例如1毫秒）。而每个采样点仍然表示服务器在采样周期内正在使用的资源利用率。

图22表示了站点状态消息62的格式。站点状态62用于站点11、12、13的站点代理向指令器20定期报告自身状态，包括用于IP核心网40进行路由的IP包头，记录发送消息的站点名称的站点名称，记录站点的全部服务器当前是否都为开机状态的站点忙碌标识，记录单位处理器资源需求所消耗的服务器电力成本的电力系数，记录单位带宽资源需求所消耗的带宽成本的带宽系数，记录站点总能耗和所有服务器能耗之和的比值的电力使用效率，以及记录发送站点中所有种类的业务的资源消耗统计数据的业务资源需求。其中业务资源需求又进一步包括记录业务种类编号的业务索引，记录各种业务的业务类型（例如流类型）的业务类型，记录各种业务的协议类型（例如TCP和UDP）的协议类型，记录各种业务的目的端口号（例如目的TCP端口号）的端口号，记录统计的各种业务消耗的处理器资源的CPU需求，以及记录统计的各种业务消耗的带宽资源带宽需求。

图23表示了负载请求消息63的格式。负载请求消息63用于指令器20向所选站点的站点代理发送所分配的负载的负载描述信息，包括用于IP核心网40进行路由的IP包头，记录负载业务类型（例如流类型）的业务类型，记录负载协议类型（例如TCP和UDP）的协议类型，记录负载的目的端口号（例如目的TCP端口号）的端口号，记录负载所产生的任务的数量的任务数，记录负载所产生的任务的描述信息的任务列表，记录估计的负载可能消耗的处理器资源的标准化使用率的CPU需求，以及记录估计的负载可能消耗的带宽资源的标准化使用率的带宽需求。其中任务列表又进一步包括记录任务编号的任务索引，以及记录获取任务的输入输出路径的任务路径。

尽管已经参考本发明的典型实施例，具体示出和描述了本发明，但本领域普通技术人员应当理解，在不脱离所附权利要求所限定的本发明的精神和范围的情况下，可以对这些实施例进行形式和细节上的多种改变。

Claims (12)

1.一种数据中心系统，其特征在于，包括：

多个数据中心站点，每个数据中心站点包括一个以上用于处理用户的应用的服务器；

指令部，其管理所述多个数据中心站点，并向用户提供应用服务；

多个站点代理部，其对应所述多个数据中心站点的每一个而设置，管理各自的数据中心站点的状态并将应用分配给服务器运行；和

通信网络，其连接用户、所述多个数据中心站点、所述指令部和所述站点代理部，

所述指令部具有计算各个数据中心站点运行应用的、至少包括电力成本和带宽成本的运行成本的成本计算器，

当用户向所述指令部发送应用请求时，所述指令部根据所有种类的应用所需的资源估算运行用户请求的应用所需的资源，所述成本计算器根据各数据中心站点的资源使用状态和估算的所需的资源计算在各个数据中心站点运行用户请求的应用的电力成本和带宽成本，所述指令部向运行用户请求的应用的电力成本与带宽成本之和最低的数据中心站点的站点代理部发送应用运行请求，接收到所述应用运行请求的站点代理部将请求运行的应用分配给该站点代理部管理的服务器。

2.如权利要求1所述的数据中心系统，其特征在于：

所述应用运行请求中包含估算的运行用户请求的应用所需的资源的信息，

所述站点代理部根据本站点的各服务器的资源使用状态和估算的运行用户请求的应用所需的资源的信息，将用户请求的应用分配给能够运行该应用的服务器。

3.如权利要求1或2所述的数据中心系统，其特征在于：

所述指令部还包括指令部存储器，其存储有数据中心站点状态表和应用资源需求表，

所述数据中心站点状态表用于记录所述各数据中心站点的资源使用状态，

所述应用资源需求表用于记录所述所有种类的应用所需的资源。

4.如权利要求3所述的数据中心系统，其特征在于：

所述站点代理部具有站点代理部存储器，该站点代理部存储器存储有用于记录本站点的各服务器的资源使用状态的服务器状态表和用于记录本站点的各服务器正在运行的应用的资源增量表，所述服务器状态表和资源增量表被定期地上传至所述指令部，以更新所述指令部存储器存储的数据中心站点状态表和应用资源需求表。

5.如权利要求2所述的数据中心系统，其特征在于：

接收到所述应用运行请求的站点代理部，在没有找到能够运行请求的应用的服务器的情况下，向所述指令部返回拒绝运行应用的信息，

所述指令部接收到拒绝运行应用的信息后，向另一数据中心站点的站点代理部发送应用运行请求，该另一数据中心站点运行用户请求的应用的电力成本与带宽成本之和仅比返回拒绝运行应用的信息的站点代理部所管理的数据中心站点高。

6.如权利要求3所述的数据中心系统，其特征在于：

所述数据中心站点状态表包括电力系数、电力使用效率和带宽系数，所述应用资源需求表包括应用类型、CPU需求和带宽需求，

所述指令器根据应用资源需求表的应用类型、CPU需求和带宽需求估算运行应用所需的资源，

所述成本计算器，根据所述电力系数、电力使用效率和估算的运行应用所需的资源计算电力成本，根据带宽系数和估算运行应用所需的资源计算带宽成本。

7.一种数据中心系统的管理方法，所述数据中心系统通过通信网络联接用户、多个数据中心站点、指令部和站点代理部而构成，所述多个数据中心站点的每一个都包括一个以上的服务器，所述数据中心系统的管理方法的特征在于，包括：

所述指令部接收来自用户的应用请求，根据所有种类的应用所需的资源估算运行用户请求的应用所需的资源的步骤；

根据各个数据中心站点的状态和估算的所需的资源计算在各个数据中心站点运行用户请求的应用的、至少包括电力成本和带宽成本的运行成本的步骤；

所述指令部向运行用户请求的应用的电力成本与带宽成本之和最低的数据中心站点的站点代理部发送应用运行请求的步骤；和

接收到所述应用运行请求的站点代理部将请求运行的应用分配给该站点代理部管理的服务器的步骤。

8.如权利要求7所述的数据中心系统的管理方法，其特征在于：

所述应用运行请求中包含估算的运行用户请求的应用所需的资源的信息，

所述站点代理部根据本站点的各服务器的资源使用状态和估算的运行用户请求的应用所需的资源的信息，将用户请求的应用分配给能够运行该应用的服务器。

9.如权利要求7或8所述的数据中心系统的管理方法，其特征在于：

所述指令部还包括指令部存储器，其存储有数据中心站点状态表和应用资源需求表，

所述数据中心站点状态表用于记录所述各数据中心站点的资源使用状态，

所述应用资源需求表用于记录所述所有种类的应用所需的资源。

10.如权利要求9所述的数据中心系统的管理方法，其特征在于：

还包括所述站点代理部定期地将该站点代理部管理的服务器的状态信息上传至所述指令部，以更新所述数据中心站点状态表和所述应用资源需求表的步骤。

11.如权利要求8所述的数据中心系统的管理方法，其特征在于，还包括：

在站点代理部没有找到能够运行该应用的服务器的情况下，向所述指令部返回拒绝运行应用的信息的步骤；和

所述指令部接收到拒绝运行应用的信息后，向另一数据中心站点的站点代理部发送应用运行请求的步骤，该另一数据中心站点运行用户请求的应用的电力成本与带宽成本之和仅比返回拒绝运行应用的信息的站点代理部所管理的数据中心站点高。

12.如权利要求9所述的数据中心系统的管理方法，其特征在于：

所述数据中心站点状态表包括电力系数、电力使用效率和带宽系数，所述应用资源需求表包括应用类型、CPU需求和带宽需求，

在估算运行用户请求的应用所需的资源的步骤中，根据应用资源需求表的应用类型、CPU需求和带宽需求估算运行应用所需的资源，

在计算至少包括电力成本和带宽成本的运行成本的步骤中，根据所述电力系数、电力使用效率和估算的运行应用所需的资源计算电力成本，根据带宽系数和估算运行应用所需的资源计算带宽成本。