CN110603526A

CN110603526A - 基础设施控制结构系统和方法

Info

Publication number: CN110603526A
Application number: CN201880025446.6A
Authority: CN
Inventors: 史蒂文·格芬
Original assignee: Victor Information Technology Systems Co Ltd
Current assignee: Victor Information Technology Systems Co Ltd; Avocent Huntsville LLC
Priority date: 2017-06-30
Filing date: 2018-05-15
Publication date: 2019-12-20
Anticipated expiration: 2038-05-15
Also published as: WO2019005309A1; EP3610337A1; EP3610337A4; CN110603526B

Abstract

一种数据中心基础设施管理(DCIM)系统，其具有集成到数据中心中的至少一个基础设施装置中的基础设施控制结构(ICF)子系统，用于使独立的基础设施装置能够独立地与DCIM进行通信并由ICF子系统控制。

Description

基础设施控制结构系统和方法

相关申请的交叉引用

本申请要求于2017年6月30日提交的美国发明申请第15/639,898号的优先权，该发明申请是于2013年10月16日提交的美国序列号13/984,417的部分继续申请，该序列号是于2012年2月9日提交的PCT/US12/024405的国家阶段；PCT/US12/024405要求于2011年3月30日提交的美国临时申请第61/469,357号和于2011年2月9日提交的美国临时申请第61/441,131号的权益。以上申请的公开内容通过引用并入本文。

技术领域

本公开内容涉及数据中心基础设施管理系统和方法，并且更具体地涉及能够监视特定数据中心组件的操作和配置的数据中心基础设施管理系统和方法。更具体地，本公开内容涉及能够实时地与特定数据中心组件直接通信以向组件通知是否可以鉴于其他数据中心操作因素来适应对组件的建议配置或操作变更的数据中心基础设施控制结构系统和方法。

背景

该章节提供与本公开内容相关的背景信息，其不一定是现有技术。

在现代数据中心中，物理基础设施的静态性质(例如，电力可用性、冷却容量和空间限制)以及信息技术(“IT”)工作负荷的固有动态性质已经创建了通常会存在显著的低效率的数据中心环境。解决这些低效率将使数据中心的操作员能够提高他们的基础设施的容量利用率并降低总体功耗。然而，到目前为止的挑战是无法根据在任何给定时间经历的IT负载动态地变更与数据中心相关联的物理容量(例如，功率和/或冷却容量)。

由于基础设施的静态性质，IT工作负荷通常被给定其操作的安全裕度。参照图10，这意味着将总会有至少一定程度的可用容量未被使用。如果IT工作负荷开始变得太接近容量，则基础设施升级有额外容量，这始终是一项资本密集型工作。然后，从成本的角度来看，为功率和冷却需求提供“安全裕度”的现有方法会意味着实体的显著增加的费用。这是因为在各种IT组件以低于最大容量操作或完全不活动的二十四小时时段期间通常存在显著的延伸。然而，现代数据中心通常仍然必须提供足够的额外功率和冷却容量，以满足各种IT组件的最大预期工作负荷。

参照图11，在理想环境中，IT组件和设施基础设施(例如，目前可用的冷却容量；目前可用的未使用电力和目前可用的机架空间)将通过一些物理数据中心管理基础设施来进行持续通信。物理基础设施将监视IT设备并相应地调节容量。当IT组件的工作负荷超过安装的最大总容量时，数据中心管理基础设施还将能够限制IT设备使用的资源量。然而，可能仍然存在应用请求特定IT组件(例如，服务器)开始执行将可能(或确定)导致基础设施资源诸如功率或冷却被超过的任务的情况。换句话说，可能仍然存在特定IT设备本身在开始用户命令的操作或任务之前不具有关于可供使用的数据中心资源的特定信息的情况。当特定IT设备开始命令的操作或任务时，这会导致数据中心环境中的功率或冷却容量中的至少一个被超过。当功率或冷却容量被超过时，这可能需要数据中心管理系统在数据中心资源被超过时限制或缩减其他IT设备的使用。因此，让特定IT设备在没有首先检查数据中心资源的可用性的情况下开始采取其请求的动作可能导致数据中心生态系统的总体动态的不期望的变更。在典型的大规模动态IT环境中尤其如此，在大规模动态IT环境中，设备被频繁地投入使用和解除以解决不同的业务IT需求。每一次变更都携带有内在的风险。因此，IT负载的动态和物理基础设施的静态性质通常迫使数据中心在全功率和冷却容量(即具有大量备用容量)的安全距离内操作，以确保始终能够满足数据中心资源需求。

发明内容

在一个方面，本公开内容涉及一种数据中心基础设施管理(DCIM)系统。该系统可以具有用于使独立的基础设施装置能够独立地与DCIM进行通信的基础设施控制结构(ICF)子系统。可以包括DCIM子系统，用于与独立的基础设施装置进行通信并且控制独立的基础设施装置。可以包括基础设施控制结构子系统(ICF)，用于形成DCIM系统的一部分并且与独立的基础设施装置进行通信并控制独立的基础设施装置。管理器组件可以存在于独立的基础设施装置上，用于与DCIM子系统和ICF子系统两者进行通信，并且协助执行命令和控制独立的基础设施装置的操作。通信子系统可以存在于独立的基础设施装置内。可以包括形成ICF子系统的一部分的元件库，其用于包含实现独立的基础设施装置和与ICF子系统相关联的至少一个应用之间的直接通信的信息。ICF子系统可以包括位于可管理性子系统引擎中、域模型中、服务服务器上以及独立的基础设施装置的通信子系统中至少之一的组件，以使独立的基础设施装置能够向DCIM系统发送事件和报告数据中至少之一，并且使至少一个应用能够在启动对独立的基础设施装置的操作或者继续对独立的基础设施装置的操作中至少之一之前与独立的基础设施装置进行通信。

在另一方面，本公开内容涉及一种用于使数据中心基础设施管理(DCIM)系统能够与独立的基础设施装置直接且实时地通信的方法。该方法可以包括提供用于与独立的基础设施装置进行通信并控制独立的基础设施装置的DCIM子系统。该方法还可以包括为独立的基础设施装置提供通信子系统和管理器组件，通信子系统协助实现与独立的基础设施装置的通信和报告由独立的基础设施装置生成的数据或事件中至少之一。管理器组件可以用于管理独立的基础设施装置的操作。DCIM系统的基础设施控制结构(ICF)子系统可以用于独立于DCIM子系统直接与独立的基础设施装置的管理器组件进行通信。元件库可以位于ICF子系统中，其中，元件库具有关于独立的基础设施装置的信息，使得ICF子系统能够进行以下中至少之一：与独立的基础设施装置进行通信或控制独立的基础设施装置。元件库可以用于协助使独立的基础设施装置能够与ICF子系统进行通信以及使独立的基础设施装置能够进行以下中至少之一：向ICF子系统发送数据或向ICF子系统发送事件，同时实现从与ICF子系统相关联的应用接收命令并将所接收的命令传递给管理器组件以实现ICF子系统对独立的基础设施装置的控制。

从本文中提供的描述，其他应用领域将变得明显。应当理解，描述和具体示例仅用于说明的目的，并不旨在限制本公开内容的范围。

附图说明

本文中描述的附图仅用于所选实施方式而不是所有可能的实现的说明性目的，并且不旨在限制本公开内容的范围。

图1是公共数据中心模型自从其起源于大型机计算以来已经进展的变更的现有技术高级表示；

图2是可以在典型的现有技术现有数据中心的各种功能层中使用的各种组件的一个示例的高级表示；

图3是根据本公开内容的用于执行多个硬件装置的功能的单个DCIM工具的一个示例的高级表示；

图4A和图4B是可以用于形成本公开内容的DCIM解决方案的一个实施方式的DCIM软件套件的示例性模块的高级图表；

图5是DCIM解决方案架构的一个示例的高级图表；

图6是示出公共/私有服务与DCIM解决方案的域模型和CDMR之间的关系的高级图表；

图7是示出跨域模型使用的域对象与DCIM域对象之间的区别的高级框图；

图8是示出MSS组件与域模型和MSS引擎/DCIM工具的交互的架构的一个示例的高级框图；

图9是实现DCIM解决方案的一个示例的高级图表；

图10是示出IT工作负荷如何可以随时间变化并且还示出如何给IT工作负荷提供其操作的物理容量“安全裕度”的曲线图；

图11是示出如下的曲线图：如何在理想环境中在一天内调节物理容量(冷却和功率)以满足匹配IT需求，以及在IT设备使用的IT资源量试图超过对数据中心可用的总体物理容量的情况下，如何限制对IT基础设施可用的资源量；

图12是根据本公开内容的用于与思科统一计算系统(UCS)直接通信的DCIM系统的实施方式的高级框图；

图13A和图13B示出了列出涉及DCIM系统和思科UCS的各种使用场景的使用表格；

图14是当DCIM系统发现UCS时可以执行的操作的控制流程图；

图15是可以由UCS执行以发现DCIM系统的操作的控制流程图；

图16A至图16Q示出了概述图13的表格中列出的各种使用场景的操作详情的表格；

图17是示出依据形成ICF而将UCS集成到DCIM的各种子系统或组件中的点的高级图表；

图18是示出依据形成ICF而将UCS集成在DCIM的各种子系统内的点的更详细的高级框图；

图19是形成目前可用于UCS的各种符号的示例的表格；

图20是示出DCIM可以结合由VMware公司制造的一个或更多个组件来实现的四个示例性用例的图表；

图21A至图21C示出了阐述实现图20的第一用例的操作，并且更具体地DCIM用于将新的VMware公司硬件提供到ESX集群中以及数据中心的物理基础设施中的操作的表格；

图22A和图22B示出了阐述实现图20的第二用例的操作，并且更具体地在考虑数据中心中的条件的同时将新的VMware服务器提供到集群中的表格；

图23A和图23B示出了阐述实现图20的第三用例的操作，并且更具体地动态地决定最佳功率和冷却适当位置以进行定位新VM(虚拟机)的操作的表格；

图24A和图24B示出了阐述实现图20中的第四用例的操作，并且更具体地基于影响VMware系统中的迁移建议的变更的物理条件或数据中心策略的变更来重新平衡VM的操作的表格；

图25示出了根据本公开内容的另一实施方式的系统，其中，该系统适合与基础设施装置一起使用；以及

图26是示出图25的与网关/聚合器一起用于数据聚合的系统的图。

具体实施方式

DCIM工具和DRIP(硬件)

现在将参照附图更全面地描述数据中心基础设施管理(在下文中称为“DCIM”)解决方案10的示例实施方式。

概述

本章节提供本公开内容的大体概要，并不是其全部范围或其特征中的所有特征的全面公开。DCIM解决方案10是被设计成从中央位置管理数据中心的所有元件的模块化可扩展的硬件和软件产品家族。特别地，DCIM解决方案10包括一个或更多个DCIM硬件工具(在下文中简称为“DCIM工具”)和一套软件产品(在下文称为“DCIM软件套件”)。DCIM解决方案具有如下能力：管理Microsoft服务器、服务器、服务器、存储装置和串行装置、服务处理器、机架/环境传感器、数据中心电力单元、冷却单元和电力分配单元(PDU)，其中所有数据都由公共收集引擎收集。它允许数据中心操作员具有完全访问以监视和控制数据中心中的每件设备。

到现在为止，为了管理数据中心，需要多个点解决方案。DCIM解决方案10将所有这些点解决方案带入到单个产品套件中。先前，需要多个独立的硬件装置，例如远程访问应用和相关联的硬件，诸如用于管理服务器的Avocent的KVM工具；用于管理服务器、串行装置和iPDU的高级控制台服务器(ACS)；MergePoint^TM服务处理器管理器；用于管理机架传感器和环境传感器的机架数据单元(RDU)以及SiteLink^TM通信接口。先前，通常还需要多个独立的软件应用，诸如：MergePoint Infrastructure Explorer数据中心管理软件；SiteScanWeb集中监视和控制系统；用于监视电力和冷却设备的艾默生网络电力ASCO PowerQuest^TM电力接口软件；以及Vista企业软件解决方案。通过将多个软件工具联合到形成DCIM解决方案10的DCIM软件套件的统一的软件平台中，并且将多个硬件工具联合到聚合的DCIM硬件工具中，DCIM解决方案10不仅释放设备机架上的物理空间，而且操作员对数据中心的管理幅度得到增强。这使数据中心管理员能够更有效地管理和控制服务器和其他计算/存储装置、电力设备和冷却系统，以优化性能和能量使用。

除了DCIM工具提供的明显益处之外，DCIM软件套件使管理数据中心可以比先前更容易且更有效。包括DCIM软件套件的软件模块可以在与DCIM工具分离的公共主机服务器上运行，并且可以工作以提供数据中心的完整和准确的视图，同时仍然允许用户管理和控制数据中心的每个方面。主机服务器经由它们的可管理性子系统(MSS)收集引擎从整个数据中心的所有DCIM工具接收数据。通过使用DCIM软件套件模块，数据中心管理员可以从丰富的基于web的图形用户接口(“GUI”)接进实时数据、查看报告并远程管理装置。

还应当注意，DCIM工具和DCIM软件套件可以单独实现并且可以被缩放以适合用户的需要。通过以其自身实现DCIM工具，用户仍然可以远程访问DCIM工具，并且因此也可以访问连接至它们的装置。然而，用户不会从DCIM软件套件提供的报告和增强的管理能力中获益。同样，DCIM软件套件可以在没有DCIM工具的数据中心中实现，但是在没有DCIM工具提供的物理连接的情况下，实时数据收集、监视和控制不被支持。

DCIM工具和DRIP(硬件)

DCIM工具12可以包括通常驻留在所选择的设备机架中或者可以安装在数据中心内的墙壁上的一个或更多个硬件工具。DCIM工具12上的接口的布置向用户提供为了控制和性能度量收集而对各种设备的访问。如图3中所示，单个DCIM工具12将若干先前产品的功能联合到一件硬件中。DCIM工具12可以替换现有的交换机、高级控制台服务器(ACS)、MergePoint服务进程管理器(SPM)和机架数据单元(RDU)产品，并且将其所有功能联合到一个或更多个硬件工具中。工具12的基本实施方式—被称为“DCIM SP”—目标是替换现有的服务进程管理器(SPM)硬件。DCIM SP可以具有两种特定的端口配置，一种端口配置具有24个IP端口，而另一种端口配置具有40个IP端口。两个版本都可以包括8个专用串行端口。对于每个版本，IP端口可以与网络接口端口隔离并且用作第二层交换机。这种布置保留了当前SPM的配置。很多IP端口和8个专用串行端口提供可以服务服务处理器的整个机架的工具，并且还提供对机架中基于串行的交换机和电源板的控制。除了两个物理端口SPM变型之外，存在一种只有主网络端口而不具有任何后面板端口的逻辑版本——DCIM SP逻辑。

除了DCIM SP实施方式之外，DCIM工具12可以具有标记为“DCIM分支8”、“DCIM条目”和“DCIM企业”的三个较高端实施方式。DCIM工具12的实施方式的较高端组提供可以在IP或串行连接之间自动选择的自动感测端口。DCIM分支8不具有RDU连接，而DCIM条目和DCIM企业装置具有RDU连接。DCIM条目和DCIM企业工具上的RDU接口模仿RDU工具的主连接并且允许类似功能被包括在较高端DCIM装置上。较高端DCIM工具12实施方式还可以具有与提供常规的KVM功能的IQ模块对接的能力。该IQ模块被称为“数字机架接口盒”(DRIP)，提供模拟视频的数字化以及键盘和鼠标控制以及虚拟媒体访问。

DRIP的关键功能是：

■为装置键盘和鼠标提供USB和PS/2端口；

■使模拟视频数据数字化并将其发送至DCIM工具；

■连接至服务器的服务处理器，以向DCIM工具发送IPMI数据；

■实现对虚拟媒体的访问；以及

■实现智能卡支持。

为了支持各种硬件平台，提供了工具主机软件平台。工具主机平台可以基于vServer补丁并且用作OS虚拟化平台。这使得基于操作系统的应用在DCIM工具12主机平台上以最小的变更运行。以这种方式建立DCIM工具12使将各种技术组合到单个工具中所需的变更最小化。它还有助于组能够专注于他们的核心功能，而无需了解DCIM工具12主机平台的详情。

DCIM工具12软件架构的非常期望的特征是它使完成的装置看起来像单个内聚工具，即使它们可以由若干个底层不同的软件应用构造。为实现此目的，主机系统可以被设置成提供若干系统功能，若干系统功能提供外部用户与内部客户应用之间的网关。这些功能包括许可、认证、授权和审核(AAA)以及用户接口。这些功能接受外部输入并将其映射至正确的应用上，而无需用户需要底层架构的任何知识。例如，当用户对DCIM工具12进行认证时，AAA功能可以通知客户应用中的每个客户应用该用户是有效的。用户不需要对每个客户应用进行认证。其他主机部分可以包括诸如内核、基本文件系统和硬件组件驱动器支持的内容。DCIM工具12中的每一个还可以托管可管理性子系统(MSS)软件引擎(将结合图5进行讨论)。

总之

总之，在下面的表格中示出了两个DCIM平台—平台“A”和“B”—的至少六种不同的配置。

DCIM软件套件

模块的DCIM软件套件12a是模块化的、可扩展的并且被设计成使数据中心的操作、管理、配置或扩展无缝且简单。模块的DCIM软件套件12a的一个示例在图4A和图4B中示出并且可以包括：库存管理器14、设施管理器16、场景规划器18、变更规划器20、变更管理器22、操作管理器24、事件监视器26、虚拟化管理器28(以及可能的机架电力管理器和配置管理器30)。这些模块彼此无缝集成并且提供丰富的用户接口，具有如下能力：拖放条项，显示资产的高保真图像和报告数据，并且利用可用设施的组合来编译用户特定视图。

DCIM软件套件12a足够灵活，以适应系统管理器从操作系统和数据库到web浏览器界面在许多不同区域中的偏好。软件模块可以安装在服务器、服务器或服务器上，并且也可以安装在其他品牌的服务器上。支持SQL和数据库。为了访问软件模块，支持各种商业上可用的操作系统和web浏览器。

对于使用艾默生网络电力或公司的现有产品例如数据中心资源管理系统、集中监视和控制系统或MergePoint^TMInfrastructure Explorer软件(AMIE)的管理员，DCIM软件套件12a支持数据的迁移。该数据可以包括所有资产和规划数据、相关联的项目和符号库。可以手动触发导入，而将不需要将任何资产、放置、规划或项目数据从AMIE手动映射到DCIM软件套件的模块。在下面的页面中详细描述各个DCIM软件套件12a软件模块。

DCIM库存管理器模块14

库存管理器模块14管理构成设备的数据中心库存的DCIM记录。通常，数据中心管理员和现场技术员通过诸如电子表格、文档、图纸文件、财务系统、提货单等的各种手段管理设备列表。这些都不是理想的方法，而是趋于格式特定的、不准确的并且经常是过时的。它们也没有及时提供对关于物理设备位于何处及其用途的信息的访问。DCIM库存管理器模块14用以下系统替换所有这些特定方法，该系统利用诸如服务器和交换机以及像电力分配单元(“PDU”)和不间断电源(“UPS”)的关键基础设施设备的IT资产的设备计数给出数据中心的整个库存的清晰图片。它使得用户快速看到设备位于何处并且给出功率和空间使用的总计。

为此，DCIM库存管理器模块14可以依赖于导入软件能力和专用视图，例如：1)导入能力，用于从各种源提取设备记录，并将来自这些源的信息组合成完整的数据集；2)地理视图，使得用户能够提供数据中心安装的全局定位，并深化以显示更详细的位置视图，诸如校园视图、区域视图、建筑物的图片等；3)文本和图形库存列表，作为关于“已放置的”和“未放置的”库存(尚未分配位置的条项)的文本视图；4)数据中心档案视图，其列出由系统管理的数据中心；5)关于“已放置的”库存(已分配位置的条项)的楼层平面图和立视图；6)工作空间，允许用户组合来自其他视图的图形和数据元件来为他们提供关键信息的“仪表板”，他们可以随时参考这些信息；以及7)层，允许用户在库存管理器图形绘图内看到来自其他应用的信息。

DCIM库存管理器模块14能够创建、更新和删除所有表示的对象。这些对象包括：

IT空间——IT设备所位于和被容纳的区域，以及更精细级别地，安装设备的区域。

楼层——包含一个或多个数据中心空间并且与建筑物中的楼层相关的区域。

数据中心——被设计成容纳和运行IT设备的区域。典型的数据中心具有升高的楼层空间以及专用的电力和冷却设备。

空间——直接安装IT设备的数据中心楼层的区域。典型的数据中心空间具有升高的楼层和机架以容纳设备，并且防止未经授权的进入。

区——由顾客定义的数据中心的地理区域，允许列出整个数据中心区域内的容量和资源使用。在我们的定义中，区是数据中心楼层内的一个连续空间。

其他空间(走道、自由空间)——当从总数据中心空间中扣除时允许可使用的数据中心空间的计算的空间。

企业——跟踪关于企业的信息来为整个数据中心档案和管理它们的团队提供背景。可以在软件中以全局级别跟踪企业信息。

IT设备——可以包括用于数据处理、通信和存储的直接目的的所有设备以及用于容纳它们的设备。这包括：机架、长凳、架子、数据柜；服务器、网络工具；符号、占位符；以及传感器设备。

关键基础设施——可以包括支持关于数据中心空间的冷却和电力分配的所有装置，包括：本地公用事业进入仪表、浪涌保护装置、变压器、开关设备(HV/MV/LV)、发生器、不间断电源(UPS)、能量存储装置和系统(例如，电池、飞轮、燃料电池)、断电装置(例如电路断路器、开关/电力接头)、静态转换开关、落地式PDU系统、电源板、远程电源板、母线槽电力分配、突击机插座、机架PDU、太阳能阵列、冷却塔、冷却器、泵、节能器(水/空气)、落地式CRAC、机柜级CRAC、冷凝器、热交换器和水容器(罐)。

DCIM配置管理器模块30

DCIM配置管理器模块30扩展由DCIM库存管理器模块14提供的DCIM记录的管理。DCIM配置管理器模块30消耗DCIM库存管理器模块14的能力，扩展它们以管理所选资产之间的关系。这些关系可以包括但不限于连接、逻辑组和冗余。为此，DCIM配置管理器模块30可以包含各种特征，诸如：

■连接视图，允许用户详述任何放置的资产之间的连接。这可以包括拓扑、端到端跟踪、依赖性和冗余；

■面板明细表，允许用户查看面板和该面板内的断路器的详情；

■报警能力，允许用户指定关于规划、组或资产的阈值并对违背该阈值的消耗进行报警；

■可定制的视图，允许用户定制他们想要使用和导航的应用数据的视图；以及

■Web服务接口，允许用户操纵来自外部软件实体的应用数据。

DCIM设施管理器模块16

DCIM设施管理器模块16为关键基础设施设备提供完整的性能利用和事件管理能力。它提供了数据中心楼层和周围设备房间上的设备和机架的真实的、虚拟的视图，以及电力系统的底层电气单线示意图和冷却系统的管道和仪器装设系统图。它还可以提供设备维护特征，以协助维护跟踪、安排和设备投入使用。通过如设计的提供电力和冷却基础设施的系统视图，DCIM设施管理器模块16允许用户查看每个装置或系统级的功耗和冷却容量(在使用中和搁置中这两者情况下)。另外，它使用户对电力和冷却系统预留负载块，并基于历史容量使用将功率和冷却容量需求投射到未来中。

设施管理器模块16可以以文本和以图形这两种方式提供使用户更好地理解和管理数据中心基础设施的许多有用视图。DCIM设施管理器模块16可以显示楼层平面图、电气图、空气分布以及管道和仪器装设系统图。DCIM设施管理器模块16可以提供各个元件或基础设施设备组的实时性能状态。如果设备支持，则图中的每个条项都允许用户启动以下动作或控制操作：

■接通/关断特定设备/装置(如果适用的话)；

■变更用户可配置条项(例如设定点、标签)；以及

■查看关于每件设备/装置的详细信息。

除了主要视图之外，DCIM设施管理器模块16可以具有至少三个单独的仪表板视图，以向用户提供数据中心基础设施中的实时操作的整体图片。“工业效率仪表板”可以显示数据中心的能耗的标准效率度量(例如PUE/DCiE)。“公用事业消耗仪表板”可以显示总功率负载(kW)、总冷却负载、水消耗——如果适用的话——以及总体公用事业费用。“容量仪表板”可以显示每种类型的数据中心设备的聚合容量(例如，所有楼层安装PDU的当前容量)的细分，以及数据中心电力和冷却系统的搁置容量的细分。

在一个示例中，DCIM设施管理器模块16还提供显著的可伸缩性，例如支持多达5000个关键基础设施设备和仪器装置(或可能更多)，每个设备具有大约200个数量的数据点。设备数据(除事件之外的所有参数)也可以以最低每五分钟来轮询。该数据的一些示例可以包括温度、UPS的百分比负载和电路断路器状态，仅举几个示例度量。

场景规划器模块18

DCIM场景规划器模块18提供了建立和比较数据中心中未来资源使用的成本有效场景的能力。它可以利用来自数据中心基础设施管理应用和现实世界测量的信息来绘制准确的资源使用历史，并投射未来的增长和下降趋势。利用DCIM场景规划器模块18，数据中心管理员和容量规划员可以确定最佳的动作方针。无论它意味着应当解除安装和联合安装，还是建立新安装，DCIM场景规划器模块18都允许顾客比较和对比未来数据中心使用的不同场景。可以比较技术更新的影响、数据中心空间内增加的密度、用于更高效的能量使用的关键基础设施的升级以及估算对IT的需求，以建立以尽可能低的成本满足服务水平的动作规划。一旦确定了动作方针，DCIM场景规划器模块18就协助将规划传达给管理层。可以包括在DCIM场景规划器模块18中的软件能力包括但不限于以下中的一个或更多个：

■收集和了解聚合的全球数据中心基础设施资源的过去趋势的能力；

■将过去的聚合使用趋势投射到未来中以全局地预测基本基础设施需求的能力；

■进行关于基础设施需求的“假设”场景规划，以及评估数据中心移动、增加、解除和联合的影响的能力；以及

■为项目管道管理建立工作流过程的能力，包括技术专家和系统所有者的改进以及业务管理者的批准。

DCIM变更规划器模块20

DCIM变更规划器模块20允许用户规划和执行数据中心基础设施中的变更。为此，DCIM变更规划器模块20可以依赖于：

■规划视图，允许用户看到规划的项目的详情；

■时间线，允许用户看到整个项目中关于所选资产规划的变更；以及

■报警能力，允许用户在任务完成时得到通知。

DCIM变更规划器模块20允许用户创建任意数量的项目，管理这些项目并在它们之间浏览。用户可以向项目分配名称、标签、描述、目标完成日期和所有者，并且也可以向项目分配单个任务。一旦项目已经创建，其详情可以以日历格式被视觉化，其中进一步的详情可用于任何选定的项目或任务。可以通过移动项目日期、删除任务或添加任务来编辑项目，并且可以删除项目。除了特定任务之外，用户可以分配通用任务，通用任务与模块中任何特定放置的资产不相关。DCIM变更规划器模块20还允许用户分配和查看对项目中的其他任务的依赖性。利用创建和管理多个项目的能力，可能会出现项目之间可能存在冲突，但DCIM变更规划器模块20允许用户查看冲突及其严重性，并通过变更项目的参数来解决冲突。

一旦创建了项目并分配了任务，DCIM变更规划器模块20允许用户查看项目的时间线以及与受项目影响的任何资产相关联的变更的视觉化。用户可以看到所选资产(例如，机架)的视图，其中资产以其各种变更状态示出，这些变更状态被安排成在项目的生命周期期间发生。DCIM变更规划器模块20还可以显示在通过所选日期着色的项目期间要被执行的工作的视图，这允许时间线向IT人员显示在给定日期对于任何所选资产发生了什么。

对于给定项目，DCIM变更规划器模块20还允许用户记录所有项目活动并向任何受影响人员通知该活动。一旦用户的指定任务或项目被创建、编辑、发生冲突或被标记为已完成，通过电子邮件通知用户。另外，用户可以创建自定义的报告，从外部源以标准格式导入项目信息，以及将项目信息导出为PDF或电子表格以供外部使用。

DCIM变更管理器模块22

DCIM变更管理器模块22扩展DCIM变更规划器模块20的规划和执行能力，以在项目上施加预定义的过程或工作流并将进展和决定传达给项目成员。为此，DCIM变更管理器模块22可以依赖于以下软件能力和专用视图：

■模板工作流过程，允许工作流设计者设计和发布未来项目要使用的工作流过程。

■与DCIM模块的交互，允许工作流过程与DCIM模块交互，以验证某些必需的动作是否已完成。

■支持与第三方IT系统的集成，以允许设计者配置接口，以允许外部源查询应用数据并启动工作流过程。

■工作流过程中的人员交互，允许用户与从模板创建的过程进行交互。

DCIM变更管理器模块22提供创建项目模板的能力，该项目模板具有由DCIM变更规划器模块20提供的较低级任务支持的用户定义的高级动作。项目模板可以用于在需要时创建项目，其中，项目可以遵循模板预定义的步骤到完成。模板可以包含但不限于：

■与已安装的库存管理器模块相关的预定义的高级任务(例如“移动服务器”或“添加连接”)。

■用户定义的任务类别(例如“移动”、“添加”)。

■到现有工作流模板的触发点。

一旦模板被创建，用户可以分配角色以在模板中使用。用户向角色分配名称、描述和标签，并且可以分配其他用户。DCIM变更管理器模块22允许在必要时将用户分配给多个角色。除角色外，用户可以创建工作流进程并向每个工作流分配名称、描述和标记。一旦工作流被创建，可以添加步骤(无论是用户定义的还是预定义的)，并且可以向每个步骤分配特定的用户或角色。为了添加进一步的详情，用户可以向每个步骤定义规则，诸如进入和退出标准。步骤可以链接在一起以定义进展，并且可以通过某些步骤来创建子过程。

一旦用户设置了工作流，他/她就可以模拟执行的“运行”以识别任何错误并验证工作流。用户还可能想要为各种工作流事件设置自定义通知。DCIM变更管理器模块22允许用户这样做，并且当任务开始、完成时或当发生任何其他工作流事件时向参与者传播通知。

DCIM操作管理器模块24

DCIM操作管理器模块24将现实世界信息与管理数据中心基础设施配置相结合。它提供如下接口，接口用于测量整个数据中心基础设施的性能和利用率并且揭示机架中当前可用的净空高度，使得可以实现设备的适当放置。DCIM操作管理器模块24可以连接至来自可管理性子系统(MSS)服务的实时数据馈送(关于功率和温度)，以比较和验证在配置管理器模块30能力中建立的性能指南和设计标准。

DCIM操作管理器模块24还可以用于优化功率、冷却和空间容量，以实现数据中心基础设施资源的总体优化。该模块解决的业务问题是围绕功率和冷却的管理。数据中心管理员通常会维护功率和冷却的大型缓冲器，以保护系统免受由于功率急升和使用周期增加而导致的断电。通常不能有效管理要预留的缓冲器数量。这些缓冲器的减少实现更好的资源利用。例如，更多设备可以位于一个或更多个设备机架中，同时对于所有设备条项仍然满足足够的功率和冷却需求。

该产品的一个重要特征是它提供了一种自然而优雅的方法来查看关于数据中心的监视信息——存在由许多系统以许多不同格式生成的数据中心的大量信息。处理所有这些数据并以可用形式看到数据的结果可以更准确地理解数据中心环境的操作，更好地理解能量使用的真实成本，使数据中心中的投资最大化，并且确保关于IT的连续24/7操作。

软件能力继承自为DCIM配置管理器模块30和DCIM库存管理器模块14定义的软件能力。DCIM操作管理器模块24将新特征添加到如本文中所列的DCIM配置管理器模块30能力。然而，可能存在为DCIM操作管理器模块24定义的其他软件设施，诸如但不限于：

■用于监视实时数据馈送的仪表板。

■用于显示温度传感器输出和冷却参数诸如空气流的其他视觉化。

DCIM事件监视器模块26

DCIM事件监视器模块26提供易于理解的用于管理警报的系统。它提供单一、统一的视图，以监视关于整个用户的整个企业中关键基础设施设备的警报。相关信息以简单、图形的方式呈现，使其易于理解和快速响应。DCIM事件监视器模块26允许用户但不限于：

■维护服务级别协议(SLA’s)。

■保持业务关键的IT基础设施可用和在线。

■维护关键基础设施系统冗余。

■确认并验证动作是否已发生。

DCIM虚拟化管理器模块28

DCIM虚拟化管理器模块28提供用于管理数据中心中的虚拟基础设施的工具。它有助于将物理机与虚拟机映射，管理虚拟机以及对虚拟机进行分组以便于管理。DCIM虚拟化管理器模块28可以将信息中继到DCIM操作管理器模块24，以与虚拟化管理服务器(例如，VMware虚拟中心管理服务器)进行接合。然后，DCIM操作管理器模块24可以自动发现主机和虚拟机，将该信息中继回到DCIM虚拟化管理器模块28。利用该信息，用户能够在周期性的、预定义的时间间隔上指定虚拟化管理与虚拟化管理服务器之间的虚拟化基础设施信息的同步安排。用户还可以基于需求从DCIM虚拟化管理器模块28启动同步。

随着虚拟化库存同步，用户能够以图形格式查看库存。DCIM虚拟化管理器模块28可以对照物理库存或服务器在图形上描绘虚拟机，以显示哪些虚拟机被安置在哪里。另外，DCIM虚拟化管理器模块28可以提供集群视图(示出各种集群中的虚拟机的组)、具有相关联的虚拟机的服务器的虚拟列表以及使用户找到他/她想要管理的特定虚拟机、集群或服务器的搜索特征。当用户选择正确的虚拟机时，虚拟化管理器模块28通过从虚拟机启动虚拟化提供商的远程控制台、Web浏览器或RDP来提供访问虚拟机控制台的能力。

DCIM解决方案10的其他详情

参照图5，可以看到DCIM解决方案10的各种组件。DCIM解决方案10的架构包含以下高级组件。将在下面的讨论中更详细地描述每个组件。

呈现UI 32——这些组件表示关于各个应用和关于平台的人机接口。通用平台34包含基于web的控制台框架，该框架允许各个应用和平台插入用户接口组件。呈现UI 32消耗由提供实际业务功能的服务层36暴露的公共接口。逻辑上，呈现UI 32可以分为两个层：客户层38，通常驻留在web浏览器内并且表示模型-视图-控制器架构中的“视图”；以及服务器层40，通常表示控制器。

企业服务总线(ESB)——企业通用平台42包含企业服务总线44，企业服务总线44提供用于商业服务的容器并且提供服务之间的消息的智能路由。该架构假设呈现UI 32层(具体地，控制器40)与ESB 44之间的通信将是SOAP/HTTP，尽管可以基于特定的应用设计要求使用其他传输。

应用服务36——这些可以是提供产品应用功能的单个和/或复合服务。服务组合是为使特定任务或业务流程自动化而共同组成的服务的聚合。这些服务36可以由私有服务和公共服务两者组成。公共服务在ESB 44上暴露并且可供其他应用消耗。这些应用服务36使用域模型46(例如通过Java)来访问特定于产品域的业务对象。

通用平台服务48——这些是被提供为企业通用平台42的一部分的实用程序服务并且可以是单个服务或复合服务。企业通用平台42提供可能被任何产品使用的这些服务，并且可以包括诸如认证、授权和审核的服务。这些服务是可配置的，使得产品线架构PLA可以选择对于给定PLA要包括的哪些服务。为了最大程度的可扩展性，这些服务应当被数据驱动成使得它们还通过添加域特定知识(例如，对于给定域是唯一的新事件类型)是可扩展的。

可管理性子系统(MSS)服务50——这些是通过分布式实时框架提供受管元件(或受管装置)的管理(例如发现、数据获取、命令和控制)的复合服务。MSS服务50与DCIM工具12进行交互以执行数据获取并将获取的数据存储在时间序列数据库52和通用数据模型存储库CDMR 54中。

时间序列数据库(TSD)52——时间序列数据库52操作以保持从MMS服务50发送的遥测数据。

DCIM工具12——DCIM工具12(或工具12)形成作为到受管设备或受管装置的接触点的硬件工具。每个DCIM工具12可以加载有包括KVM、串行、服务处理器和用于数据获取的MSS引擎56的若干软件应用。

MSS引擎56——MSS引擎56可以是可以部署在每个DCIM工具12上以获取度量数据并对由每个DCIM工具12处理的受管设备执行管理(例如，发现、数据获取、命令和控制)的软件组件。MSS引擎56将数据馈送到MSS服务50以存储在时间序列数据库52和CDMR 54中。

受管设备(或受管装置或受管组件)——表示可寻址并且可以被管理(即，以某种方式控制)和/或监视的实体(例如，“装置”)。

域模型46——域模型46提供跨所有应用的域概念的通用定义(例如，允许应用特定定制的共享的、可扩展的域类库)。在一个示例中，域模型46可以表示为本机Java对象。它还将可管理性旋钮和拨号类型操作委派给MSS服务50。

通用数据模型存储库(CDMR)54——CDMR 54形成负责创建和保持域模型对象的存储库。CDMR 54隐藏了初始化域对象的复杂性并且隐藏了持久性子系统58。

DCIM数据仓库60——DCIM数据仓库60可以是保持定义的域对象和与这些域对象相关联的其他配置信息的SQL数据库。DCIM数据仓库60可以与持久性子系统58通信。

集成服务62——为支持与第三方应用的集成而部署的复合服务。

第三方应用——可以与企业通用平台42集成的外部应用(例如，Hewlett-PackardOpenView软件、CiscoWorks LAN管理解决方案工具、EMC公司EMC Smarts应用发现管理器(ADM))。

技术联盟——用于紧密集成并实现闭环控制系统的关键技术联盟的开发(艾默生内部和外部)。技术联盟具有：

艾默生网络电力产品：用于将DCIM组件嵌入到受管装置和元件内的Liebert电力和冷却产品允许发现、监视和控制各种Liebert产品。

外部技术联盟(例如：思科、EMC和VMware)，用于将DCIM组件嵌入受管装置和元件中，以提供关于服务器工作负荷的详细信息并集成电力和冷却消耗。

所有组件可以部署在同一服务器上，但DCIM解决方案10足够灵活，以允许将主要组件放置在单独的服务器(例如客户端、应用服务器、数据库服务器、报告服务器等)上，以实现可伸缩性和冗余目的。

以下是DCIM解决方案10的各种组件的进一步讨论。

域模型/CDMR

参照图6，域模型46可以被视为表示数据中心基础设施实体的Java类的集合——以及这些实体存在于的上下文。另外，域模型46可以表示用户、软件许可证和其他相关联的数据中心基础设施管理(DCIM)实体。这些可以被视为“事实”。这些事实由应用和服务使用。

通用数据模型可以在所有DCIM应用模块14至30之间共享。各个产品通常扩展DCIM产品线的共享的通用数据模型。CDMR 54将Java类实例映射到持久性存储(在关系数据库诸如DCIM数据仓库60中)，强制授权，隔离租户，检查完整性约束等。CDMR可以解决各种交叉问题。

域模型46是用于表示实体(被管理)、实体之间的关系以及关于实体的策略等的域类的集合。域模型46建立用于表示DCIM域内的所有已知‘事实’的约定。然后，这些‘事实’在DCIM产品线内的所有产品之间共享。

参照图7，CDMR 54为被管理的实体呈现监督控制和数据获取(SCADA)解决方案。该接口紧密耦合至域对象。CDMR 54支持任意一组域类(其构成域模型)。CDMR 54协调并发对象修改，支持域对象持久性并且提供许多其他支持服务(如对象标识符——OID生成约定/机制)。另外，CDMR 54提供了可以由域类开发人员调用以解决如授权解决/执行、多租户检查、易失性属性访问等的交叉问题的一套设施。

对于大部分目的，DCIM域模型46隐藏由MSS服务50和MSS引擎56形成的可管理性子系统(MSS)62(将结合图8进一步讨论)。命令和控制操作通过域模型46启动并且根据需要委派给MSS子系统62。

在DCIM域模型46的覆盖下，MSS引擎56可以重复使用CDMR支持的DCIM域模型46。这消除了设计域模型信息的不同表示的需要——以及然后将其映射到CDMR 54支持的DCIM域模型46中(以及之外)的需要。这还允许MSS引擎56重复使用CDMR 54以最终(最接近于装置和最近)检查授权策略、多租户策略、完整性约束等。为了支持多个网络操作中心，每个CDMR54实例可以参与渴望的(尽快的)最终一致性机制。

以上讨论解释了跨域模型使用的域对象与DCIM域对象之间的区别。上面，跨域模型应用的域对象被称为‘管理域对象’。本质上，这些是描述其他域对象的一些方面——例如授权策略(关于域对象)、多租户策略(关于域对象)、用户定义属性(UDP——与域对象相关联)等的域对象。

在字面意义上，所描绘的‘管理域对象’是由‘平台’本身贡献的域模型对象。更具体地，示例显示由平台的CDMR 54组件贡献(并且可能需要)。

所描绘的库和工具可以包括CDMR 54。这些中的第一者可以是可重复使用的(JAVA)库，用于生成全局唯一标识符(GUIDS)以用作对象标识符。其他库可以帮助解决/实施访问控制(例如授权)、多租户控制、用户定义的属性管理、序列化(例如通用、反射驱动、格式化)等。在这个意义上，域模型46的类实现与CDMR 54之间的分界线有些模糊。它可以被认为是虚线。然而，所有应用/服务逻辑应当与在域类接口的覆盖下发生的任何事情强烈隔离。这有效地升高了实现应用/服务逻辑的抽象级别。

交互需求

域模型46以及它支持的CDMR 54提供了跨DCIM产品线的存储不可知的数据共享。另外，域模型/CDMR对解决与数据访问、将适当任务委派给可管理性子系统(MSS)62、数据变更触发/回调等相关的交叉问题。域模型46消费者是应用服务、通用平台服务以及甚至可管理性子系统62。MSS服务50将发现信息作为域模型46类的新实例(存储在CDMR54中)进行中继。域模型46可以表示事实的单个源——以及历史的单个源。

应用和服务36——支持应用特征所需的CRUD域对象。

报告数据访问64——只读访问域对象用于报告目的。这需要用于所选报告引擎66的“数据提供者”。

管理UI 68——CRUD管理域对象定义访问策略、多租户策略、完整性约束策略和其他策略。这些策略配置并驱动交叉问题的处理。

可管理性子系统62委派——应将与域对象相关联的某些操作(例如命令、控制等)委派给可管理性子系统62以进行最终执行。还应将当前的易失性数据访问(用于传感器读数等)委派给可管理性子系统62以进行实时提取(相对于最新值/估计查找)。

ORM/RDBMS 60访问——域对象通过对象关系映射技术(层70)被保持到RDBMS 60。直接访问底层RDBMS是对域模型46(和支持CDMR54)层的规避。对于应用/服务级别逻辑，直接访问底层RDBMS 60将是严重的架构违规。

另一方面，域模型46和CDMR 54是有意地可扩展的，域类相关的逻辑的特定比特应当最好通过手工制作的SQL、存储的过程等来实现。当面对一些相对罕见的、但大多数具有挑战性的实现需求时，可能有必要在应用级别、域模型级别以及甚至CDMR/ORM/RDBMS级别上点缀实现逻辑。

重复使用

DCIM解决方案10的产品线的通用数据模型利用在Vista、MergePoint^TMInfrastructure Explorer(AMIE)、信息技术操作管理(ITOM)库原型、DSView等中使用的代表模型中的域知识清单。通用数据模型还可以利用行业标准的某些方面，如分布式管理任务组(DMTF)的通用信息模型(CIM)。

CDMR 54可以基于行业标准(SQL99)关系数据库管理系统(RDBMS)。

域模型46内的一些最重要的域类将可管理性操作委派给可管理性子系统62。另外，可管理性子系统62将关于域类实例的发现/存在信息馈送到域模型46中。对于如相关事件过滤的事项，某些策略也被委派给可管理性子系统62以进行分布式处理(接近这样的事件的源)。

可管理性子系统

在图8中更详细地示出由附图标记62表示的可管理性子系统。可管理性子系统62提供如下能力：发现和控制艾默生和非艾默生装置，并从这些装置收集和分析实时数据。可管理性子系统62可以由三个主要区域组成：

MSS服务50——在平台42上暴露公共服务以向应用和域模型46提供对可管理性子系统62特征的访问，诸如检索随时间收集的历史数据点以及按需直接从终端装置检索数据点。可管理性子系统62提供用于平台42与MSS引擎56之间的通信的私有服务。

TSD 52(时间序列数据库)——存储随时间收集的历史数据点。应用和域模型46可以通过在平台42上暴露的公共接口检索这些数据点。

可管理性子系统62

MSS引擎56——可以是在DCIM工具12中运行的软件，其提供对和非艾默生装置的发现和控制，以及对来自那些装置的实时数据的收集和分析。MSS引擎56可以包含关于如何与和非艾默生装置通信的知识。MSS引擎56与在平台42上运行的MSS服务50通信。可以在顾客环境中部署多个MSS引擎56，以随着要支持的受管装置的数量增加而提供可伸缩性。每个MSS引擎56可以使用复杂事件处理器(CEP)56a来确保实时数据聚合和相关。时间序列数据库56b可以与每个MSS引擎56相关联，用于存储收集的实时数据。以下章节利用域模型46和MSS引擎56/DCIM工具12简要描述可管理性子系统62组件。

引擎管理——引擎管理服务71提供管理表示MSS引擎56和相关对象诸如产品知识和插件的域模型对象的能力。该服务还提供添加、更新和管理DCIM解决方案10的MSS引擎56的能力。

数据点——数据点服务72提供访问收集的度量数据并配置与数据点收集、聚合和分析相关的规则的能力。

基础设施——基础设施服务74提供管理MSS引擎56的基础设施(装置、容器、关系、收集规则、聚合规则和分析规则)的能力。基础设施服务74使基础设施对象在域模型46(和支持的CDMR 54)与MSS引擎56之间保持同步。随着对平台42上的域模型对象进行变更和添加，必要的信息与MSS引擎56同步。基础设施服务74服务还处理由MSS引擎56发现的新的和更新的装置/关系与平台42的域模型46的同步。

发现——发现服务76提供管理发现参数的能力，并且还提供执行按需发现的手段。MSS引擎56实际上基于这些配置的发现参数执行按需发现和后台发现活动。

命令——命令服务78提供对装置执行命令诸如断电和通电的能力。MSS引擎56实际上处理向装置或工具发送必要的命令以对装置引起期望的动作。

事件接收器——事件接收器80服务处理从一个或更多个MSS引擎56接收的未经请求的事件。根据需要将这些事件转换成匹配平台42的域模型46定义，并且然后将这些事件转发到平台42的事件系统。

路由器——路由器组件82处理MSS服务50与MSS引擎56之间的请求的路由。对于来自MSS服务50的请求，该组件确定适当的MSS引擎56来处理该请求，诸如按需发现请求或断电请求。对于来自MSS引擎56的请求，该组件确定适当的MSS服务来处理该请求。

SiteWeb协议——SiteWeb协议组件84实现专有SiteWeb协议并且提供MSS组件与MSS引擎56/DCIM工具12之间的通信。

TSD聚合器——TSD聚合器服务86与TSD 60进行通信以执行跨越由多于一个MSS引擎56管理的装置的基础设施容器的聚合。聚合规则定义数据如何被聚合并将结果存储在TSD 60中。

视频——视频服务90提供检索MSS引擎56中存储或捕获的视频内容的能力。视频数据可以从MSS引擎56流式传输至消费者。

实时数据——实时数据服务92提供从MSS引擎56以流式传输/持续方式实时检索度量值的能力。实时数据可以从MSS引擎56流式传输至消费者。

TSD——TSD服务88提供管理表示TSD 60的域模型对象的能力以及配置TSD 60的能力。

装置管理——装置管理服务94提供执行升级，配置和管理装置的能力。

交互需求

MSS服务50通过被域模型46暴露的Java接口来操纵域对象，以实现数据持久性和访问。这能够实现以下：

○提供域对象的基本创建、更新、删除和查询；

○允许通过发现MSS引擎56而识别的新的或更新的域对象的同步；

○允许域对象在平台42与MSS引擎56之间的同步；以及

○允许访问规则以控制数据聚合和数据分析。

域模型46中的域对象的委派方法可以通过企业服务总线(ESB)44使用SOAP来消费公共MSS服务50。这些委派方法可以用于执行以下活动：

○执行命令，诸如断电；

○检索历史度量值；

○检索按需度量值；以及

○执行按需发现操作。

公共和私有MSS服务50使用路由器组件82将请求路由到适当的MSS引擎56。

MSS服务50通过ESB 44使用SOAP来消费平台42的CPS平台服务。CPS平台服务可能由于以下原因被消费。

○确定执行由MSS服务50提供的功能的必要权利的消费授权服务；

○确定MSS服务可用什么功能的消费许可服务；

○发布事件的消费事件服务；以及

○用于基于事件注册通知的消费事件服务。

MSS服务50可以使用合适的通信组件来与MSS引擎56进行通信。

MSS服务50使用合适的通信组件与DCIM工具12上的MSS引擎56进行交互以实现以下功能。

○命令执行；

○发现；

○数据收集；

○固件升级；以及

○配置。

MSS UI 96通过HTTP与呈现服务器40(即，其控制器)进行交互，并且控制器使用SOAP或其他合适的协议(例如，经由ESB 44)与MSS服务50进行交互。

应用服务36(图5)通过来自MSS服务50的发布/订阅机制消费视频和实时数据流。从MSS引擎56检索视频和实时数据流。

DCIM工具

在图9中的一个实施方式中示出DCIM工具12。DCIM工具12提供MSS引擎56能力，并且因此提供DCIM解决方案10应用层与正在被管理的实际基础设施装置之间的网关。它还提供了允许它在独立环境中提供装置管理的行业标准接口的集合，诸如WebGUI、基于SSH/Telnet的CLI以及SMASH/CLP。外部接口有意限制为提供对于DCIM应用套件可用的整体功能的子集。还存在可以用于由DSView当前消费的访问目的并且最终可以用于基于DCIM的访问应用的Avocent特定协议。

DCIM工具的架构

DCIM工具12的详细架构可以(以高级别)被认为是被分成包括以下的三个主要区域的系统：1)工具框架12a；2)可管理性元件12b/访问应用12c；以及3)用户接口12d。

工具框架12a提供可以被DCIM解决方案10中的所有组件使用的一组通用服务，诸如数据库管理、认证等。该框架的另一关键部分是一组标准化通信接口，组件可以使用这些接口在DCIM解决方案10周围移动数据和消息。

“可管理性元件12b”可以由知道如何与各个受管装置和设备通话的组件组成。受管装置和设备的一些示例包括：

●KVM开关；

●串行接口工具；

●电力分配单元(PDU)；

●数字机架接口盒；

●服务处理器；

●冷却单元；

●数字和模拟传感器；以及

●第三方装置。

该区域还包括执行各种任务但不具有任何外部接口的应用组件。诸如CEP 56a和时间序列数据库56b的MSS引擎56组件以及从访问工具继承的一些扩展特征都是应用的示例。

用户接口12d可以包含诸如Onboard WebUI、命令行接口并且重要地用于与MSS引擎56进行通信的MSS可管理性协议的用户接口。由工具框架12a提供的通信接口使得用于UI组件的通用方法能够获得数据并将控制消息发送至各种应用和可管理性扩展。

上述架构使得DCIM工具12能够容易地部署在各种配置中，支持在每个配置中被支持的不同数量和类型的受管元件。基于可插拔组件的这种设计还允许在产品线进展时容易地添加新类别的受管装置。

DCIM解决方案10的云实现

参照图9A，示出了DCIM解决方案10的“云”实现的一个示例。在该示例中，云13可以被理解为任何广域网，但是在一种特定形式中，它可以包括万维网(或简称为“Web”)。为方便起见，云13将始终被称为“Web”13。

呈现UI 32的应用的DCIM软件套件可以位于第一位置处，顾客A和B可以各自位于其他远程位置处，并且CPS 42可以位于另一远程位置处。DCIM工具12还可以位于远程位置处，并且每个可以经由Web 13与CPS 42和呈现UI 32进行通信。顾客A和B可以各自经由Web13与呈现UI 32进行通信，并且呈现UI 32可以经由Web 13与CPS 42进行通信。最终，工具12可以各自经由Web 13与CPS 42进行通信。如将理解的，图9A中示出的云配置使得呈现UI 32和CPS 42中的每一个能够通过Web 13被提供为“服务”。这使得一个CPS 42能够用于与位于不同位置处的多个DCIM工具12进行通信。类似地，呈现UI 32可能会用作“服务”以与位于不同站点处的多个CPS 42进行通信。这在缩放DCIM解决方案10上提供了极大的灵活性，以满足快速扩展的数据中心的需求，并且尤其是在受管设备或装置位于物理上远程位置，可能处于不同州或甚至不同国家的情况下。将理解，图9A的图仅是用于将DCIM解决方案10部署在“云”环境中的一种可能配置，并且许多其他可能的配置对于本领域技术员而言将是明显的。

DCIM系统包含基础设施控制结构系统

现在参照图12至图19，将结合计算系统描述包括基础设施控制结构系统1010(在下文中称为“ICF 1010”)的DCIM系统1000的实现，计算系统在该示例中是由加利福尼亚州圣何塞的思科系统公司生产的统一计算系统(在下文中称为“UCS”)。DCIM系统1000可以另外被构造成类似于DCIM 10，并且可以具有上面针对DCIM 10描述的特征中的一些或所有特征。UCS将被描述为在数据中心环境内操作。将立即理解，虽然以下讨论将集中于思科系统公司生产的UCS，但ICF 1010的原理和特征同样对数据中心中经常使用的其他受管装置是可适用的和有效的。此外，本文中呈现的与ICF 1010相关的教导可以很容易地应用于其他制造商的特定系统或装置。例如，ICF 1010可以容易地适于与由马萨诸塞州Hopkinton的EMC公司(关于存储装置)、加利福尼亚州Palo Alto的VMware公司(关于虚拟化)以及其他服务器或数据中心组件供应商制造的组件或系统一起使用。所以，虽然示例是基于与思科组件一起使用的ICF 1010，但是将理解，这仅仅是ICF 1010的一个示例实现，并且预期ICF1010会找到与来自各种制造商的各种受管装置相关的实用程序。

简而言之，DCIM 1000包括提供架构设计和相关联的软件的基础设施控制结构1010，该软件允许许多数据中心装置诸如刀片服务器、机架服务器、存储管理设备、虚拟化中心等直接与各种数据中心基础设施管理工具进行通信。这使得装置中的每个装置能够被提供有装置的功耗、冷却可用性、温度和/或湿度、数据中心内的特定位置以及装置与数据中心生态系统的关系的实时知识。因此，ICF 1010不是简单地将其自身呈现为可用于给定数据中心装置进行访问的另一管理工具，而是在不破坏现有装置的用户接口或给定装置和给定装置与之通信的其他管理工具之间的交互的情况下与每个登记装置以并排方式工作。实际上，给定装置的实时信息和通信对于装置的用户接口和可能与该装置通信的其他组件实质上看来是透明的。

另一个优点是，被登记以与ICF 1010进行通信的每个装置的用户接口可能仅需要最小的修改以便覆盖装置的登记过程。然而，预期的是，在大多数情况下，每个登记的装置的用户接口将不需要用户控制装置的方式上的任何改变。通过与每个数据中心装置实时共享重要的实时功率信息、冷却信息和其他操作信息，可以显著增强每个装置的决策能力。在特定实例中，如果打开子组件可能违反先前确定的分配给特定设备机箱的功率和/或冷却容量规则，则特定数据中心装置从ICF 1010接收的实时信息可以使装置能够避免打开其子组件(例如，特定设备机箱中的另一个服务器)。在其他实例中，在不知道这样的动作可能违反预先确定的关于安装有该装置的给定机箱的功率和/或冷却容量分配规则的情况下，组件可以请求安装在给定机箱内的装置(例如，刀片服务器、机架服务器、存储管理装置、虚拟化中心等)通电。因为ICF 1010直接且无缝地与计算装置进行通信，所以计算装置能够向ICF 1010进行实时查询，以确定是否可以在不违反预先确定的功率和/或冷却分配规则的情况下对所请求的刀片服务器通电。然后，ICF 1010能够鉴于预先确定的功率和冷却容量分配规则进行该确定并且实时通知计算装置是否允许对刀片服务器通电。有利地，这些双向通信对于监视计算装置的操作的用户可以是透明的。

ICF 1010的关键创新特征是它使受管装置能够“伸出”到ICF 1010，以验证涉及功率、冷却和空间的操作(除了附加功能)。因此，通过在受管装置与ICF 1010之间提供直接路径(如图12中所示为SOAP请求和响应，或者可替选地通过REST请求和响应或甚至可能的其他通信方式)，ICF 1010的使用有效地缩小了受管装置与其他数据中心组件之间的差距。这使得受管装置能够在采取一些特定动作之前获得实时信息(例如，关于功率、冷却或空间限制/可用性)。

在图12、图17以及图18中，ICF 1010用于促进与加利福尼亚州圣何塞的思科系统公司生产的统一计算系统(UCS)1012(在下文中简称为“UCS 1012”)的直接通信。UCS 1012可以包括思科6100系列20端口结构互连1014，其包括嵌入其中的思科UCS管理器1016(在下文中简称为“UCSM 1016”)。至少一个但多达两个思科2104XP结构扩展器1018可以位于思科5100系列刀片服务器机箱1020中。刀片服务器机箱1020还可以在六机架单元(RU)外壳中支持多达八个思科UCS B系列刀片服务器1022(半宽和全宽可用)。

可以将UCS 1012添加到由DCIM系统1000应用(例如，库存、监视、配置、操作、设施操作和变更规划器)支持的设备的列表。这允许用户将UCS 1012硬件安装在具有可用空间、功率和冷却的机架或机箱中。为了电力和冷却资源的可用性，它还允许UCS 1012实时查询ICF 1010。重要的是，ICF 1010的实时监视能力还允许系统用户设置机箱1020的功率预算，并且ICF 1010能够在在正使用UCS 1012的数据中心中出现紧急情况的情况下实时通知UCS1012。

UCSM 1016是关于UCS 1012的所有组件的管理服务。它调解ICF 1010与UCS 1012的任何组件之间的所有通信。不需要直接访问UCS 1012组件(例如，机箱、刀片服务器等)。图17和图18更详细地示出了DCIM系统1000内的特定区域，其中，UCS 1012被集成到DCIM系统中，从而形成ICF 1010。在图17中，阴影框内的字母“U”指示DCIM系统1000内有助于形成ICF 1010的集成点的位置。图18，在框1026至1036处指示UCS 1012的特定元件，并且这样的元件可以在DCIM系统1000组件内位于何处。

在图13A和图13B中示出并且将在以下段落中描述用于详述ICF 1010与UCS 1012之间的交互的各种用例。在图16A至图16Q的表格中呈现关于图13中概述的用例中的每个用例的附加具体详情。在一个实现中，ICF 1010元件库可以被配置成包括UCS 1012，并且可以调用思科UCSM XML API(应用编程接口)以直接与UCSM 1016进行通信。UCSM 1016 API可以用于发现UCS 1012设备的拓扑(来自图13A的用例1和2)以收集统计数据，用于设置功率预算(来自图13A的用例7、8以及9)以及用于在在数据中心出现严重情况的情况下向UCS 1012发送通知(图13B中的用例17)。UCSM 1016可以发送SOAP(简单对象访问协议)请求，或者可以使用REST(表述性状态转移)，以与ICF 1010 Web服务进行通信以查询电力和冷却可用性(图13A/图13B的用例11、12、13以及14)。将理解，UCSM 1016实时直接查询ICF 1010的能力是ICF 1010的主要益处和优点。UCS 1012还可以将SNMP(简单网络管理协议)陷阱发送至ICF 1010的元件库，或者可以使用REST，以向元件库通知诸如阈值交叉警报(TCA)、电力状态变更等的事件(图13B的用例15)。

关于图13A的表格中列出的第一用例，ICF 1010可以根据图14的流程控制图1040中示出的动作发现UCS 1012。在在ICF 1010用户接口中配置UCS 1012 FQDN(完全合格域名)或IP地址、用户名和密码之后，ICF 1010可以发现UCS 1012。由于密码可以改变，ICF1010可以将其证书保存在UCS 1012中以避免对密码的依赖。ICF 1010可以在与UCS 1012的第一连接中使用用户名和密码，但是一旦将证书推送(即，保存)到UCS 1012，ICF 1010将在由UCS 1012发起的后续联系期间使用证书来认证UCS 1012。思科UCS XML API可以用于发现UCS拓扑(结构互连、机箱、刀片、扩展器等)。ICF 1010可以具有UCS 1012的产品知识和用于数据获取的感兴趣的数据点。为了使UCS 1012连接至与ICF 1010相关联的DCIM Web服务，ICF 1010可以将其自己的IP保存在UCS 1012中并且请求UCS提供其证书。一旦ICF 1010保存UCS证书，UCS 1012将能够通过证书与DCIM Web服务进行认证。

参照图15，流程控制图1042示出了当UCS发现ICF时可能在ICF 1010与UCS 1012之间发生的各种操作。发现的该替选方式涉及配置UCS 1012，其中UCS用户接口(UI)中的新选项卡指定关于ICF 1010的配置信息。可以使输入ICF 1010 FQDM或IP地址、用户名、密码以及超时配置的字段在UCS 1012用户接口中可用。UCS 1012使用用户名和密码连接至ICF1010，并且请求ICF证书。UCS 1012可以保存ICF 1010证书以使DCIM元件库通过所保存的证书连接至UCS。当DCIM Web服务不知道UCS 1012时，ICF 1010可以请求其元件库发现特定的UCS管理器及其组件。

由于ICF 1010密码可以改变，DCIM元件库还可以请求UCSM 1016提供其证书以使UCS 1012经由证书连接至DCIM Web服务。一旦提供了UCS 1012证书，UCS就可以使用该证书对DCIM Web服务进行自身认证，并且因此对ICF 1010进行认证。

DCIM Web服务

认证Web服务和UCS Web服务可用于UCS 1012以从ICF 1010请求信息。认证Web服务可以使用用户名和密码提供登录服务。这将允许UCS 1012在ICF 1010中为特定UCSM1016创建会话。该服务将仅在UCS 1012用户接口提供DCIM登录配置的情况下使用，并且仅应在第一次连接至ICF 1010时使用。一旦ICF 1010请求UCS 1012证书，UCS应当优选地使用下面描述为“通过证书登录”的过程。“通过证书登录”过程允许UCS 1012通过X509证书登录到ICF 1010。这允许UCS 1012在ICF 1010中为其UCSM 1016创建会话。证书可以在超文本传输安全协议(https)中使用并且/或者安全使用。

UCS Web服务可以是UCS 1012特定服务，即“保存凭证”、“获得DCIM证书”、“验证服务器”、“获得环境数据”以及“获得机箱可用的插槽功率容量”。

服务“保存凭证”允许将UCS 1012用户名和密码保存在ICF 1010中，以使ICF使用用户名和密码经由XML API连接至UCS。输入可以是会话ID；UCS用户名；UCS密码和UCS IP地址。输出可以是“结果状态”结果，其由ICF 1010发送至UCS 1012以指示操作是否成功。

“获得DCIM证书”是获得将由ICF 1010使用的DCIM公共证书的服务。返回的证书将保存在UCS 1012中，以使DCIM系统1000的ICF 1010通过证书与UCSM 1016进行认证。输入可以是会话ID。输出可以是X509证书证书和结果状态结果，其中结果状态结果由ICF 1010发送至UCS 1012以指示操作是否成功。

“验证服务器动作”web服务涉及ICF 1010基于关于所选服务器的数据中心规则(例如，管理电力和冷却可用性的用户预定义规则)来验证动作。ICF 1010向UCS 1012返回响应，通知UCS来自存储的服务器输入列表的哪些服务器可以执行所请求的动作(图13A中的用例11和12)。请求的动作可以是“通电”、“断电”或“维持通电”(其中，“维持通电”将仅是运行实用程序操作系统所需的电力，而不是用于服务器的完全通电)。如果可能，输入可以是会话ID、动作、“Ucs刀片服务器服务器”以及要被通电或断电的服务器的数量。“Ucs刀片服务器”输入包含关于“DN”(其中，DN表示分配给每个UCS 1012组件的唯一、区别于其他的名称)、优先级和刀片类型的信息。如果刀片类型未被定义，则可以假定该动作是针对刀片的最大铭牌容量。输出可以是“结果状态”结果和可以执行所请求的动作的UCS刀片服务器的列表。

“获得环境数据”服务可以获得UCS 1012的特定组件的环境数据(例如，涉及机箱所处的机架中的任何传感器、机箱的功率度量等)。输入可以是会话ID和UCS DN。输出可以是“结果状态”结果和环境数据。

服务“获得机箱可用的插槽功率容量”获得机箱1020(图12)的空插槽的功率容量。这有助于用户将其刀片服务器插入最佳位置。功率容量可以是指示多少功率容量可用于插入新的刀片服务器的指标。输入可以是会话ID、空UCS机箱插槽以及要插入的服务器的数量(可选的，默认为1)。输出可以是具有功率容量信息的空插槽的列表，其可以是用于对这些空插槽进行分类的索引。

UCSM XML API

ICF 1010可以使用UCSM XML API来从任何UCS 1012设备组件检索数据或将数据设置到任何UCS 1012设备组件。可以将请求发送至UCS 1012管理器，UCS 1012管理器从特定组件(例如，机箱、刀片等)获得数据或者向特定组件(例如，机箱、刀片等)发送数据。ICF1010可以调用的现有XML API是“aaa登录”、“aaa刷新”以及用于获得UCS 1012组件的API(图13A中的用例1和2)。还可以实现用于设置机箱的功率预算的API(图13A中的用例7、8以及9)。ICF 1010可能需要多个新的UCSM 1016 API。一个这样的UCSM 1016 API是“保存证书”，其保存DCIM系统1000公共证书，并且使ICF 1010通过证书与UCSM 1016进行认证。“保存证书”API可以生成X509证书证书和成功/失败消息作为输出。另一UCSM API是“获得UCS证书”，其获得UCS公共证书。ICF 1010可以保存返回的证书以使UCSM 1016使用证书与DCIMWeb服务进行认证。UCS 1012将保存DCIM IP以了解DCIM Web服务IP。输入可以是DCIM web服务的IP地址，而输出可以是X509证书和“成功/失败’消息。另一UCSM 1016 API可以是“通过证书登录”，其便于使用证书并获得认证cookie而登录到UCSM。输入可以是X509证书，而输出可以是“退出Cookie”和成功/失败消息。其他可能的API可以涉及用于添加、删除或变更涉及UCS 1012的操作的规则的API。

又一UCSM 1016 API可以是“事件接收”API，其中，对于出现的紧急情况，ICF 1010将事件发送至UCS 1012(图13B中的用例17)。例如，这样的情况可能涉及不间断电源电池电量低。这将允许UCS 1012采取一些动作，例如，重新关联服务配置文件。输入可以是数据中心中发生紧急事件的通知。例如，考虑检测到停电并且电源自动切换到UPS(不间断电源)模式的情况。由于DCIM系统1000的ICF 1010知道由该UPS供电的所有UCS机箱，因此ICF 1010可以通过该API发布警报以便通知UCSM 1016。然后，UCSM 1016可以鉴于接收的通知而决定需要什么动作。一个动作可能是将在受影响的刀片上运行的风险较高的应用迁移到另一UCS机箱。输出可以是“成功/失败”消息。

再一UCSM 1016 API是“保存DN的物理信息”。该API保存UCS 1012的特定组件的物理位置。物理位置可以是UCSM 1016显示的新属性。输入可以是“物理位置位置”以指示特定UCS 1012组件所处的机架。输出可以是“成功/失败”消息。

UCS通知DCIM

除了经由XML API从UCSM 1016接收通知之外，UCSM 1016还可以经由SNMP陷阱或可能经由REST向ICF 1010提供通知。XML API提供事件订阅，并且可以向订户通知UCSM1016管理信息树中的每个单个变更。因此，每一次由于用户或系统动作而变更对象时，都会生成事件。从UCSM 1016通过SNMP陷阱或REST的通知可以替选地操作以仅报告一些特定事件。例如，UCSM 1016允许配置许多类型的阈值交叉警报(TCA)，并且它们都可以通过SNMP陷阱被检索。还将理解，UCS 1012可以设置有过滤哪些通知被发送至ICF 1010的能力。

统计数据收集

UCS 1012还具有允许通过轮询收集统计数据(例如，电力供应电压、电流、功率、环境温度等)的能力。如果UCS 1012被修改成允许将统计数据“推送”到ICF 1010而不是被轮询，则收集的数据点可以基于UCS设计阶段中详述的UCS 1012能力。

图19示出了作为目前可用于UCS 1012的各种符号的示例的表格。将理解，该列表仅仅是示例性的，并且当出现需要时可以利用附加符号容易地扩展。

结合VMware组件使用DCIM系统1000

现在参照图20，示出了各种用例的图表，其中，DCIM系统1000可以结合加利福尼亚州帕洛阿尔托的VMware公司制造的设备使用。将理解，虽然图20的图表列出了四个具体用例，但关于由VMware公司以及其他制造商制造的其他特定类型的设备的各种其他用例可能会使用DCIM来实现。

图21A至图21C阐述了图20中的用例1的各种考虑因素和操作，DCIM系统1000可以在将新硬件供应到ESX集群中以及供应到正在使用DCIM系统1000的数据中心的物理基础设施中时考虑这些考虑因素和操作。

图22A和图22B详述了与图20的用例2相关联的考虑因素和各种操作。在这种情况下，当将新的VM供应到集群中时，DCIM系统1000与VMwareDRS(动态资源调度程序)进行交互。该特征使用DCIM系统1000来考虑各种重要因素，诸如实时功率、冷却数据、网络和存储器资源可用性，同时考虑功率预算和冗余策略、热点和动态冷却环境。

图23A和图23B详述了图20中的用例3的各种考虑因素和操作，在用例3中，DCIM系统1000用于帮助决定电力和冷却适当位置以迁移ESX服务器主机上的所有VM以用于维护目的。此外，DCIM系统1000可以使用从数据中心收集的连续和实时动态测量来报告实际功率和冷却使用情况，而不是依赖于关于正在被考虑的设备的静态铭牌额定值上列出的峰值功率容量。

图24A和图24B详述了图20中的用例4的各种考虑因素和操作，在用例4中，DCIM系统1000用于基于数据中心中的改变的物理条件或数据中心策略的改变来重新平衡VM。该决定将影响VMware系统中的迁移建议。在该示例中，DCIM系统1000与DRS进行交互以在考虑数据中心环境的功率预算和功率冗余策略、热点以及动态冷却和湿度考虑因素的情况下提供实时功率和冷却数据可用性。可以增强DRS动态重新平衡算法以基于实时功率、冷却和湿度数据来并入DCIM VM迁移建议。

然后将理解，与ICF 1010相关联的双向通信、架构设计和软件允许ICF向受管装置(例如，UCS 1012、VMware装置或其他形式的受管装置)提供关于实时资源可用性(例如，设备机架中的物理空间、机架目前可用的电力、提供给机架的冷却等)以及实时网络和存储可用性或限制的知识。ICF 1010还可以向登记成与ICF 1010进行通信的装置提供涉及数据中心布局和策略的实时信息(例如，功率预算、功率冗余、热点、动态冷却环境、重量限制等)。基于ICF 1010提供的实时信息，数据中心的每个登记的受管装置能够在本地做出谨慎的决定并向其各自的用户和管理应用提供更好的信息，以用于管理/配置/使用每个登记的装置。

ICF 1010软件能够利用从数据中心收集的实时动态测量(数据点)而不是依赖于每个受监视的组件的静态铭牌额定值上提供的峰值容量来报告实际功率和冷却使用情况。可以由ICF 1010动态报告的生态系统参数的具体示例可以包括：

出现基础设施(电力或冷却)警报或单元故障的情况，基础设施(电力或冷却)警报或单元故障由于冗余可能不会影响操作，但由于备份组件的可用性降低而给用户带来额外风险；

出现由于超出关于给定装置的特定要求的容差而导致温度和湿度风险的情况；

当前负载已经下降到可以空出整个区(电力或冷却)并且其中的设备移动到“待机”状态的点的情况；

发生功率比变更的情况，例如当功率比在一天的某个时间变更时；

经历功率限制或当已经使用替选(例如，备用)电源时的情况；

非时间敏感的工作负荷(批处理)可以由于更具成本效益的功率比在一天的特定时间期间变得可用而运行的情况；以及

现在可以将负载移动到不同的位置以更经济地利用电力或冷却可用性的情况。

总之，ICF 1010允许数据中心在没有过载的风险的情况下以更接近全容量操作，这可能会导致更有利的资本投资回报并且/或者可能延迟在新设备上的支出。重要的是，ICF 1010在被每个登记的组件联系时实时执行“假设”类型分析，并且能够告知组件采取所请求的动作是否将负面影响基础设施资源的总体消耗或可能负面影响数据中心内的一些其他装置或子系统的操作。

ICF 1010与DCIM系统1000一起工作的一个特别重要的优点是它可以显著提高数据中心内组件的容量利用率。这可以导致用于使数据中心内的组件冷却的冷却设备的功耗降低。ICF 1010执行的实时能力和“假设”场景分析还可能会通过在受管装置采取人工操作请求的动作之前向受管装置提供信息来减少数据中心内设备的将另外由人为错误引起的停机时间。此外，预期ICF 1010在涉及CRAC(机房空调)的控制的应用中具有显著的实用性。ICF 1010可以用于实时控制与CRAC相关联的风扇的开/关操作，以使整体冷却能力更接近地与数据中心中的实时冷却要求一致，从而减少过度的冷却能力。

在基础设施装置中实现的ICF

参照图25，示出了根据本公开内容的另一实施方式的DCIM系统2000。DCIM系统2000利用上面呈现的DCIM系统1000和ICF 1010的教导，并且相同地或利用修改扩展这些教导，以与在现代数据中心中经常使用的各种独立的基础设施装置一起使用。因此，上面针对DCIM系统1000描述的与实现/控制与数据中心内的独立计算装置的通信有关的各种特征可以扩展到并完全应用于实现/控制与通过在数据中心中提供或管理电力、冷却或其他数据中心基础设施操作支持独立计算装置的独立基础设施装置的通信。然后，将理解，本文中描述的说明如何将DCIM系统1000的各种元件集成到DCIM系统的特定位置或子系统中的图17和图18同样适用于实现DCIM系统2000。

在图25中，DCIM系统2000可以包括DCIM子系统2000a，其与具有ICF子系统2004的至少一个服务器2002进行通信。DCIM子系统2000a和ICF 2004可以各自与数据中心环境内存在的各种基础设施装置进行通信。因此，DCIM子系统2000a和ICF 2004能够与图25中示出的基础设施装置中的每一个基础设施装置双向且独立地通信。

DCIM子系统2000a和ICF子系统2004两者都可以通过点对点通信链路或通过网络(例如，LAN)与各种基础设施装置进行通信。因此，本公开内容设想两种实现。ICF子系统2004可以包括一个或更多个应用2006a，用于控制数据中心中的各种基础设施装置。可以包括分析子系统2006b，用于对从基础设施装置接收的数据和/或事件进行分析。ICF 2004还可以包括一个或更多个Web服务2008，其可以涉及基于Web的服务，包括但不限于数据聚合和丰富、发现和连接、安全性、数据规范化和去规范化等。ICF子系统2004还可以并入元件框架2010，其包括多个元件库2012至2024，用于处理与数据中心环境内存在的各种类型的基础设施装置的通信。在图25中，数据中心环境内存在的基础设施装置被示为CRAC(机房空调)单元2026、功率计2028、UPS(不间断电源)2030、PDU(电力分配单元)2032、发生器2034、转换开关2036和建筑管理系统(BMS)2038。这些只是可以存在于现代数据中心中的各种类型的基础设施装置的一些示例，并且DCIM系统2000不限于仅与这些类型的基础设施装置一起使用。

基础设施装置2026至2038中的每一个可以分别并入通信子系统(下文中简称为“通信卡”)2026a至2038a，其可以包括实现与ICF 2004的通信的元件库，并且其实现暴露所收集的数据并向ICF 2004发送事件，以及能够使从DCIM系统2000接收的命令或控制功能由与基础设施装置2026至2038中的每一个相关联的管理器/控制器组件(下文中简称为“管理器”组件)2026b至2038b执行。管理器组件2026b至2038b还可以处理基础设施装置的控制操作并执行经由基础设施装置2026至2038的通信卡2026a至2038a从应用接收的任何命令或控制功能。管理器组件2026b至2038b可以位于独立电路板上。可替选地，通信卡2026a至2038a和管理器组件2026b至2038b的功能可以被集成至其相关联的基础设施装置2026至2038内的单个电路板上。

元件库2012至2024中的每一个构造有实现与特定基础设施装置2026至2038的通信所需的信息。因此，例如，元件库2012被构造成能够实现CRAC单元2026的通信和/或控制，元件库2014被构造成能够实现与功率计2028的通信，等等。ICF子系统2004可以被配置成在将IP地址范围放入到ICF 2004的用户接口(未明确示出)之后自动发现独立基础设施装置2026至2038中的任何一个的管理器组件2026b至2038b。可替选地，发现可以通过将以下中的一个或更多个输入到ICF 2004用户接口中来完成：独立基础设施装置的完全合格域名(FQDN)；独立基础设施装置的互联网地址；用户名；或用户密码。在某些实施方式中，ICF子系统2004可以使用可扩展标记语言(XML)应用编程接口(API)或JSON(JavaScript对象表示法)数据交换格式来调用独立基础设施装置并发现独立基础设施装置的拓扑。

DCIM系统2000使得许多数据中心基础设施装置能够经由DCIM子系统2000a或ICF2004直接与各种数据中心基础设施管理工具进行通信。这使得装置中的每一个能够报告(即，暴露)与基础设施装置的操作有关的许多实时信息和/或数据(例如，可能地功耗、冷却性能、温度和/或湿度中的一个或更多个)以及每个装置与数据中心生态系统的关系。该配置还使得ICF 2004能够监视基础设施装置2026至2038中的每一个的操作并且双重检查执行来自DCIM子系统2000a的以及在特定基础设施装置处接收的命令是否将违反任何数据中心策略(例如，关于功耗、冷却等)。DCIM系统2000使每个基础设施装置2026至2038也能够将事件发送至ICF子系统2004。这使得相关应用(例如，可能地应用2006之一)能够在命令基础设施装置之一采取特定动作之前确定某些动作是否是可允许的。例如，故障中的CRAC单元2036可以向服务器2002传送指示它仅能够以减小的容量操作的信息。然后，ICF 2004的相关应用(例如，应用2006之一)可以确定将由正由故障中的CRAC单元2036支持的所选IT装置执行的操作移动到数据中心的不同部分中的其他IT装置。以这种方式，DCIM子系统2000a和ICF 2004实际上可以以对用户透明的并排方式工作，以确保没有基础设施装置2026至2038采取违反数据中心策略的动作，或者确保在允许命令的任务继续之前采取适当的纠正动作(例如，将计算任务从一个服务器移动到另一个服务器)。因此，ICF2004相当充当备用系统，其与DCIM子系统2004协同工作，并且对用户透明，以在数据中心环境内提供其他级别的监视和基础设施管理。

参照图26，在并入具有元件库2040a的网关/聚合器子系统2040的另一实施方式中可以看到DCIM系统2000。网关/聚合器子系统2040可以用于对在基础设施装置与ICF服务器2002之间交换的数据执行数据聚合和/或协议转换。元件库2040a可以包含关于用于基础设施装置2028中的每一个的通信协议的信息。除了规则、阈值和/或算法之外，ICF子系统2004内的分析子系统2006b可以包含软件和硬件(例如，处理器和存储器)两者，以分析和评估从基础设施装置2026至2038中的每一个接收的数据和/或事件。网关/聚合器子系统2040的一个重要优点是提供水平伸缩以更好地处理大量的基础设施装置以及IT装置两者。网关/聚合器子系统2040可能在通过应用存储的规则来执行数据聚合方面是有利的，这可以减少要求通过维护网络传输的数据量。网关/聚合器子系统2040可以包括其自己的处理器和存储器，用于实现数据聚合规则、阈值等。

已经出于说明和描述的目的提供了实施方式的前述描述。其并非旨在穷举或限制本公开内容。特定实施方式的各个元件或特征通常不限于该特定实施方式，而是在适用的情况下，即使没有具体示出或描述，也是可互换的并且可以在所选实施方式中使用。同样也可以以多种方式变化。不应将这样的变化视为脱离本公开内容，并且所有这样的修改旨在包括在本公开内容的范围内。

提供示例实施方式使得本公开内容是透彻的，并且将范围完全传达给本领域技术员。阐述了许多具体细节，诸如特定组件、装置和方法的示例，以提供对本公开内容的实施方式的透彻理解。对于本领域技术员将明显的是，不需要采用具体细节，示例实施方式可以以许多不同的形式实施，并且两者都不应被解释为限制本公开内容的范围。在一些示例实施方式中，没有详细描述公知的过程、公知的装置结构和公知的技术。

本文中使用的术语仅用于描述特定示例实施方式的目的，而不旨在限制。如本文中所使用的，单数形式“一”、“一个”和“该”也可以旨在包括复数形式，除非上下文另有明确指示。术语“包括(comprises)”、“包括(comprising)”、“包含”和“具有”是包含性的，并且因此指定所陈述的特征、整数、步骤、操作、元件和/或组件的存在，但不排除一个或更多个其他特征、整数、步骤、操作、元件、组件和/或其组的存在或添加。本文中描述的方法步骤、过程和操作不应被解释为必须要求它们以所讨论或示出的特定顺序执行，除非特别标识为执行顺序。还应理解，可以采用附加或替选步骤。

当元件或层被称为“在另一元件或层上”、“接合至”、“连接至”或“耦合至”另一元件或层时，它可以直接在另一元件或层上，直接接合、连接或耦合至另一元件或层，或者可以存在中间元件或层。相比之下，当元件被称为“直接在另一元件或层上”、“直接接合至”、“直接连接至”或“直接耦合至”另一元件或层时，可能不存在中间元件或层。用于描述元件之间的关系的其他词语应以类似的方式解释(例如，“在…之间”与“直接在…之间”、“与…相邻”与“直接与…相邻”等)。如本文中所使用的，术语“和/或”包括相关联的所列项目中的一个或更多个的任何和所有组合。

尽管本文中可以使用术语第一、第二、第三等来描述各种元件、组件、区域、层和/或部分，但是这些元件、组件、区域、层和/或部分不应受这些术语的限制。这些术语可以仅用于将一个元件、组件、区域、层或部分与另一个区域、层或部分区分开。本文中使用的诸如“第一”、“第二”和其他数字术语的术语不暗示序列或顺序，除非上下文明确指示。因此，在不脱离示例实施方式的教导的情况下，下面讨论的第一元件、组件、区域、层或部分可以被称为第二元件、组件、区域、层或部分。

为了便于描述，本文中可以使用诸如“在…内部”、“在…外部”、“在…之下”、“在…下方”、“在…下部”、“在…上方”、“在…上部”等的空间相对术语来描述一个元件或特征与另一元件或特征的关系，如附图中所示。除了附图中描绘的取向之外，空间相对术语可以旨在涵盖使用或操作中的装置的不同取向。例如，如果附图中的装置被翻转，则被描述为在其他元件或特征“下方”或“之下”的元件将被取向为在其他元件或特征“上方”。因此，示例术语“下方”可以涵盖上方和下方取向两者。装置可以以其他方式取向(旋转90度或以其他取向)，并且相应地解释本文中使用的空间相对描述符。

Claims

1.一种具有基础设施控制结构(ICF)子系统的数据中心基础设施管理(DCIM)系统，所述ICF子系统用于使独立的基础设施装置能够独立地与DCIM进行通信，所述DCIM系统包括：

DCIM子系统，其用于与独立的基础设施装置进行通信并且控制所述独立的基础设施装置；

基础设施控制结构子系统(ICF)，其形成所述DCIM系统的一部分，并且与所述独立的基础设施装置进行通信并控制所述独立的基础设施装置；

管理器组件，其存在于所述独立的基础设施装置上，用于与所述DCIM子系统和所述ICF子系统两者进行通信，并且协助执行命令和控制所述独立的基础设施装置的操作；

通信子系统，其存在于所述独立的基础设施装置内；以及

元件库，其形成所述ICF子系统的一部分，用于包含实现所述独立的基础设施装置和与所述ICF子系统相关联的至少一个应用之间的直接通信的信息，

其中，所述ICF子系统包括位于可管理性子系统引擎中、域模型中、服务服务器上和所述独立的基础设施装置的通信子系统中至少之一的组件，以使所述独立的基础设施装置能够向所述DCIM系统发送事件和报告数据中至少之一，并且使所述至少一个应用能够在开始对所述独立的基础设施装置的操作或者继续对所述独立的基础设施装置的操作中至少之一之前与所述独立的基础设施装置进行通信。

2.根据权利要求1所述的DCIM系统，其中，所述元件库与以下之一相关联：

不间断电源；

功率计；

机房空调(CRAC)单元；

电力分配单元(PDU)；

发生器；

转换开关；或

建筑管理系统。

3.根据权利要求1所述的DCIM系统，其中，所述ICF子系统包括Web服务。

4.根据权利要求1所述的DCIM系统，其中，所述ICF子系统在与所述DCIM系统操作上相关联的服务器上实现。

5.根据权利要求1所述的DCIM系统，其中，所述ICF子系统被配置成自动发现所述独立的基础设施装置的通信子系统。

6.根据权利要求1所述的DCIM系统，其中，所述ICF子系统被配置成在接收到以下中至少之一之后发现所述通信子系统：

独立的计算装置的完全合格域名(FQDN)；

所述独立的计算装置的互联网地址；

用户名；或

用户密码。

7.根据权利要求1所述的DCIM系统，其中，所述独立的基础设施装置的通信子系统包括以下中至少之一：

可扩展标记语言(XML)应用编程接口(API)；或

JSON(JavaScript对象表示法)数据交换格式；

所述ICF子系统使用所述XMLAPI和所述JSON数据交换格式来调用所述独立的基础设施装置并发现所述独立的基础设施装置的拓扑。

8.根据权利要求1所述的DCIM系统，其中，所述独立的基础设施装置的通信子系统发送简单对象访问协议(SOAP)请求来与所述ICF子系统进行通信。

9.根据权利要求1所述的DCIM系统，其中，所述独立的基础设施装置的通信子系统使用表述性状态转移(REST)来与所述ICF子系统进行通信。

10.根据权利要求1所述的DCIM系统，其中，ICF子系统被配置成从所述独立的基础设施装置接收简单网络管理协议(SNMP)陷阱，所述SNMP陷阱向所述ICF子系统通知与所述独立的基础设施装置的操作有关的操作事件。

11.根据权利要求1所述的DCIM系统，其中，所述ICF子系统被配置成进行以下中至少之一：

为所述独立的基础设施装置设置功率预算并且将所述功率预算传送至所述独立的基础设施装置；

使用从所述独立的基础设施装置的通信子系统提供的数据或事件中至少之一来监视所述独立的基础设施装置在其中操作的数据中心中的环境或操作情况；以及

接收和监视来自所述独立的基础设施装置的数据，所述数据涉及所述独立的基础设施装置的操作，所述数据由所述独立的基础设施装置报告。

12.根据权利要求1所述的DCIM系统，还包括网关/聚合器子系统，所述网关/聚合器子系统用于在由所述独立的基础设施装置报告的数据被发送至所述ICF子系统之前聚合所述数据。

13.一种用于使数据中心基础设施管理(DCIM)系统能够与独立的基础设施装置直接且实时地通信的方法，所述方法包括：

提供用于与所述独立的基础设施装置进行通信并且控制所述独立的基础设施装置的DCIM子系统；

为所述独立的基础设施装置提供通信子系统和管理器组件，所述通信子系统协助实现与所述独立的基础设施装置的通信和报告由所述独立的基础设施装置生成的数据或事件中至少之一，所述管理器组件管理所述独立的基础设施装置的操作；

使用所述DCIM系统的基础设施控制结构(ICF)子系统来独立于所述DCIM子系统直接与所述独立的基础设施装置的管理器组件进行通信；

将元件库定位在ICF子系统中，其中，所述元件库具有关于所述独立的基础设施装置的信息，使所述ICF子系统能够进行以下中至少之一：与所述独立的基础设施装置进行通信或控制所述独立的基础设施装置；以及

使用所述元件库来协助使所述独立的基础设施装置能够与所述ICF子系统进行通信以及使所述独立的基础设施装置能够进行以下中至少之一：向所述ICF子系统发送数据或向所述ICF子系统发送事件，同时实现从与所述ICF子系统相关联的应用接收命令并将所接收的命令传递给所述管理器组件以实现所述ICF子系统对所述独立的基础设施装置的控制。

14.根据权利要求13所述的方法，还包括：

使用所述DCIM系统的可管理性子系统引擎来监视从所述独立的基础设施装置发送的数据，使用所述DCIM系统的包括扩展的域模型，其中，所述扩展包括涉及所述独立的基础设施装置的信息；

使用所述DCIM系统的可管理性子系统来从所述独立的基础设施装置接收信息；

使用所述DCIM系统的服务服务器来提供共享的服务基础设施层；以及

将所述ICF子系统的组件定位在所述可管理性子系统引擎中、所述域模型中、所述服务服务器上和独立的计算装置的通信子系统中的每一个中。

15.根据权利要求14所述的方法，其中，定位所述ICF子系统的组件的操作包括将具有关于所述独立的基础设施装置的信息的元件库定位在所述可管理性子系统引擎中。