专利名称：在软件部署中进行故障管理的方法和系统的制作方法
技术领域：
本发明总体上涉及计算机系统管理，并且具体地涉及管理软件部署中的故障的方法和系统。
背景技术：
随着现代计算机系统复杂性的增加，需要改善对软件部署的管理。软件部署管理涉及按照特定顺序的多个管理任务，直到完成软件安装为止。然而，在部署软件的过程中， 可能发生错误或故障。特别是因为发生在执行给定任务期间的错误可能影响其他任务的执行，因此监控这种错误是重要的挑战。在向目标机器部署操作系统期间进行故障管理更具挑战，因为目标机器在部署操作系统之前具有非常有限的能力。US 2008/0077935提供了如下解决方案，该解决方案用于在执行系统管理流时，使用工作流引擎与该工作流引擎所调用的任务之间的标准协议来处理可解决的和不可解决的错误。然而，这一方法是静态的，并且需要来自管理员的人工干预来补救故障。进一步， 该方法不允许处理目标机器上的远程控制的软件安装中的错误。因此，该方法不适于在操作系统部署期间或在复杂的服务器级系统中自动地管理故障。
发明内容
为了解决这些和其他问题，提供了根据所附独立权利要求1的、处理目标数字设备上的远程控制的软件安装中的错误的方法，以及分别根据所附权利要求11、12和13的计算机程序、计算机可读介质以及系统。在所附从属权利要求中限定了优选实施方式。本发明相应地提供了用于特别是在复杂的/差别化的服务器级环境中处理远程操作系统(OS)部署中的错误的有效的解决方案。本发明进一步提供并利用了向服务器发送的清单(inventory)信息(硬件细节、 BIOS等级、DASD-直接存取存储设备接口细节)，其有助于在服务器侧识别正确的补救措施。本发明的另一优点是对可能发生在所考虑的环境中的挂起情形进行补救。在计算系统(诸如个人计算机或服务器)中，在单个计算机程序或整个系统未能对用户输入(例如键盘和鼠标输入、或者利用控制设备输入键入的其他命令)进行响应时，发生挂起或冻结。根据本发明的实施方式，可以通过在网卡中利用带外(out-of-boimd)通信、强制远程重新引导，来解决由服务器检测到的挂起状况。然后，这使得可以自动恢复操作系统(OS) 部署流。本发明还使得能够用在将要在所述预OS环境中运行的BIOS和1/0驱动器接口上的测试套件来仿真真实的行为。与限于静态查看的现有技术文献不同，本发明的进一步优点是处理如下场景在操作系统(OS)设置场景期间，目标故障被渐进发现，并且需要响应于检测到引导故障并根据硬件清单和症状目录，例如利用自动的BIOS刷新或其他的固件更新或重新配置，来动态地解决该目标故障。在研究附图和详细描述后，本发明的进一步优点对于本领域技术人员将变得清楚。旨在将任何附加的优点都包含在其中。
现在将参考附图、通过示例的方式描述本发明的实施方式，其中相似的参考标号表示类似的元件，并且其中图1示意性地图示了操作系统部署(OSD)内核与执行I/O操作的I/O驱动器之间的交互；图2示意性地示出了用于实现操作系统部署的示例性架构；图3示出了根据本发明特定实施方式的故障管理系统；图4A和图4B表示在OS部署的硬件发现阶段期间捕获的示例性清单数据；图5示出了用于OS部署的流程图；以及图6示出了用于OS部署期间的故障管理的流程图。
具体实施例方式根据本发明的特定实施方式，提供了一种用于自动地管理对目标机器的操作系统部署期间的故障的方法。目标机器可以是任何类型的计算机机器或系统，无论是物理的还是虚拟的(例如工作站、移动/手持设备等)。本发明可以应用于对具有客户端库的增强型浏览器、或管理程序、或虚拟机、或其组合的按需的或实时的安装中的故障管理。通常紧接在引导之后从系统存储器加载和执行操作系统。预OS引导用于在加载和执行操作系统之前引导计算机系统。在预OS环境期间，计算机系统能力是有限的，这提供有限的资源来监控OS部署故障。为便于理解本发明，下面是在特定优选实施方式的详细描述中使用的特定表达的定义巡表示操作系统。OSD表示操作系统部署。操作系统(OS)表示管理计算设备的硬件和软件的软件，该计算设备诸如智能电话、计算机、手持计算机、台式计算机、膝上型计算机、超级计算机、视频游戏控制台、机器人、如洗碗机或洗衣机之类的家用电器、便携式媒体播放器等。操作系统向应用程序和用户提供多个服务。应用通过应用编程接口(API)或系统调用来访问这些服务。常见的当代操作系统包括AIX或Linux。NTFS是Microsoft Windows系统的标准文件系统。10(或I/O)代表“输入/输出”，并且表示信息处理系统的不同的功能性单元用来彼此通信的接口集合。_代表基本输入/输出系统，其是限定引导固件的事实上的标准。BIOS的功能是识别、测试和初始化系统设备，诸如视频显卡、硬盘、软盘、以及其他硬件。BIOS将机器准备为已知状态，从而使得存储在兼容介质上的软件能够被加载、执行对计算机给出控制。大多数时候，BIOS程序存储在芯片上。某些组件携带其自身的BIOS扩展R0M，该ROM提供附加的功能性。操作系统和软件取代这些基本的功能性并向应用提供替代软件接口。当存储在可重写存储器中时，刷新BIOS表示用BIOS映像重写BIOS内容的处理。将BIOS更新到较新版本以修复特定缺陷(bug)，用以支持较新的硬件，或者用以修复受损的BIOS。如果没有正确地进行操作，则其可能致使系统不可操作。■(或EFI或UEFI)是“(统一)可扩展固件接口”的缩写，其是定义操作系统与平台固件之间的软件接口的规范。EFI是计算机中存在的BIOS固件接口的大得多的、更复杂的、类OS的替代。EFI规范由统一 EFI论坛管理。PXE是指“预引导执行环境”并且又称为预执行环境或“pixie”。其表示用以使用独立于可用数据存储设备(诸如硬盘)或所安装的操作系统的网络接口来引导计算机(客户端或服务器)的环境。PXE利用若干网络协议，如网际协议(IP)、用户数据报协议(UDP)、 动态主机配置协议(DHCP)以及小文件传输协议(TFTP)，并且利用多个概念，如全球唯一标识符(⑶ID)、通用唯一标识符(UUID)以及通用网络设备接口。其利用一组预定应用编程接口(API)来扩展PXE客户端(有待经由PXE引导装入(bootstrap)的计算机)的固件。 术语PXE客户端仅仅是指机器在PXE引导处理中所承担的角色。PXE客户端可以是配备有 PXE引导代码的服务器、台式机、膝上型计算机或者任何其他机器。WINPE表示“Windows预安装环境”，其是用于部署工作站和服务器的某些Windows 系统的轻量级版本。其是在Windows安装阶段期间MS-DOS的替代，并且能够经由PXE或存储设备来引导。对于Windows的部署，可以使用微软公司的Windows ΡΕ。对于Linux的部署，可以使用IBM的MCP Linux环境。设置管理器是指设置管理器系统,诸如TPMfOSD (用于操作系统部署的Tivoli设置管理器)。Tivoli是IBM公司的商标。尽管描述利用TPMfOSD提供了示例，但应当理解， 本发明的实施方式不限于这一特定环境。用于远程地管理裸机目标(例如个人计算机)上的OS安装和部署的系统通常以无人管理的方式与远程机器交互(通过其BIOS)，从而加载预引导微型OS环境(例如网络之上的PXE)，转移和准备可安装或可恢复的映像，然后作用于它们。结果可能是克隆的机器或者模板机器的特定化。在预引导阶段期间的所有情况下，利用在目标系统BIOS中可用的特征和接口而发生交互。这例如可以使用用于OS部署的Tivoli设置管理器(TPMfOSD)来完成。这一系统显露特征以利用PXE协议集在裸机机器上安装OS映像。操作者一般地将硬件配置任务绑定到OS映像的部署。这些配置任务通常在实际部署OS映像之前执行以便正确地配置机器固件；这种任务的示例包括刷新/设置BIOS或RAID盘配置。TPMfOSD中的硬件配置的典型场景包括以下步骤1.管理员在服务器上输入特定硬件工具包；2.操作者配置选择目标机器的任务；3.在发布硬件配置任务后，将与所发现的硬件目标和任务配置设置匹配的工具包下载到目标机器上。然后在目标机器上执行以下附加步骤-将该环境加载在作为RAM盘的存储器中；RAM盘是仿佛该存储器是盘驱动(辅助存储设备)那样对待计算机的软件的一块RAM(主存储设备或易失性存储器)。其有时称为虚拟RAM驱动或软件RAM驱动，以将其作为“主存储设备”的用法与使用包含RAM的分立硬件的“硬件RAM驱动”(诸如固态驱动)区分开。-基于经由web接口作出的选择，将任何附加的二进制或配置文件添加到RAM盘；-计算机引导RAM盘；-执行硬件配置任务；-RAM盘重新引导；-如果进行了任何选择，则恢复进行部署序列，但硬件配置还可以作为单独任务而运行。对于“台式机”和“膝上型计算机”环境，对于OS部署而言待管理的特征是稳定的， 这是因为它们在这一等级的系统中表现为高标准化级别。特征是从BIOS以及可能地从某些内核IO驱动器(例如NTFS)实现的。当试图解决服务器级系统时，由于BIOS中的高差别化和低级别软件组件而出现了若干问题。例如，可能存在某些不稳定性和性能问题。管理这种交互时的故障将通过“挂起”或连续的重新引导来显示(manifest)其本身。图1图示了 OSD内核与执行I/O操作所需的I/O驱动器之间的交互。如图所示，BIOS和预引导环境可操作地交互。为执行I/O操作，操作系统部署 (OSD)内核100进行对BI0S/EUFI 110或对内部NTFS驱动器101的调用。备选地，NTFS驱动器101可以调用BI0S/EUFI110，BI0S/EUFI 110可以调用I/O驱动器120。I/O驱动器 120实现实际I/O操作。当前，通过手动地检测和修复发生故障的BIOS以及通过刷新目标机器上的BIOS 更新，来解决“挂起”或连续重新引导问题。这一非自动处理缺乏效率并且可能极其繁琐。 其可能需要特定版本的BIOS。不可能将这种任务作为标准软件依赖关系来管理同一 BIOS 版本能够在给定的硬件环境上工作，而不能在另一硬件环境上工作。本发明改善了用于管理OS部署期间的故障的方法和系统的情形，特别是对于复杂的和差别化的服务器级系统而言。即使本发明具有针对复杂的和差别化的服务器级系统的特定优点，其也不限于这种系统。来自硬件/固件准备和OS安装步骤的多数常见故障通过异常、利用服务器侧症状目录来处理并且通过触发最适当的设置动作(例如BIOS刷新、 其他固件更新和重新配置)来自动地补救。图2图示了根据本发明某些实施方式的用于将操作系统部署到目标机器的示例性部署架构20。部署架构20包括-参考计算机机器200，用于捕获要在操作系统部署处理期间使用的操作系统映像；-操作部署服务器210，用作用于操作系统部署的设置管理器。提供服务器210以捕获操作系统映像和在目标计算机机器上部署这些操作系统映像，以及还使用与所考虑的目标机器相关的清单信息以及与检测到的故障相关的信息来管理OS部署期间的故障。-目标机器220和221，在其上，服务器210以联机模式(即通过与目标机器220 和221的直接网络连接)执行操作系统部署操作；-脱机存储设备230，诸如CD或DVD或硬驱动或适于存储的任何其他设备，在其上，服务器210以脱机模式存储其先前已经针对部署目标计算机系统而克隆和准备的操作系统映像；以及-目标计算机机器231，在其上，服务器210以脱机模式执行操作系统部署操作，即不需要或要求来自服务器210的直接网络连接。图2中所表示的系统组件在操作系统克隆和部署处理期间进行协作。操作系统和软件先前已经安装到参考计算机机器200，其形成参考操作系统映像。参考操作系统映像将是由OSD服务器210执行的操作系统部署操作的对象。OSD服务器210从参考计算机机器 200创建克隆参考操作系统映像，并将这一克隆的映像存储在其本地存储设备中，从而使得其准备好在操作系统部署操作期间使用。备选地，服务器210还将这一克隆的映像存储在脱机存储设备230 (诸如DVD或CD)上，从而使得其准备好在操作系统部署操作期间使用。OSD服务器210可以支持两种类型的操作系统部署。第一 OS部署类型以联机模式执行并使用服务器210与目标机器220或221之间的直接网络连接。在这一联机模式中， OSD服务器计算机210在目标机器220或221上直接部署克隆的参考操作系统映像。第二 OS部署类型以脱机模式发生，因为在服务器210与目标机器231之间不需要直接连接。在这一第二 OS部署中，操作者或管理员使用存储设备230(克隆的操作系统映像存储在其上)， 并且将操作系统手动地部署在目标机器231上。图3图示了根据本发明某些实施方式的用于处理OS部署期间的故障的系统。任何时候，用信号通知OSD服务器210所实现的用以向目标机器31部署OS的OS部署过程的进行状况，并且OSD服务器210适于接收与OS部署过程的每个阶段的结果相关的通知(成功通知、故障通知或者其他类型的指示符)。根据本发明的某些实施方式，OS部署服务器210配备有错误处理组件332。错误处理组件332使用来自清单数据存储库333的、源于目标机器处的渐进的硬件发现的清单信息，来自动地管理故障通知(目标和源发服务器)。硬件发现(或硬件捕获)在每次PXE引导时捕获与目标机器相关的硬件信息。图4A和图4B表示在清单信息存储库333中能够维持的示例性清单信息。清单信息包括与目标机器相关的、将用于在检测到故障时确定所需的补救措施的参数，诸如标识硬件机器的 PCI 代码(VersionID、DevicelD、SUbdevice ID，...)。返回到图3，错误处理组件332包括故障检测单元334，用于检测OS部署期间的故障；以及补救处理单元335，用于响应于故障检测、基于从故障检测单元接收的故障信息和在清单信息存储库333中维持的清单信息，而触发补救措施。当检测到故障时，补救处理单元335使用所报告的故障搜索补救存储库336(在下文中也称为错误目录)以获取适当的补救措施。补救存储库336将补救措施与故障代码和清单信息相关联，诸如以下示例性表所示
故障代码清单信息补救惜施故障代码XPCI代码XBIOS版本χ故障代码yPCI代码yBIOS版本y
错误处理组件332进一步适于控制从补救存储库336获取的补救措施的执行。补救措施可以包括例如用于BIOS更新的BIOS刷新动作或者任何其他适当的补救措施。可选地，BIOS和IO驱动器接口上的测试套件可以在预OS环境中运行。这一测试套件可以在PXE 引导之后运行，并且可以帮助在实际工作期间减少故障发生。测试套件能够使用信令协议。图5是根据本发明某些实施方式的用于OS部署的流程图。在步骤500中，在目标机器激活后，将控制传递到BIOS以便检查引导序列。通过 PXE协议将引导序列设置为从网络启动。BI0S/PXE逻辑联系引导服务器(通过示例的方式，引导服务器在TPMfOSD服务器本身中运行)，并且预OS内核被下载并在目标机器31上启动。在步骤510中，预OS内核执行硬件发现并向OSD服务器210发送回清单数据。将服务器接收到的清单数据存储在清单存储库333中。在步骤510中，反复地执行BIOS测试套件以基于在清单存储库333中维持的清单信息，而检测OS部署期间的故障(下面参考图6而描述)。然后从OSD服务器下载虚拟盘(ramdisk)(诸如WINPE和/或MCP虚拟盘)并启动该虚拟盘。在步骤511中，可以执行硬件配置任务(例如刷新或设置BIOS)。可以加载用于配置硬件的特定工具并在WINPE/MCP之上运行该特定工具，从而使得使用标准OS运行时间来实际地执行任务。在步骤520中，OSD代理在WINPE之上运行，并执行分区创建和对文件系统中的文件的实际复制。可以加载用于创建分区和复制文件的OSD代理并在虚拟盘(例如WINPE/ MCP)之上运行该OSD代理，以便使用标准OS运行时间来实际地执行任务。一旦完成这些操作，虚拟盘WINPE/MCP就重新引导(因为直接加载预OS内核一般是不可能的)。在步骤MO中，在重新引导后，BIOS再次承担控制并重复步骤500到520。在步骤550中，预OS内核检测在前一阶段中是否已经发生了错误。其将任何错误传送给OSD服务器。其还检查待执行的附加任务。在这一阶段，其在硬盘上引导0S，并且还前进到设置待在OS起动时运行的OSD代理。在步骤560中，当OS引导时，OSD工具启动并激活特定OS工具以定制OS(诸如OS 联网配置、用户设置、语言设置等)。例如，在Microsoft Windows (Windows是微软公司在美国和其他国家的注册商标)的情况下，可以执行“syspr印”工具，特别是以便使操作系统准备好经由磁盘映像来进行磁盘克隆和恢复。在这一步骤之后，可以安装附加的安装包。然后“ syspr印”重新引导和重新引导序列再次启动。在步骤570中，当重新引导时，BIOS再次承担控制并像在步骤500中一样重新启动该序列。在步骤580中，预OS内核检查故障和附加任务，然后可以可选地安装附加的安装包。在步骤590中，如果没有其他动作要执行，则OS被引导和正常地启动。图6是用于故障监控和OS部署补救的流程图。流程图的左边部分表示由预OS内核执行的步骤，而流程图的右边部分表示由OSD服务器210执行的步骤。
故障监控在预OS内核的渐进的硬件发现阶段期间执行。在步骤600中，预OS内核将在硬件捕获期间所发现的清单数据发送给OSD服务器210用于存储。在步骤602中将由服务器接收到的清单数据存储在清单存储库333中。在步骤603中，通过向服务器210通知测试启动来发起测试套件。在步骤604中，服务器210注册测试启动时间，然后在步骤605中在预OS内核侧运行BIOS测试套件。并行地，服务器210等待预定时间量(步骤606)直到向目标通知测试完成(607)为止。如果向目标通知了测试完成，则服务器210在步骤608中复位启动测试时间，然后在步骤609中确定该测试是否成功。如果测试成功，则部署继续到步骤610。否则，如果已经检测到故障，则部署过程在步骤611中结束。当在测试套件期间检测到故障时，生成故障代码。然后，使用故障代码和在清单存储库333中可获得的清单信息，来从补救存储库336中确定补救措施。补救措施可以包括识别将被刷新的新BIOS版本。 然后，步骤612刷新所识别的新BIOS，并且通过返回到步骤600来重新启动部署流。如果服务器在预定时间量已经到期之后没有接收到测试完成通知(步骤613和 614)，则服务器210确定目标机器处于挂起状态并且在步骤615中依赖于硬件配置而选择新的BIOS版本。步骤616使用带外技术(即AMT)将新的BIOS刷新到目标上。然后，重新引导机器，并且通过返回到步骤600来重新启动部署流。本发明由此提供了用于处理OS部署期间的故障的自动和高效的方法，而不需要来自用户或管理员的手动操作。错误处理组件332使用在硬件发现期间所发现的信息来检测故障，并基于故障信息来确定要在发生故障的目标上执行的补救措施。刷新BIOS被认为是危险的操作，其可能致使目标机器无法使用。通过根据检测到的故障以及由已更新的 BIOS版本，在硬件发现期间渐进地捕获的清单信息自动地提供补救措施，本发明进一步避免了此类不希望的/不适当的BIOS刷新操作。本发明可以采取完全硬件实施方式、完全软件实施方式或者包含硬件元件和软件元件两者的实施方式的形式。在优选实施方式中，本发明以软件实现，该软件包括但不限于固件、驻留软件、微代码等。特别地，应当意识到，图5和图6的很多组件的功能性可以借助于软件、硬件或者这些软件和硬件的任何组合的固件来实现。例如，在高性能系统中，Java 执行的硬件实现可以证明是有利的。另外，本发明可以采取计算机程序产品的形式，该计算机程序产品可从计算机可用或计算机可读介质访问，该计算机可用或计算机可读介质提供由计算机或任何指令执行系统使用或者结合计算机或任何指令执行系统使用的程序代码。出于本描述的目的，计算机可用或计算机可读介质可以是能够包含、存储、传送、传播或传输由指令执行系统、装置或设备使用或者结合指令执行系统、装置或设备使用的程序的任何装置。Tivoli是IBM公司在美国、其他国家或这两者中的商标。其他公司、产品或服务名称可以是其他的商标或服务标记。
权利要求
1.一种在向目标机器的操作系统部署中进行故障管理的方法，所述操作系统部署包括运行渐进的硬件发现，以捕获与所述目标机器有关的清单信息，以及将所述清单信息存储在清单数据存储库中，其中所述方法包括a-监控所述操作系统部署以在预定持续时间内检测预操作系统环境中的操作系统部署中的故障，b-响应于所述预定持续时间到期而发出故障监控完成通知，C-确定在所述监控所述操作系统部署的步骤期间是否已经生成了故障代码，以及d-如果在步骤c中检测到故障代码，则使用所述故障代码和所述清单信息，来确定与 BIOS有关的至少一个补救措施，并且执行所述至少一个补救措施。
2.根据权利要求1所述的方法，其中所述方法包括如果在所述预定持续时间内没有发出故障监控完成通知，则检测所述目标机器的挂起状态，并且响应于检测到所述挂起状态而执行至少一个补救措施。
3.根据权利要求2所述的方法，其中响应于检测到所述挂起状态而执行的所述至少一个补救措施包括-依赖于硬件配置而选择新的BIOS版本，以及-使用带外技术将所述新的BIOS刷新到目标上。
4.根据权利要求2或3所述的方法，其中响应于检测到所述挂起状态而执行的所述至少一个补救措施进一步包括强制远程重新引导所述目标机器。
5.根据权利要求4所述的方法，其中所述强制远程重新引导的步骤在所述目标机器的网卡中使用带外通信。
6.根据任一前述权利要求所述的方法，其中所述步骤d包括从补救存储库确定所述至少一个补救措施。
7.根据任一前述权利要求所述的方法，其中在步骤d中确定的所述至少一个补救措施包括依赖于所述故障代码和所述清单信息而选择新的BIOS版本，以及刷新所述新的BIOS 版本。
8.根据任一前述权利要求所述的方法，其中在步骤d中确定的所述至少一个补救措施包括更新或重新配置所述目标机器的固件。
9.根据任一前述权利要求所述的方法，其中所述清单信息包括以下信息之中的至少一个硬件细节、BIOS等级或者直接存取存储设备接口细节。
10.根据任一前述权利要求所述的方法，其中所述监控操作系统部署的步骤包括用在将要在所述预操作系统环境中运行的BIOS和I/O驱动器接口上执行的一系列测试来仿真所述机器的行为。
11.一种计算机程序，包括当在合适的计算机上执行所述计算机程序时用于执行根据权利要求1到10中任一项的方法的步骤的指令。
12.—种计算机可读介质，其上编码有根据权利要求11的计算机程序。
13.—种系统，包括适于执行根据权利要求1到10中任一项所述的方法的步骤的装置。
全文摘要
本发明涉及在软件部署中进行故障管理的方法和系统。具体地，本发明提供了一种向目标机器的操作系统部署期间进行故障管理故障的方法，所述操作系统部署包括运行渐进的硬件发现以捕获与目标机器有关的清单信息，以及将所述清单信息存储在清单数据存储库中。该方法包括监控OS部署以在预定持续时间内检测预OS环境中的操作系统部署中的故障；响应于该预定持续时间到期而发出故障监控完成通知；确定在监控操作系统部署的步骤期间是否已经生成了故障代码；如果检测到故障代码，则使用该故障代码和清单信息来从补救存储库确定与BIOS有关的补救措施，并且执行该补救措施。
文档编号G06F11/07GK102375764SQ20111022862
公开日2012年3月14日 申请日期2011年8月5日 优先权日2010年8月13日
发明者A·佩罗尼, C·马里内利, L·皮彻蒂, R·萨勒姆 申请人:国际商业机器公司