将固件更新应用在具有零停机时间的系统中的制作方法
【专利摘要】本公开的实施例涉及通过使用升级向上扩展管理程序层使得硬件选择性地离线和在线来将固件更新应用在具有零停机时间的系统中。一种方法，包括：在包括至少一个服务器的服务器复合体上运行向上扩展管理程序，并且运行单个操作系统和在向上扩展管理程序之上的至少一个应用。该方法还包括标识可用于服务器复合体内的第一硬件部件的固件更新。向上扩展管理程序从第一硬件部件移除所有工作负荷，并且当第一硬件部件空闲并且管理程序继续运行单个操作系统和至少一个应用时，所标识的固件更新被应用到第一硬件部件。优选地，该方法可以被用于在未曾关闭全部多个服务器的情况下，将固件更新顺序地应用到在多个服务器上的各个硬件部件。
【专利说明】
将固件更新应用在具有零停机时间的系统中
技术领域
[0001]本发明涉及用于更新服务器的硬件部件中的固件的方法和系统。
【背景技术】
[0002]数据中心是针对集中操作和管理合并计算机设备和相关基础设施的设施。计算机设备可以与数据中心相互连接来产生大型的强大的计算机系统，其能够存储和处理针对实体(诸如大型企业、web托管服务和因特网搜索引擎)的大量的数据。数据中心可以安置任何数目的机架，每个机架能够保持大量的服务器和支持设备，诸如交换机、电源、网络通信接口、环境控制和安全设备。服务器和支持设备通常安置在机架式多服务器外壳(例如，多叶底架)中并且以高密度配置被布置。所需要的多个服务器和机架式外壳可以相互连接来产生具有期望的性能的系统。
[0003]个人和企业想要其计算机应用经历零停机时间来避免对其繁忙日程、商业目标和顾客需求的影响。这向保持服务窗口很小施加了压力，使得所需要的维护和更新常常尽可能地被延迟。例如，服务器或者服务器的集群可以利用已经长期过时的固件版本运行。未更新部件的主要原因在于，更新固件的任务通常花费大量的时间段完成并且然后可能要求服务器重新启动。遗憾的是，继续运行旧固件意味着系统可靠性随时间下降，这是因为关键更新修复未得到应用。这种类型的可靠性下降是甚至针对频繁地释放关键更新修复的复合体扩展系统的特定关心问题。使得针对固件更新的复合体扩展系统离线可能导致服务的完全中断，这是因为出于该目的安装冗余扩展系统是成本过高的。
【发明内容】
[0004]本发明的一个实施例提供一种方法，包括:在包括至少一个服务器的服务器复合体上运行向上扩展管理程序，并且运行单个操作系统和在向上扩展管理程序之上的至少一个应用。该方法还包括标识可用于服务器复合体内的第一硬件部件的固件更新。向上扩展管理程序从第一硬件部件移除所有工作负荷，并且当第一硬件部件空闲时并且管理程序继续运行单个操作系统和至少一个应用时，所标识的固件更新被应用到第一硬件部件。
【附图说明】
[0005]图1是使用适于更新集群的各个计算节点和部件的固件的向上扩展管理程序的计算机集群的示图。
[0006]图2是根据本发明的各种实施例的可以使用的计算节点的示图。
[0007]图3是确定固件更新的定时和范围的过程的示意图。
[0008]图4是经由基板管理控制器(BMC)更新固件的带外(OOB)过程的示意图。
[0009]图5是经由操作系统(OS)更新固件的带内(IB)过程的示意图。
[0010]图6是经由操作系统(OS)和基板管理控制器(BMC)更新固件的带内(IB)过程的示意图。
[0011]图7是表示固件更新包的表。
[0012]图8是表示包括使用固件的每个硬件设备的已安装的固件版本的标识的每个服务器或者计算节点的重要产品数据(VPD)的一组表。
[0013]图9A-D是图示从服务器元件移除工作负荷(图9A)、使得服务器元件离线(图9B)、更新服务器元件上的固件(图9C)和使得服务器元件恢复在线以处置工作负荷(图9D)的过程的示意图。
[0014]图10是顺序地更新多个服务器元件上的固件的方法的流程图。
【具体实施方式】
[0015]本发明的一个实施例提供一种方法，包括:在包括至少一个服务器的服务器复合体上运行向上扩展管理程序，并且运行单个操作系统和在向上扩展管理程序之上的至少一个应用。该方法还包括标识可用于服务器复合体内的第一硬件部件的固件更新。向上扩展管理程序从第一硬件部件移除所有工作负荷，并且当第一硬件部件空闲并且管理程序继续运行单个操作系统和至少一个应用时，所标识的固件更新被应用到第一硬件部件。
[0016]向上扩展管理程序可以运行在包括单个服务器的服务器复合体上或者包括多个服务器的服务器复合体上，多个服务器创建对操作系统(OS)看起来像单个服务器的大型对称多处理器(SMP)。这有时被称为SMP缩放。本发明的实施例将向上扩展管理程序利用在将固件更新应用到服务器复合体中的任何硬件部件的方法中。如本文所公开的，向上扩展管理程序可以从任何一个硬件部件或者服务器移除工作负荷，来促进相关固件的更新或者修复，同时继续运行服务器复合体上的操作系统和应用。换句话说，在应用没有经历任何停机时间的情况下，可以将所标识的固件更新应用到第一硬件部件。本发明的各种实施例的有益方面在于，可以将固件更新顺序地应用到在服务器复合体上的硬件部件。
[0017]可选地，该方法还可以包括:在已经完成对第一硬件部件的所标识的固件更新之后，向上扩展管理程序将工作负荷分配给第一硬件部件。因此，当更新第一硬件部件的固件时，第一硬件部件的容量仅在很短时间段是不可用的。在另一选择中，方法还可以包括标识可用于服务器复合体内的第二硬件部件的固件更新，向上扩展管理程序将工作负荷从第二硬件部件移除到服务器复合体内的一个或多个其他硬件部件，并且将所标识的固件更新应用到第二硬件部件，同时管理程序继续运行服务器复合体上的操作系统和应用。类似地，本发明的方法可以从任何一个或多个硬件部件顺序地移除工作负荷，并且在更新任何进一步的硬件部件的固件之前，更新一个或多个硬件部件上的固件。应当认识到，如果服务器复合体包括多个服务器并且将工作负荷从整个服务器移除，那么可以同时将固件更新应用到该服务器上的硬件部件中的任何或者全部硬件部件。
[0018]在另一实施例中，该方法还可以包括:向上扩展管理程序将所有工作负荷从服务器复合体内的第一服务器移除，然后在已经从第一服务器移除所有工作负荷之后，使得第一服务器离线。在所标识的固件更新已经被完成之后，该方法可以使得第一服务器恢复在线并且将工作负荷分配给第一服务器。可选地，可以将所标识的固件更新应用到第一服务器上的处理器。更进一步地，当服务器已经被使得离线时，可以期望的是，将固件更新应用到该服务器上的、固件更新可用的任何硬件部件。利用服务器离线，电力还可用于平台管理模块(即，基板管理控制器(BMC))或者集成管理模块(IMM))，并且应用可以通过平台管理模块处理的任何固件更新是可能的。例如，管理员可以通过网络将指令和固件更新传递给平台管理模块。
[0019]该方法还可以包括向上扩展管理程序将针对每个服务器或者硬件部件的系统资源使用数据传递给每个服务器上的平台管理模块。响应于来自平台管理模块的请求或者响应于资源使用到达预先确定的设定点，可以以定期的时间间隔传递这样的数据。可选地，该方法可以响应于针对所有服务器的系统资源使用小于预定数量的系统资源使用而发起固件更新。更进一步地，可以根据一天中的时间、一周中的一天或者一年中的一天对系统资源使用进行建模，使得可以预测或者计划用于应用固件更新的适当的时间。可以由管理员模块使用经由操作系统或者平台管理模块从向上扩展管理程序所接收的系统资源使用数据来准备这样的建模。一个优选的方法包括:请求平台管理模块在建模期望小于预定数量的系统资源使用的系统资源使用的时间处报告当前系统资源使用，并且如果平台管理模块指示当前系统资源使用小于预定数量的系统资源使用，则发起固件更新。在特定选择中，平台管理模块可以请求向上扩展管理程序提供针对由管理员模块标识为具有可用的固件更新的一个或多个硬件部件的系统资源使用。
[0020]本发明的实施例可以包括操作系统将固件更新应用到第一服务器的第一硬件部件。此外，平台管理模块可以将固件更新应用到第一服务器的第二硬件部件。可以通过操作系统或平台管理模块应用任何单独的固件更新，这取决于服务器的配置。此外，可以通过操作系统、平台管理模块或者操作系统和平台管理模块二者应用包括针对服务器的多个硬件部件的固件更新的固件更新包。应当认识到，服务器的一些硬件部件可能仅能够通过操作系统接收固件更新，并且服务器的其他硬件部件可能仅能够通过平台管理模块接收固件更新。另外，诸如处理器的特定硬件部件可能仅在服务器离线时接收固件更新。
[0021]管理员可以将安装在硬件部件上的固件的固件版本与可用于硬件部件的固件更新的固件版本相比较，以确定是否更新硬件部件的固件。可以将关于各个硬件部件的当前安装的固件版本的信息从平台管理模块报告给管理员，所述平台管理模块将该信息存储为重要产品数据。提供给管理员的固件更新包将包括针对一个或多个硬件部件类型、模型或者版本的更新的固件版本。因此，管理员可以确定是否任何可用的固件更新应当被应用到服务器中的给定服务器的任何硬件部件。
[0022]向上扩展管理程序负责移动工作负荷来促进对硬件部件的固件更新。优选地，针对在系统资源使用足够低时的时间段延迟或者安排固件更新，使得一个或多个硬件部件离线将不导致工作负荷性能的显著减少。在确定固件更新应当被应用到特定硬件部件之后，向上扩展管理程序可以防止第一服务器的第一硬件部件的使用，同时将固件更新应用到第一硬件部件。尽管向上扩展管理程序可以从服务器移除所有工作负荷并且使得服务器离线，但是对于向上扩展管理程序而言在不将所有工作负荷迀移远离第一服务器并且在不使得第一服务器离线的情况下，防止一个或多个硬件部件的使用也是可能的。特别地，向上扩展管理程序可以在给定服务器内的相同类型的硬件部件之间移动工作负荷，诸如将工作负荷移动远离多处理器服务器中的一个处理器。应当认识到，由于完成工作负荷的减少的延迟，在服务器内本地移动工作负荷对于将工作负荷从复合体内的一个服务器移动到另一(远程)服务器并且避免网络带宽的使用可以是优选的。
[0023]图1是包括运行向上扩展管理程序或者管理程序层40的服务器复合体的系统10的示图，向上扩展管理程序或者管理程序层40适于更新在多个计算节点或者服务器20上的硬件部件的固件。管理程序层40跨越扩展复合体(诸如对称多处理器系统)中的多个服务器20，并且以虚拟机42的形式虚拟化服务器20的物理硬件部件。然而，管理程序可以甚至运行在服务器20的单个服务器上。虚拟机42托管操作系统44，其使得应用46能够被安装并且被运行在操作系统之上。管理程序层40使多个服务器20对操作系统44似乎作为单个服务器。管理如何将来自应用46的工作负荷分配给服务器内的各个服务器或者硬件部件的管理程序层40。因此，当期望促进固件更新时，管理程序层可以从所选择的硬件部件移除工作负荷。
[0024]在系统10中，单个服务器20被连接用于网络48上的通信，所述网络48优选地是诸如以太网的专用网络。网络使得服务器能够协调任务，诸如维护服务器之间的镜像存储器。相同网络48或者分离的网络可以被用于管理员模块(或者简单地“管理员”)50与平台管理模块之间的带外(OOB)通信，所述平台管理模块此处示出为每个服务器20的基板管理模块(BMC)或者集成管理模块(IMM)30。例如，通过网络的OOB通信可以由管理员50用于从BMC 30接收系统资源使用数据并且将固件更新向下推送给BMC 30。管理员50还可以与操作系统44带内(IB)通信以提供固件更新。更进一步地，管理员可以与其他扩展系统52进行类似的OOB和/或IB通信，使得管理员可以协调针对多个扩展系统的固件更新。非限制性地，管理员50被示出为包括固件更新54和更新逻辑56。
[0025]计算节点或者服务器20包括各自连接到系统总线的处理器或者中央处理单元(CPU)21、存储器22、网络接口23、PCI适配器24和统一可扩展固件接口(UEFI)25。平台管理模块(示出为基板管理控制器(BMC)或者集成管理模块(MM)30)包括服务包括监视系统性能的各种功能的服务处理器。出于本发明的实施例的目的，BMC 30执行平台管理逻辑32并且具有对针对服务器20的硬件部件的固件重要产品数据(VPD)34的访问。BMC 30还包括接口，诸如到CPU 21的键盘控制器类型(KCS)接口或者快速“USB上的LAN”接口 36ICS和USB上的LAN是带内接口，其允许BMC 30与CPU 21之间的通信，诸如由于管理程序和操作系统工具将更新向下推送给BMC或者由于BMC将固件更新应用到CPU。应当认识到，任何特定服务器配置可以包括其他或者附加的通信信道。例如，一些芯片集可以包括专用于与BMC或者其他平台管理模块通信的引脚。
[0026]在不要求BMC/MM具有IPMI设备驱动程序或者USB后台程序的情况下，使用USB上的LAN接口使能到BMC/HM的带内通信。相反，系统板上的BMC/I丽硬件将内部以太网NIC从BMC/HM呈现给操作系统。USB上的LAN还被称为頂M Web接口中的“USB带内接口”。通常地，针对USB上的LAN的IMM IP地址被设定为169.254.95.118的静态地址和255.255.0.0的子网掩码。在网络上的IP地址冲突的情况下，I丽可以获得169.254.xxx.xxx范围内的不同的IP地址。因为IMM可能获得针对USB上的LAN接口的不同的IP地址，所以联想高级设置实用程序(ASU)和固件闪速实用程序、DSA和IBM Director Agent使用服务位置协议(SLP)来发现頂MIP地址。这些工具执行USB上的LAN接口上的SLP多播发现。当它们接收来自IMM的响应时，它们获得包含IMM将用于USB上的LAN接口的IP地址的属性。
[0027]图2是根据本发明的各个实施例的可以使用的计算节点或者服务器的示图。计算节点20包括耦合到系统总线106的处理器单元21。处理器单元21可以利用一个或多个处理器，其中的每个处理器具有一个或多个处理器核心。可选的视频适配器108(其驱动/支持显示器22)还可以耦合到系统总线106。系统总线106经由总线桥接器112耦合到输入/输出(I/O)总线114，输入/输出(I /0)总线114耦合到I /0接口 116。I /0接口 116提供与各个I /0设备的通信，诸如包括键盘23和鼠标24。I/O设备可以可选地包括存储设备，诸如CD-ROM驱动和多媒体接口、其他打印机和(一个或多个)外部USB端口。尽管连接到I/O接口 116的端口的格式对于计算机架构的本领域技术人员可以是已知的，但是在优选的实施例中，这些端口中的一些或者全部端口是通用串行总线(USB)端口 126。如所描绘的，计算节点20能够使用网络接口 23在网络48上进行通信。网络48优选地是诸如以太网LAN的专用网络。
[0028]硬盘驱动器接口132还耦合到系统总线106并且与硬盘驱动器134对接。在优选的实施例中，硬盘驱动器134构成系统存储器22，其还耦合到系统总线106。系统存储器被定义为计算机100中的最低层的易失性存储器。该易失性存储器可以包括附加的更高层的易失性存储器(未示出)，包括但不限于高速缓存存储器、寄存器和缓冲器。位于系统存储器136的数据可以包括管理程序40、操作系统(0S)44和应用程序46。计算机20中所描绘的硬件元件不旨在是详尽的，而是适合于执行计算节点或者服务器的过程的代表性部件。
[0029]图3-6是仅图示图1的系统10的某些实体和连接连同过程中的步骤的示图。图3-6中的每副图中的步骤不是排他性方法，而是已经分为分离的附图来简化讨论并且强调本发明的方法中的潜在变化。此外，已经省略实体的参考数字以便不损失步骤的图示。应当理解，关于服务器复合体中的任何一个或多个服务器也可以执行该方法。
[0030]这些过程中所实现的总体策略是避免消耗由现有工作负荷所需要的主机CHJ资源。由于BMC具有其独立于主机CPU运行的自身的处理器，并且管理员可以在网络上与BMC进行带外通信，管理员可以从BMC采集数据，并且在对工作负荷没有任何影响的情况下，将固件更新提供给BMC。当BMC指示系统资源使用足够低时，那么固件更新可以以两个不同的方式或者两个方式的组合进行。在第一选择中，管理员可以在网络上将固件更新推送给BMC，其可以将固件更新应用到某些硬件部件，诸如UEF1、FPGA或者BMC自身。在第二选择中，管理员可以将更新工具向下推送给带内运行的操作系统，其中，运行工具以便执行固件更新。当在客户操作系统中带内运行工具时，操作系统还可以通过诸如USB上的LAN的带内信道将某些固件更新转发给BMC，以用于应用到(一个或多个)相关硬件部件。
[0031]图3是确定针对特定服务器上的一个或多个硬件部件的固件更新的定时和范围的过程60的示意图。应当理解，管理员可以与系统中的其他服务器交互来执行相同或者类似的过程。在步骤61中，管理员接收固件更新包。这可以例如以更新磁盘或者从制造商的网站下载的形式获得。典型的更新包包括可扩展标记语言(XML)定义文件连同实际的固件更新。XML可以从更新包当中被解析以促进当前安装在系统中的固件版本与将请求以经由固件更新包传递的固件版本之间的版本检查，并且验证固件更新将被应用到适当的系统或者硬件部件。
[0032]在步骤62中，BMC或者其他平台管理模块将重要产品数据(VPD)提供给列举当前被安装在相关计算节点或者服务器上的硬件部件上的固件版本的管理员。在步骤63中，管理员通过将固件更新包与重要产品数据相比较来执行固件版本检查。因此，管理员可以标识服务器中的、具有可用的固件更新的那些硬件部件。在适用的情况下，管理员还可以应用各种合格规则，以验证可用更新与硬件部件兼容或者与先前的固件版本兼容。在一些实例中，应用一个或多个中间固件版本以便避免不兼容性问题可能是必要的。
[0033]在步骤64中，管理员向BMC发送针对(一个或多个)相关硬件部件的固件更新的请求。在步骤65中，BMC将针对系统资源使用数据的请求发送给管理程序，这可能指定固件更新可用的硬件部件。然后，在步骤66中，管理程序对针对相关硬件部件的系统资源使用数据做出响应。基于系统资源使用是否小于预先确定的水平的确定，在步骤67中，BMC可以向管理员指示是否是应用固件更新的适当的时间并且可能应当在带内(IB)或者带外(OOB)执行任何这样的固件更新。应当认识到，针对系统资源使用的请求可以限于固件更新可用的一个或多个硬件部件，或者可以将针对系统资源使用的请求指向整个服务器。
[0034]尽管未特别地示出在图3中，但是管理员可以在一段时间期间对系统资源使用进行建模以便预期何时系统资源使用可能是低的。取决于系统资源使用模式，使用可以在一天中的特定时间、一周中的一天、一年的中的一周或者周末等等处是低的，并且可以等待这些时间段之一来请求固件更新。
[0035]图4是经由基板管理控制器(BMC)更新固件的带外(OOB)过程70的示意图。在步骤71中，管理员将针对一个或多个硬件部件的固件更新发送给BMC。在步骤72中，BMC请求管理程序从(一个或多个)相关硬件部件移除工作负荷(WL)。在步骤73中，管理程序确认已经移除工作负荷，或者指示在(一个或多个)相关硬件部件上将不允许工作负荷。例如，管理程序层可以将服务器的当前工作负荷合并到扩展复合体中的一个或多个其他服务器，或者如果当前固件更新仅适于服务器内的I或2个硬件部件，则管理程序可以选择性地使得那些硬件部件降级并且将工作负荷(如果有的话)移动到扩展复合体内的冗余资源，以考虑到在不要求重置的整个底盘或者整个扩展复合体的情况下，对该硬件部件的选择性重置。在步骤74中，BMC将固件更新应用到一个或多个硬件部件，诸如UEF1、BMC/nM、FPGA或者芯片集/CPU。在下文中，在步骤75A中，BMC向管理程序通知更新已经完成，使得管理程序将(一个或多个)硬件部件返回到服务中。类似地，步骤75B向管理员通知固件更新已经被完成。BMC的VPD和由管理员所维护的任何类似表二者都可以被修改为反映相关硬件部件现在正运行在新固件版本上。
[0036]图5是经由操作系统(OS)更新固件的带内(IB)过程80的示意图。在步骤81中，管理员将固件更新发送给操作系统。在步骤82中，操作系统请求管理程序从相关硬件部件移除工作负荷。在步骤83中，管理程序确认已经移动工作负荷或者指示相关硬件部件准备用于接收固件更新。在步骤84中，操作系统和/或从管理员所接收的更新工具将固件更新应用到诸如PCI适配器的相关硬件部件。然后，步骤85A和85B相应地通知管理程序和管理员固件更新已经被完成。
[0037]图6是经由操作系统(OS)和基板管理控制器(BMC)更新固件的带内(IB)过程90的示意图。在步骤91中，管理员将固件更新发送给操作系统。在步骤92中，操作系统请求管理程序从相关硬件部件移除工作负荷。在步骤93中，管理程序确认已经移动工作负荷或者指示相关硬件部件准备用于接收固件更新。在步骤94中，操作系统和/或从管理程序所接收的更新工具将固件更新或者固件更新的至少一部分转发给BMC。在步骤95中，BMC将固件更新应用到相关硬件部件，诸如UEF1、BMC/nM、FPGA或者芯片集/CPU。在步骤96中，BMC向操作系统报告固件更新已经被完成，并且在步骤97中，操作系统向管理员报告更新已经被完成。
[0038]图7是表示固件更新包的表54。表的每行标识硬件设备、固件更新包中所提供的(一个或多个)固件版本，并且可以可选地包括兼容性规则。
[0039]图8是表示针对系统中的每个服务器或者计算节点的重要产品数据(VH))34的一组表。每个表标识特定服务器上的、使用被安装在该硬件部件上的固件和固件版本的每个硬件设备或者部件。同时，图7的表和图8的表提供足够的数据，使得管理员可以确定哪些硬件设备需要固件更新包中的固件更新中的一个固件更新。
[0040]图9A-D是图示从服务器元件移除工作负荷(图9A)、使得服务器元件离线(图9B)、更新服务器元件上的固件(图9C)和使得服务器元件返回在线以处理工作负荷(图9D)的过程的示意图。
[0041]关于图9A，管理程序层40负责将工作负荷从服务器元件I迀移到一个或多个其他服务器元件，以便促进将固件更新应用到服务器元件I。一般而言，服务器元件可以是但不限于可启动节点(服务器)、多处理器复合体内的一个或多个处理器、PCI express适配器、数据存储设备、专业DIMM或者电源。
[0042]图9B图示在已经从服务器元件I移除工作负荷之后服务器元件I可以被使得离线。注意，其他服务器元件中的所有、许多或者至少一些服务器元件仍然在线并且可以被用于继续服务工作负荷，诸如在操作系统44上运行的应用。然而，由于服务器元件I离线，因而减少服务器元件的整个系统的容量，使得方法优选地在当系统资源使用小于某个预先确定的水平时的时间段期间仅使得服务器元件I离线。
[0043]图9C图示了在服务器元件I离线时应用到其的固件更新或者更新。可以将该固件更新应用到服务器元件I的任何一个或多个子部件，如果有的话。
[0044]图9D图示了在固件更新已经完成之后，服务器元件I被热添加或者被使得恢复在线，使得管理程序可以再次将工作负荷分配给服务器元件I。这可以是新工作负荷或者从其他服务器元件迀移的工作负荷。应当认识到，图9A至9D中所图示的步骤可以然后针对服务器元件中的另一服务器元件重复，以便更新该服务器元件中的固件。可以执行任何数目的重复以便实现顺序地移除工作负荷并且在扩展复合体的一部分或者整体上更新固件的方法。通过顺序地仅更新扩展复合体的子集而绝非同时整个复合体，在未曾使整个复合体离线或者没有经历停机时间或者性能的重大损失的工作负荷的情况下，可以将固件更新应用到整个复合体。
[0045]图10是顺序地更新多个服务器元件上的固件的方法140的流程图。在步骤142中，在接收固件更新之后，步骤144确定总体系统使用是否大于预定的设定点。如果是的话，那么步骤146在返回到步骤144的确定之前进行等待。如果总体系统使用不大于预定的设定点，那么步骤148标识需要固件更新的硬件部件(S卩，固件更新可用于该硬件部件)。如果步骤150确定所选择的硬件部件的工作负荷不小于预定的设定点，那么按照步骤152跳过部件。然而，如果所选择的硬件部件具有小于预定的设定点的工作负荷，则在步骤154中移除工作负荷并且使得硬件部件离线，在步骤156中将固件更新应用到硬件部件，并且在步骤158所选择的硬件部件恢复在线并且分配工作负荷。在步骤152或者158中的任一项中，步骤160确定是否存在需要固件更新的其他硬件设备。如果是的话，那么方法返回到步骤148以标识要被更新的下一硬件部件。如果没有其他硬件设备需要被更新，那么方法结束。
[0046]在不脱离本发明的范围和精神的情况下，许多修改和变型将对于本领域的技术人员是明显的。选择和描述实施例以便最好地解释本发明的原理和实际应用，并且使得本领域的普通技术人员能够理解针对具有如适于所预期的特定使用的各种修改的各种实施例的本发明。
【主权项】
1.一种方法，包括: 在包括至少一个服务器的服务器复合体上运行向上扩展管理程序； 运行单个操作系统和所述向上扩展管理程序之上的至少一个应用； 标识可用于所述服务器复合体内的第一硬件部件的固件更新； 所述向上扩展管理程序从所述第一硬件部件移除所有工作负荷；以及当所述第一硬件部件空闲并且所述管理程序继续运行所述单个操作系统和所述至少一个应用时，将所标识的固件更新应用到所述第一硬件部件。2.根据权利要求1所述的方法，其中所述向上扩展管理程序从所述第一硬件部件移除所有工作负荷包括:所述向上扩展管理程序将所有工作负荷从所述第一硬件部件迀移到所述服务器复合体内的至少一个其他硬件部件，其中所述第一硬件部件和所述至少一个其他硬件部件是相同类型的部件。3.根据权利要求1所述的方法，其中所述向上扩展管理程序从所述第一硬件部件移除所有工作负荷包括:在不向所述第一硬件部件分配任何附加工作负荷的情况下，所述向上扩展管理程序允许所述第一硬件部件完成当前工作负荷。4.根据权利要求1所述的方法，其中在所述应用没有经历任何停机时间的情况下，所标识的固件更新被应用到所述第一硬件部件。5.根据权利要求1所述的方法，其中所述第一硬件部件是具有多个处理器的服务器中的处理器。6.根据权利要求1所述的方法，还包括: 在对所述第一硬件部件的所标识的固件更新已经被完成之后，所述向上扩展管理程序向所述第一硬件部件分配工作负荷。7.根据权利要求6所述的方法，还包括: 标识可用于所述服务器复合体内的第二硬件部件的固件更新； 所述向上扩展管理程序从所述第二硬件部件移除工作负荷；以及当所述第二硬件部件空闲并且所述管理程序继续运行所述单个操作系统和所述至少一个应用时，将所标识的固件更新应用到所述第二硬件部件。8.根据权利要求1所述的方法，还包括: 所述操作系统将固件更新应用到所述第一服务器的所述第一硬件部件。9.根据权利要求8所述的方法，还包括: 所述第一服务器上的平台管理模块将固件更新应用到所述第一服务器的第二硬件部件。10.根据权利要求1所述的方法，还包括: 管理员将被安装在硬件部件上的固件的固件版本与可用于所述硬件部件的固件更新的固件版本相比较，以确定是否更新所述硬件部件的所述固件。11.根据权利要求1所述的方法，其中所述服务器复合体包括多个服务器。12.根据权利要求11所述的方法，还包括: 所述向上扩展管理程序将所有工作负荷从所述服务器复合体内的第一服务器移除到所述服务器复合体内的、除了所述第一服务器之外的一个或多个其他服务器； 在所述工作负荷中的所有工作负荷已经从所述第一服务器被移除之后，使得所述第一服务器离线；以及 在所标识的固件更新已经被完成之后，使得所述第一服务器恢复在线并且向所述第一服务器分配工作负荷。13.根据权利要求11所述的方法，其中固件更新能够被应用到所述多个服务器中的任何硬件部件。14.根据权利要求13所述的方法，还包括: 将固件更新顺序地应用到在所述服务器复合体中的所述多个服务器上的多个硬件部件。15.根据权利要求1所述的方法，还包括: 所述向上扩展管理程序向所述至少一个服务器上的平台管理模块传递针对所述至少一个服务器的系统资源使用数据。16.根据权利要求15所述的方法，还包括: 响应于系统资源使用小于预定数量的系统资源使用，发起所述固件更新。17.根据权利要求15所述的方法，还包括: 根据一天中的时间、一周中的一天或者一年中的一天，对系统资源使用进行建模。18.根据权利要求17所述的方法，其中所述系统资源使用由不是所述服务器复合体的一部分的管理员模块来建模。19.根据权利要求17所述的方法，还包括: 请求所述平台管理模块在所述建模期望小于预定数量的系统资源使用的系统资源使用的时间处报告当前系统资源使用；以及 如果所述平台管理模块指示所述当前系统资源使用小于所述预定数量的系统资源使用，则发起所述固件更新。20.根据权利要求19所述的方法，还包括: 所述平台管理模块请求所述向上扩展管理程序提供针对由所述管理员模块标识为具有可用的固件更新的一个或多个硬件部件的系统资源使用。
【文档编号】G06F9/445GK106020854SQ201610169429
【公开日】2016年10月12日
【申请日】2016年3月23日
【发明人】S·科查尔, R·科尔维克, J·伯尔肯哈根
【申请人】联想企业解决方案(新加坡)有限公司