将硬件清单部署为云计算戳记

摘要

提供了用于自动地配置硬件清单以无缝地与数据中心的计算结构进行交互的方法、系统和计算机可读介质。初始地，建立在用户设备和硬件清单的计算单元之间的通信耦合。该通信耦合允许正在用户设备上运行的引擎向这些计算单元提供允许硬件清单用作数据中心的结构计算群集(FCC)的软件。提供涉及将计算结构部署到这些计算单元，以及部署将在计算结构上运行的核心基础结构服务。该计算结构允许这些计算单元作为统一的逻辑系统来进行交互，而核心基础结构服务表示提供对正在FCC上运行的应用的底层支持的操作系统级组件。在实现该提供之际，确认在硬件清单的计算单元内部的组件。

说明书

背景

一般而言，分布式服务应用被主存(host)在云计算网络中(跨多个节点)，且主要是为了通过服务－应用组件的冗余性、动态可缩放性以及自动复原功能来促进高可用性。这些服务应用通常被划分成多个部分，这多个部分包括一组服务－应用组件。这些服务－应用组件可贯穿一个或多个数据中心的节点(例如，物理机和虚拟机)来主存。通常，存在以下需要：创建或扩展这些数据中心的计算/存储能力以容适服务应用的使用需要并帮助确保整个服务应用不会由于缺乏来自底层硬件的支持而变得不可用。

数据中心的扩展可涉及各种场景，诸如配置新的一组硬件或重新配置现有的一组硬件来与数据中心内现有的节点协同操作。在一个示例中，新的一组机架(每个机架都容适多个刀片)可被定为用于集成到与数据中心节点互连的结构(fabric)中的目标。该结构帮助确保跨现有节点分布的服务－应用组件和新添加的硬件(诸如机架、网络设备(L2/3交换机、路由器、负载平衡器)、功率和串行设备以及刀片)能够交互，就好像每个服务应用在其自己独立的计算设备上运行那样。

当进行数据中心的扩展时，将该新的一组硬件集成到该结构中的步骤当前是手动进行的。这些手动进行的步骤通常是耗时、低效的且在结果方面是不一致的，由此，可能导致服务在该结构中中断。因此，扩建一组指定的硬件以供部署到结构中的自动化的端对端过程将有助于实现高效的、稳健的且可缩放的框架以供扩展数据中心的计算/存储能力。

概述

提供本概述是为了以简化的形式介绍将在以下具体实施方式中进一步描述的概念。本概述并不旨在标识出所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。

本发明的各实施例涉及用于实现自动化的引导过程的系统、方法和计算机存储介质，该引导过程在验证未被配置的硬件的清单的物理拓扑结构之际将硬件清单集成并部署为数据中心的云计算结构内的结构-计算群集(FCC)。实现引导过程的自动化方式避免从用于重新配置数据中心或向数据中心增加能力的手动执行的规程所引起的有问题的后果(以上讨论的)。因此，在本发明的各实施例中，自动化的引导过程使得能够以一致且高效的方式将硬件清单合并到云计算结构中。

一般而言，在接收到要创建或扩展数据中心的计算/存储能力的指示之际触发引导过程。在各实施例中，数据中心包括多个节点(例如，物理机或虚拟机)、网络设备、串行设备、功率设备以及可经由云计算结构可操作地互连和管理的其他装备。结构提供对遍及数据中心内分布的服务应用的底层支持。尤其，可通过结构的控制器来管理在节点中遍及分布的这些服务应用的各部分(例如，角色实例或程序组件)。结构控制器一般负责围绕以下的各种职责：监视、维护和管理计算机资源、网络设备、串行设备和支持结构的底层功能性的功率单元的健康。

在一示例性实施例中，引导过程在被事件(例如，对于扩展数据中心的能力的调用)触发之际在独立的阶段中执行。这些阶段分别通过执行自包含工作流来实现并一般地在图2中描绘。初始地，可进行共同创作阶段来指定硬件清单的初始设置。这个阶段涉及用于实现以下过程中的一个或多个的工作流：接收指定在顾客的场所上要求的附加能力的顾客的依赖性方案；标识满足该依赖性方案的硬件；与顾客对接以收集用于配置所标识的硬件的值；从值中生成符号表示；在递送硬件之际使用该符号表示来确认配置；以及准备记录拓扑结构的布局的模板文件。

在准备模板文件之际，可开始涉及发现和确认网络设备与硬件设备的阶段。用于为这些设备中的每一者执行发现和确认的工作流一般涉及经由基于网络的连接和/或基于串行的连接与网络设备通信以发现硬件设备周围的物理拓扑结构(例如，机架间位置和接线排列)的用户设备。这些用户设备可对照模板文件来交叉参考所发现的物理拓扑结构以确认硬件设备。一旦物理/逻辑拓扑结构配置被完整地生成，就可开始对新的结构实例的部署或对现有结构实例的扩展。应当注意，对新的结构实例的部署或对现有结构实例的扩展可涉及给定数据中心或数据中心容器中的一部分硬件或在其之上。

接着，用户设备可发起与数据中心的云计算结构的通信以实现将数据中心的结构内的硬件清单部署为结构-计算群集(FCC)并在FCC上提供安全性的阶段。这些阶段涉及支持设置硬件群集来与数据中心内的资源和现有硬件进行交互的各个工作流。此外，这些工作流可包括以下步骤：在验证硬件清单的物理拓扑结构之际从收集的信息中准备基础结构状态；通过将基础结构状态与结构控制器共享来将硬件清单集成到数据中心的结构中；在硬件清单内部署在该结构上运行的服务；以及将硬件清单指定为数据中心FCC。因此，当接连实现时，引导过程的这些阶段推动用于扩建硬件清单和用于将硬件清单集成到数据中心的结构内的端对端自动化。该端到端自动化可进一步在数据中心内预先建立的硬件清单内(例如，将现有的FCC重新配置为表示数据中心内的新FCC实例)或在数据中心外部的站点处(例如，将远程硬件清单集成为数据中心内的新FCC实例)实现高效、稳健和可缩放的框架。

附图简要说明

以下参考附图详细描述本发明的实施例，附图中：

图1是适用于在实现本发明的各实施例中使用的示例性计算环境的框图；

图2是示出根据本发明的一实施例的用于将硬件清单合并到数据中心的结构-计算群集(FCC)中的引导过程的示例性阶段的流程图；

图3是示出用于将硬件清单集成在数据中心内的示例性部署生态系统的图示，该部署生态系统适合在实现本发明的各实施例时使用；

图4是示出根据本发明的一实施例的被部署在硬件清单上的各组件之间的关系的示例性示意图；

图5-7是示出根据本发明的各实施例的、用于部署硬件清单内的各个组件的示例性系统的图示；

图8是示出根据本发明的各实施例的、用于保护硬件清单并将硬件清单转换成与数据中心交互的FCC的各个组件的操作图；

图9是显示根据本发明的一实施例的用于将硬件清单转换成FCC的总体方法的流程图；以及

图10是示出根据本发明的一实施例的用于发现和确认在硬件清单的服务器内部的一个或多个组件的总体方法的流程图。

详细描述

本文中用细节来描述本发明各实施例的主题以满足法定要求。然而，该描述本身并非旨在限制本专利的范围。相反，发明人已设想所要求保护的主题还可结合其它当前或未来技术以其它方式来实施，以包括不同的步骤或类似于本文中所描述的步骤的步骤组合。

本发明的各方面聚焦于总体引导过程内的两个相关阶段，其中引导过程被设计成达成高效、稳健且可缩放的框架以将云操作系统(Windows Azure)纳入到专用硬件上而不管位置如何。这些相关阶段为以下：将硬件清单部署成数据中心的云计算结构内的结构-计算群集(FCC)；并在FCC上提供安全性。引导过程的这两个阶段通常在发现和确认阶段之后进行，其涉及发现、确认和配置网络设备和计算机硬件来作为硬件清单和设备返回制造授权(RMA)场景的初始扩建的一部分。在一个特定实例中，与用于这些元件中的每一者的发现、确认和配置相关联的工作流部分地依赖于先前从引导过程的先前进行的共同创作阶段中收集的信息(例如预期拓扑结构描述)。共同创作阶段、发现-确认-配置阶段以及本文中讨论的这两个阶段的工作流可以由同一个生态系统来实现。该生态系统一般涉及与硬件清单通信(例如，串行和/或网络连接)以便执行将硬件清单部署成FCC以及在部署之前、期间或之后在FCC上提供安全性的用户设备(例如，移动设备、膝上型计算机或公共设施箱)。

如下文更全面地讨论的，本发明的各实施例在云计算结构内引入用于自动部署硬件清单上的软件以便最终将该硬件清单合并成数据中心内的FCC的技术。如本文中所使用的，短语“硬件清单”不旨在限制到任何特定的组件配置，而是泛指可最终被集成到结构中的任何设备汇编(例如，网络设备、计算设备、以及电源设备)。在一个实例中，硬件清单可位于由云计算网络服务提供商的顾客管理的私有企业网络中，其中将引导过程实现为这种类型的硬件清单上的装置允许数据中心和私有企业网络之间的远程可到达性。在另一实例中，硬件清单可位于由云计算网络服务提供商管理的数据中心内，其中实现引导过程允许扩建数据中心的本地存储/计算能力。

在一示例性实施例中，硬件清单表示包括任何数目的以下各项的系统：网络设备(例如交换机、路由器和负载平衡器)、功率设备、串行设备、刀片(例如计算和/或存储设备)、以及刀片内的各组件(例如BIOS、驱动程序、固件)。相应地，各个系统可以被分类为硬件清单，并且短语硬件清单不限于本文所描述的示例性系统。

此外，硬件清单可以被装备成经由一个或多个信道与外部设备(例如，被配置成运行和管理硬件清单的引导过程的膝上型计算机)和/或内部设备(例如，用于执行计算和存储操作的刀片)通信。这些信道可包括管理信道(“串行通信信道”)和一个或多个基于网络的信道(“网络通信信道”)。串行通信信道表示提供硬件清单(例如机架上的刀片)与一组串行设备(例如连接器设备)之间的挂钩的带外连接。通常，对硬件清单在串行通信信道上的串行管理(例如，访问和验证机架上的刀片)在设置关于机架上的每一刀片的网络能力之前进行。网络通信信道表示用于提供硬件清单的外部和/或内部设备与各个网络位置之间的网络链路的带内连接。例如，网络通信信道可包括使用带内信令来交换呼叫-控制信息的网络管理以太网线缆。这两个信道可以取决于硬件配置使用同一介质(例如以太网)来实现。

如将在以下更完整描述的，引导过程使用一个或多个工作流引擎(在图3和8的用户设备310上运行)来特征化端对端自动化，该一个或多个工作流引擎驱动对包括引导过程的各个阶段的编排和执行。在各实施例中，这些阶段可被实现为独立的工作流，使得每个阶段可被分开地调用和驱动来完成，而无需依赖另一阶段或工作流的并发操作。通过允许各阶段以自包含形式来独立地实现，每个阶段一致地将递增的改进递送到硬件清单，而没有对先前或后续工作流的任何不利交互。

如在以下的讨论中显而易见的，以下的讨论中的大多数将聚焦于围绕引导过程的硬件清单部署和安全性提供阶段的工作流，其中这些工作流支持在云计算平台内设置硬件清单。在操作时，这些工作流被设计成实现这两个阶段的各种目标，诸如在硬件清单上部署核心基础结构服务(例如，结构和存储)以使得它表现为如同数据中心的云计算结构内的FCC。这些工作流的一个目标是在硬件清单上提供安全性。这些工作流的另一目标是用关于硬件清单的信息来配置数据中心内的结构。这些工作流的又一目标是在部署之际进行对硬件清单的群集范围的确认。一般来说，一旦核心基础结构服务被提供在硬件清单上并且硬件清单被部署在数据中心的结构中后，群集范围的确认就会发生。群集范围的确认被用来验证这些服务是实况的、可访问的和完全可操作的。

这些工作流的再一目标是用生产设置(例如凭证和协议数据)来配置硬件清单的设备。在用生产设置来配置该设备之际，这些生产设置被确认。此外，硬件清单的网络配置被建立，这允许访问服务器或经由一个或多个交换机与服务器的网络连接性。不恰当的网络配置(被工作流检测和修复)通常阻止与服务器的预期交互，即便在服务器周围的接线是正确的(例如，数据分组将不会正确地遍历从交换机到服务器的网络连接)情况下。

这两个阶段的又一目标在于验证服务器及其组件的配置和功能与预定义的模板文件相匹配。模板文件可以部分地使用在引导过程的共同创作阶段或硬件SKU认证阶段期间开发/生成的SKU定义来准备。SKU定义在2012年6月22日提交的现在为待审的题为“Establishing an Initial Configuration of aHardware Inventory(建立硬件清单的初始配置)”的美国申请号13/531,136(代理卷宗号335263/MFCP.165833)中更详细地讨论。该模板文件可用于通过进行用于验证设备之间的物理连接的连线检查来验证硬件清单内部的接线(例如，服务器、串行接入设备和PDU之间的连接)以及可能地硬件清单外部的接线(例如，串行聚集器之间的连接)与预期的一样。在引导过程的发现和确认阶段期间进行的对硬件清单的物理拓扑结构的确认在2012年10月8日提交的现在为待审的题为“Discovering,Validating,and Configuring Hardware-inventoryComponents(发现、确认和配置硬件清单组件)”的美国申请号13/647,116(代理卷宗号335264.01/MFCP.165834)中更详细地讨论。

在简要描述了本发明的各实施例的概览后，以下描述适于实现本发明的各实施例的示例性操作环境。

操作环境

首先具体参考图1，示出了用于实现本发明的各实施方式的示例性操作环境，并将其概括地指定为计算设备100。计算设备100只是合适的计算环境的一个示例，并且不旨在对本发明的使用范围或功能提出任何限制。也不应该将计算设备100解释为对所示出的任一组件或其组合有任何依赖性或要求。

本发明可以在由计算机或诸如个人数据助理或其他手持式设备之类的其他机器执行的计算机代码或机器可使用指令(包括诸如程序模块之类的计算机可执行指令)的一般上下文中描述。一般而言，包括例程、程序、对象、组件、数据结构等等的程序模块是指执行特定任务或实现特定抽象数据类型的代码。本发明可以在各种系统配置中实施，这些系统配置包括手持式设备、消费电子产品、通用计算机、专用计算设备等等。本发明也可以在其中任务由通过通信网络链接的远程处理设备执行的分布式计算环境中实施。

参考图1，计算设备100包括直接地或间接地耦合以下设备的总线110：存储器112、一个或多个处理器114、一个或多个呈现组件116、输入/输出(I/O)端口118、输入/输出组件120、以及说明性电源122。总线110表示可以是一条或多条总线(诸如地址总线、数据总线、或其组合)。虽然为了清楚起见利用线条示出了图1的各框，但是实际上，各组件的轮廓并不是那样清楚，并且比喻性地来说，线条更精确地将是灰色的和模糊的。例如，可以将诸如显示设备等呈现组件认为是I/O组件。而且，处理器也具有存储器。发明人认识到这是本领域的特性，并重申，图1的图示只是例示可以结合本发明的一个或多个实施方式来使用的示例性计算设备。诸如“工作站”、“服务器”、“膝上型计算机”、“手持式设备”等类别之间没有区别，它们全部都被认为是在图1的范围之内的并且被称为“计算设备”。”

计算设备100通常包括各种计算机可读介质。计算机可读介质可以是可由计算设备100访问的任何可用介质，而且包含易失性和非易失性介质、可移动和不可移动介质。作为示例而非限制，计算机可读介质可包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其它数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括，但不限于，RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字多功能盘(DVD)或其它光盘存储、磁带盒、磁带、磁盘存储或其它磁性存储设备、或能用于存储所需信息且可以由计算设备100访问的任何其它介质。通信介质一般将计算机可读指令、数据结构、程序模块或其它数据包含在经调制的数据信号中，诸如载波或其它传输介质并且包括任何信息传递介质。术语“已调制数据信号”是指使得以在信号中编码信息的方式来设置或改变其一个或多个特性的信号。作为示例而非限制，通信介质包括有线介质，诸如有线网络或直接线路连接，以及无线介质，诸如声学、RF、红外线和其他无线介质。上述的任意组合也应包含在计算机可读介质的范围内。

存储器112包括易失性和/或非易失性存储器形式的计算机存储介质。存储器可以是可移动的、不可移动的、或其组合。示例性硬件设备包括固态存储器、硬盘驱动器、光盘驱动器等。计算设备100包括从诸如存储器112或I/O组件120等各种实体读取数据的一个或多个处理器。呈现组件116向用户或其他设备呈现数据指示。示例性呈现组件包括显示设备、扬声器、打印组件、振动组件等等。

I/O端口118允许计算设备100逻辑上耦合至包括I/O组件120的其他设备，其中某些设备可以是内置的。说明性组件包括话筒、操纵杆、游戏手柄、圆盘式卫星天线、扫描仪、打印机、无线设备等等。

引导过程的各阶段

转向图2，现在将讨论引导过程中用于建立硬件清单与数据中心的云计算结构之间的互操作的各阶段的一般讨论。一般而言，图2示出了根据本发明的一实施例的显示用于将硬件清单合并到数据中心的结构中的引导过程的5个示例性阶段的流程图200。在各实施例中，使用以下讨论的各阶段来将硬件清单扩建成结构计算群集(FCC)可通过用户设备(参见图3的附图标记310)上的配置软件(参见图3的附图标记311)来实现。用户设备以及硬件清单、数据中心和/或其他网络设备一起协同工作以形成实现引导过程的一个或多个阶段的各个生态系统。

参考图2，如在框210中描绘的，引导过程的第一阶段包括用于指定硬件清单的初始设置的工作流。一般而言，该工作流导致生成需要被用于在框230和240之间部署结构网络的逻辑/物理配置。在第一阶段期间，该工作流可涉及在将硬件清单发布为数据中心的FCC之前获得关于该硬件清单的初始配置的了解。例如，第一阶段工作流可尝试确认硬件清单的初始配置以确保它对应于预期的硬件布局(例如，设备位置、IP地址、VLAN以及接线(wiring))并确保它满足由数据中心实施的特定规则(例如，标记的不安全组件缺失而理想的通信组件存在)。

在一示例性实施例中，第一阶段的工作流涉及验证初始的逻辑资源以及这些资源的适当规范匹配支持的配置。验证的一个实例可涉及确定在配置中是否提供了足够的网络资源(例如，IP地址、VLAN、端口等)来与规范所表达的理想配置匹配。例如，第一阶段工作流可验证每个机器至少被提供一个IP地址，如果这样的条件存在于规范内的话。

验证的另一实例可涉及确定是否存在配置与已知现有范围(例如，被意外提供的当前正在使用的资源)的重叠。验证的还一实例可涉及确定所计划的一组资源是否构成支持的配置(例如，是否有足够的每个需要的资源来满足规范、是否支持这些类型的资源的组合、所检测到的TOR交换机是否兼容所检测到的刀片)。验证的又一实例涉及确定是否需要与终端用户/顾客的交互来收集执行所需要的资源(例如，口令、地址、IP块、VLAN等)。

如在框220所描绘的，可在硬件清单上实现用于发现和确认网络设备和接线检查的第二阶段。在各实施例中，第二阶段的工作流可涉及分别经由基于串行的连接和基于网络的连接与架顶式(TOR)交换机和网络设备的串行接入设备进行通信。此外，第二阶段工作流可涉及通过连接中的一个或多个来发送向TOR交换机和/或串行接入设备提示选择性地引起硬件设备(例如，处理器、处理单元、计算设备、服务器以及插入机架的刀片)向用户设备发送通信以供分析的指令并可涉及使用功率分配单元(PDU)来选择性地对设备循环上电以重置它们的状态。这一分析可包括发现和确认硬件设备，如在框230中描绘的。即，引导过程的第三阶段采用从硬件设备输送到用户设备的数据分组。第三阶段的工作流可涉及解析数据分组的内容(例如，有效载荷和头部)以确定硬件设备的位置或缺失、硬件设备的配置以及到硬件设备的内部连接。

在各实施例中，第三阶段工作流还可向各个设备和/或刀片发送/注入特定工作流、工具等以执行对设备/刀片本身内硬件和/或软件组件(例如，BIOS和设备固件)的确认、更新和/或配置。在其他实施例中，第三阶段的工作流可执行“烟雾测试(smoke test)”，其用于验证所述组件与设备/刀片是可工作的并且满足结构要求。此外，第三阶段工作流可标识设备/刀片的型号、制造商以及固件版本以供记录和最终使用。

如在框240中描绘的，引导过程的第四阶段涉及将清单部署为数据中心的结构内的FCC实例。在一示例性实施例中，第四阶段工作流可涉及与结构共享硬件清单的基础结构状态(例如，在至少一个先前的阶段期间生成的)并在硬件清单上安装允许与结构进行交互的服务。将服务安装到硬件清单上可对应于多个场景之一，其将在以下更全面地讨论。如在框250中描绘的，引导过程的第五阶段涉及群集范围的确认以及对硬件清单的安全措施的提供，一旦该硬件清单被指定为FCC实例的话。在一示例性实施例中，第五阶段工作流可涉及在与新的FCC实例相关联的秘密存储与结构的控制器之间传递数据(例如，设备凭证、原始证书、私钥和口令)。

虽然描述了引导过程的5个不同阶段，但是应当了解并理解，可使用帮助提前数据中心的结构内硬件清单的合并的其他类型的工作流的合适安排，并且本发明的实施例并不限定为在此描述的5个阶段。例如，本发明的各实施例构想将单个阶段(例如，阶段五)的工作流划分成能以互斥方式执行的各分开的工作流(例如，群集范围的确认和安全性提供)中。

现在将描述用于将服务安装到硬件清单之上的多个场景的示例。在一个场景中，硬件清单表示对于数据中心是新的且先前没被配置的装备。因此，新的硬件被配置成与数据中心的现有资源透明地操作并且作为新的FCC实例或由云计算结构的控制器管理的云计算戳记被干净地集成到数据中心中。

在另一场景中，硬件清单表示在数据中心请求附加的存储/计算能力之际被添加的数据中心的本地扩展。本地扩展可包括扩建以允许结构控制器来管理的刀片的机架。在各实施例中，扩建的过程涉及发现机架内刀片的接线模式、针对预先定义的模板文件来确认该接线模式以及批准刀片用于合并进入数据中心内。实际上，扩建刀片帮助确保机架内任何潜在的接线问题或硬件问题(例如，缺失部分的物理缺陷、部分的无效版本或不合适的配置)被检测并解决，从而确保刀片在数据中心内的合并将不会不利地影响正由数据中心提供到在其上运行的服务的实况底层支持。

在又一场景中，硬件清单被配置有其自己的云计算结构的实例，该云计算结构与当前与数据中心的资源相互耦合的结构分开并分隔。由此，在将硬件清单合并到数据中心之际，数据中心将运行至少两个用于将分配到被新引导的硬件清单的服务与被分配到原始数据中心的服务相隔离的云计算结构(例如，操作系统)。通过这种方式，分开的结构可专用于特定顾客的服务，从而虚拟地和物理地排除一些服务/保护一些服务免受数据中心内的其他服务(例如，数据中心容器内的扩建/引导)损害。

在另一场景中，称为返回制造商授权(RMA)场景，硬件清单表示被认为不被数据中心的结构的控制器(此后称为“结构控制器”)可到达的(例如，不可操作的或断开连接的)(诸)计算设备或其他设备(例如，网络、PDU以及串行)。在对硬件的生命周期管理期间，结构控制器可周期性地请求被聚集在数据中心内的计算设备(例如，物理机和/或虚拟机)的状态。请求状态可涉及将请求传递到分别在计算设备上运行的代理，并接收作为返回的健康信息。如果结构控制器由于任何原因而不能到达特定的计算设备(例如，将计算设备互连到结构控制器的网络设备发生故障)，则结构控制器可发出指示硬件清单不可到达的警告。

在将硬件清单识别为不可到达之际，结构控制器可发起自动复原过程。在各实施例中，自动复原过程包括至少撤离和确认的步骤，其中确认通常也在引导过程的一个或多个阶段中实现。撤离步骤可涉及将消耗不可到达的硬件清单上的资源的服务(例如，顾客拥有的应用和基于系统的应用)转移到替代硬件清单。由此，撤离确保自动修复过程对于数据中心的顾客而言是透明的，这是因为在确认和维护期间，对他们的服务的可见性不受影响。

一旦撤离被成功执行，就调用确认步骤。在一示例性实施例中，确认步骤包括实现引导过程的验证驻留在不可到达硬件清单内组件的配置设置并针对不可到达硬件清单的预期物理拓扑结构(例如，在模板文件内提供的)来交叉参考可到达硬件清单的所检测到的物理拓扑结构(例如，组件之间的链接和设备之间的接线)的工作流。在各实施例中，如果不可到达的硬件/设备不可经由带内信道访问，则这样的确认可经由带外信道发生。由此，确认步骤确定不可到达硬件清单是否被适当地配置来与结构控制器的驱动程序进行交互，其中驱动程序被设计为与特定硬件配置交互。

如在以下更完整讨论的，确认步骤涉及使得不可到达的硬件清单离线，这是预先进行撤离步骤的一个理由。应当注意，撤离通常在真实的服务在受影响的硬件上运行时被采用。RMA在引导期间通常不涉及撤离步骤；然而，对正运行的实况结构的硬件的RMA确实涉及针对服务的受影响角色实例的撤离步骤，以用于将顾客数据从不可到达的硬件清除/准备好要访问和调查的OEM/运营商、以及隔离不可到达的硬件以免被重新使用直到问题被解决。

一般而言，由于发生若干个将中断服务在不可到达硬件清单的设备上和/或数据中心的设备上的执行的破坏性动作，将不可到达硬件清单离线。这些破坏性动作可包括以下各项中的一个或多个：通过请求串行接入设备来选择性地(经由PDU)将功率驱动到硬件(例如，刀片、功率单元、串行设备/网络设备)来操纵到该硬件的功率流(例如，开启和关闭)；从发送自被操纵的刀片的通信收集信息；从在该通信内发送的数据分组的内容中提取信息(例如，刀片的MAC地址)；以及通过针对模板文件来评估所提取的信息并执行确认来验证刀片的位置和接线。应当注意，串行接入设备通常被用于带外通信，而架顶式(TOR)交换机采用带内通信(例如，经由以太网)。

在选择性地将功率驱动到刀片的一示例中，结构控制器可关闭到馈送未知/无效硬件清单的刀片的端口范围的功率。接着，结构控制器可直接或间接地指示PDU开启到链接到主体刀片的所选端口的功率。结构控制器接着可从当前正在发送通信的主体刀片发送的数据分组中读取MAC地址。由此，当所选端口对应于模板文件的预期端口时，主体刀片的连接性被验证。除了验证所选端口以供接收来自PDU的功率之外，确认步骤可进一步涉及使用TOR交换机来确定被分配到硬件清单的刀片的端口范围内的哪个端口被连接到主体刀片。该确定由标识端口范围中正接收从主体刀片递送的数据分组的主体端口来作出。

部署和提供阶段的介绍

部署和提供阶段(见图2的框240和250)基本上涉及集成硬件清单以及安装硬件清单内的特定硬件。参考图3，为示出根据本发明的各实施例的、用于将硬件清单360集成在数据中心(例如，图8的数据中心820)内的示例性部署生态系统300的图示。初始地，部署生态系统300包括与硬件清单360的各组件通信耦合的用户设备310。在一示例性实施例中，通信耦合被组织到至少一个基于网络的连接(被示为细虚线)和基于串行的连接(被示为粗虚线)中。如在图3中所解说的，基于串行的连接涉及用户设备310和串行聚集器320之间的通信路径，其中串行聚集器320负责将指令从用户设备310适当地分发到合适的串行设备(例如，通过对从用户设备310流传输的数据分组内携带的地址进行处理)。例如，串行聚集器320可以表示与多个串行设备通信和通话的中枢型机制(例如，连接至多个机架中的多个设备)。

基于网络的连接涉及用户设备310与TOR交换机350之间经由网络设备330的通信路径。在一个示例中，网络设备可以表示L3聚集器交换机，其中L3聚集器交换机负责将数据分组恰当地从TOR交换机350分发到用户设备310(例如，聚集来自多个网络设备的数据分组)。应当注意，网络设备330可以被配置成聚集多个TOR交换机并且与多个TOR交换机通信，其中网络设备充当TOR交换机的父节点并且有时充当其他高级路由器的子节点。

在操作中，网络设备330可用作现有基础结构和硬件清单360之间的上行链路。相应地，网络设备330用于选择性地将硬件清单360与现有基础结构(例如数据中心)以及因特网的其余部分隔离。通过确保没有广播话务通过该上行链路进入或离开，网络设备330有助于抵消对于当前运行在现有基础结构上的外部服务的任何影响。

通过这种方式，部署生态系统300可以按自包含的方式行动，该自包含的方式将消息收发限制到用户设备310和硬件清单360之间的互相通信，以便确保被扩建的硬件清单360和现有基础结构之间的适当隔离。这种隔离在至少以下两个方面是有用的：在引导过程期间通过限制外部干扰来提供更高的可靠性；以及确保在现有基础结构内的任何当前活动的硬件不受引导过程的影响。在各实施例中，该隔离被配置为用作分隔现有基础结构和硬件清单360的虚拟层的安全边界，硬件清单360不被认为可信直到各阶段的每个阶段成功。因此，引导过程本身并不依赖于现有架构的安全上下文。一般来说，在引导过程的最后阶段期间(在确认和提供阶段之前)，设置安全凭证/令牌。

部署生态系统的架构

现在将讨论部署生态系统300的配置。初始地，生态系统300包括用于链接到硬件清单360内的机架301、302和303并控制其功能的用户设备310。关于机架301(例如，高密度机架)，存在一个或多个功率分配单元(PDU)381、刀片(例如计算单元371和372)、串行设备361以及网络设备(例如，TOR交换机350)。应当注意，每个机架可以有附加的TOR交换机(例如，上层和下层TOR设备)。计算单元371和372被设计成充当执行计算/存储任务的处理器，并且被OEM配置成在各自接收到功率之际单独地生成数据分组。在一个实例中，计算单元371和372表示被安排和部署在机架301内的服务器。PDU被设计成向计算单元371和372选择性地提供和聚集功率。TOR交换机350被配置成用于经由基于网络的连接来发送数据分组，而串行设备361被配置成用于在经由基于串行的连接上接收到指令之际调用对数据分组的生成。在各实施例中，串行设备361可被用于配置机架内的设备(例如，PDU、TOR交换机和刀片)。

硬件清单360可进一步包括互连用户设备310内的机架301-303的串行聚集器320和网络设备330。串行聚集器320经由串行通信信道(粗虚线)聚集各个机架301的多个串行设备361并且与其通话。网络设备330(例如聚集器交换机)经由网络通信信道(细虚线)聚集多个TOR交换机并且与其通话。如可以看到的，网络装备(例如，网络设备330和TOR交换机350)和串行路由器(例如，串行聚集器320和串行设备361)一般被组织成树形拓扑结构，其中当沿着树朝着用户设备310向上移动时存在的连接越少。

用户设备310包括被设计成驱动引导过程的至少部署和提供阶段的部署软件(例如，数据中心管理器(DCM)引擎311)。部署软件经由基于网络的连接(带内信道)通信地耦合到TOR交换机350并经由基于串行的连接(带外信道)通信地耦合到串行设备361。在各实施例中，引导过程的部署和提供阶段包括：向用户设备310提供被配备成访问模板文件的DCM引擎311，并触发DCM引擎311以更新数据中心内的主服务(MS)，其中MS有助于通过允许FCC与数据中心的外部资源集成来将FCC与数据中心集成。如上所述，模板文件包括在多个计算单元的发现和确认期间记录的硬件清单的属性。

虽然已经描述了网络/串行设备330和361的各种不同配置，但是应当理解并领会，可使用分发或聚集消息的其他类型的合适的设备和/或机器，并且本发明的各实施例不限于在此描述的串行设备361和TOR交换机350。例如，可对整个机架301提供多个串行设备，其中串行设备用作到PDU 381的串行接入连接/接口以及用作到每个计算单元371和372的串行连接/接口。在另一实例中，串行设备361和PDU 381可被组合到单个设备中。在另一实例中，TOR交换机350可被具有以太网接口能力的专用刀片替换。因此，可使用任意数量的网络设备来实现发现和确认阶段，使得至少一个网络设备包括用于网络通信的带内能力并且至少一个网络设备包括用于串行通信的带外能力。或者，如果带外能力经由以太网被采用，那么可使用次级网络交换机来替代串行设备。通过这种方式，带内能力补充带外能力并允许对网络设备的调试和诊断以及在能力之一离线的情况下允许对计算单元371和372的继续访问。

本领域普通技术人员可以理解和明白，图3中示出的生态系统300仅仅是用于实现引导过程的部署和提供阶段的环境的一个合适的部分的一个示例并且不旨在对本发明的各实施方式的使用范围或功能提出任何限制。生态系统300也不应解释为具有与其中解说的任何单个资源或资源的组合有关的任何依赖性或要求。此外，尽管为了清楚起见用线条示出了图3的各个框，但是在实际上，各组件的轮廓并不是那样清楚，并且比喻性地来说，线条更精确地将是灰色的和模糊的。

硬件清单360包括经由基于串行的连接和/或基于网络的连接互连到用户设备310的各个装备/资源。如在此描述的，这种装备/资源可包括软件组件(例如，安装在网络设备内的)以及有形硬件元件，诸如机架301、302和303和用户设备310。这些装备/资源可跨各个物理资源分布式地放置以便在其间建立通信。此外，可提供通过连接装备/资源以及引导过程所要求的任何其他元件的信道来促进这种通信的网络(未示出)。该网络可包括但不限于一个或多个局域网(LAN)和/或广域网(WAN)。这样的联网环境常见于办公室、企业范围计算机网络、内联网和因特网中。因此，不在此进一步描述该网络。

生态系统300的示例性系统架构包括用户设备310和计算单元371和372。在图3中示出的这些设备310、371和372中的每个都可采取各种类型的计算设备的形式，诸如举例来说，上文参考图1描述的计算设备100。作为示例而非限制，设备310、371和372可以是个人计算机、台式计算机、膝上型计算机、消费者电子设备、手持式设备(例如，个人数字助理)、各种服务器、刀片等。然而，应当注意，本发明不限于在这些计算设备上实现，而是可在处于本发明的各实施例的范围内的各种不同类型的计算设备的任一种上实现。

通常，设备310、371和372中的每一个包括或被链接到某种形式的计算单元(例如，中央处理单元、微处理器等)以支持在其上运行的组件的操作(例如，在接收到信号或被提供功率之际始发数据分组)。如本文所使用的，短语“计算单元”一般指的是具有处理能力和存储存储器的专用计算设备，它支持作为其上的软件、应用和计算机程序的执行的基础的操作软件。在一个实例中，该计算单元是用有形硬件元件或机器来配置的，所述有形硬件元件或机器是集成的、或者可操作地耦合到设备310、371和372以使得每个设备都能够执行与通信有关的过程和其他操作。在另一实例中，该计算单元可以涵盖处理器(未示出)，该处理器耦合到由设备310、371和372中的每一个所容纳的计算机可读介质。一般而言，计算机可读介质至少临时地存储可由处理器执行的多个计算机软件组件。如本文所使用的，术语“处理器”不旨在是限制性的，并且可包含具有计算能力的计算单元的任何要素。在这种能力中，处理器可被配置为处理指令的有形物品。在一示例性实施例中，处理可涉及抓取、解码、解释、执行和写回指令(例如，通过呈现运动模式的动画来重构物理姿势)。

同样，除了处理指令外，处理器可以向集成到或部署在设备310、371和372上的其他资源传送或从中传出信息。一般而言，资源指的是使设备310、371和372能够执行特定功能的软件和硬件机制。仅作为示例，这些资源可包括以下机制中的一者或多者：部署软件(例如，DCM引擎311)；模板文件；以及驻留在计算单元371和372内的各组件。

部署和提供阶段的工作流

现在将参考图8描述引导过程的用于将硬件清单360部署成FCC 830以及用于在FCC 830上提供安全性的工作流。初始地，用户设备310提供有在其上运行的用于实现总体引导过程的部署和提供阶段的部署软件。可以经由基于串行的连接和/或基于网络的连接将用户设备310有线地或无线地钩住到硬件清单360，基于串行的连接和/或基于网络的连接用作供用户设备310将硬件清单360集成在数据中心820内的入口点。来自用户设备310的连通性可直接地执行或通过附加的网络设备(未示出)来执行以允许其间的通信。

如本文中所使用的，短语“部署软件”旨在一般指代提供高效、稳健和可缩放的框架以将基于云的操作系统(例如，Windows Azure)纳入到指定的硬件清单360上而不管位置如何的软件。在一个实例中，部署软件允许将硬件清单360部署成云计算网络(例如，分布式数据中心820)内的云计算戳记(例如，FCC 830)。在各实施例中，允许部署涉及将未经配置的硬件清单360构建在云计算戳记中，该云计算戳记最终被纳入到云计算网络的结构中。因此，允许部署硬件清单360可涉及在硬件清单360上提供基于云的操作系统并确认该基于云的操作系统。在一示例性实施例中，基于云的操作系统包括以下：计算结构(内核空间)及核心基础结构服务(OS和/或应用空间)，诸如操作服务、监视数据服务、域名服务和前端服务。

如上所述，参考图3，部署软件可包括正在用户设备310上允许的DCM引擎311。在一个实施例中，DCM引擎311可表示能够管理硬件和设备的结构的一部分。在另一实施例中，DCM引擎311被编程为驱动用于将硬件清单360安装到数据中心820中以及将硬件清单360从数据中心820中移除的工作流。这些工作流可包括允许现有的结构扩展而无需服务中断。

此外，这些工作流可涉及DCM引擎311访问模板文件，该模板文件包括在多个计算单元的发现和确认期间记录在其中的硬件清单360的属性。发现和确认是在引导过程的先前阶段期间实现的，其中这些阶段涉及发现刀片上的组件，以及对照模板文件比较这些组件的属性，该模板文件用作预期驻留在刀片上的软件和硬件的蓝图。引导过程的各阶段进一步涉及对照模板文件验证刀片的各组件。例如，发现和验证使刀片准备好被部署到结构中，因为这些工作流确保该刀片能够正确地与刀片将被纳入其中的数据中心820内的各组件(例如，结构控制器)进行通信。如果刀片没有被正确地配置，则这些刀片将无法正确地允许其上的服务。

用户设备310存储模板文件或具有对模板文件的访问。模板文件一般被配置成包括对硬件清单360的预期物理拓扑结构的定义，其描述了设备之间的接线(例如，TOR交换机350与串行设备361之间的接线)。在一个实例中，硬件清单360的接线以由硬件清单360的设备所执行的功能类型(例如计算或存储)来定义。通常，模板文件可以由在引导过程的先前阶段(例如，图2的引导过程的初始设置阶段210)期间原始检查硬件清单360的硬件厂商来提供。

DCM引擎311可访问在这些阶段期间收集的信息(诸如，被记录在模板文件上的数据)。在另一实例中，在用户设备310正在发现并确认机架内的刀片和这些刀片的组件的同时，得到的信息正被实时地馈送至DCM引擎311以供最终使用。因此，DCM引擎311知晓在硬件清单360内检测到的设备(例如，刀片、串行和网络设备以及PDU)的配置和属性以及硬件清单360本身的物理和逻辑拓扑结构。

现转至图4，根据本发明的一实施例示出了示出由DCM引擎311部署在硬件清单360上的各个组件之间的关系的示例性示意图。初始地，在硬件清单360的部署期间，DCM引擎311可开辟出用于管理硬件清单360的不同层级设备的各个组件。这些组件包括以下：用于管理实用程序结构群集(UFC)410的主服务(MS)430；以及用于管理FCC 420的CTM 440。

在操作时，在部署MS 430之际，MS 430可具有管理图8中的FCC 830以及数据中心820中的其他FCC的能力。管理FCC 830的能力部分由DCM引擎311在硬件清单360和数据中心820之间的交互引起。如上所述，DCM引擎311表示正在用户设备310上运行的部署软件，其包括用于访问硬件清单信息(例如，SML方案和/或模板文件)并经由正在数据中心820上运行的MS 430将硬件清单信息导出到数据中心820的计算结构中的基于API的机制。换言之，DCM引擎311可能够通过简单地转换硬件清单信息而将硬件清单信息在逻辑上直接传输到数据中心820的预先存在的MS 430中而无需进一步安装。或者DCM引擎311可能够在硬件清单360的部署期间在MS 430目前不包含硬件清单信息时向MS 430填充该信息。

现转至图5-7，根据本发明的各实施例示出了解说用于部署硬件清单360内的各组件的示例性系统的图示。参考图5，硬件清单360被证明为是按子集(例如，总体机架的部分)来部署的，这与一次部署全部硬件清单相反。通过这种方式，在发现并确认一子集时，部署该子集使得其可用于MS 430，该MS430被部署在硬件清单360内。对这些子集(诸如FCC₁421和FCC₂422)的部署随后被传达给MS 430。该通信警告MS 430开始管理FCC₁421和FCC₂422以用于主存租户应用等。在动态地部署硬件清单360的子集之际，它们被发现并被确认。对CTM的部署可涉及DCM引擎分配供硬件清单360运行子集内的各CTM的各部分。例如，参考图5，FCC₁421内的硬件的一部分被分配来主存并运行CTM₁441，而FCC₂422内的硬件的一部分被分配来主存并运行CTM₂442。类似于MS 430，CTM 441和442被复制在硬件清单360的各部分上，并被配置成在生产事件期间彼此交互。使硬件清单360的剩余部分变得可用于运行顾客的租户应用。

除了MS 430以及CTM 441和442外，DCM引擎还被编程为向硬件清单360内的计算单元提供软件。在一示例性实施例中，提供软件可包括下列步骤：部署硬件清单的计算结构，使得其中的多个计算单元像统一逻辑系统一样交互；以及将核心基础结构服务部署成在计算结构上运行。从操作系统的角度来看，计算结构影响内核空间。例如，MS 430、CTM 441和422以及用于协助运行核心基础结构服务的任何其他工具都可以在计算结构内部。同样，从操作系统的角度来看，该核心基础结构服务表示用户空间内的操作系统级组件。这些操作系统级组件用于提供在FCC 421和422上运行的底层支持租户应用。

操作系统级组件的示例包括存储服务511、监视数据服务(MDS)512、域名服务(DNS)513和前端服务514。在各实施例中，存储服务511协助建立和维护文件系统。MDS 512被配备成检测FCC 421和422内的事件并基于检测到的事件来识别和诊断故障。DNS被配置成管理硬件清单360内的机架的刀片的静态和/或动态IP地址，以及分配并记录与这些刀片上运行的租户服务相关联的虚拟IP地址。前端服务514被设计成向租户服务提供用于允许外部设备与FCC 421和422交互的应用编程接口(API)。即，前端服务514允许外部设备(例如，私有企业网络)通过调用API来与正在硬件清单上运行的承租者应用交互—从而使得FCC 421和422的未被分配的各部分可用于顾客。应当注意，除了参考图5示出并提到的那些核心架构服务以外，还存在其他核心基础结构服务，诸如软件负载平衡器(SLB)等。

转至图8，根据本发明的各实施例示出了示出用于保护硬件清单360并将硬件清单360转换成与数据中心820进行交互的FCC 830的各个组件的系统架构800的操作图。此各个组件包括但不限于以下：配置引擎810、安全工具813、部署引擎814、确认设置引擎816和确认测试引擎817。这些组件可以是正在用户设备310上运行的DCM引擎的一部分或与其处于通信。或者这些组件中的一者或多者可与DCM引擎隔离，并与引导过程的部署阶段独立地运行。

初始地，在提供硬件清单360内的计算结构和核心基础结构服务之际，配置引擎810被配备成通过应用配置设置来配置硬件清单360。在一个实例中，配置引擎810被配备成将第一组配置设置应用于计算结构。第一组配置设置表示适用于数据中心820内的许多FCC的通用属性，由此将多个FCC的操作集成在公共网络中。

在另一实例中，配置引擎810被配备成将第二组配置设置应用于核心基础结构服务。第二组配置设置表示适用于个体FCC 830的专用属性。第二组配置设置可包括适用于核心基础结构服务的环境专用设置、硬件专用设置或租户专用设置。环境专用设置确定硬件清单360正投入生产还是仍在被测试。硬件专用设置对于硬件清单360是否在生产位置本地、在生产位置远程、为独立的数据中心、联合联网的数据中心的计算结构和/或是运行计算结构的第一FCC而言是特定的。硬件专用设置还可管控诸如FCC 830的专用IP范围以及硬件清单360的存储量或计算能力之类的事物。租户专用设置被提供来支持所指定的在FCC 830上运行的租户服务。这些租户专用设置通常为应用驱动的属性，诸如端点的标识符、IP地址范围和VLAN的名称。

在操作时，配置引擎810被配备成接收这些配置设置作为设置文件811内的名/值对。配置引擎810可随后将人类可读的名/值对转换成计算机可读格式(例如，服务描述文件)语言的配置设置，该计算机可读格式语言是部署在FCC830上的计算结构所预期的或者可被该计算结构理解。在一个实例中，该配置可使用配置方案来将人类可读的名/值对编写成MS和/或CTM可解释的内容专用值的格式。

安全工具813一般被配置用于在访问秘密存储812之际在硬件清单360内提供安全措施。秘密存储812表示保持机密信息一个或多个独立机制，并且其与用户设备310上的安全工具813对接。通过这种方法，秘密存储812不需要对因特网或其他公众可访问的网络有任何依赖性，从而保留了秘密存储812内存储的机密信息的私有本质。在一些实施例中，秘密存储812可表示经由因特网访问的集中式保护的秘密存储位置。

在对FCC830的部署之前，秘密存储812采用管理API来管理在初始引导过程阶段期间在扩建硬件清单360时实时地生成的机密信息。机密信息(例如，网络和硬件设备的凭证、原始证书、私钥、串行接入设备的口令、用户名、访问协议以及其他许可)被写入秘密存储812直到发现和确认阶段完成。在一个实例中，机密信息被顾客或管理员手动地上传到秘密存储812中。在另一实例中，机密信息被自动地从凭证机构导入到秘密存储812中。

在部署期间，秘密存储812可自动地将一些机密信息传输至安全工具813以导出到MS或CTM中。秘密存储812可将其他机密信息传输至高度可用的位置以供数据中心820的保管者查看。该机密信息随后可被保管者使用来在当FCC830被集成在数据中心820内时经历问题之际调试该FCC。

在操作的一个实例中，在机密信息正被注入到硬件清单360的合适位置中时，安全工具813确保机密信息的完整性。对机密信息的安全传输允许正在FCC830上运行的租户应用对消息进行加密和解密。应当注意，对机密信息的安全传输可在将硬件清单360部署成FCC 830期间或之后发生。

在使用安全工具813成功完成将机密信息注入到FCC 830和/或数据中心820之际，FCC 830可被集成在数据中心820内。集成还可包括用新的安全凭证来替换在硬件清单360的扩建期间采用的本地生成的凭证信息(被用于访问网络和硬件设备)。在一个实例中，通过利用用于创建、审计和轮换现有节点上的安全性令牌的现有云计算结构过程来执行凭证信息的替换。通过这种方式，在扩建硬件清单360时可能已经与各方(例如，技术人员、OEM、管理者或管理员)共享的凭证信息被停用，由此，FCC930变得更安全。应当注意，即使集成后，用户设备310可保留作为网关设备来在引导过程完成后服务于核心基础结构服务(例如，MS和CTM)。

安全工具813还可被分派提供虚拟IP地址的访问控制列表(ACL)以及提供FCC 830内的DNS的任务。对于大多数租户服务而言，都存在有(例如外部实体可使用虚拟IP地址来访问的)端点，该端点允许访问租户服务。该端点被给予了安全措施以便计量对其的访问。例如，安全措施可调用以下规则：即仅被图5的前端服务514授权的外部实体才可在引导期间与该计算结构交流。实施安全措施可涉及手动地改变联网硬件清单360上的许可以确保选择的外部实体群具有访问这些端点的许可，或者实施安全措施可涉及所部署的计算结构自动将安全措施(例如，访问策略)应用于硬件清单360的计算单元或联网硬件。自动应用安全措施可涉及使用基于软件的LB以及可编程接口以允许指定哪些安全措施是所期望的以及所指定的安全措施将安装安全计算结构的哪些端点。在一个实例中，指定安全措施包括设置某范围的虚拟IP地址以在ACL内用于租户服务的特定端点。

使用安全工具813来提供DNS涉及在DNS中提供对应于ACL的至少一个条目，其中该条目将域名映射到端点的一个或多个IP地址。还可有与该端点相关联的凭证证书被存储在该DNS。因此，DNS为正在FCC 830上运行的每一个端点到租户服务管理客户顾客到租户虚拟IP地址转换。

通常，对于每一个租户服务而言，存在两种类型的端点：内部(在计算结构内的)端点和外部(对公众可见的)端点。在各实施例中，动态IP(DIP)地址被用于专用于内部端点的机器层寻址，而虚拟IP(VIP)地址被用于对外部端点公开展示的公共层寻址。基于硬件或软件的LB可被用于在VIP和DIP之间映射，以便保护某范围的IP地址。此外，LB可执行网络-地址转换以使对FCC 830的内部功能的攻击受挫。

部署引擎814可在用户设备310上运行或在FCC 830的计算结构内运行。此外，部署引擎814可经由用于例示FCC 830的部署的接口来调用，其中部署引擎814负责驱动引导过程内的各个工作流的端到端自动化，该驱动包括执行用于进行以下的工具和机制：完成调度部署中固有的工作流、管理飞行中的部署以及对发生的任何问题作出响应。部署引擎814通过执行以下来进行部署：对照运行计算结构来执行工作流、报告进展、使问题升级、以及随时间收集可用于驱动部署改善的度量。

在操作时，部署引擎814可被配置成(并行或串行地)执行一组命令以执行工作流以供自动地部署硬件清单360内的配置镜像815。配置镜像815可包括虚拟硬盘(VHD)分组以及用于实现对该分组的部署的工作流的逻辑步骤。在消费配置镜像815之际，部署引擎814可开始执行工作流的各逻辑步骤。这些逻辑步骤涉及预动作(例如，确认FCC 830以确保符合预期依赖性)、动作(例如，对配置镜像815的部署)和后动作(例如，后部署确认)。

对配置镜像815的部署可按正被部署的各组件的优先级来分阶段。这些区分优先级的组件包括(按从最高优先级到最低优先级排序)核心租户、基础结构租户和平台租户。核心租户有助于提供起作用的数据中心820并包括允许计算结构的通用操作的服务。核心租户包括支持节点间通信能力的组件，诸如DNS、MS和CTM。基础结构租户有助于提供FCC 830的可用性和有效性，并使得它可用于运行租户服务。基础结构租户包括图5的存储服务511(例如，XStore)，该存储服务511支持找出针对位于远程的顾客账户的数据并提供顾客的用于与CTM进行交互的接口。平台租户有助于向消费者提供对于数据中心820的操作而言不一定是必须的顾客选项。在各实施例中，平台租户包括与依赖性方案的定义相对应的属性，因此有助于决定要在数据中心820上运行什么软件。

在完成对配置镜像815的部署之际，硬件清单360表示准备好与数据中心820的计算结构内的FCC平衡集成的新FCC 830。在将FCC 830与现有数据中心820集成时，关于FCC 830的信息(例如，MAC地址、硬件清单360中的计算单元的配置等)被传达给数据中心820以将FCC 830合并在数据中心820的先前创建的群集的布局内。一旦被集成在数据中心820后，FCC 830将用作群集之一。

初始地，集成FCC 830的过程涉及从在验证硬件清单360的物理拓扑结构时收集的信息准备基础结构状态。如在此使用的，短语“基础结构状态”旨在广义地包含被用于描述当前被网络和硬件设备展现的硬件和/或软件特性的任何数据。在一特定示例中，基础结构状态帮助将硬件清单的实用程序标识为存储、计算或存储和计算的混合，其中实用程序基于诸如物理拓扑结构(例如，出于高安全性存储目的，被链接到具有适当许可的端口的高姿态的刀片)、配置设置和网络和硬件设备的身份的考量。由此，基础结构状态表面上用作当硬件清单360被扩建到FCC 830时安装在其内的软件、配置设置以及操作系统的镜像。

在操作中，当将硬件清单360集成在计算结构内时，基础结构状态被用户设备310与数据中心820的一个或多个组件共享。通过这种方式，基础结构状态用作包括硬件清单360的使得结构控制器能够将硬件清单360作为FCC 830或云计算戳记来管理的细节的输入。例如，细节可包括网络和硬件设备的MAC或IP地址以及配置、特定设备的位置、设备和PDU之间的端口连接以及管理FCC830所需的其他信息。

确认设置引擎816和确认测试引擎817被配置成协同工作以执行对FCC830的后部署确认。一般来说，在从引导过程的一个阶段移动到下一阶段时，作出确保符合每一阶段的先决条件的确认。即，每一阶段得到的输出通常使硬件清单360保留在使下一阶段毫无困难的开始的条件中。例如，如果计算结构的部署得到的结果不允许CTM充分访问计算单元，则问题被检测到并且补救在处理下一阶段之前被触发。虽然引导过程的每一阶段可包括作为其工作流的部分的确认，但全面的结构范围确认是在对硬件清单360的扩建的结束之际被执行的。

全面的结构范围确认通过运行测试套件使得针对来自许多位置的不同子系统进行不同的测试来确保FCC 830的硬件准备好供使用。这些位置可包括以下：用于将连接变换成灾难恢复输入点的用户设备310；数据中心820的用于验证FCC 830可内部地到达的结构控制器；用于确定FCC 830是否可外部地到达(例如，通过以太网)的外部实体(例如，协作网络)；以及顾客所请求的专用实体。

初始地，当实现用于确认FCC 830的测试套件时，确认设置引擎816被指令实现其内建特征(例如，远程执行、作为…运行、暂停和恢复)可被使用来执行任务(例如，租户部署或网络配置)的工作流。由此，确认设置引擎816可借用用于设置并验证基于测试的租户服务或“金丝雀租户(canary tenant)”的合适功能的现有工作流并重新使用其来验证FCC 830的部署和配置是成功的。通常，金丝雀租户展现出在硬件清单360用作数据中心820的FCC 830时该硬件清单360将主存的至少一个租户服务的特性。在各实施例中，确认FCC830的配置和部署可包括以下步骤：部署硬件清单360上的计算结构(如前所述)；生成要被安装在硬件清单360的计算结构内的金丝雀租户的制品；将该金丝雀租户部署在硬件清单360内；将某范围的DIP和VIP地址分配给金丝雀租户；以及使用这些地址来测试金丝雀租户的操作以确保在硬件清单360的物理和逻辑拓扑机构内的合适功能。

转至图6和7，现将讨论用于部署金丝雀租户的方案。参考图6，描绘了其中确认设置引擎816采用多实例方案的场景600。多实例方案涉及跨硬件清单360的许多计算单元(例如，机架301-303上的服务器)分发金丝雀租户(例如，VM 601-603)的角色的单个实例的许多复制。随后测试这些单个角色实例以确保硬件清单360的物理和逻辑拓扑结构允许合适的功能。在一个示例中，测试可涉及验证网络和LB设置允许与VM 601-603中的每一者进行通信，并由此确认机架301-303中的每一者都是可到达的。

参考图7，描绘了其中确认设置引擎816采用多租户方案的场景700。多租户方案(例如，多个租户，其中每个租户具有多个角色)涉及跨硬件清单360的许多计算单元(例如，机架301-303上的服务器)分发各金丝雀租户(例如，VM 601-603和701-703)的实例的许多复制。这些不同的租户实例随后被测试以确保硬件清单360的物理和逻辑拓扑结构允许在同一硬件清单360上运行的至少第一租户服务(例如，VM 601-603)和第二租户服务(例如，VM 701-703)的合适功能。

现转至图8，确认测试引擎817被配置成一旦金丝雀租户被确认设置引擎816生成和分发后就对其进行测试。在测试时，确认测试引擎817一般采用具有内建特征(例如，数据驱动的测试、基于属性的测试执行、多平台测试执行和多模式测试执行)的测试框架以准许按不同的模式来执行各种各样的测试。初始地，确认测试引擎817被配置成将工具注入到硬件清单360的计算单元(例如，图7的机架301-303的刀片)中。这些注入的工具被配置成确定在按与生产相类似的方式来使用硬件清单360时是否存在计算单元故障。如果被不合适地配置，则硬件清单360可在被发布以供顾客使用之前展现出可被解决的推论故障。

正由确认测试引擎817注入的工具可至少部分地基于为硬件清单360、模板文件或在引导过程期间收集的任何其他信息开发的SKU定义来选择。此外，注入的工具可包括基于OEM的分组或顾客构建的分组。在操作时，注入的工具可在有或没有金丝雀租户的情况下运行各测试。在一个实例中，注入的工具可运行烟雾测试(smoke test)，烟雾测试包括检查被安装在硬件清单360上的硬件和软件将如何与正在数据中心820的计算结构上运行的服务交互。在另一实例中，注入的工具可运行预烧测试(burn-in test)，该预烧测试包括耗尽硬件清单360的计算能力和各种资源(诸如网络带宽)来确定服务/刀片在物理上变热之际是否会发生故障的扩展压力测试。在该测试中，服务/刀片在机架中的位置被检查，由此确认测试引擎817能够在允许将FCC 830部署在数据中心820之前检测服务器/刀片的短期故障。

在又一实例中，注入的工具可通过从(例如，在硬件清单360内部和外部的)各个位置作出调用同时检查响应于这些调用而发生的各种行为来运行测试矩阵。在一个实例中，这些调用会调用肯定操作来检查诸如可用性、等待时间和安全性之类的属性。在另一实例中，这些调用会从不同的位置调用否定操作或设计成失败的测试。通过指定测试并从各位置运行这些测试，确认测试引擎817可针对每一测试来控制选择哪些位置，由此通过区分其调用导致了故障的位置来诊断该故障。

应当注意，图8的示例性系统架构800只是可以被实现以实现本发明的各方面的合适的环境的一个示例，而非旨在对本发明的使用范围或功能提出任何限制。所示的系统架构800也不应被解释成对于所示组件810-817中的任一组件或其组合有任何依赖或要求。在一些实施例中，组件810-817中的一个或多个可被实现为独立设备或服务或可执行代码。在其他实施例中，组件810-817中的一者或多者可被直接集成到数据中心820、FCC 830和/或用户设备310中。本领域的普通技术人员可以理解，图8所示的组件810-817本质和数量上是示例性的，并且不应被解释为限制。应当注意，可在无需以上列出的特定组件中的任意组件而用提供类似功能的替换过程的情况下来实现部署。

因此，可以采用任何数量的组件来实现本发明的各实施例的范围内的所需功能。尽管为了清楚起见用线条示出了图8的各组件，但是在实际上，各组件的描绘并不是那样清楚，并且按比喻的说法，线条更精确地将是灰色的或模糊的。此外，虽然将图8的某些组件示为单个框，但是这些描述在本质和数量上是示例性的且不应被解释为限制(例如，虽然仅示出一个秘密存储812，但多得多的秘密存储可通信地耦合到正在对其他硬件清单执行引导过程的其他用户设备)。

过程流

现在参考图9，显示了示出根据本发明的一个实施例的用于将硬件清单转换成FCC的总体方法900的流程图。尽管术语“步骤”和/或“框”可在此处用于暗示所采用方法的不同元素，但除非而且仅当明确描述了各个步骤的顺序时，该术语不应被解释为意味着此处公开的多个步骤之中或之间的任何特定顺序。初始地，硬件清单表示机架，其中机架可包括网络设备(例如，TOR交换机)和一组计算单元(例如，插入到机架中的刀片集合)。该组刀片通常在串行接入设备和TOR交换机之间互连。

初始地，图9的方法900涉及建立耦合在用户设备和硬件清单之间的通信，如框910处所指示的。通常，硬件清单包括被配置成向数据中心提供附加计算或存储能力的多个计算单元。如框912处所指示的，此多个计算单元提供允许硬件清单用作数据中心的FCC的软件。在各实施例中，提供包括将计算结构部署到多个计算单元(见框916)以及部署将在计算结构上运行的核心基础结构服务(见框918)。在一个实例中，计算结构允许多个计算单元作为统一的逻辑系统来进行交互，而核心基础结构服务表示提供对正在FCC上运行的应用的底层支持的操作系统级组件。

如框914所指示的，方法900还涉及将硬件清单配置成表现为数据中心的FCC。在各实施例中，配置包括将第一组配置设置应用于计算结构(见框920)以及将第二组配置设置应用于核心基础结构服务(见框922)。在各实例中，第一组配置设置表示在整个数据中心中都适用的通用设置，而第二组配置设置包括特殊化设置，诸如环境专用设置、硬件专用设置和租户专用设置。

转至图10，现在将根据本发明的各实施例描述示出了用于在硬件清单内提供安全措施的总体方法1000的流程图。图10的方法1000涉及访问秘密存储内的机密数据的步骤，如框1010处所指示的。通常，秘密存储被配备成至少临时地维护从第三方实体(例如，顾客、管理员、数据中心的保管者或凭证机构)检索到或接收到的机密数据。在其他实施例中，秘密存储表示针对秘密存储服务内的机密数据的长期储存库，其中该服务的版本可表示正在设备310上运行的在引导期间管理秘密的独立单元。在又一些实施例中，引导过程可适用该服务的独立版本或远程服务(如果可到达的话)。

如1012处所指示的，由正在用户设备上运行的DCM引擎从秘密存储处检索机密信息。用户设备经由串行和/或网络连接通信地耦合到硬件清单。硬件清单通常包括被配置成向数据中心提供附加计算或存储能力的多个计算单元。DCM引擎被配置成将机密数据转换成部署在硬件清单上的计算结构所预期的格式，如框1014处所指示的。此外，DCM引擎被配置用于自动地将经转换的机密数据注入到硬件清单的计算结构中，如框1016处所指示的。

参考具体实施例描述了本发明的实施例，具体实施例在所有方面都旨在是说明性的而非限制性的。不偏离本发明范围的情况下，各替换实施例对于本发明的各实施例所属领域的技术人员将变得显而易见。

从前面的描述可以看出，本发明很好地适用于实现上文所阐述的所有目的和目标，并且具有对于该系统和方法是显而易见且固有的其他优点。可理解的是，某些特征和子组合是有用的，并且可以加以利用而无需参考其它特征和子组合。这由权利要求所构想的，并在权利要求的范围内。