发现、确认和配置硬件清单组件.pdf

提供了用于自动地确认和配置硬件清单以无缝地与数据中心的云计算结构进行交互的方法、系统和计算机可读介质。初始地，通过分别经由带外通信信道和网络通信信道发送和接收消息来定位硬件清单内部的设备。定位内部设备涉及建立从用户设备到硬件清单的通信，并且选择至少一个内部设备以用于在其上进行发现过程。发现过程涉及经由带外通信信道接收第一网络标识符以及经由网络通信信道接收第二网络标识符。当第一和第二网络标识符匹配时，确认所选设备的互连。否则，发起关于所选设备的一个或多个补救措施。确认涉及在MOS内进行服务器引导以及执行确认和配置工具。

权利要求书1.  一个或多个其上包含计算机可执行指令的计算机可读介质，所述计算机可 执行指令在被执行时执行一种用于发现、配置和确认硬件清单的方法，所述方法包 括： 建立从用户设备到所述硬件清单的通信，其中所述硬件清单包括经由网络通 信信道和带外通信信道互连的多个内部设备； 选择所述多个内部设备中的至少一个内部设备以用于在其上进行发现过程， 其中所述发现过程包括： (a)监听来自预定与至少一个所选设备相关联的预期带外端口的信号； (b)经由与所述预期带外端口耦合的带外通信信道接收第一标识符； (c)监听来自预定与所述至少一个所选设备相关联的预期网络端口的信号； 以及 (d)经由与所述预期网络端口耦合的网络通信信道接收第二网络标识符； 对照所述第二网络标识符来比较所述第一网络标识符以便验证所述至少一个 所选设备被恰当互连； 当所述第一和第二网络标识符匹配时，确认所述至少一个所选设备的互连； 以及 否则，发起关于所述至少一个所选设备的一个或多个补救措施。 2.  如权利要求1所述的计算机可读介质，其特征在于，所述至少一个所选设 备包括带外设备或网络交换机，并且其中所述至少一个所选设备的互连包括通过所 述带外通信信道与带外聚集器的耦合以及通过所述网络通信信道与网络设备的耦 合。 3.  如权利要求2所述的计算机可读介质，其特征在于，所述至少一个所选设 备包括所述硬件清单内的服务器，并且其中所述至少一个所选设备的互连包括通过 所述带外通信信道与带外设备的耦合以及通过所述网络通信信道与网络交换机的 耦合。 4.  如权利要求3所述的计算机可读介质，其特征在于，选择所述多个内部设 备中的至少一个内部设备以用于在其上进行发现过程包括按照以下顺序来定标设 备类型：网络交换机、带外设备、功率分发单元(PDU)、和服务器。 5.  如权利要求4所述的计算机可读介质，其特征在于，所述方法进一步包括 分别配置所述带外设备以向所述PDU发送指令，其中所述PDU负责选择性地向所 述服务器提供功率，其中所述指令使得所述PDU向至少一个所选设备递送功率以 及对所述多个内部设备中的至少一个未选设备拒绝提供功率。 6.  如权利要求5所述的计算机可读介质，其特征在于，所述第一和第二网络 标识符包括标识所述硬件清单的物理拓扑结构内的至少一个所选服务器的位置的 相应的媒体接入控制(MAC)地址，并且其中所述方法进一步包括： 访问模板文件，所述模板文件分别展现所述MAC地址与所述多个内部设备之 间的映射；以及 对照所述模板文件来交叉参考从所述至少一个所选设备接收的所述第一和第 二网络标识符以验证所述至少一个所选设备的身份。 7.  如权利要求6所述的计算机可读介质，其特征在于，在确定所述第一和第 二网络标识符不匹配之际，所述一个或多个补救措施包括： 在一个或多个非预期带外端口处搜索携带与所述至少一个所选设备相关联的 MAC地址的信号；或者 在一个或多个非预期网络端口处搜索携带与所述至少一个所选设备相关联的 MAC地址的信号，其中所述MAC地址被映射到所述模板文件内的所述至少一个 所选设备。 8.  一种用于在硬件清单的服务器上发现、确认和配置工具的计算机化的方法， 所述方法包括： 发起对本地地驻留在所述硬件清单内的服务器上的至少一个工具的执行，其 中所述至少一个工具被配置成访问所述服务器的一个或多个内部组件； 使用所述至少一个工具来执行对所述一个或多个内部组件的扫描以验证所述 服务器的配置，其中所述扫描包括： (a)发现现存于所述服务器上的一个或多个内部组件； (b)抽象出所发现的一个或多个内部组件的属性；以及 (c)用抽象出的属性来更新硬件列表，其中所述硬件列表维护所发现的一个 或多个内部组件的记录； 访问硬件方案，所述硬件方案展现用于确定所述服务器的配置是否可接受用 于部署在数据中心内的准则； 对照所述硬件列表的对应抽象出的属性来比较所述硬件方案的准则； 当抽象出的属性无法满足所述准则时，发出指示所述服务器的配置是非预期 的通知；以及 当抽象出的属性满足所述准则时，将所述比较的结果存储在用户设备内。 9.  如权利要求8所述的计算机化的方法，其特征在于，所述至少一个工具被 注入到安装在所述服务器上的维护操作系统(MOS)内，其中所述至少一个工具 在执行对所述MOS的引导之际被执行，其中对所述至少一个工具的执行在所述用 户设备远程引导所述服务器之际被发起，且其中执行所述至少一个工具包括执行压 力测试工具、固件更新工具、固件确认工具、或固件配置工具中的至少一者。 10.  一种用于执行自动发现和确认机架内的刀片的方法的计算机系统，所述 计算机系统包括： 所述刀片，在被上电之际向所述机架内的架顶式(TOR)交换机发送预引导 执行环境(PXE)请求； 所述TOR交换机，从所述PXE请求读取媒体接入控制(MAC)地址，将MAC 地址与所述刀片的关联纳入表中并且将所述表的内容传递给用户设备； 所述用户设备，将所述表的内容纳入在所述用户设备上运行的PXE服务的清 单中并且使用所述PXE服务通过维护操作系统(MOS)来远程引导所述刀片；以 及 所述机架内的带外设备，发起对嵌入在所述刀片上安装的MOS内的至少一个 工具的执行，其中所述工具被配置成用于将所述刀片的MAC地址广告给所述带外 设备。

说明书发现、确认和配置硬件清单组件
背景
一般而言，分布式服务应用被主存(host)在云计算网络中(跨多个节点)， 且主要是为了通过服务－应用组件的冗余性、动态可缩放性以及自动复原功能来促 进高可用性。这些服务应用通常被划分成多个部分，这多个部分包括一组服务－应 用组件。这些服务－应用组件可贯穿一个或多个数据中心的节点(例如，物理机和 虚拟机)来主存。通常，存在以下需要：创建或扩展这些数据中心的计算/存储能 力以容适服务应用的使用需要并帮助确保整个服务应用不会由于缺乏来自底层硬 件的支持而变得不可用。
数据中心的扩展可涉及各种场景，诸如配置新的一组硬件或重新配置现有的 一组硬件来与数据中心内现有的节点协同操作。在一个示例中，新的一组机架(每 个机架都容适多个刀片)可被定为用于集成到与数据中心节点互连的结构(fabric) 中的目标。该结构帮助确保跨现有节点分布的服务－应用组件和新添加的硬件(诸 如机架、网络设备(L2/3交换机、路由器、负载平衡器)、功率和串行设备以及 刀片)能够交互，就好像每个服务应用在其自己独立的计算设备上运行那样。
当进行数据中心的扩展时，将该新的一组硬件集成到该结构中的步骤当前是 手动进行的。这些手动进行的步骤通常是耗时、低效的且在结果方面是不一致的， 由此，可能导致服务在该结构中中断。因此，扩建一组指定的硬件以供部署到结构 中的自动化的端到端过程将帮助实现高效的、稳健的且可缩放的框架以供扩展数据 中心的计算/存储能力。
概述
提供本概述是为了以简化的形式介绍将在以下具体实施方式中进一步描述的 概念。本概述不旨在标识出所要求保护的主题的关键特征或必要特征，也不旨在用 于帮助确定所要求保护的主题的范围。
本发明的各实施例涉及用于实现自动化的引导进程的系统、方法和计算机存 储介质，该引导进程验证未被配置的硬件的清单的物理拓扑结构并将硬件清单集成 /部署为数据中心的云计算结构内的结构-计算群集(FCC)。实现引导进程的自动 化方式避免从用于重新配置数据中心或向数据中心增加能力的手动执行的规程所 引起的有问题的后果(以上讨论的)。因此，在本发明的各实施例中，自动化的引 导进程使得能够扩建硬件清单并以一致且高效的方式将其合并到云计算结构中。
一般而言，在接收到要创建或扩展数据中心的计算/存储能力的指示之际触发 引导进程。在各实施例中，数据中心包括多个节点(例如，物理机或虚拟机)、网 络设备、串行设备、功率设备以及可经由云计算结构可操作地互连和管理的其他装 备。结构提供对遍及数据中心内分布的服务应用的底层支持。尤其，可通过结构的 控制器来管理在节点中遍及分布的这些服务应用的各部分(例如，角色实例或程序 组件)。结构控制器一般负责围绕以下的各种职责：监视、维护和管理计算机资源、 网络设备、串行设备和支持结构的底层功能性的功率单元的健康。
在一示例性实施例中，引导进程在被事件(例如，对于扩展数据中心的能力 的调用)触发之际在独立的阶段中执行。这些阶段分别通过执行自包含工作流来实 现并一般地在图2中描绘。初始地，可进行共同创作阶段来指定硬件清单的初始设 置。这个阶段涉及用于实现以下过程中的一个或多个的工作流：接收指定在顾客的 场所上要求的附加能力的顾客的依赖性方案；标识满足该依赖性方案的硬件；与顾 客对接以收集用于配置所标识的硬件的值；从值中生成符号表示；在递送硬件之际 使用该符号表示来确认配置；以及准备记录拓扑结构的布局的模板文件。
在准备模板文件之际，可开始涉及发现和确认网络设备与硬件设备的阶段。 用于为这些设备中的每一者执行发现和确认的工作流一般涉及经由基于网络的连 接和/或基于串行的连接与网络设备通信以发现硬件设备周围的物理拓扑结构(例 如，机架间位置和接线排列)的用户设备。这些用户设备可对照模板文件来交叉参 考所发现的物理拓扑结构以确认硬件设备。一旦拓扑结构物理/逻辑配置被完整地 生成，对新的结构实例的部署或对现有结构实例的扩展可开始。
接着，用户设备可发起与数据中心的云计算结构的通信以实现将数据中心的 结构内的硬件清单部署为结构-计算群集(FCC)并对FCC提供安全性的阶段。这 些阶段涉及支持设置硬件群集来与数据中心内的资源和现有硬件进行交互的各个 工作流。此外，这些工作流可包括以下步骤：在验证硬件清单的物理拓扑结构之际 从收集的信息中准备基础结构状态；通过将基础结构状态与结构控制器共享来将硬 件清单集成到数据中心的结构中；在硬件清单内部署在结构上运行的服务；以及将 硬件清单指定为数据中心FCC。因此，当接连实现时，引导进程的这些阶段推动 用于扩建硬件清单和用于将硬件清单集成到数据中心的结构内的端对端自动化。该 端到端自动化可进一步在数据中心内预先建立的硬件清单内(例如，将现有的FCC 重新配置为表示数据中心内新的FCC实例)或在对于数据中心而言外部的站点处 (例如，将远程硬件清单集成为数据中心内新的FCC实例)实现高效、稳健和可 缩放的框架。
附图说明
以下参考附图详细描述本发明的实施例，附图中：
图1是适用于在实现本发明的各实施例中使用的示例性计算环境的框图；
图2是示出根据本发明的一实施例的用于将硬件清单合并到数据中心的云计 算结构中的引导进程的示例性阶段的流程图；
图3是解说用于发现、确认和配置硬件清单的物理拓扑结构的示例性验证生 态系统的图形表示，该验证生态系统适用于在实现本发明的各实施例中使用；
图4是解说用于使用远程引导机制来确认本发明的一个实施例的硬件清单内 的设备接线的技术的高级概览的操作流程图；
图5是解说根据本发明的各实施例的用于检查和运行设备的MOS内的工具的 示例性系统的图形表示；
图6是示出根据本发明的一实施例的用于发现和确认被合并在数据中心的拓 扑结构内的硬件清单的总体方法的流程图；以及
图7是示出根据本发明的一实施例的用于发现和确认硬件清单的服务器内部 的一个或多个组件的总体方法的流程图。
详细描述
本文中用细节来描述本发明各实施例的主题以满足法定要求。然而，该描 述本身并非旨在限制本专利的范围。相反，发明人已设想所要求保护的主题还可结 合其它当前或未来技术以其它方式来实施，以包括不同的步骤或类似于本文中所描 述的步骤的步骤组合。
本发明的各方面聚焦于引导进程内的发现和确认阶段，其中引导进程被设计 成达成高效、稳健且可缩放的框架以将云操作系统(Windows Azure)纳入到专用 硬件上而不管位置如何。这一发现和确认阶段涉及发现、确认和配置网络设备和计 算机硬件来作为硬件清单的初始扩建和设备返回制造授权(RMA)场景的一部分。 与用于这些元件中的每一者的发现、确认和配置相关联的工作流部分地依赖于先前 在共同创作阶段中收集的信息(例如预期拓扑结构描述)。同样，这些工作流可以 由同一生态系统来执行，该生态系统涉及具有挂钩到硬件清单中以便执行发现、确 认和配置的配置软件的用户设备(例如移动设备、膝上型计算机、或公用设施箱)。
如下文更全面地讨论的，本发明的各实施例在云计算结构内引入用于自动发 现和确认硬件的未经细化的集合或清单以便最终将该硬件清单与数据中心合并的 技术。如在此使用的，短语“硬件清单”不旨在限制到任何特定的组件配置，而是泛 指可最终被集成到结构中的任何设备汇编(例如，网络设备、计算设备、以及电源 设备)。在一个实例中，硬件清单可位于由云计算网络服务提供商的顾客管理的私 有企业网络中，其中将引导进程实现为这种类型的硬件清单上的装置允许数据中心 和私有企业网络之间的远程可到达性。在另一实例中，硬件清单可位于由云计算网 络服务提供商管理的数据中心内，其中实现引导进程允许扩建数据中心的本地存储 /计算能力。
在一示例性实施例中，硬件清单表示包括任何数目的以下各项的系统：网络 设备(例如交换机、路由器和负载平衡器)、功率设备、串行设备、刀片(例如计 算和/或存储设备)、以及刀片内的各组件(例如BIOS、驱动器、设备固件)。相 应地，各个系统可以被分类为硬件清单，并且短语硬件清单不限于本文所描述的示 例性系统。
此外，硬件清单可以被装备成经由一个或多个信道与外部设备(例如，被配 置成运行和管理硬件清单的引导进程的膝上型计算机)和/或内部设备(例如，用 于执行计算和存储操作的刀片)通信。这些信道可包括基于串行的信道(“串行通 信信道”)和基于网络的信道(“网络通信信道”)。串行通信信道表示提供硬件 清单(例如机架上的刀片)与一组串行设备(例如连接器设备)之间的挂钩 的带外连接。通常，在串行通信信道上对硬件清单的管理是在硬件设备中的每一者 上设置联网能力之前进行的。串行通信信道用于启用联网能力。网络通信信道表示 用于提供硬件清单的外部和/或内部设备与各个网络位置之间的网络链路的带内连 接。例如，网络通信信道可包括使用带内信令来交换呼叫-控制信息的网络管理以 太网线缆。这两个信道可以取决于硬件配置使用同一介质(例如以太网)来实现。
如将在以下更完整描述的，引导进程使用一个或多个工作流引擎(在图5的 用户设备310上运行)来特征化端对端自动化，该一个或多个工作流引擎驱动对包 括引导进程的各个阶段的编排和执行。在各实施例中，这些阶段可被实现为独立的 工作流，使得每个阶段可被分开地调用和驱动来完成，而无需依赖另一阶段或工作 流的并发操作。通过允许各阶段以自包含形式来独立地实现，每个阶段一致地将递 增的改进递送到硬件清单，而没有对先前或后续工作流的任何不利交互。
如在以下的讨论中显而易见的，下文的讨论的大部分将聚焦于围绕引导进程 的发现和确认阶段的工作流。在操作中，这些工作流被设计成达成发现和确认阶段 的各个目标，诸如通过进行接线检查来验证设备之间的物理连接以确保服务器机架 内部的接线(例如，服务器、串行接入设备、和PDU之间的连接)以及潜在地服 务器机架外部的接线(例如，服务器机架之间的网络连接)如预期那样。发现和确 认阶段的另一目标是用生产设置(例如凭证和协议类型)来配置硬件清单的设备。 在用生产设置配置设备之际，采用各工作流以确认硬件清单的生产设置以及网络配 置，允许经由一个或多个交换机接入服务器或与服务器的网络连通性。不恰当的网 络配置(被工作流检测和修复)通常阻止与服务器的预期交互，即便在服务器周围 的接线是正确的(例如，数据分组将不会正确地遍历从交换机到服务器的网络连接) 情况下。
发现和确认阶段的又一目标在于检查服务器及其组件的配置和功能与预定义 的模板文件相匹配。与模板文件相匹配的一个实施例涉及检查安装到服务器的存储 器、硬件驱动器和其他硬件组件的存在和性能与硬件方案相匹配以确保存在充足的 存储器以使得服务器可以正确地在云计算结构的上下文中运行。模板文件可以部分 地使用在引导进程的共同创作阶段期间开发的SKU定义来准备。SKU定义在2012 年6月22日提交的题为“Establishing an Initial Configuration of a Hardware Inventory (建立硬件清单的初始配置)”的美国申请号13/531,136(代理卷宗号 335263.01/MFCP.165833)中更详细地讨论，该申请通过援引纳入于此。
发现和确认阶段的又一目标在于验证硬件清单内的设备正在运行内部软件 (例如固件、驱动程序和Bios)的受支持版本。也就是说，发现和确认阶段采用 各工作流来检测不顺应的、过时的、或者制造商开发的软件何时在设备上运行。如 果检测到不顺应的软件，采用各工作流来执行升级以确保在部署引导进程是的顺应 性。
在简要描述了本发明的各实施例的概览后，以下描述适于实现本发明的各实 施例的示例性操作环境。
操作环境
首先具体参考图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以及串行)。 在对硬件的生命周期管理期间，结构控制器可周期性地请求被聚集在数据中心内的 计算设备(例如，物理机和/或虚拟机)的状态。请求状态可涉及将请求传递到分 别在计算设备上运行的代理，并接收作为返回的健康信息。如果结构控制器由于任 何原因而不能到达特定的计算设备(例如，将计算设备互连到结构控制器的网络设 备发生故障)，则结构控制器可发出指示硬件清单不可到达的警告。
在将硬件清单识别为不可到达之际，结构控制器可发起自动复原过程。在各 实施例中，自动复原过程包括至少撤离和确认的步骤，其中确认通常也在引导进程 的一个或多个阶段中实现。撤离步骤可涉及将消耗不可到达的硬件清单上的资源的 服务(例如，顾客拥有的应用和基于系统的应用)转移到替代硬件清单。由此，撤 离确保自动修复过程对于数据中心的顾客而言是透明的，这是因为在确认和维护期 间，对他们的服务的可见性不受影响。
一旦撤离被成功执行，就调用确认步骤。在一示例性实施例中，确认步骤包 括实现引导进程的验证驻留在不可到达硬件清单内组件的配置设置并针对不可到 达硬件清单的预期物理拓扑结构(例如，在模板文件内提供的)来交叉参考不可到 达硬件清单的所检测到的物理拓扑结构(例如，组件之间的链接和设备之间的接线) 的工作流。由此，确认步骤确定不可到达硬件清单是否被适当地配置来与结构控制 器的驱动程序进行交互，其中驱动程序被设计为与特定硬件配置交互。
如在以下更完整讨论的，确认步骤涉及将不可到达硬件清单离线，这是预先 进行撤离步骤的理由。一般而言，由于发生若干个将中断服务在不可到达硬件清单 的设备上和/或数据中心的设备上的执行的破坏性动作，将不可到达硬件清单离线。 这些破坏性动作可包括以下各项中的一个或多个：通过请求串行接入设备来选择性 地(经由PDU)将功率驱动到刀片来操纵到刀片的功率流(例如，开启和关闭)； 从发送自被操纵的刀片的通信中收集信息；从在该通信内发送的数据分组的内容中 提取信息(例如，刀片的MAC地址)；以及通过针对模板文件和执行确认来评估 所提取的信息以验证刀片的位置和接线。应当注意，串行接入设备通常被用于带外 通信，而架顶式(TOR)交换机采用带内通信(例如，经由以太网)。
在选择性地将功率驱动到刀片的一示例中，结构控制器可关闭到馈送未知/无 效硬件清单的刀片的端口范围的功率。接着，结构控制器可直接或间接地指示PDU 开启到链接到主体刀片的所选端口的功率。结构控制器接着可从当前正在发送通信 的主体刀片发送的数据分组中读取MAC地址。由此，当所选端口对应于模板文件 的预期端口时，主体刀片的连接性被验证。除了验证所选端口以供接收来自PDU 的功率之外，确认步骤可进一步涉及使用TOR交换机来确定被分配到硬件清单的 刀片的端口范围内的哪个端口被连接到主体刀片。该确定由标识端口范围中正接收 从主体刀片递送的数据分组的主体端口来作出。
发现和确认阶段的介绍
发现和确认阶段(见图2的框220和230)基本上涉及验证硬件清单的设备间 接线以及安装硬件清单内的特定软件。参考图3，采用解说用于发现、确认和配置 硬件清单360的物理拓扑结构的示例性验证生态系统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包括被设计成驱动引导进程的至少发现和确认阶段的配置软件。 配置软件经由基于网络的连接(带内信道)通信地耦合到TOR交换机350并经由 基于串行的连接(带外信道)通信地耦合到串行设备361。在各实施例中，引导进 程的发现和确认阶段包括：发现网络设备(TOR交换机350和串行设备361)以及 该组刀片(计算单元371和372)；以及通过对照描述机架301的物理拓扑结构的 模板文件312来比较数据分组内携带的信息来确认该组刀片的位置。如以上讨论 的，在完成指定硬件清单360的初始设置的阶段之际生成模板文件312。
串行设备361(例如DIGI)使用带外接入方法用于建立到PDU381以及到计 算单元371和372中的每一者的连通性。在操作中，串行设备361聚集计算单元 371和372的串行连接。串行设备361被进一步配置成从配置软件接收指令并且在 处理指令之际控制PDU 381。在一个实例中，控制PDU 381涉及向其传达指令。 在接收并读取指令之际，PDU 381可被配置成将功率递送到计算单元371和372 中的至少一个所选刀片并对计算单元371和372中的至少一个未被选择的刀片拒绝 提供功率。作为响应，(诸)所选刀片可开始对数据分组的生成，数据分组在被路 由到配置软件之前在TOR交换机350处被聚集并随后在网络设备330处被聚集。 另一方面，未被选择的刀片将可能放弃发送数据分组。由此，配置软件能够根据指 令所选的刀片的位置与在机架301内生成的数据分组的始发位置之间的比较来确 认网络设备330和TOR交换机350、计算单元371和372、PDU 381、和串行设备 320和361之间的内部连接。
虽然已经描述了网络/串行设备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。 装备/资源可跨各个物理资源被可分布地放置，由此，用户设备310可通过发现和 确认阶段(参见图2的附图标记220和230)来识别装备/资源的位置以便建立它们 之间的通信。此外，可提供通过连接装备/资源以及引导进程所要求的任何其他元 件的信道来促进这种通信的网络(未示出)。该网络可包括但不限于一个或多个局 域网(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 能够执行特定功能的软件和硬件机制。仅作为示例，资源可包括以下机制中的一者 或多者：配置软件(未示出)、模板文件312、重新引导机制311、以及驻留在计 算单元371和372内的组件。
发现和确认阶段的工作流
现在将描述引导进程中用于发现和确认图3的验证生态系统300的硬件清单 360内的网络和硬件设备的各工作流(见图2中的附图标记220和230)。初始地， 向用户设备310提供在其上运行的用于验证硬件清单360的装备和组件的配置软 件。初始地，用户设备310有线或无线地挂钩到串行聚集器320和网络设备330 以分别形成基于串行的连接和基于网络的连接，其中串行聚集器320和网络设备 330(例如网络集成路由器)充当用户设备310的入口点来扩建硬件清单360。来 自用户设备310的连通性可直接地或通过附加的网络设备来执行以在设备320和 330之间路由话务来实现它们之间的通信。
在各实施例中，其上运行有配置软件的用户设备310可以被运送至消费者， 以便使得装置外的电器(例如，远离数据中心的硬件清单360)在线。一般地，配 置软件能用于将硬件清单360设置成用作数据中心内的群集/戳。例如，在启动配 置软件之际，自动执行用于设置硬件清单的过程，其中该过程一般涉及以下步骤(下 文更全面地讨论)：通过命令设备发送话务来自动发现设备；以及在从其接收到话 务之际确认设备的接线。
用户设备310可进一步包括模板文件312。模板文件312一般被配置成包括对 硬件清单360的预期物理拓扑结构的定义，其描述了设备之间的接线(例如，TOR 交换机350与串行设备361之间的接线)。在一个实例中，硬件清单360的接线以 由硬件清单360的设备所执行的功能类型(例如计算或存储)来定义。通常，模板 文件312可以由在引导进程的先前阶段(例如，图2的引导进程的初始设置阶段 220)期间原始检查硬件清单360的硬件厂商来提供。
一般而言，短语“模板文件”可宽泛地表示硬件清单360内的设备的结构和/ 或组织的蓝图，并且它用于展示硬件清单360内设备的预期位置以及设备之间的接 线。例如，模板文件312可以指定每一个计算单元371和372必须连接到PDU 381、 TOR交换机350和串行设备361的相应槽，藉此提供一种区别计算单元371和372 在物理拓扑结构内的网络位置的方式。在另一实例中，模板文件312展示哪些串行 设备361连接到串行聚集器320的哪个端口。在另一实施例中，模板文件312还可 展示硬件清单360内的设备的MAC地址。相应地，在从硬件清单的设备分发的通 信中抽象出MAC地址之际，用户设备310的配置软件可以对照模板文件312来比 较截取的MAC地址并且对它们进行交叉参考。
在使用模板文件312进行发现和确认阶段时，进行用户设备310(主存和运行 模板文件312)与高层设备(例如，串行聚集器320、网络设备330、脊柱(spine) 和网络路由器)之间的连接。一般而言，脊柱在一种类型的物理拓扑结构中实现， 而网络路由器在另一种类型的物理拓扑结构中实现(即，仅脊柱或网络路由器之一 用于特定硬件清单)。如图所示，在图3中，网络设备用于表示脊柱或网络路由器。
这些高层设备一般被预配置成(例如提供有先前安装在其上的软件)使得至 少一种类型的网络设备(例如网络设备330)和至少一种类型的串行设备(例如串 行聚集器320)已经被配置成与用户设备310的配置软件通话。例如，在将网络设 备330和串行聚集器320挂钩到用户设备310之际，这通常要求纯手动设置，网络 设备330和串行聚集器320被预配置成在依据来自用户设备310的指令将话务路由 至机架310。如上所提及的，用户设备310与网络设备330和串行聚集器320之间 的挂钩可以是物理接线(在现场的消费者本地的)或无线连通性(远离服务提供者)。 串行聚集器320和网络设备330各自表示用于初始发现机架301内的设备的接线的 入口点。
在用户设备310与网络设备330和串行聚集器320之间建立连接之际，可以 开始发现过程。一般而言，发现过程涉及通过以自上到下的方式访问设备来自动检 查设备的连接。例如，因为串行聚集器320首先连接到串行设备361(DIGI)接着 向下沿线连接到TOR交换机350和PDU 381，所以发现过程通常在TOR交换机 350和PDU 381之前检查和配置串行设备361。相应地，发现过程可初始地将串行 设备361确定为用于检查的目标，接着将TOR交换机350确定为用于检查的目标， 再接着将PDU 381确定为用于检查的目标。
一旦设备被确定为目标并且被访问，对连接的检查涉及对照模板文件来比较 来自两种通信信道(网络和串行)中的每一者的信息。如上所提及的，机架301 内的每一个设备可以从串行通信信道(经由串行聚集器320)以及从网络通信信道 (经由网络设备330)来访问以便提供对接线的验证。对接线的验证可初始地涉及 经由串行连通性(粗虚线)从被定标的设备拉取和/或读取MAC地址，其中串行 (第一)MAC地址与被定标的设备被预期要连接的串行端口相关联。接着，接线 验证可涉及经由网络连通性(细虚线)从被定标的设备拉取和/或读取MAC地址， 其中网络(第二)MAC地址与被定标的设备被预期要连接的网络端口相关联。应 当注意，在串行(第一)和网络(第二)上的MAC地址验证的排序可以颠倒并且 仍然能够实现本发明的各实施例。
一旦发现串行(第一)MAC地址和网络(第二)MAC地址，就对照彼此来 比较它们以确定是否存在匹配。如果存在匹配，可以假定机架301内的被定标的设 备、串行聚集器320和网络设备330之间的内部连接是恰当的(例如，没有人意外 地将被定标的设备接线到非预期位置中的另一串行/网络设备)。同样，如果存在 匹配，用户设备310可以作出至被定标的设备的网络和串行连通性是有效的记录。 此外，对照模板文件312来比较串行(第一)MAC地址和网络(第二)MAC地 址可以在在实际硬件清单与模板文件312内的预期位置之间建立接线相关。
如果用户设备310无法经由一个或多个信道检索到MAC地址，则配置软件可 以记录被定标的设备要么被误接线(例如连接到分开的设备的端口)要么接线被切 断(例如，来自预期端口的接线不存在)的指示和/或可以将错误报告给消费者。 此外，如果不存在匹配，则用户设备310的配置软件可以继续检查其他端口以确定 被定标的设备是否在端口的可接受范围内连接。即，如果检索到的端口值与预期端 口值不同并且被确定为如当前接线那样能够正常工作，则可以记录非预期的检索到 的端口值而不触发失败。以此方式，发现过程可以原谅与模板文件312的某些不一 致性(即，被定标的设备不是按照模板文件312中原始指定的那样来接线)，只要 被定标的设备在可接受端口的预定义范围内从而允许发现过程适配微小的不一致 性。
例如，如果对于在哪个端口上将TOR交换机350连接到网络设备330没有严 格限制，则发现过程可以简单地跨网络设备330上的端口范围来检查TOR交换机 350的MAC地址。一旦标识接收到TOR交换机350MAC地址的端口地址，出于 错误追踪目的将所标识的端口报告给消费者并且用正确的信息来更新模板文件 312(例如，所标识的端口被映射到TOR交换机350)。
通过将灵活性构建到发现过程中，度量对模板文件312的遵循水平以便接受 接线方面的一些错误。因而，代替以严格的方式对照模板文件312来进行接线检查 并且在每一次不一致性时均提出警告，发现过程被允许检查端口范围并且将被标识 为正与被定标的设备连接的端口记录到模板文件312(或分开的结果文件)上。然 而，在一些实例中，要求对模板文件312所预期的端口的严格遵循。在一个示例中， 当安全端口被标记为用于连接到被定标的设备时，严格遵循模板文件312。在另一 示例中，当被标识为正连接到被定标的设备的端口不恰当地跨越安全边界或者在被 分配用于被定标的设备的端口的可接受范围之外时，严格遵循模板文件312。
在一示例性实施例中，为了帮助发现被定标的设备的存在和接线/连接以及确 认被定标的设备的初始功能，发现和确认阶段可涉及配置过程。配置过程通常包括 以下步骤：(a)将网络配置设置应用于被定标的设备的固件以使得被定标的设备 能用作网络发现的基线；以及(b)向被定标的设备指派IP地址，以使得在试图访 问被定标的设备时可以向其他网络/串行设备广告该IP地址。
参考图3，出于发现的目的，配置过程可涉及连续地或并发地将串行设备361、 TOR交换机350和PDU 381配置成具有恰当的网络接口(网络接口通常比串行接 口更快且更可靠)。这一配置过程可以在用户设备310初始地挂钩到机架301之际 来实现。在一个实例中，配置过程可涉及通过串行通信信道向串行设备361发送信 号以在串行设备361内建立使得串行设备361可访问且顺应的配置设置。此外，配 置设置使得串行设备361能够自动地将其自身在上行流中广告给网络或串行设备。 在各实施例中，自动的上行流广告需要串行设备361通过网络和/或串行通信信道 发送其MAC或IP地址而无需提示。一旦配置设置被安装到串行设备361，它们可 以被安装到下行流设备，诸如TOR交换机350、PDU 381和计算单元371和372。
现在将提供将配置设置安装到目标设备的一特定示例。初始地，安装被设计 成打开被定标的设备内的特殊模式的协议(例如，ARP或DHCP协议)。在打开 特殊模式时，被定标的设备开始自动向外发送具有其MAC或IP地址的数据分组 或者向网络广告它自身。相应地，在被激活时，特殊模式启用被定标的设备的网络 可见性(如果尚未被预配置成这么做的话)。在操作中，特殊模式允许经由串行和 网络通信信道接收被定标的设备的标识符(例如IP或MAC地址)而无需用户设 备310主动地抵达被定标的设备并且从其拉取标识符。
如上所提及的，遍历串行和网络通信信道的标识符被用户设备收集并且对照 彼此以及对照模板文件312来进行匹配。如果存在匹配，则被定标的设备可以用操 作凭证和其他结构要求的软件来配置。此外，如果存在关于PDU 381的匹配，具 有协议的配置设置可以被安装到PDU 381以允许其被用户设备310控制以使得 PDU 381顺序地选择性地向被定标的计算单元371和372分发功率。
应当领会和理解，以上用于在网络和硬件设备上实现发现和确认阶段的步骤 可被迭代地执行，以使得串行设备(例如，串行设备361)和网络设备(例如，TOR 交换机350)可被递归地确定为目标以连续地确认计算单元371和372中的每一个 的位置和到其的连接。因而，机架301的整个接线模式可以通过简单地重复上述发 现过程来提取，这可以被提取成以下步骤：在串行设备处检测经由串行通信信道从 被定标的设备广告的串行(第一)MAC地址；在网络设备处检测经由网络通信信 道从被定标的设备广告的网络(第二)MAC地址；对照彼此来比较第一和第二 MAC地址以确保被定标的设备的接线是正确的且是完全可工作的；以及对照模板 文件312来比较第一和第二MAC地址以确保被定标的设备的位置是如预期那样 的。如果是，则用配置设置、协议、凭证等来配置被定标的设备。
虽然已经描述了硬件清单的各种不同配置，但是应当理解和领会，可使用允 许增加存储/计算能力的其他类型的合适的机器以及在机器之间路由话务的合适的 设备，并且本发明的各实施例不被限于在此描述的生态系统300的布局。即，各种 其他类型的设备的物理拓扑结构可出现在硬件清单360内，这些被本发明的各实施 例所考虑。
伴随于变化的拓扑结构，模板文件312可对应地变化，使得用于交叉参考和 确认的过程可适应接线内的修改(网络方案)和设备内的改变(硬件方案)。因此， 与每当对被扩建的新的硬件清单360的物理拓扑结构作出修改就要全部地重写确 认代码相反，新的模板文件312基于新的硬件清单360来简单地生成，而用于确认 网络和硬件设备的引导进程阶段保持在过程中不被改变。由此，将引导进程应用到 当前存在的各个物理拓扑结构以及应用到还没有被开发的那些物理拓扑结构而无 需大修各个阶段的工作流的能力允许在对接线和设备的标准、统一的设置之外扩建 和部署硬件清单。
应当注意，模板文件312可在用户设备310处提供，或者在与用户设备310 通信的数据存储处维护。一般而言，模板文件312揭示被组装到机架301-303的设 备的身份以及设备之间内部接线的模式。在一个实例中，模板文件312包括定义预 期位置和地址(例如，MAC地址、IP地址或被分配到网络接口以供在物理网络分 段上引导通信的其他唯一标识符)以供映射计算单元371和372的硬件方案。例如， 硬件方案可指定机架301包括被标识为刀片1、刀片2(计算设备371和372)的硬 件设备，而机架301被配备有被标识为TOR1(TOR交换机350)的网络设备。
此外，硬件方案可在具有来自准许对串行设备361的初始访问的硬件清单360 的厂商的默认的一组凭证的用户设备310内编程。作为背景，在供应商的硬件接受 技术人员扫描在硬件清单360内发货的设备的条形码之际，凭证和/或地址可被输 入到硬件方案。
在另一实例中，模板文件312包括定义在TOR交换机350、计算单元371和 372、PDU 381和串行设备361之间的内部接线的拓扑结构方案。通常，拓扑结构 方案分开指定用于各种功能类型(例如，存储和计算)的接线。在一示例性实施例 中，拓扑结构方案包括串行聚集器320内被分配来经由基于串行的连接与串行设备 361进行通信的端口范围。同样，在各实施例中，拓扑结构方案指定所分配的端口 范围内预期的槽，在这些槽中出于成功确认应该出现到某些设备的链接。例如，拓 扑结构方案可指定在网络设备330处的端口范围的槽“A”被指派为与TOR1(TOR 交换机350)链接，而在TOR1处的端口范围的槽“B”被指派为与刀片2(计算设备 372)链接。在另一示例中，拓扑结构方案可指定在串行聚集器320处的端口范围 的槽“C”被指派为与串行设备361链接，而在串行设备361处的端口范围的槽“D” 和“E”被指派为分别与刀片2(计算单元372)和PDU2(PDU 381)链接。由此， 硬件和拓扑结构方案相结合来提供了用于从感知到的网络通信中标识硬件和网络 设备的物理位置的方式。
此时，用户设备310上的配置软件可通过控制PDU 381选择性地向计算单元 371和372提供功率来开始发现和确认设备位置和接线。将参考图4来描述用于选 择性地提供功率的这一过程。一般地，图4表示解说用于使用远程引导机制来确认 本发明的一个实施例的硬件清单内的设备接线的技术的高级概览的操作流程图。用 于确认设备接线的技术可包括使用图3的远程引导机制311来确认硬件清单360 的机架301-303中的每一者内的具体服务器。在高级别上，确认通过递归地触发 PDU 381的每一端口以及重新引导特定服务器并且使用远程引导机制311(例如， 预引导执行环境(PXE)引导)来发现特定服务器的物理和网络位置(例如，机架 301内的配置)来执行。一旦发现特定服务器的物理和网络位置，就对照机架内容 规范(例如在模板文件312内)来验证它们以识别任何丢失或未响应的设备。以此 方式，用于确认接线的技术允许验证三种类型的连通性：功率连接，网络连接和串 行连接。
现在将讨论用于确认硬件清单的机架的接线的技术的详细步骤。初始地，机 架的设备被预配置成在被打开时广告标识符(例如，IP或MAC地址)。相应地， 用户设备310被配置成经由PDU 381打开或控制到至少一个刀片的上电。这在图4 的操作411处描绘。应当注意，设备可以被单独地打开(例如计算单元371)或者 以群组的方式在一起被打开。当计算设备371被打开时，它将自动经由网络通信信 道向外发送PXE请求。这一PXE请求包括计算单元371的MAC地址，如操作412 处所描绘的。TOR交换机350被配置成通过网络通信信道从计算单元371接收PXE 请求并且将PXE请求重定向到PXE服务410，如操作413处所描绘的。
如操作414处所描绘的，PXE服务410可以试图抽象出计算单元371的MAC 地址并且将其与清单作比较。通常，MAC地址将不会在PXE请求被初始接收到时 就被识别。当MAC地址未被PXE服务410识别时，不会由此采取动作。此外， 在无法在PXE服务410处识别MAC地址之际，TOR交换机350可以从PXE请求 中抽象出MAC地址，如操作415处所描绘的。在一个实施例中，抽象MAC地址 可涉及解析由计算设备371自动分发的PXE请求并且将MAC地址添加到TOR交 换机350处主存的表。
如操作416处所描绘的，一旦在TOR交换机350处的表处收集到MAC地址， TOR交换机350就与用户设备310通信以重新配置PXE服务410来将MAC地址 添加到其清单。具体地，如框417所描绘的，PXE服务410用来自由TOR交换机 350维护的表的条目来更新其清单。一般而言，PXE服务410将仅引导已经在清单 中列举的那些服务器。因而，PXE服务410在确认期间按照清单来引导。
相应地，在计算单元371重新发送PXE请求之际，如操作418处所描绘的， PXE服务410将识别PXE请求内传达的MAC地址。具体地，PXE服务410将对 照经更新的清单来检查MAC地址并且标识出该MAC地址被列举为条目，如操作 419处所描绘的。一旦MAC地址被PXE服务410识别，PXE服务410就通过用 维护操作系统(MOS)来引导计算单元371来开始对来自计算单元371的PXE请 求作出响应，如操作420处所描绘的。作为示例，MOS可以表示具有特殊工具的 Windows操作系统的轻量版本。然而，应当注意，MOS可以是帮助对服务器进行 确认的操作系统的任何映像。有利的是，MOS给予用户设备310将附加专用工具 和/或应用加载到计算单元371上的能力。
在另一实施例中，在对串行设备361进行初始接线检查时，计算单元371被 确定为具有网络配置(例如，提供有生产软件)，则不提示用户设备310改变操作 系统。取而代之，用户设备310被设计成基础ping(查验)网络命令以检索MAC 地址或者仅仅启用计算单元处的协议来广告MAC地址(如果装备有特殊模式的 话)。
如操作421处所描绘的，用户设备310一旦用MOS引导就将开始从串行通信 信道访问服务器(例如计算设备371)。此外，用户设备310可以执行MOS上提 供的工具，诸如检索计算单元371的MAC地址的工具，提供对与其的串行接线的 确认的工具。或者，在引导计算单元371之前，用户设备310可以将计算单元371 的MAC地址的初始打印输出与串行设备361作比较。然而，使用MOS来管理递 送MAC地址的格式是有利的以便于消除解析从计算单元371打印的原始输出的步 骤。
接着，确认对计算单元371的功率连接。如上所提及的，出于混淆跨接线的 风险，服务器通常是逐一被打开的，这与并行打开不同。在用户设备310触发PDU 381以打开计算单元371之际，串行设备361可以访问来自计算单元371的MAC 地址(见操作423)并且将所访问的MAC地址返回到用户设备310(见操作424)。
如操作425处所描绘的，在接收到MAC地址之际，用户设备310可以通过对 照TOR交换机350所收集的MAC地址来比较串行设备361所返回的MAC地址 来确认计算单元371的功率接线。作为第二检查，用户设备310可以确认计算单元 371的MAC地址从网络中消失(即端口变得静默)并且在计算单元371下电之际 到串行设备361的输出停止。如果在任何点处在计算单元371广告的MAC地址与 先前输入到表和/或清单的预期MAC地址之间存在不一致性，则生成通知并且存 储不一致性以供将来参考。
转向图5，将讨论解说根据本发明的实施例的用于检查和运行设备上部署的 MOS内的工具的示例性系统的图形表示。初始地，用户设备310连接到机架301 的串行设备361并且经由端口520连接到计算单元371。一旦PXE服务410用MOS 来引导计算单元371，用户设备310将具有运行嵌入在MOS上的工具的能力。一 般而言，运行这些工具允许深度发现和确认设备(例如计算单元371)上的组件(例 如，图5的参考标号511和512)。
在操作中，根据本发明的各实施例，用运行特殊环境的MOS来引导计算单元 371，该特殊环境被设计成除了其他方面之外尤其用于配置和确认其上的软件和硬 件组件。MOS的特殊环境可包括库存单元(SKU)检查器工具510和硬件方案550， 硬件方案550可以在部署之际使用SKU检查器工具510来动态生成。MOS上的这 些工具允许计算单元371在执行外部(由用户设备310)或内部发出的命令之际与 串行设备361通信。
此外，这些工具允许在执行之际运行各种操作。例如，在执行之际，SKU检 查器工具510可以枚举计算单元371的硬件属性。执行可涉及使用串行设备361 来调用SKU检查器工具510以便开始计算单元371上本地的验证过程，其中验证 过程的结果被传达给串行设备361。在验证过程的一个示例中，SKU检查器工具 510使用即插即用接口来发现计算单元371上提供的组件511和512。这些组件511 和512包括但不限于设备、驱动程序、软件以及计算单元371的硬件上的其他项。 此外，计算单元371上提供的组件511和512的量不限于图5所解说的那些并且可 以包括任何数目。
使用即插即用接口来发现组件511和512允许SKU检查器工具510从计算单 元371拉取与组件511和512相关联的信息521和523。在一个示例中，信息521 和523包括由组件511和512表示的一种类型的组件，这可以从其硬件属性中进行 提取。此外，基于组件的类型，SKU检查器工具510可以对计算单元371执行更 深的扫描以提取详细数据522，诸如BIOS、存储器(例如分区大小)、硬盘驱动 器(例如型号)、CPU、和制造商身份。在各实施例中，所提取的细节数据522 包括被认为对于确认计算单元371的组件511和512有关的一组准则。一旦收集到 所提取的细节数据522，SKU检查器工具510可以执行附加测试来确保所标识的组 件511和512满足该组准则。例如，附加测试可包括确定计算单元371上的硬盘驱 动器的存储容量是否满足用于与结构操作环境合作的准则。
信息521和523以及详细数据522可被保存到硬件列表540，该硬件列表540 维护所提取的详细数据522以供与硬件方案550(例如XML文档)作比较。在各 实施例中，与硬件方案550的比较可涉及对照硬件列表540上的预定义属性来匹配 详细数据522。一般而言，硬件方案550解说什么组件应当出现在计算单元371内 以用于对硬件的进一步确认。在一个实例中，硬件方案550描绘什么组件可接受存 在于计算单元371上，其中排除可能会危及系统的安全。在另一实例中，硬件方案 550描绘不期望什么存在于计算单元371上，其中包括可能会危及系统的安全。
在一示例性实施例中，对照所提取的详细数据522与硬件方案550的比较涉 及确定计算单元371是否满足硬件方案550的准则(预定义属性)。满足准则可以 使用精确的匹配规程或可变的匹配规程来确定。精确的匹配规程(对于要求的组件) 标识硬件方案550的预定义属性中的每一者存在并且被具体地配置成促进恰当的 功能。可变的匹配规程(对于可任选的组件)在匹配方案内具有内置灵活性以在比 较期间接受值的范围。例如，可变的匹配规程允许计算单元371上出现的组件类型 的可接受变动(例如，如果标识了五个可接受硬盘驱动器中的任一个则设备通过)。 在另一实例中，可变的匹配规程允许组件配置的可接受变动(例如，如果硬件存储 器的大小落在从5到10千吉字节的范围内则硬件存储器将通过)。
尽管文本描述了精确的和可变的匹配规程两者，但应当领会和理解，可以采 用用于对照硬件列表540内所提取的详细数据522来比较硬件方案550的其他方 法，并且这些方法由本发明的各方面构想。例如，对照硬件列表540来比较硬件方 案550可涉及以下步骤：构造禁止设备列表，该禁止设备列表包括可能导致结构内 的问题或不一致性的设备；将禁止设备列表纳入硬件方案550内；对照禁止设备列 表来比较硬件列表540内所提取的详细数据522；以及如果禁止设备列表上的一个 或多个项匹配所提取的详细数据522则使计算单元371失败。
一旦完成匹配规程，对整体结果的检查指示计算单元371通过还是失败。例 如，如果组件511和512通过精确的、可变的且禁止匹配规程，则计算单元371 通过。如果在任何匹配规程的执行期间存在不匹配，则计算单元371失败并且可以 提取附加数据来确定该失败的原因。
在一些实施例中，远程命令可执行文件560可被安装在计算单元371的MOS 内。安装远程命令可执行文件560涉及建立次于串行通信信道的高速通信信道(例 如TCP信道)，该高速通信信道允许计算单元371与用户设备310之间的通信并 且当前正在运行引导框架软件。安装远程命令可执行文件560进一步涉及使用MOS 的功能来启动远程命令可执行文件560。启动远程命令可执行文件560因此创建监 听来自计算单元371的PXE请求的端口520(例如TCP端口)。在此点处，用户 设备310通过端口520来连接并且可以通过TCP网络连接在MOS上运行命令，这 允许在收集来自计算单元371的数据时进行更快的连接。此外，一旦被启动，远程 命令可执行文件560可用作计算设备371上的代理，该代理被装备成将新的可执行 文件(逻辑)注入到MOS上或者通过上传重复对计算单元371的确认的新的方案 文件和工具来更新MOS。在一个示例中，被注入到MOS中的新的可执行文件可 包括压力测试工具和/或性能收集工具。
过程流
现在参考图6，显示了示出根据本发明的一个实施例的用于发现和确认硬件清 单的总的方法600的流程图。尽管术语“步骤”和/或“框”可在此处用于暗示所采用 方法的不同元素，但除非而且仅当明确描述了各个步骤的顺序时，该术语不应被解 释为意味着此处公开的多个步骤之中或之间的任何特定顺序。初始地，硬件清单表 示机架，其中机架可包括网络设备(例如，TOR交换机和串行接入设备)和一组计 算单元(例如，插入到机架中的一组刀片)。该组刀片通常在串行接入设备和TOR 交换机之间互连。
初始地，图6的方法600涉及在用户设备(例如图3的参考标号310)与硬件 清单(例如图3的参考标号360)之间建立通信，如框610处所指示的。通常，硬 件清单包括经由网络通信信道(细虚线)和串行通信信道(粗虚线)互连的多个内 部设备(例如图3的计算单元371和372)。方法600可进一步涉及选择多个内部 设备中的至少一个内部设备以在其上进行发现过程，如框612处所指示的。
在各实施例中，选择硬件清单内部的设备之一包括以下步骤：监听来自预定 与所选设备相关联的预期串行端口的信号(见框614)；经由与预期串行端口耦合 的串行通信信道来接收第一网络标识符(见框616)；监听来自预定与所选设备相 关联的预期网络端口的信号(见框618)；以及经由与预期网络端口耦合的网络通 信信道来接收第二网络标识符(见框620)。
在从预期端口接收到信号之际，对照第二网络标识符来比较第一网络标识符 以便验证所选设备被恰当地互连。该步骤在框622处指示。在进行比较之际，对所 选设备的验证涉及在第一和第二网络标识符匹配时确认互连，如框624处所指示 的。否则，发起关于所选设备的一个或多个补救措施，如框626处所指示的。
转向图7，现在将描述示出根据本发明的各实施例的用于发现和确认硬件清单 的服务器内部的一个或多个组件的总体方法700的流程图。图7的方法700涉及发 起对本地地驻留在硬件清单内的服务器上的工具的执行的步骤，如框710处所指示 的。在一个实例中，该工具被配置成访问服务器的一个或多个内部组件(例如，见 图5的SKU检查工具510)。如框712处所指示的，该工具用于对内部组件执行 扫描以便验证服务器的配置。验证服务器配置的过程涉及以下步骤：发现现存于服 务器上的内部组件(见框714)；抽象出所发现的内部组件的属性(见框716)； 以及用所抽象的属性来更新硬件列表(见框718)。通常，硬件列表维护所发现的 内部组件的记录。
在构建硬件列表之际，访问硬件方案，如框720处所指示的。一般而言，硬 件方案展现用于确定服务器的配置是否可接受用于部署在数据中心内的准则。如框 722处所指示的，对照硬件列表的对应抽象出的属性(例如，图5的参考标号540) 来比较硬件方案的准则(例如，图5的参考标号550)。当抽象出的属性无法满足 准则时，如框724处所指示的，发出指示服务器的配置是非预期的通知。当抽象出 的属性满足准则时，如框726处所指示的，比较的结果被存储在用户设备内。
参考具体实施例描述了本发明的实施例，具体实施例在所有方面都旨在是说 明性的而非限制性的。不偏离本发明范围的情况下，各替换实施例对于本发明的各 实施例所属领域的技术人员将变得显而易见。
从前面的描述可以看出，本发明很好地适用于实现上文所阐述的所有目的和 目标，并且具有对于该系统和方法是显而易见且固有的其他优点。可理解的是，某 些特征和子组合是有用的，并且可以加以利用而无需参考其它特征和子组合。这由 权利要求所构想的，并在权利要求的范围内。