数据中心系统及数据中心系统的管理方法
数据中心系统及数据中心系统的管理方法
【专利摘要】本发明提供一种数据中心系统和数据中心系统的管理方法。在由通信网络连续用户、多个数据中心站点、指令部、多个站点代理部而构成的数据中心系统中，当用户向指令部发送应用请求时，指令部根据所有种类的应用所需的资源估算运行用户请求的应用所需的资源，根据各数据中心站点的资源使用状态和估算的所需的资源计算在各个数据中心站点运行用户请求的应用的电力成本和带宽成本，指令部向运行用户请求的应用的电力成本与带宽成本之和最低的数据中心站点的站点代理部发送应用运行请求，接收到应用运行请求的站点代理部将请求运行的应用分配给该站点代理部管理的服务器。由此避免了分别优化电力成本或带宽成本产生的不平衡，从而减少了数据中心的总运营成本。
【专利说明】数据中心系统及数据中心系统的管理方法
【技术领域】
[0001] 本发明涉及数据中心，特别是涉及数据中心系统及数据中心系统的管理方法。
【背景技术】
[0002] 数据中心作为高速发展的云计算产业的基础设施，对成本管理有高度要求。特别 是随着IT设备计算能力和设备密度的增长，初期建设成本和设备购置成本在数据中心的 总体成本中的比重逐渐下降，而运营成本、特别是电力成本正在不断增加，并且达到了和设 备购置成本相近的比重。因此数据中心的运营成本正在受到越来越多的关注，并产生了一 些能降低数据中心运营成本的方法和技术。
[0003] 例如，在公知技术US 2011/0191773 A1中，公开了一种数据中心能耗管理的系统 和方法。所述方法包括，对多个数据中心中的每一个都至少部分地根据在各个数据中心执 行应用所需的电力来判定在各个数据中心执行应用相关的成本。所述方法还包括根据在各 个数据中心执行应用相关的成本来从多个数据中心中选择一个来执行应用，并且在所选的 数据中心执行应用。
[0004] 该方法通过优化负载(也就是所述的应用，下文中统称为负载）在多个数据中心中 的分配来最小化作为一个整体考虑的所述多个数据中心的电力成本，从而降低了所述多个 数据中心的运营成本。但是数据中心的运营成本除了电力成本通常还包括固定资产折旧、 人工费、以及带宽成本。其中固定资产折旧和人工费通常为固定费用支出，而带宽成本和电 力成本一样，属于可以优化的费用支出。特别是在中国，和其他国家相比，带宽较贵而电价 较低，导致带宽成本成为影响数据中心总运营成本的重要因素。例如，根据中国联通在2009 年的报告，带宽成本占其数据中心总运营成本的29%，而电力成本占28%。
[0005] 此外，在中国目前大多数省市执行的电价是分季节和峰平谷分时段的电价，还没 有实现逐时或逐分实时电价，这使得不同地区以及不同时间的电价变化相对较小，部分的 局限了公知技术中的优化效果。同时，中国不同地区的网络建设差异较大，带宽定价较为 灵活，使得不同地区的单位带宽价格差异较大，具有潜在的优化可能性。例如，根据发明人 的调研，在中国不同城市的带宽价格的变异系数（CV)是0.32,而电力价格的变异系数是 0. 12。也就是说，对于中国的数据中心，在不同地区执行负载所需要的带宽成本的差异要超 过电力成本的差异。因此，如果使用公知技术来进行数据中心管理，可能无法得到最佳总运 营成本。
[0006] 此外，公知技术通过用基准测试得到的预设数据来估计给定负载的电力消耗。这 不能处理不包含在基准测试中的新类型的负载。
【发明内容】
[0007] 为了解决上述问题，本发明通过优化负载在多个数据中心中的分配来最小化所述 多个数据中心的电力成本和带宽成本之和，从而降低了所述多个数据中心的总运营成本。 此外，本发明对数据中心状态进行实时监测，并基于历史监测数据来在线估计在不同站点 执行负载所需的电力和带宽消耗。
[0008] 本发明的第一方面的数据中心系统包括：多个数据中心站点，每个数据中心站点 包括一个以上用于处理用户的应用的服务器；指令部，其管理上述多个数据中心站点，并向 用户提供应用服务；多个站点代理部，其对应上述多个数据中心站点的每一个而设置，管理 各自的数据中心站点的状态并将应用分配给服务器运行；和通信网络，其连接用户、上述多 个数据中心站点、上述指令部和上述站点代理部，上述指令部具有计算各个数据中心站点 运行应用的、至少包括电力成本和带宽成本的运行成本的成本计算器，当用户向上述指令 部发送应用请求时，上述指令部根据所有种类的应用所需的资源估算运行用户请求的应用 所需的资源，上述成本计算器根据各数据中心站点的资源使用状态和估算的所需的资源计 算在各个数据中心站点运行用户请求的应用的电力成本和带宽成本，上述指令部向运行用 户请求的应用的电力成本与带宽成本之和最低的数据中心站点的站点代理部发送应用运 行请求，接收到上述应用运行请求的站点代理部将请求运行的应用分配给该站点代理部管 理的服务器。
[0009] 本发明的第二方面的数据中心系统的管理方法，上述数据中心系统通过通信网络 联接用户、多个数据中心站点、指令部和站点代理部而构成，上述多个数据中心站点的每一 个都包括一个以上的服务器，上述数据中心系统的管理方法包括：上述指令部接收来自用 户的应用请求，根据所有种类的应用所需的资源估算运行用户请求的应用所需的资源的步 骤；根据各个数据中心站点的状态和估算的所需的资源计算在各个数据中心站点运行用户 请求的应用的、至少包括电力成本和带宽成本的运行成本的步骤；上述指令部向运行用户 请求的应用的电力成本与带宽成本之和最低的数据中心站点的站点代理部发送应用运行 请求的步骤；和接收到上述应用运行请求的站点代理部将请求运行的应用分配给该站点代 理部管理的服务器的步骤。
[0010] 根据本发明的数据中心系统及数据中心系统的管理方法，同时考虑了数据中心总 运营成本中的电力成本和带宽成本的优化，避免了分别优化电力成本或带宽成本产生的不 平衡，从而减少了数据中心的总运营成本。本发明还可以处理任何类型的负载，而不需要预 先设定的基准测试。
【专利附图】
【附图说明】
[0011] 根据以下结合附图对本发明非限制实施例的详细描述，本发明的以上和其他目 的、特征和优点将变得更加清楚，其中：
[0012] 图1表示具有全局负载均衡的多站点数据中心系统结构。
[0013] 图2表示指令器的结构。
[0014] 图3表示运行在虚拟机上的站点代理的结构。
[0015] 图4表示处理流类型需求的时序。
[0016] 图5表示处理MapReduce类型需求的时序。
[0017] 图6表示选择第二低成本站点的时序。
[0018] 图7表示为业务选择站点失败的时序。
[0019] 图8表示指令器选择具有优化成本的站点的流程图。
[0020] 图9是表示站点代理为从指令器来的负载请求选择服务器的流程图。
[0021] 图10是表示指令器为业务需求估计资源需求并生成负载描述的流程图。
[0022] 图11是表示站点代理在业务资源增量表中记录流类型负载的业务运行时资源消 耗的流程图。
[0023] 图12是表示站点代理在业务资源增量表中记录MapReduce类型负载的业务运行 时资源消耗的流程图。
[0024] 图13是表示站点代理分析站点状态并发送站点状态消息的流程图。
[0025] 图14是表示站点代理调节开机中的服务器和上联带宽的数量的流程图。
[0026] 图15是表示指令器从站点代理收到站点状态消息并更新站点状态表和业务资源 需求表的流程图。
[0027] 图16表不全局负载列表的格式。
[0028] 图17表示站点状态表的格式。
[0029] 图18表示业务资源需求表的格式。
[0030] 图19 (a)表不了站点11的本地负载列表的格式；图19 (b)表不了站点12的本 地负载列表的格式。
[0031] 图20表示站点11的服务器状态表的格式。
[0032] 图21表示站点11的业务资源增量表的格式。
[0033] 图22表示站点状态消息的格式。
[0034] 图23表示负载请求消息的格式。
【具体实施方式】
[0035] 下面参照【专利附图】
【附图说明】本发明的实施方式。图中相同的符号代表相同的部件。
[0036] 图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 相连接。
[0037] 客户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的时候能以此作为依据。
[0038] 图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的一个或多个的一 个或多个服务器上。
[0039] 类似的，站点代理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。
[0040] 站点代理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除了 供电设施，还包括空调、照明、水循环等系统，在本实施例中没有涉及，因此未示出。
[0041] 在本实施例中，将数据中心需要提供的业务分为两类，一类是流类型的业务，其中 使用业务的客户和提供业务的一个服务器之间建立会话和连接，另一类是MapReduce类型 的业务，其中把使用业务的客户提交的业务拆分成若干任务并分发给多个服务器来执行。 下面在图4和图5中分别对处理这两种业务的时序进行描述。
[0042] 图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拆除相应的 网络路径(未示出）。
[0043] 图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)。
[0044] 在某些情况下，图4和图5中选择的最低成本的站点可能会拒绝执行任务，例如站 点的总可用资源大于业务的资源需求，但是单个服务器的最大可用资源小于业务的资源需 求，或者站点状态62的传输和处理延时造成站点状态表202和实际上的站点状态之间存在 差异。在这种情况下，指令器20需要顺序选择成本次优的站点。
[0045] 图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类业务的后继处理(未示出）。
[0046] 图7表示了为业务选择站点失败的时序。首先由客户51向指令器20发送业务需 求61(步骤701)。指令器20为该业务生成负载描述并添加到全局负载列表201中（参考图 10的流程图)，然后指令器20的全局均衡器204和成本计算器205从所有数据中心站点中 选择一个对于执行所述负载具有最低成本的站点（参考图8的流程图)，例如站点11 (步骤 702)，并通过消息接口 207向所选站点11的站点代理30发送负载请求63来通知所选站点 11执行所述负载(步骤703)。
[0047] 当所选站点11的站点代理30通过消息接口 308收到所述负载请求63时，站点代 理30的本地均衡器304进行站点内服务器的选择失败（参考图9的流程图，步骤704)，并 向指令器20返回拒绝来拒绝执行负载(步骤705)。指令器20收到拒绝消息后，继续从除 了站点11之外的数据中心站点中选择一个对于执行所述负载具有最低成本的站点，也就 是在所有数据中心站点中具有第二低成本的站点（参考图8的流程图)，例如站点12 (步骤 706)，并通过消息接口 207向所选站点12的站点代理209发送负载请求63来通知所选站 点12执行所述负载(步骤707)。
[0048] 当所选站点12的站点代理209收到所述负载请求63时，站点代理209进行站点 内服务器的选择失败(参考图9的流程图，步骤708)，并向指令器20返回拒绝来拒绝执行负 载(步骤709)。指令器20收到拒绝消息后，继续从除了站点11、12之外的数据中心站点中 选择一个对于执行所述负载具有最低成本的站点，也就是在所有数据中心站点中具有第三 低成本的站点（参考图8的流程图)，例如站点13 (步骤710)，并通过消息接口 207向所选 站点13的站点代理210发送负载请求63来通知所选站点13执行所述负载(步骤711)。
[0049] 当所选站点13的站点代理210收到所述负载请求63时，站点代理210进行站点 内服务器的选择失败(参考图9的流程图，步骤712)，并向指令器20返回拒绝来拒绝执行负 载(步骤713)。指令器20收到拒绝消息后，发现对于所述负载的可用站点为空，因此判定 为所述业务选择站点失败(参考图8的流程图)，从全局负载列表201中移除所述负载(步骤 714)，并向客户51返回失败来拒绝客户的业务需求61 (步骤715)。
[0050] 下面结合具体的流程图对图4-图7中涉及的指令器20和站点代理30的处理过 程进行说明。在图8-图23中所使用的用字母表示的序号指代含义为，i表示某个数据中 心站点，η表示站点内的某个服务器，j表示某个具体的业务或负载，k表示某个业务类型， p表示MapReduce类业务或负载拆分得到的某个任务。
[0051] 图8表示了指令器20选择具有优化成本的站点的流程图。如图4-图7中所述，当 指令器20收到第j个(例如，j=2)业务需求61时(步骤801)，指令器20的需求处理器206 根据业务资源需求表203估计第j个业务需求61的处理器资源需求R OT(j，t)和带宽资源 需求Rbw(j，t)，产生第j个需求对应的负载描述(参考图10的流程图，步骤802)，并把产 生的第j个负载添加到全局负载列表201中（参考图16的表格式，步骤803)。然后指令器 20的成本计算器205根据所述资源需求R OT(j，t)，Rbw(j，t)和站点状态表202依次计算在 第i个（i=l，2, 3)站点执行第j个负载时可能消耗的电力成本(步骤804): ^0052] Ce,v(/, /) = j ( RCPl;(jj) " .V,,(/, /,) //>HE (/, /〇) * di
[0053] 其中，Cele(j，i)是第i个站点执行第j个负载时可能消耗的电力成本，N ele(i，tQ) 是第i个站点在当前时间h的电力系数，PUE(i，〇是第i个站点在当前时间h的电源使 用效率（Power Usage Effectiveness), tj是第j个负载可能执行的时长。既然负载的可 能执行时长对每一个数据中心站点是不变的，并不影响最后的优化结果，因此h可以设定 为单位时长，例如1秒。
[0054] 类似的，指令器20的成本计算器205根据所述资源需求ROT(j，t)，R bw(j，t)和站 点状态表202依次计算在第i个（i=l，2, 3)站点执行第j个负载时可能消耗的带宽成本(步 骤805):
[0055] ( ；,,(/,/) = Rhw(jJ) * NfjL/〇) * dt
[0056] 其中，Cbw(j，i)是第i个站点执行第j个负载时可能消耗的带宽成本，N bw(i，〇是 第i个站点在当前时间h的带宽系数，\是第j个负载可能执行的时长，例如1秒。
[0057] 在成本计算器205完成对所有站点的成本计算后，把中间计算结果Celc;(j，i)和 Cbw (j，i)发送给全局均衡器204,并由全局均衡器204选择具有最小电力成本及带宽成本之 和卿Min(Sum(Cele(j，i)，Cbw(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)。
[0058] 图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^at)和带宽资 源需求R bw(j，t)，将其设为选择一个服务器的算法的输入(步骤903)，然后调用例如网络感 知的负载均衡算法(参照中国专利申请CN201210033677. 6)来根据ROT(j，t)、Rbw(j，t)和 服务器状态表302从站点11的所有开机中的服务器中选择一个满足资源需求的服务器， 例如服务器112 (步骤904)。如果步骤902的判断结果为否，表示MapReduce业务，则从负 载请求63中读出第j个负载的处理器资源需求R ePU(j, t)、带宽资源需求Rbw(j, t)和任务 数，将处理器资源需求RCTU(j，t)和带宽资源需求Rbw(j，t)除以任务数后设为选择一个服 务器的算法的输入(步骤905)，然后调用例如网络感知的负载均衡算法(参照中国专利申请 CN201210033677. 6)来根据所述输入和服务器状态表302从站点11的所有开机中的服务器 中为所述负载的下一个任务选择一个满足资源需求的服务器，例如服务器111 (步骤906)。
[0059] 运行完选择一个服务器的算法后，本地均衡器304查看运行结果是否包含可用的 服务器和从边缘路由器115到达所述服务器的路径(步骤907)。如果步骤907的判断结果 为是，则检查负载请求63中的业务类型和任务列表来判断是否完成负载请求63的处理(步 骤908)，步骤908具体包括如果步骤903-步骤906处理的是一个流类型负载或者是一个 MapReduce负载的最后一个任务则判断结果为是，否则如果步骤903-步骤906处理的是一 个MapReduce负载的最后一个任务之前的任务则判断结果为否。如果步骤908的判断结果 为是，则本地均衡器304把负载和所选的一个或多个服务器{P(j，η)}加入到本地负载列表 301(参考图19的表格式，步骤910)，并通过消息接口 308向指令器发送接受负载的答复消 息(步骤911 )。如果步骤908的判断结果为否，则返回步骤902继续处理MapReduce负载的 下一个任务。对于流类型的负载，本地均衡器304只需要执行一遍步骤902-步骤907。而 对于MapReduce负载，本地均衡器304需要重复步骤902-步骤907的循环，直到处理完该 负载的所有任务。
[0060] 如果步骤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)。
[0061] 图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)。
[0062] 完成步骤1005或步骤1008后，需求处理器206根据从业务需求61得到的信息 {:业务类型，协议类型，端口号}搜索业务资源需求表203中的匹配业务(步骤1009)，并检 查是否存在匹配记录(步骤1010)。如果步骤1010的判断结果为是，则根据找到的匹配记录 (例如第k条记录）来估计所述业务需求的资源需求。具体包括，判断业务类型是否为流类 型(步骤1012)。如果步骤1012的判断结果为是，则把匹配记录中处理器资源需求和带宽资 源需求对站点i和时间t的平均值分别设为当前的第j个业务需求61的处理器资源需求 和带宽资源需求，即
【权利要求】
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需求和带宽需求估算运行应用所需的资源， 在计算至少包括电力成本和带宽成本的运行成本的步骤中，根据所述电力系数、电力 使用效率和估算的运行应用所需的资源计算电力成本，根据带宽系数和估算运行应用所需 的资源计算带宽成本。
【文档编号】G06Q50/06GK104144183SQ201310166725
【公开日】2014年11月12日 申请日期:2013年5月8日 优先权日:2013年5月8日
【发明者】石颖 申请人:株式会社日立制作所
【专利摘要】本发明提供一种数据中心系统和数据中心系统的管理方法。在由通信网络连续用户、多个数据中心站点、指令部、多个站点代理部而构成的数据中心系统中，当用户向指令部发送应用请求时，指令部根据所有种类的应用所需的资源估算运行用户请求的应用所需的资源，根据各数据中心站点的资源使用状态和估算的所需的资源计算在各个数据中心站点运行用户请求的应用的电力成本和带宽成本，指令部向运行用户请求的应用的电力成本与带宽成本之和最低的数据中心站点的站点代理部发送应用运行请求，接收到应用运行请求的站点代理部将请求运行的应用分配给该站点代理部管理的服务器。由此避免了分别优化电力成本或带宽成本产生的不平衡，从而减少了数据中心的总运营成本。
【专利说明】数据中心系统及数据中心系统的管理方法
【技术领域】
[0001] 本发明涉及数据中心，特别是涉及数据中心系统及数据中心系统的管理方法。
【背景技术】
[0002] 数据中心作为高速发展的云计算产业的基础设施，对成本管理有高度要求。特别 是随着IT设备计算能力和设备密度的增长，初期建设成本和设备购置成本在数据中心的 总体成本中的比重逐渐下降，而运营成本、特别是电力成本正在不断增加，并且达到了和设 备购置成本相近的比重。因此数据中心的运营成本正在受到越来越多的关注，并产生了一 些能降低数据中心运营成本的方法和技术。
[0003] 例如，在公知技术US 2011/0191773 A1中，公开了一种数据中心能耗管理的系统 和方法。所述方法包括，对多个数据中心中的每一个都至少部分地根据在各个数据中心执 行应用所需的电力来判定在各个数据中心执行应用相关的成本。所述方法还包括根据在各 个数据中心执行应用相关的成本来从多个数据中心中选择一个来执行应用，并且在所选的 数据中心执行应用。
[0004] 该方法通过优化负载(也就是所述的应用，下文中统称为负载）在多个数据中心中 的分配来最小化作为一个整体考虑的所述多个数据中心的电力成本，从而降低了所述多个 数据中心的运营成本。但是数据中心的运营成本除了电力成本通常还包括固定资产折旧、 人工费、以及带宽成本。其中固定资产折旧和人工费通常为固定费用支出，而带宽成本和电 力成本一样，属于可以优化的费用支出。特别是在中国，和其他国家相比，带宽较贵而电价 较低，导致带宽成本成为影响数据中心总运营成本的重要因素。例如，根据中国联通在2009 年的报告，带宽成本占其数据中心总运营成本的29%，而电力成本占28%。
[0005] 此外，在中国目前大多数省市执行的电价是分季节和峰平谷分时段的电价，还没 有实现逐时或逐分实时电价，这使得不同地区以及不同时间的电价变化相对较小，部分的 局限了公知技术中的优化效果。同时，中国不同地区的网络建设差异较大，带宽定价较为 灵活，使得不同地区的单位带宽价格差异较大，具有潜在的优化可能性。例如，根据发明人 的调研，在中国不同城市的带宽价格的变异系数（CV)是0.32,而电力价格的变异系数是 0. 12。也就是说，对于中国的数据中心，在不同地区执行负载所需要的带宽成本的差异要超 过电力成本的差异。因此，如果使用公知技术来进行数据中心管理，可能无法得到最佳总运 营成本。
[0006] 此外，公知技术通过用基准测试得到的预设数据来估计给定负载的电力消耗。这 不能处理不包含在基准测试中的新类型的负载。
【发明内容】
[0007] 为了解决上述问题，本发明通过优化负载在多个数据中心中的分配来最小化所述 多个数据中心的电力成本和带宽成本之和，从而降低了所述多个数据中心的总运营成本。 此外，本发明对数据中心状态进行实时监测，并基于历史监测数据来在线估计在不同站点 执行负载所需的电力和带宽消耗。
[0008] 本发明的第一方面的数据中心系统包括：多个数据中心站点，每个数据中心站点 包括一个以上用于处理用户的应用的服务器；指令部，其管理上述多个数据中心站点，并向 用户提供应用服务；多个站点代理部，其对应上述多个数据中心站点的每一个而设置，管理 各自的数据中心站点的状态并将应用分配给服务器运行；和通信网络，其连接用户、上述多 个数据中心站点、上述指令部和上述站点代理部，上述指令部具有计算各个数据中心站点 运行应用的、至少包括电力成本和带宽成本的运行成本的成本计算器，当用户向上述指令 部发送应用请求时，上述指令部根据所有种类的应用所需的资源估算运行用户请求的应用 所需的资源，上述成本计算器根据各数据中心站点的资源使用状态和估算的所需的资源计 算在各个数据中心站点运行用户请求的应用的电力成本和带宽成本，上述指令部向运行用 户请求的应用的电力成本与带宽成本之和最低的数据中心站点的站点代理部发送应用运 行请求，接收到上述应用运行请求的站点代理部将请求运行的应用分配给该站点代理部管 理的服务器。
[0009] 本发明的第二方面的数据中心系统的管理方法，上述数据中心系统通过通信网络 联接用户、多个数据中心站点、指令部和站点代理部而构成，上述多个数据中心站点的每一 个都包括一个以上的服务器，上述数据中心系统的管理方法包括：上述指令部接收来自用 户的应用请求，根据所有种类的应用所需的资源估算运行用户请求的应用所需的资源的步 骤；根据各个数据中心站点的状态和估算的所需的资源计算在各个数据中心站点运行用户 请求的应用的、至少包括电力成本和带宽成本的运行成本的步骤；上述指令部向运行用户 请求的应用的电力成本与带宽成本之和最低的数据中心站点的站点代理部发送应用运行 请求的步骤；和接收到上述应用运行请求的站点代理部将请求运行的应用分配给该站点代 理部管理的服务器的步骤。
[0010] 根据本发明的数据中心系统及数据中心系统的管理方法，同时考虑了数据中心总 运营成本中的电力成本和带宽成本的优化，避免了分别优化电力成本或带宽成本产生的不 平衡，从而减少了数据中心的总运营成本。本发明还可以处理任何类型的负载，而不需要预 先设定的基准测试。
【专利附图】
【附图说明】
[0011] 根据以下结合附图对本发明非限制实施例的详细描述，本发明的以上和其他目 的、特征和优点将变得更加清楚，其中：
[0012] 图1表示具有全局负载均衡的多站点数据中心系统结构。
[0013] 图2表示指令器的结构。
[0014] 图3表示运行在虚拟机上的站点代理的结构。
[0015] 图4表示处理流类型需求的时序。
[0016] 图5表示处理MapReduce类型需求的时序。
[0017] 图6表示选择第二低成本站点的时序。
[0018] 图7表示为业务选择站点失败的时序。
[0019] 图8表示指令器选择具有优化成本的站点的流程图。
[0020] 图9是表示站点代理为从指令器来的负载请求选择服务器的流程图。
[0021] 图10是表示指令器为业务需求估计资源需求并生成负载描述的流程图。
[0022] 图11是表示站点代理在业务资源增量表中记录流类型负载的业务运行时资源消 耗的流程图。
[0023] 图12是表示站点代理在业务资源增量表中记录MapReduce类型负载的业务运行 时资源消耗的流程图。
[0024] 图13是表示站点代理分析站点状态并发送站点状态消息的流程图。
[0025] 图14是表示站点代理调节开机中的服务器和上联带宽的数量的流程图。
[0026] 图15是表示指令器从站点代理收到站点状态消息并更新站点状态表和业务资源 需求表的流程图。
[0027] 图16表不全局负载列表的格式。
[0028] 图17表示站点状态表的格式。
[0029] 图18表示业务资源需求表的格式。
[0030] 图19 (a)表不了站点11的本地负载列表的格式；图19 (b)表不了站点12的本 地负载列表的格式。
[0031] 图20表示站点11的服务器状态表的格式。
[0032] 图21表示站点11的业务资源增量表的格式。
[0033] 图22表示站点状态消息的格式。
[0034] 图23表示负载请求消息的格式。
【具体实施方式】
[0035] 下面参照【专利附图】
【附图说明】本发明的实施方式。图中相同的符号代表相同的部件。
[0036] 图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 相连接。
[0037] 客户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的时候能以此作为依据。
[0038] 图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的一个或多个的一 个或多个服务器上。
[0039] 类似的，站点代理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。
[0040] 站点代理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除了 供电设施，还包括空调、照明、水循环等系统，在本实施例中没有涉及，因此未示出。
[0041] 在本实施例中，将数据中心需要提供的业务分为两类，一类是流类型的业务，其中 使用业务的客户和提供业务的一个服务器之间建立会话和连接，另一类是MapReduce类型 的业务，其中把使用业务的客户提交的业务拆分成若干任务并分发给多个服务器来执行。 下面在图4和图5中分别对处理这两种业务的时序进行描述。
[0042] 图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拆除相应的 网络路径(未示出）。
[0043] 图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)。
[0044] 在某些情况下，图4和图5中选择的最低成本的站点可能会拒绝执行任务，例如站 点的总可用资源大于业务的资源需求，但是单个服务器的最大可用资源小于业务的资源需 求，或者站点状态62的传输和处理延时造成站点状态表202和实际上的站点状态之间存在 差异。在这种情况下，指令器20需要顺序选择成本次优的站点。
[0045] 图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类业务的后继处理(未示出）。
[0046] 图7表示了为业务选择站点失败的时序。首先由客户51向指令器20发送业务需 求61(步骤701)。指令器20为该业务生成负载描述并添加到全局负载列表201中（参考图 10的流程图)，然后指令器20的全局均衡器204和成本计算器205从所有数据中心站点中 选择一个对于执行所述负载具有最低成本的站点（参考图8的流程图)，例如站点11 (步骤 702)，并通过消息接口 207向所选站点11的站点代理30发送负载请求63来通知所选站点 11执行所述负载(步骤703)。
[0047] 当所选站点11的站点代理30通过消息接口 308收到所述负载请求63时，站点代 理30的本地均衡器304进行站点内服务器的选择失败（参考图9的流程图，步骤704)，并 向指令器20返回拒绝来拒绝执行负载(步骤705)。指令器20收到拒绝消息后，继续从除 了站点11之外的数据中心站点中选择一个对于执行所述负载具有最低成本的站点，也就 是在所有数据中心站点中具有第二低成本的站点（参考图8的流程图)，例如站点12 (步骤 706)，并通过消息接口 207向所选站点12的站点代理209发送负载请求63来通知所选站 点12执行所述负载(步骤707)。
[0048] 当所选站点12的站点代理209收到所述负载请求63时，站点代理209进行站点 内服务器的选择失败(参考图9的流程图，步骤708)，并向指令器20返回拒绝来拒绝执行负 载(步骤709)。指令器20收到拒绝消息后，继续从除了站点11、12之外的数据中心站点中 选择一个对于执行所述负载具有最低成本的站点，也就是在所有数据中心站点中具有第三 低成本的站点（参考图8的流程图)，例如站点13 (步骤710)，并通过消息接口 207向所选 站点13的站点代理210发送负载请求63来通知所选站点13执行所述负载(步骤711)。
[0049] 当所选站点13的站点代理210收到所述负载请求63时，站点代理210进行站点 内服务器的选择失败(参考图9的流程图，步骤712)，并向指令器20返回拒绝来拒绝执行负 载(步骤713)。指令器20收到拒绝消息后，发现对于所述负载的可用站点为空，因此判定 为所述业务选择站点失败(参考图8的流程图)，从全局负载列表201中移除所述负载(步骤 714)，并向客户51返回失败来拒绝客户的业务需求61 (步骤715)。
[0050] 下面结合具体的流程图对图4-图7中涉及的指令器20和站点代理30的处理过 程进行说明。在图8-图23中所使用的用字母表示的序号指代含义为，i表示某个数据中 心站点，η表示站点内的某个服务器，j表示某个具体的业务或负载，k表示某个业务类型， p表示MapReduce类业务或负载拆分得到的某个任务。
[0051] 图8表示了指令器20选择具有优化成本的站点的流程图。如图4-图7中所述，当 指令器20收到第j个(例如，j=2)业务需求61时(步骤801)，指令器20的需求处理器206 根据业务资源需求表203估计第j个业务需求61的处理器资源需求R OT(j，t)和带宽资源 需求Rbw(j，t)，产生第j个需求对应的负载描述(参考图10的流程图，步骤802)，并把产 生的第j个负载添加到全局负载列表201中（参考图16的表格式，步骤803)。然后指令器 20的成本计算器205根据所述资源需求R OT(j，t)，Rbw(j，t)和站点状态表202依次计算在 第i个（i=l，2, 3)站点执行第j个负载时可能消耗的电力成本(步骤804): ^0052] Ce,v(/, /) = j ( RCPl;(jj) " .V,,(/, /,) //>HE (/, /〇) * di
[0053] 其中，Cele(j，i)是第i个站点执行第j个负载时可能消耗的电力成本，N ele(i，tQ) 是第i个站点在当前时间h的电力系数，PUE(i，〇是第i个站点在当前时间h的电源使 用效率（Power Usage Effectiveness), tj是第j个负载可能执行的时长。既然负载的可 能执行时长对每一个数据中心站点是不变的，并不影响最后的优化结果，因此h可以设定 为单位时长，例如1秒。
[0054] 类似的，指令器20的成本计算器205根据所述资源需求ROT(j，t)，R bw(j，t)和站 点状态表202依次计算在第i个（i=l，2, 3)站点执行第j个负载时可能消耗的带宽成本(步 骤805):
[0055] ( ；,,(/,/) = Rhw(jJ) * NfjL/〇) * dt
[0056] 其中，Cbw(j，i)是第i个站点执行第j个负载时可能消耗的带宽成本，N bw(i，〇是 第i个站点在当前时间h的带宽系数，\是第j个负载可能执行的时长，例如1秒。
[0057] 在成本计算器205完成对所有站点的成本计算后，把中间计算结果Celc;(j，i)和 Cbw (j，i)发送给全局均衡器204,并由全局均衡器204选择具有最小电力成本及带宽成本之 和卿Min(Sum(Cele(j，i)，Cbw(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)。
[0058] 图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^at)和带宽资 源需求R bw(j，t)，将其设为选择一个服务器的算法的输入(步骤903)，然后调用例如网络感 知的负载均衡算法(参照中国专利申请CN201210033677. 6)来根据ROT(j，t)、Rbw(j，t)和 服务器状态表302从站点11的所有开机中的服务器中选择一个满足资源需求的服务器， 例如服务器112 (步骤904)。如果步骤902的判断结果为否，表示MapReduce业务，则从负 载请求63中读出第j个负载的处理器资源需求R ePU(j, t)、带宽资源需求Rbw(j, t)和任务 数，将处理器资源需求RCTU(j，t)和带宽资源需求Rbw(j，t)除以任务数后设为选择一个服 务器的算法的输入(步骤905)，然后调用例如网络感知的负载均衡算法(参照中国专利申请 CN201210033677. 6)来根据所述输入和服务器状态表302从站点11的所有开机中的服务器 中为所述负载的下一个任务选择一个满足资源需求的服务器，例如服务器111 (步骤906)。
[0059] 运行完选择一个服务器的算法后，本地均衡器304查看运行结果是否包含可用的 服务器和从边缘路由器115到达所述服务器的路径(步骤907)。如果步骤907的判断结果 为是，则检查负载请求63中的业务类型和任务列表来判断是否完成负载请求63的处理(步 骤908)，步骤908具体包括如果步骤903-步骤906处理的是一个流类型负载或者是一个 MapReduce负载的最后一个任务则判断结果为是，否则如果步骤903-步骤906处理的是一 个MapReduce负载的最后一个任务之前的任务则判断结果为否。如果步骤908的判断结果 为是，则本地均衡器304把负载和所选的一个或多个服务器{P(j，η)}加入到本地负载列表 301(参考图19的表格式，步骤910)，并通过消息接口 308向指令器发送接受负载的答复消 息(步骤911 )。如果步骤908的判断结果为否，则返回步骤902继续处理MapReduce负载的 下一个任务。对于流类型的负载，本地均衡器304只需要执行一遍步骤902-步骤907。而 对于MapReduce负载，本地均衡器304需要重复步骤902-步骤907的循环，直到处理完该 负载的所有任务。
[0060] 如果步骤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)。
[0061] 图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)。
[0062] 完成步骤1005或步骤1008后，需求处理器206根据从业务需求61得到的信息 {:业务类型，协议类型，端口号}搜索业务资源需求表203中的匹配业务(步骤1009)，并检 查是否存在匹配记录(步骤1010)。如果步骤1010的判断结果为是，则根据找到的匹配记录 (例如第k条记录）来估计所述业务需求的资源需求。具体包括，判断业务类型是否为流类 型(步骤1012)。如果步骤1012的判断结果为是，则把匹配记录中处理器资源需求和带宽资 源需求对站点i和时间t的平均值分别设为当前的第j个业务需求61的处理器资源需求 和带宽资源需求，即
【权利要求】
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需求和带宽需求估算运行应用所需的资源， 在计算至少包括电力成本和带宽成本的运行成本的步骤中，根据所述电力系数、电力 使用效率和估算的运行应用所需的资源计算电力成本，根据带宽系数和估算运行应用所需 的资源计算带宽成本。
【文档编号】G06Q50/06GK104144183SQ201310166725
【公开日】2014年11月12日 申请日期:2013年5月8日 优先权日:2013年5月8日
【发明者】石颖 申请人:株式会社日立制作所
相关技术
网友询问留言
已有0条留言
- 还没有人留言评论。精彩留言会获得点赞！
1