CN105518629B - 云部署基础结构确认引擎 - Google Patents

Abstract

本发明的各实施例提供一组确认器，这些确认器可以被用来确定安装是否在期望的参数内操作并符合任何要求。确认器可提供有例如软件应用程序或版本，并且可以在安装期间和/或安装之后被运行以测试应用操作。当由确认器检测到错误时，可以触发一组自我修复操作。这允许软件应用程序自动诊断并自动自我修复任何检测到的错误。

Description

云部署基础结构确认引擎

背景

随着数据中心设备的数量增多，云基础结构和服务的硬件和软件的部署变得越来越复杂化。当将跨许多物理和虚拟机安装和配置操作系统和软件组件时，数据中心操作员可能很难检测何时许多组件中的一者或多者发生故障、标识哪些组件已发生了故障并分析故障以确定合适的解决办法。

通常，现有的数据中心组件展示并不绑定在一起并且跨多个服务器或操作系统实例不好使的多个错误检测机制。结果，在当前配置中，由操作员负责以人工方式来使多个系统和/或设备上的错误日志和事件相关并对其进行解释以诊断故障。跨大量的数据中心设备和分布式服务标识时间依赖的或瞬时问题的源(诸如临时网络假信号、安全入侵、部署故障等等)可能特别困难。当数据中心服务提供商配置它们的云服务时，可花数天或数周才能成功地安装服务。

概述

提供概述是为了以精简的形式介绍将在以下详细描述中进一步描述的一些概念。本概述并不旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于限制所要求保护的主题的范围。

云部署基础结构确认引擎可通过自动化安装确认和故障诊断来使数据中心或云服务被快速地安装。另外，确认引擎可用于通过故意的错误注入并观察故障转移操作来验证灾难恢复和备份操作。

云部署基础结构确认引擎向作者提供通用可插入、灵活并且可扩展的框架，并执行状态确认器、诊断操作以及补救动作。云部署基础结构确认器消耗来自安装日志文件的数据以及安装、配置和操作期间的实时事件。确认器查询组件及相关的事件以确定当前执行状态、连接性、错误状态、系统入侵或符合性问题。如果确认器不满足预定的条件，则可以自动地调用诊断操作以诊断该系统并潜在地使该系统自我修复或向操作员提供解决的指导。

本发明的各实施例提供一组确认器，这些确认器可以被用来确定安装是否在期望的参数内操作并符合任何要求。可以给确认器提供例如软件应用程序或版本，并且确认器可以在安装期间和/或安装之后运行以测试应用操作。当确认器检测到错误时，可以触发一组自我修复操作。这可使软件应用程序自动诊断并自动自我修复任何检测到的错误。

确认器消耗将服务器与角色链接并标识特定确认器想要确认哪个角色的图。例如，可以将SQL角色映射到物理机，并且确认器可以确认对跨越多个服务器节点的高度可用的SQL集群的成功配置。

单一角色可以要求多个确认器。使用清单来描述这些确认器之间的依赖关系。当确认单一角色时，测试管理器知道要调用哪些确认器以及它们之间存在什么依赖关系(例如，如果确认器A成功，则只调用确认器B，而确认器C、D和E可以全部都并行运行，且它们之间没有交叉依赖关系)。角色清单还描述需要经由日志聚集器聚集哪些日志。

当确认器返回错误或警告时，测试管理器可以具有适当的将诊断器与特定确认器相关联的依赖关系。诊断器可以解析与正被确认的服务器角色相关联的经聚集的日志文件(例如，SQL安装日志文件、集群中的各服务器节点的事件日志等)。诊断器可以搜索已知的设置错误字符串或特定的事件，以及使用事件日志中的时间戳来确定各错误之间的依赖关系(例如，对节点X的设置失败触发在节点Y和Z上引起的跨集群事件)。

在某些情况下，诊断器可能能够调用解决器(例如，通过重试特定操作的自我修复、强制更新特定网络设置等等)，此后重新调用原始确认器将以确认所提供的解决方案实际上解决了该问题。在自我修复不可能的情况下，诊断器可以提供指向在线帮助文档、对特定错误代码的解决方案或类似于FAQ解决方案的指针(例如，“在发生X的情况下，尝试进行Y”)。

附图简述

为进一步阐明本发明的各实施例的上述及其他优点和特征，将参考附图，呈现对本发明的各实施例的更具体的描述。应该理解，这些附图只描述了本发明的典型的实施例，因此，不应该被视为限制本发明的范围。将通过使用附图并利用附加特征和细节来描述和解释本发明，在附图中：

图1是示出根据一个实施例的云部署基础结构确认引擎过程的流程图。

图2是支持云部署基础结构确认框架的云管理框架的框图。

图3是示出一个实施例中的用于确认监视角色的确认器的分层结构的流程图。

图4是根据一个实施例的云部署基础结构确认引擎的内部组件组织的框图。

图5示出根据一个实施例的云部署基础结构确认引擎中的各层之间的控制流和通信。

详细描述

提供插件确认器、诊断器以及解决器的可扩展框架可以跨数据中心设备的多个物理和虚拟实例(例如，服务器硬件、网络交换机等等)和操作系统运行，以帮助查找、诊断和解决与云基础结构和服务的安装、配置以及操作有关的问题。

例如，确认器可以与产品或软件应用一起被发布。确认器确保应用正确地运行，并在检测到故障时警告操作员。确认器可以由应用自动地运行或可以由操作员触发。确认器可被用来在特定时间验证操作，或它们可以在后台运行，偶尔“苏醒过来”以测试应用。在检测到故障之际，确认器可以触发额外的确认器以标识故障的源和/或范围。确认器可以试图通过重新配置或重新安装代码来自我修复该故障。替换地，确认器可以向操作员提供智能指令，诸如提供要执行以修复问题的步骤列表或标识描述问题和潜在的解决方案的额外的信息源(例如，网页、文本文件、FAQ、安装文档等等)。

云部署基础结构确认引擎是高度分布式和集成的，以提供拓扑知晓的跨系统确认(即，跨不同的服务器、虚拟机和机架)、虚拟实例及其他数据中心设备。通过使用自动化超时和重试，云部署基础结构确认引擎能够运行每一个体确认器，直到完成(即，成功或失败)被报告。

云部署基础结构确认引擎允许分层执行以管理组件之间的依赖关系和多个独立代码路径的并行执行。云部署基础结构确认引擎消耗实时事件，并基于多个输入来修改其行为。

在检测到故障之际，云部署基础结构确认引擎启用对配置的自我修复，例如通过触发解决器或动态网络重新配置或通过向操作员提供指令和信息来启用对配置的自我修复。

云部署基础结构确认引擎可以使用前提条件和后续条件与期望的状态配置集成，以确保安装的成功完成。另外，云部署基础结构确认引擎支持事件(例如，错误)注入，以执行完全配置的解决方案的恢复。

可以以XML脚本、WindowsVisualC#，或任何.NET支持的语言来编写确认器、诊断器及解决器。确认器可以是标识可用来确认物理机或虚拟机、服务器或设备上的角色或软件应用的操作的操作或测试的脚本、软件应用或代码。诊断器可以是标识可以被用来在确认器指示故障时标识问题的源的诊断、操作或测试的脚本、软件应用或代码。解决器可以是标识诊断器所标识的问题的潜在解决方案的脚本、软件应用或代码。

图1是示出了根据一个实施例的云部署基础结构确认引擎过程的流程图。在步骤101中，调用角色确认过程。在步骤102中，分析角色确认的成功或失败。如果确认通过了步骤102，则数据中心操作可以在步骤103中继续，诸如部署另外的服务并配置额外的机器。如果确认过程在步骤102中失败，则云部署基础结构确认引擎在步骤104中发起角色诊断以分析角色配置和部署。

在步骤105中，云部署基础结构确认引擎标识正在阻止角色确认的(诸)故障。在步骤106中，云部署基础结构确认引擎确定它是否具有针对在步骤105中标识出的故障的解决器可用。如果有解决器可用，则云部署基础结构确认引擎在步骤107中调用该解决器。当没有解决器可用时，云部署基础结构确认引擎可以在步骤108中向操作员提供故障通知及其他信息，诸如用户补救指令。在解决器应用了指定的修正之后，该过程返回到步骤101，在步骤101，确认器再次运行以确认角色。

图2是具有云部署基础结构确认框架202的云管理框架201的框图。云管理框架201构成管理数据中心中的服务器、机器以及结构的软件。云部署基础结构确认框架202基于一组可插入的组件，包括命令(cmdlet)接口层203、执行引擎204、日志综合器205以及储存库层206。云部署基础结构确认框架202通过cmdlet层203与云管理框架201的外部组件对接。

云管理框架201调用cmdlet层203中的命令，这是进入确认框架202的入口点。cmdlet接口层203将确认器和诊断提供给消费者，诸如数据中心操作员或持久者。cmdlet消耗描述与特定服务器角色相关联的服务器的服务器图以及管理访问的凭证，并输出包括错误/警告状态和日志文件列表的测试状态。

cmdlet与能够查询储存库205中的一组确认器和诊断器的执行引擎204进行对话。执行引擎204创建确认器之间的依赖关系图形，并将该图形传递到调度各个体确认器的测试管理器。测试管理器使用超时，并在各确认器没有在所分配的时间内执行的情况下潜在地重新调度这些确认器。cmdlet执行器管理用于执行包括确认器和诊断或由确认器和诊断调用的cmdlet脚本的运行空间池。

确认器和诊断器可以是自描述的并与数据中心中的特定角色相关联的脚本的列表、组或其他集合。例如，一组确认器可以与数据中心中的系统中心操作管理器(SCOM)角色相关联。该组确认器与检查成功或失败和诊断并修复SCOM角色的任何故障相关。确认器可在角色被创建时被加载，随后可在后台操作以确保角色被适当地安装并正确地操作。

确认器或诊断器可以查找特定错误代码或其他警告，以标识与特定角色有关的潜在问题。确认器和诊断器可以查找错误代码的特定序列，然后将这样的序列与特定的底层故障相关联。故障可能在相同或不同的节点或设备(诸如不同的物理机、虚拟机、交换机等等)上发生。

储存库205中的确认器和诊断器可以具有分层依赖关系。执行引擎204可以查询确认器和诊断器，并构建确认器和诊断器之间的依赖关系树。执行引擎204也可以映射与确认器和诊断器相关联的硬件目标。确认引擎可以将数据中心中的硬件映射到特定角色，然后标识需要对那些角色中的每一个运行的确认器。

操作员可以使用cmdlet来请求对特定角色的确认。例如，可以使用监视角色的cmdlet来确认该监视角色是否正在适当地操作。确认引擎将标识哪一个远程主机206或硬件目标正在运行该监视角色，并将对该硬件目标206执行合适的监视角色确认器。

该确认器导致日志被编写，包括例如由该确认器本身编写的日志以及来自可能与该确认器相关的其他源的日志。当确认器正在测试一个组件时，该组件可以使其自己的日志具有潜在相关的信息。作为其清单的一部分，作为确认器执行的一部分，确认器可以告诉确认框架收集这些日志。日志聚集器207收集由确认器编写的或由确认器标识的日志。储存库205负责序列化确认操作的结果，并被日志聚集器207用来查找将把日志从哪里复制到哪里以供诊断器使用。

日志聚集器207层复制来自远程服务器的日志，使得诊断器可以解析这些日志以得到错误条件，并可以解释不同的机器上的错误之间的依赖关系(例如，在一个服务器上触发但是影响其他服务器的级联错误的情况下)。日志可用于实现深度诊断和事后分析。例如，组件制造商可以分析错误代码、字符串、字符串组合等等以标识问题的源。

图3是示出了一个实施例中的用于确认监视角色的确认器分层结构的流程图。在确认监视角色时，首先运行确认器301以检查连接性。连接性确认器301测试确认引擎是否可以连接到正在运行监视角色的目标。如果检查连接性确认器301失败，则可以触发额外的确认器。例如，确认器302确定监视服务是否正在运行。额外的确认器303也可以运行，并确定依赖服务是否正在运行。在第一确认器301失败之后，可以按顺序或并行地触发任意数量的依赖确认器302-1到302-N以进一步向下挖掘连接问题并标识连接性故障的源。确认器302-1到302-N可以在多个不同的设备、虚拟机以及服务器上运行例如以执行额外的检查。

如果确认器302通过，则可以触发额外的确认器303、304来运行。一旦依赖确认器之一失败，就可以标识出总连接性问题的源。此时，已经标识出至少一个问题，并可触发与失败的确认器相关联的诊断器。基于这些确认器的结果(例如，确认器302-1和302-N通过，但是确认器303失败)，诊断器可以标识出问题的潜在源。管理框架可以试图自动修复该问题，或者诊断器可以为操作员提供解决该问题的信息。

依赖关系的分层结构可允许这些确认器从粗略检查开始并继续进行越来越细粒度的检查以查找出该问题的源。

确认器包括相关联的组件的期望状态的清单。执行引擎执行该清单，直到它遇到错误。然后，执行引擎可以标识清单工作流中触发该错误的步骤。然后，该错误可以触发自我修复动作，其可以是自动的或手动的。可以描述在跨越多个确认器、诊断器和/或解决器的单一清单内的各确认器之间的依赖关系。

图4是根据一个实施例的云部署基础结构确认引擎400的内部组件组织的框图。云部署基础结构确认引擎400包括cmdlet层401、执行层402以及储存库403。在一个实施例中，云部署基础结构确认引擎400用于确认远程主机404上的各组件，远程主机404可以是服务器、虚拟机、交换机或其他设备。如果检测到故障，则云部署基础结构确认引擎400可以试图诊断该故障的源并在可能的情况下修复该问题。

cmdlet层401包括cmdlet接口405、脚本储存库406以及XML解析器407。cmdlet层401的主要职责是提供接口，以便确认引擎400可以被操作员或云管理框架调用。cmdlet接口405被适配成接收激活特定角色的确认器的命令。在一个实施例中，cmdlet可以是针对WindowsVisualC#或任何.NET支持的语言来写的。

每一确认器都以特定格式被编写为XML清单，该XML清单标识该确认器所要求的参数并在合适的情况下指定确认器的分层结构。在XML清单中指定一个或多个确认功能。XML清单还标识要收集的日志。XML清单被存储在脚本储存库406中。诊断器和自我修复文件也可以被编写为XML清单，并被存储在脚本储存库406中。

XML解析器407理解如何读取储存库406中存储的XML脚本，并将从脚本中提取的任何必需的信息提供到执行层402中的执行引擎408。

执行层402包括测试执行引擎408、cmdlet执行器409以及日志聚集器410。执行引擎408中的依赖关系图生成器411从XML解析器407接收信息，并生成确认器依赖关系的图，该图表示确认器如何彼此相关。测试管理器412维护确认器之间的依赖关系映射，并保持跟踪可在脚本储存库406中的哪里查找到每一个确认器的脚本。测试管理器还跟踪哪些确认器与特定角色相关联，以便对于每一角色仅运行相关的确认器。测试调度器413控制对于一个特定角色，将在哪里运行每一确认器，诸如在数据中心管理服务器上或在远程主机上运行该确认器。测试调度器413还跟踪要被确认的每一角色正在哪里操作，这可能在多个物理机和/或虚拟机上。

cmdlet执行器409包括运行空间管理器414和测试执行器415。cmdlet执行器409负责实际地执行确认器。测试管理器412和测试调度器413使用cmdlet执行器409来在目标设备上运行确认测试。运行空间管理器414管理到远程主机404的连接，并为测试执行器415提供运行空间，以在远程主机上运行特定确认器。cmdlet执行器409处理诸如确认器故障之类的错误，并可允许信息在确认器和诊断器之间流动。这会向诊断器提供状态信息(诸如哪些故障已经被观察到、哪些确认器已经被运行、什么组件正在运行等等)，使得诊断器可以标识故障的源。

确认器不必一定立即运行或只运行一次。相反，确认器可以在确认服务之前等待服务开始。另外，如果确认器无法确认服务，则它可以重试多次，直到它超时。这允许执行层402在服务开始之前调用确认器。然后，确认器将等待服务开始，并将在那时试图确认。例如，确认器可以周期性地“苏醒”，并在服务可用的情况下运行其检查，或者在服务还没有运行的情况下，再“休眠”一段时间。确认器将继续试图确认服务，直到超时时段期满，此时确认器将关闭。然后，在超时时段之后，测试执行器415可重新启动确认器。

一旦确认测试已经在目标设备上运行，执行层402就使用日志聚集器410来收集日志。日志管理器416跟踪要为特定确认器收集哪些日志，以及要将日志存储在哪里。日志管理器416为不同类型的日志使用特定的收集器。例如，ETW日志收集器417可被用来使用Windows事件跟踪(ETW)机制来收集Microsoft的日志，以跟踪和记录软件事件。使用文本日志收集器418来收集文本文件，诸如例如纯文本日志。可以为由确认器使用的专用的或其他日志类型创建额外的日志收集器。

运行空间管理器414和日志聚集器410与远程主机404通信以运行确认器测试或者提取日志。云部署基础结构引擎可以使用标识符或其他控制来限制每一确认器可以在哪里运行。这将防止确认器在基础结构的未经批准的区域运行，诸如将确认器限制在因角色而异的区域。

储存库层403是通过从远程主机404和测试目标检索测试结果并存储这些测试结果来辅助执行层402的存储层。结果串行化器419处理这些测试结果，并以合适的格式保存这些测试结果。例如，结果串行化器419从确认器收集成功和失败信息，并以持久格式保存可被操作员、设备制造商、其他确认器和诊断器等等存储并访问的的信息。日志位置管理器420提供寻址能力，使得经序列化的数据可以被存储并从中心位置检索。日志位置管理器420还可以进一步跟踪哪些日志来自哪个远程主机和/或来自哪个确认器。

图5示出了根据一实施例的云部署基础结构确认引擎中的各层之间的控制流和通信。云部署基础结构确认引擎正在管理框架主机501上运行，并确认远程主机502上的服务。确认框架主机501和远程主机502可以是例如相同或不同的物理机上的虚拟机。该流程从请求确认框架确认远程主机502上的角色开始。虽然在图5中示出了单一远程主机502，但是可以理解可以并行地确认任意数量的远程主机。

XML解析器标识角色的确认器，并从角色清单506中检索这些确认器。XML解析器标识共用参数503以及清单所需的因角色而异的参数504。XML解析器采用这些输入来解析清单505。XML解析器计算507需要运行的测试以及需要被启用的日志。cmdlet层调用执行层，并请求它启用508远程主机502上的合适日志。

在给定清单中标识出的测试的情况下，测试执行引擎确定这些测试之间是否存在任何依赖关系，并生成依赖关系图509。还从角色清单中标识510重试的次数。向测试调度器511提供确认器信息、依赖关系图以及测试重试信息，测试调度器511与测试管理器512协调以在远程主机502上执行该确认器。

在远程主机502上，日志被启用，错误被存储到日志。当测试完成时，测试管理器停止日志收集514并调用清理515。管理器获取日志513，并且来自这些日志的数据被串行化516。然后，将该数据作为测试结果517输出。可以由测试管理器收集输出，和/或将输出存储到储存库。另外，可以向操作员输出文本，诸如对故障的描述、要采用来解决问题的步骤、或对有关故障的信息的外部源的引用(例如，网站、FAQ，等等)。

可以在不同的节点或机器上实现图1-5的示例。本发明可用众多其他通用或专用计算系统环境或配置来操作。适用于本发明的公知计算系统、环境、和/或配置的示例包括但不限于：个人计算机、服务器计算机、手持式或膝上型设备、平板设备、多处理器系统、基于微处理器的系统、机顶盒、可编程消费电子产品、网络PC、微型计算机、大型计算机、包括任何以上系统或设备的分布式计算环境等等。

本发明可在诸如程序模块等由计算机执行的计算机可执行指令的通用上下文中描述。一般而言，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等。本发明也可被实践在分布式计算环境中，分布式计算环境中任务是由通过通信网络链接的远程处理设备执行的。在分布式计算环境中，程序模块可以位于包括存储器存储设备在内的本地和/或远程计算机存储介质中。

用于实现本发明各方面的示例性系统包括计算机形式的通用计算设备。组件可包括但不限于各种硬件组件(诸如处理单元)、数据存储(诸如系统存储器)、以及将包括数据存储在内的各种系统组件耦合到处理单元的系统总线。系统总线可以是几种类型的总线结构中的任何一种，包括存储器总线或存储器控制器、外围总线、以及使用各种总线体系结构中的任一种的局部总线。作为示例而非限制，这样的架构包括工业标准架构(ISA)总线、微通道架构(MCA)总线、增强型ISA(EISA)总线、视频电子技术标准协会(VESA)局部总线和外围部件互连(PCI)总线(也称为夹层(Mezzanine)总线)。

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

数据存储或系统存储器包括诸如只读存储器(ROM)和随机存取存储器(RAM)之类的易失性和/或非易失性存储器形式的计算机存储介质。基本输入/输出系统(BIOS)通常存储在ROM中，其包含了诸如在启动过程中帮助在计算机内的元件之间传输信息的基本例程。RAM通常包含处理单元可立即访问和/或当前正在操作的数据和/或程序模块。作为示例而非限制性，数据存储保存操作系统、应用程序、其他程序模块、和程序数据。

数据存储还可以包括其它可移动/不可移动、易失性/非易失性计算机存储介质。仅作为示例，数据存储可以是对不可移动、非易失性磁介质进行读写的硬盘驱动器，对可移动、非易失性磁盘进行读写的磁盘驱动器，以及对诸如CD ROM或其它光学介质等可移动、非易失性光盘进行读写的光盘驱动器。可在示例性操作环境中使用的其它可移动/不可移动、易失性/非易失性计算机存储介质包括但不限于，磁带盒、闪存卡、数字多功能盘、数字录像带、固态RAM、固态ROM等。上文所描述的驱动器以及它们的关联的计算机存储介质，为计算机提供对计算机可读取的指令、数据结构、程序模块及其他数据的存储。

用户可通过用户接口或诸如平板、电子数字化仪、话筒、键盘和/或定点设备(通常指的是鼠标、跟踪球或触摸垫)等其它输入设备输入命令和信息。其他输入设备可以包括操纵杆、游戏垫、圆盘式卫星天线、扫描仪等等。另外，语音输入、使用手或手指的手势输入、或其它自然用户界面(NUI)也可与适当的输入设备(诸如话筒、相机、平板、触摸垫、手套、或其它传感器)一起使用。这些以及其它输入设备通常通过耦合到系统总线的用户输入接口连接到处理单元，但也可通过诸如并行端口、游戏端口或通用串行总线(USB)之类的其它接口和总线结构来连接。监视器或其他类型的显示设备也通过诸如视频接口之类的接口连接至系统总线。监视器也可以与触摸屏面板等集成。注意到监视器和/或触摸屏面板可以在物理上耦合至其中容纳计算设备的外壳，诸如在平板型个人计算机中。此外，诸如计算设备等计算机还可以包括其他外围输出设备，诸如扬声器和打印机，它们可以通过输出外围接口等连接。

计算机可使用至一个或多个远程设备(诸如远程计算机)的逻辑连接在网络化或云计算环境中操作。远程计算机可以是个人计算机、服务器、路由器、网络PC、对等设备或其它常见的网络节点，并且一般包括上面关于计算机所述的许多或全部元件。所述逻辑连接包括一个或多个局域网(LAN)和一个或多个广域网(WAN)，但是，也可以包括其他网络。此类联网环境在办公室、企业范围的计算机网络、内联网和因特网中是常见的。

当用于网络化或云计算环境中时，计算机可通过网络接口或适配器连接到公共或私有网络。在一些实施例中，使用调制解调器或用于在网络上建立通信的其它装置。可以是内置或外置的调制解调器可经由网络接口或其它适当的机制连接至系统总线。诸如包括接口和天线的无线联网组件可通过诸如接入点或对等计算机之类的合适的设备耦合到网络。在网络化环境中，相对于计算机所描绘的程序模块或其部分可被存储在远程存储器存储设备中。可以理解，所示的网络连接是示例性的，也可以使用在计算机之间建立通信链路的其他手段。

尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于上述具体特征或动作。更确切而言，上述具体特征和动作是作为实现权利要求的示例形式公开的。

Claims (10)

1.在包括一个或多个处理器和系统存储器的计算设备处，一种用于确认所述计算设备上安装的服务的方法，所述方法包括：

接收确认安装的角色的请求；

检索针对所述角色的确认器清单，所述确认器清单包括所述角色的多个确认器；

标识所述确认器中的两者或更多者之间的依赖关系；

按由所述依赖关系所指定的次序执行在所述确认器清单中指定的一个或多个操作；

检索与所述角色相关联的诊断器；以及

执行所述诊断器以标识安装的角色故障的源。

2.如权利要求1所述的方法，其特征在于，进一步包括：

标识所述安装的角色故障的所述源；

检索与所述诊断器相关联的解决器；以及

执行所述解决器。

3.如权利要求2所述的方法，其特征在于，进一步包括：

执行在所述确认器清单中指定的所述一个或多个操作，以确定故障是否被所述解决器修正。

4.如权利要求1所述的方法，其特征在于，进一步包括：

标识所述安装的角色故障的所述源；以及

向操作员提供故障通知。

5.如权利要求4所述的方法，其特征在于，所述故障通知包括标识对所述安装的角色故障的潜在修正的操作员指令。

6.如权利要求1所述的方法，其特征在于，进一步包括：

标识所述确认器中的每一者的重试次数。

7.如权利要求1所述的方法，其特征在于，进一步包括：

建立运行空间以用于执行所述确认器清单中指定的所述一个或多个操作。

8.如权利要求1所述的方法，其特征在于，进一步包括：

标识所述确认器清单中指定的一个或多个日志；以及

在执行所述确认器清单中指定的所述一个或多个操作之后，从所述一个或多个日志中收集条目。

9.一种用于确认一个或多个主机上的角色的系统，所述系统包括：

用于接收确认安装在所述一个或多个主机上的角色的请求的装置；

用于检索针对所述角色的确认器清单的装置，所述确认器清单包括所述角色的多个确认器；

用于标识所述确认器中的两者或更多者之间的依赖关系的装置；

用于按由所述依赖关系所指定的次序执行所述确认器的装置；

用于检索与所述确认器相关联的诊断器的装置；以及

用于执行所述诊断器以标识角色故障的源的装置。

10.如权利要求9所述的系统，其特征在于，所述系统进一步包括：

用于标识所述角色故障的所述源的装置；

用于检索与所述诊断器相关联的解决器的装置；以及

用于执行所述解决器的装置。