CN116166413A - 针对异构基础设施上的工作负载的生命周期管理 - Google Patents

Abstract

一种针对异构基础设施上的工作负载的生命周期管理。本文描述的示例涉及经由抽象资源提供基础设施的基于池的自动化生命周期管理。根据示例，维护消费模型，消费模型中异构基础设施以概括形式被表示为逻辑资源对象，逻辑资源对象包括节点和节点的池。节点具有指示节点可操作以基于节点的相应属性/质量向工作负载提供的特定功能的相应节点角色。维护状态模型，通过该状态模型，逻辑资源对象在状态之中被转换，并且响应于状态模型，通知被提供到与工作负载相关联的应用编排工具。通过提供API，来抽象应用编排工具与由工作负载利用的异构基础设施的交互，通过该API，对管理异构基础设施的生命周期的请求参考逻辑资源对象而被表达。

Description

针对异构基础设施上的工作负载的生命周期管理

背景技术

针对应用和基础设施的生命周期管理可以指代广泛活动集，其中包括发现、供应、升级、修正、改变管理、配置管理、和安全漏洞的管理。一些生命周期管理活动(诸如，执行升级和补丁管理)传统上涉及容易出现配置错误和实现错误的手动任务、重复任务，这些错误正由用于执行自动化生命周期管理的各种云自动化工具和生命周期管理软件解决。

自动化生命周期管理可以被有效地用于管理云计算基础设施中的应用。与云本机应用设计(例如，被设计为独立于计算基础设施生命周期改变的应用)相结合的自动化生命周期管理是针对一些生命周期管理方法的准则。

附图说明

在附图中，通过示例而非限制的方式图示本文所述的各方面，在附图中，相似的附图标记指代相似的元素。

图1根据示例示出了云计算环境的框图。

图2根据示例示出了节点环境管理器(NEM)的框图。

图3根据示例示出了图示对象模型的示图。

图4根据示例示出了图示状态模型的示图。

图5根据示例示出了图示由NEM执行的处理的流程图。

图6根据另一示例示出了图示由NEM执行的处理的流程图。

图7根据示例示出了计算机系统的框图。

具体实施方式

本文所述的示例涉及经由抽象资源来提供基础设施的基于池的自动化生命周期管理。尽管通常独立于应用的生命周期来执行基础设施生命周期管理，但是有这样的情况，其中应用需要被集成到底层计算基础设施的生命周期中，该底层计算基础设施可以是或可以不是云状的，并且在不考虑应用的生命周期的情况下不能被独立地管理。该情况的示例是当应用是用于创建和管理诸如集群等复杂计算系统架构的服务(例如，是应用的服务类型(例如，软件即服务(SAAS))时。在该情况下，计算基础设施的生命周期将需要与应用的配置编排合作地工作。另一示例是当应用是有状态的时(诸如，存储服务)，其中底层计算基础设施需要与应用集成，以保证根据需要恢复针对计算基础设施中的存储服务的持久状态信息。

当组织要求为针对本地部署工作负载提供云体验时，应用编排被暴露于云计算环境的底层计算基础设施的各种复杂性，该复杂性包括例如供应机制和资源管理工具(例如，kubevirt——开源项目、虚拟机v中心等)。在有限计算环境和/或具有异构基础设施的计算环境的上下文中，应用编排面临附加的挑战。例如，站点、设施、或数据中心(其在本文中通常可以被称为计算环境)可以包括有限数目(例如，20至80)的服务器，每个服务器提供容纳在有限数目(例如，1或2)的机架内的计算资源(例如，计算、存储、和/或联网资源)。在特定计算环境内可用的服务器也可以由不同的供应商制造，表示不同的模型、和/或具有不同的属性，该属性也被称为质量，该属性可以包括例如能力、容量、和/或配置。

附加地，服务类型应用和/或有状态的应用可以涉及监视用于给定服务或解决方案(例如，作为服务的机器学习操作(MLOpsaaS)、作为服务的容器(CaaS)、作为服务的虚拟机(VMaaS)、作为服务的存储(STaaS)等)的底层基础设施的状态以及相关映像，以处理各种改变(例如，操作系统更新的可用性、计划的中断、或未计划的中断)。通常，期望将应用与这类复杂性以及基础设施特定细节隔离，以允许应用除了别的以外，集中于所讨论的解决方案的功能和特征核心。

这样，在本文所述的示例中，提出了通过引入以中间层形式的软件框架，来简化和概括从应用的角度来看的计算基础设施上的操作，该中间层被逻辑地插入在应用及其一侧上相应的编排工具与计算基础设施(包括相关联的供应机制和资源管理工具)之间。根据各种示例，软件框架提供针对应用的资源的基于池的生命周期管理。例如，计算基础设施的元素可以被管理为具有一致的自动化生命周期管理操作和状态的类似实体组(例如，计算、存储、网络、可能具有类似的属性或质量)。

如下面进一步所描述的，在一个示例中，该框架(在本文可以被称为节点环境管理器(NEM))提供资源对象和状态模型系统以及资源配置和库存信息、用于集成定制基础设施工具和管理产品或云服务资源管理功能的基础设施插件框架、以及用于资源消费和生命周期事件的应用编程接口(API)。例如，通过消费API，应用编排可以经由与逻辑资源对象(例如，节点和节点的池)的交互，来间接地管理和/或操纵底层基础设施。

作为NEM框架的部分，北向API可用于通过使用保留系统来获取抽象的计算资源(例如，池、节点等)来归一化云计算环境中的资源的获取，用于资源生命周期改变的通知机制以触发与应用编排工具的集成，以及针对基础设施插件的南向API允许支持南向API调用的计算基础设施工具和服务的集成(例如，经由各种开发插件)。以该方式，可以提向应用编排工具提供用于计算资源获取的简单API，而无需理解云计算环境的底层计算基础设施、供应机制、和管理工具的复杂细节。此外，复杂的生命周期改变，诸如操作系统(OS)、固件、或软件更新(在裸机(BM)机器/服务器或虚拟机(VM)上)、计划的中断或故障中断，以及不受信的引导/活动，可以对应用几乎透明。例如，响应于来自NEM的通知，应用可以编排应用实例重新配置，而不考虑计算基础设施或管理工具或服务细节的复杂性。

一个或多个应用编排工具可以经由在消费模型内表示并且通过保留而被获取的节点的逻辑池来访问云计算环境中的计算资源。应用编排工具可以配置那些所获取的资源，以构建应用的实例。本质上是逻辑的节点可以表示BM机器或VM，节点可以被限定为基于节点的属性(例如，在计算、存储和/或联网方面的能力，容量和/或配置，例如，)来向应用的实例提供特定功能，并且可以由NEM组织成节点的池，该节点的池经由集成工具和管理产品在整个生命周期中被自动地和共同地管理。

在以下描述中，阐述了许多具体细节以便提供对本文所公开的主题的透彻理解。然而，对于本领域的技术人员来说清楚的是，可以在没有这些具体细节中的一些细节的情况下实践本文所述的各方面的实现。

术语“连接的”或“耦合的”以及相关术语在操作意义上被使用，并且不必限制于直接的连接或耦合。因此，例如，两个设备可以直接被耦合，或者经由一个或多个中间介质或设备而被耦合。作为另一示例，设备可以以这样的方式被耦合，即信息可以在其间传递，而不彼此共享任何物理连接。基于本文所提供的公开内容，本领域普通技术人员将理解根据前述限定存在连接或耦合的各种方式。

术语

如果说明书声明组件或特征“可以”、“可能”、“应该”、或“也许”被包括或具有特性，则不要求特定组件或特征被包括或具有特性。

除非上下文另有明确规定，否则如本文中的描述和贯穿随后的续权利要求书中所使用的，“一”、“一个”、和“所述”的含义包括复数引用。此外，除非上下文另有明确规定，如在本文的描述中所使用的，“在……中”的含义包括“在……中”和“在……上”。

短语“在示例中”、“根据示例”等通常意指该短语之后的特定特征、结构、或特性被包括在本公开的至少一个实例中并且可以被包括在本公开的多于一个实例中。重要的是，这些短语不必然指代同一示例。

如本文所使用的，“基础设施”通常指代计算环境内可用的物理计算系统(例如，机架服务器、刀片服务器、刀片、存储阵列、存储服务器、超转换平台等)和/或虚拟计算系统(例如，在物理计算系统上运行的VM)。基础设施的每个单独的组件或元素可以提供由在计算环境中运行的工作负载使用的差异化的计算资源(例如，计算资源(以执行计算)、存储资源(以存储数据)、和/或网络资源(以传送数据))。如上所述，本地部署计算环境本质上可以是异构的(例如，具有差异化的计算资源的BM机器和/或VM)和/或可以包括有限数目的服务器。在一些示例中，NEM可以在安装处维护BM/VM基础设施的库存。

本文所使用的“节点”表示基础设施的抽象元素或与基础设施相关联的一个或多个计算资源的逻辑集。取决于特定实现，节点可以表示BM机器或VM，并且可以被限定为基于节点的属性(例如，在计算、存储、和/或联网方面的能力、容量、和/或配置)向应用实例提供特定功能。在本文所述的示例中，NEM可以将节点组织成组，该组的生命周期经由集成工具和/或管理产品而被共同地管理。在一些示例中，NEM维护基础设施模型，以跟踪由消费模型中的节点表示的库存中的备份服务器(例如，哪个机架和哪个服务器)。

“编排”通常指代计算机系统、应用、计算资源、和/或服务的自动化配置、管理、和/或协调。

“应用编排”或“服务编排”是使用于实时处理或同步数据的应用和/或服务的部署、管理、扩展、联网、集成、和可用性自动化过程。在一些情况下，应用包括多个软件容器。容器可以包含一个或多个工作负载。

应用编排工具是实现应用编排的程序(通常由云计算环境中的系统管理方运行)。

云计算环境

图1根据示例示出云计算环境100的框图。在本示例的上下文中，云计算环境100包括云计算系统102、用户可通过其与云计算系统102的各个方面交互并且对云计算系统102的各个方面进行配置的SAAS门户114、以及外部提供方116(例如，BM提供方、信任提供方、VM提供方、和/或存储提供方)。云计算系统102可以位于的本地部署的数据中心或主机托管。

在一些实现中，基础设施112可以由用户或用户的组织拥有或占有，并且由基础设施提供方(用户或用户的组织是提供方的客户)管理。在一些实现中，基础设施112可以由基础设施提供方递送到用户或用户的组织(例如，安装在数据中心处、或者用户或用户的组织的主机托管处)，用于按次计费的金融模型中的消费即服务。在一些实现中，下面所述的节点环境管理器110可以由基础设施提供方提供，作为针对消费即服务的管理的部分。

云计算系统102可以运行一个或多个工作负载104。工作负载104可以由数据和应用组成，其中基础设施112向工作负载104提供计算资源(例如，计算、存储、和/或联网)以完成任务。工作负载104可以与运行时106(例如，包括操作系统(OS)、虚拟机管理器(VMM)或虚拟机管理程序、或其它系统软件的运行时环境)进行接口，以利用基础设施112内的计算资源。取决于特定站点，基础设施112可以包括资源的异构池，该资源的异构池包括差异化的服务器和/或VM实例以及其它电子组件和/或机械组件(例如，服务器机架(未示出)、电源(未示出)等)。

在一个示例中，节点环境管理器(NEM)110表示中间软件层，该软件中间层被逻辑上插入在云计算系统102中运行的应用编排工具(例如，应用编排工具108)与基础设施112之间。如下面进一步所描述的，NEM 110可以包括多个概念组件，包括库存管理、节点池管理、节点保留管理、自动化节点供应管理、和/或自动化的池管理。例如，除了消费API之外，NEM 110还可以提供库存API，云计算系统102的管理用户通过该库存API通过SAAS门户114来访问NEM 110，例如，可以管理基础设施112的机架和差异化的服务器的库存，以便向更高等级的编排器(例如，应用编排工具108)提供节点池集。

在示例中，管理用户可以使用应用编排工具108来配置针对工作负载104的基础设施112的自动化生命周期管理。

NEM 110可以提供用于资源消费的简化API，以允许应用编排工具108容易地为由云计算系统102的基础设施112支持的工作负载104保留、获取、和管理计算资源，而不需要复杂细节的知识来执行计算资源管理(尤其是对于BM资源)。如下面进一步描述的，由消费API提供的抽象层允许工作负载获取节点，而无需知道底层服务器(例如，提供计算资源)是BM机器还是VM，并且通过在限定池时以数据驱动的方式来描述节点的角色。此外，当节点或池涉及生命周期改变时(例如，由于OS或软件(SW)或固件更新的可用性、计划的中断或未计划的中断、不受信的活动等)，NEM 110可以向工作负载104提供关于计算资源的状态改变的通知。应用编排工具108随后可以通过NEM 110通过保留和获取新节点并且从其池中移除旧节点(例如，通过不可变的节点处理)来解决状态改变，这可以消除工作负载配置漂移，并且通过扩展可以消除工作负载的重新配置实例。

在示例中，NEM 110还可以在后台使节点的供应自动化。例如，具有所限定的角色(例如，作为保留工作负载配置的部分)的节点可以在其获取之前(例如，在保留之前或响应于保留)被构建，以促进一旦由应用编排工具108获取由工作负载104使用的快速可用性。这可以改善节点获取性能，因为构建BM节点通常是耗时的。该特征还可以构建VM节点的益处，VM节点通常被认为尽快供应，但是取决于OS/SW在其相应的运行时环境中的复杂性，构建也可能很慢。

节点环境管理器(NEM)

图2根据示例示出了的节点环境管理器(NEM)210的框图。NEM 210表示图1的NEM110的非限制性示例。在本示例的上下文中，NEM 210包括北向API 220(例如，下文进一步描述的消费API、库存API、和解决方案配置API)、资源对象、和状态模型系统230、以及具有南向API 240的基础设施插件框架。

基础设施插件框架240可以被用于将各种工具、管理产品、和/或云API概括和协调为与NEM 210相关联的状态和生命周期限定。例如，基础设施插件框架240可以集成物理资源和基础设施管理工具(例如，经由BM插件的资源管理器211(例如，裸机供应工具)、信任插件(例如，Keylime——开源项目、或其它受信的平台模块(TPM)远程引导证明和运行时完整性测量解决方案)、VM插件(例如，kubevirt、Kubernetes KVM虚拟化管理、或其它虚拟化工具)、和/或存储插件)等。尽管这种工具和解决方案可以备选地被嵌入在NEM 210内，但是在一些实现中，利用插件方法具有允许NEM 210集中于对象/状态管理并且使应用更简单地和更容易地被构建和被维护的优点。附加地，利用插件方法，随着时间的推移，NEM 210可以更容易地扩展为具有更多生命周期管理能力，并且当与应用编排的自动化生命周期集成时，NEM 210可以提供灵活并且持久的应用和基础设施架构。

资源对象和状态模型系统230被示为包括模型和状态管理器235、对象模型236、状态模型238、通知器232、供应器233、保留系统234、池管理器237。在实现中，对象模型236和状态模型238可以用GO(静态类型的、编译的编程语言)来实现，被部署为用于可扩展性的无状态Kubernetes荚(“pod”)，经由表示性状态转移(REST)API调用而被访问，并且被持久化在数据库中。如以下将参考图3进一步描述的，对象模型236可以具有多个层次，包括：(i)库存模型，在库存模型中可以维护云计算系统(例如，云计算系统102)内可用的BM/VM基础设施的库存，用于由工作负载(例如工作负载104)使用；(ii)解决方案模型，包含与定制设置混合的解决方案配置，该定制设置与例如经由基础设施插件框架240与NEM210集成的工具/产品相关联，用于给定解决方案；以及(iii)消费模型，包括逻辑对象集(例如，节点和节点的池)，逻辑对象集可以被用于在运行时由应用编排工具(例如，应用编排工具108)间接操纵实际计算基础设施。

基于对象模型236，通过REST API调用(例如，对API 220)或通过NEM后台进程，持久化的逻辑资源对象可以由状态模型238限定的状态而被自动地转换，状态模型238可以导致经由API 220到应用编排工具的通知(例如，由通知器232生成)和/或对基础设施插件框架240的进行调用，以调用适当的定制管理工具或云基础设施API。

如以下将参考图4进一步描述的，模型和状态管理器235可以负责编排与逻辑资源对象(例如，节点和节点的池)相关联的状态改变，状态改变是由于由与基础设施插件框架240内的基础设施插件相关联的应用编排工具、管理用户、和/或资源管理器211所采取的动作或执行的操作而引起的。在模型和状态管理器235的指导下，状态模型238可以持久化与逻辑资源对象相关联的状态。

保留系统234可以负责处理例如经由消费API 220做出的保留请求。可以与节点池结合使用节点保留管理，以确保节点的可用性和获取(潜在地具有可用性时间估计)，用于执行生命周期实现(例如，部署由工作负载使用的节点并且移除当前由工作负载使用的节点，即，不可变节点管理)。在一些示例中，可以对池上的期望数目的节点进行保留，以确保在完成任务之前可以实现任务(例如，创建工作负载控制平面或向外扩展工作负载)而无需耗尽节点。下面参考图3进一步描述关于可以经由保留系统234执行的各种示例类型的保留和各种示例类型的动作的进一步细节。

供应器233可以负责自动化节点供应管理。在一个示例中，自动化节点供应管理包括：确保不属于任何节点池(可用节点)并且符合所限定的节点角色的节点保持在被所供应的状态中，该状态具有针对该类型节点的最新操作系统映像/固件/本输入输出系统设置。在计算环境内的初始安装时，可以对所有节点映像，以确保它们具有针对解决方案和模型类型指定的映像。随后，当新映像可用于模型类型时，可以利用当前映像来更新库存。未获取的并且属于现有池的所有可用节点可以被再循环，以确保当工作负载请求节点时，节点总是具有针对节点的模型类型设计的最新映像。如下面进一步描述的，工作负载可以决定它们何时准备好更新在它们所获取的、属于它们的(多个)节点池的节点上的映像，并且随着时间的推移可以疏散节点并且用来自库存的可用节点替换它。

池管理器237可以负责自动化池管理。在示例中，自动化管理包括：与工作负载生命周期管理过程集成的节点池的自动化管理，以确保节点和/或节点池可以保持更新或被移除用于命令或经由调度的中断。如下面进一步描述的，池状态可以反映属于池的任何节点是要被更新还是应当得到维护。以这种方式，工作负载生命周期自动化可以通过池节点迭代，以通过更新过程循环或从池中移除节点以执行维护。一旦池中的所有节点都反映“正常”状态，则池状态可以返回到“正常”状态。下面参考图4进一步描述关于节点/池状态的各种示例类型和状态之间的转换的进一步细节。

以上参照图2描述的NEM 210的各种功能单元(例如，API 220、通知器232、保留系统234、供应器233、模型和状态管理器235、以及池管理器237)以及以下参照图5至图6的流程图描述的处理可以以可执行指令的形式来实现，该可执行指令被存储在非暂态机器可读介质(例如，随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、闪存、盘驱动器等)上，并且由基于硬件的处理资源(例如，微控制器、微处理器、(多个)中央处理器核心、专用集成电路(ASIC)、现场可编程门阵列(FPGA)等)和/或以其他类型的电子电路的形式来执行。例如，处理可以由各种形式的一个或多个计算机系统(例如，服务器、刀片、台式计算机、膝上型计算机)来执行，诸如以下参考图7描述的计算机系统。

对象模型

图3根据示例示出了图示的对象模型300的示图。对象模型300表示图2的对象模型236的非限制性示例。由NEM(例如，NEM 210)使用的对象模型300可以用作抽象和流线型持久模型，用于描述基础设施(例如，基础设施112)的元素。对象模型300还可以由NEM使用，用于获取或释放基础设施的元素。基于逻辑资源对象池(例如，节点(例如，节点310)和节点的池(例如，池308))的限定的对象模型允许经由节点或实例键入系统来指定节点的质量或属性，或者可以允许在获取节点并且将其分配给池时应用于节点(例如，网络连接、连接的存储卷等)的修饰方面。计算资源可以被成组使用，其中计算的资源质量的一个或多个方面(例如，CPU类型、存储器大小、服务器模型、设备类型等)可以是核心，而其它方面(例如，存储资源、块存储、卷、网络资源、网络、虚拟网络基础设施组件)可以基于核心资源的使用是上下文的。

在本示例的上下文中，对象模型300包括三个层，包括消费模型304、解决方案模型312、和库存模型322。消费模型被示为包括保留(例如，保留306)和逻辑资源对象集(例如，节点(例如，节点310)和节点的池(例如，池308))，这些逻辑资源对象可以被用于在运行时由应用编排工具(例如，应用编排工具108)间接操纵实际计算基础设施。在消费模型304中，可以为一个或多个节点集进行保留306，从而创建一个或多个节点310的池308。消费API(例如，API 220中的一个API)可以支持对节点、池、和保留的创建、读取、更新、和删除(CRUD)操作。此外，可以提供其他管理操作(例如，列表)和生命周期实现(部署、扩展等)。

在一些示例中，保留(例如，保留306)可以是多种保留类型中的一种类型，以允许生命周期管理实现来平衡生命周期操作的需要以及生命周期操作的性能与对计算环境中的节点可用性的影响。例如，可以将保留指定为立即、延迟的高影响、延迟的低影响、和延迟的再循环。立即保留适合于高优先级任务(例如，针对Kubernetes集群创建管理平面，其中如果所有节点立刻可用则最好)。在一个示例中，如果当前供应的服务器少于由保留请求的服务器，则创建立即保留将失败。如果具有与池相同的节点角色的服务器(供应或未供应的)的总数目小于所请求的数目，则创建延迟的高影响或延迟的低影响保留将失败。这种故障可能意味着应该将更多的节点添加到NEM 210库存中，以便满足保留请求。延迟的高影响保留可以首先保留供应的服务器，然后根据需要来获得要被供应的任何附加的服务器，以满足来自未被供应的服务器的请求。该类型的保留适合于中等优先级任务(例如，向外扩展工作负载)。延迟的低影响保留可以首先保留未被供应的服务器并且获得所有剩余的服务器以满足来自被供应的服务器的请求。该类型的保留针对时间不是重要考虑因素的任务是良好的，例如，在运行的工作负载中的节点的映像更新。保留可以具有指定的持续时间。如果在持续时间内不满足保留，则保留可以超时、保留可以被删除，并且剩余的、未获得的服务器可以对其他保留可用。在保留超时之前获取的那些节点可以保留在池中。

解决方案模型312可以被用于限定和保存节点标准(例如，在属性方面)以及可以用被于解决方案工作负载的生命周期实现的类似节点的管理。可以针对解决方案限定属性，并且经由解决方案管理API使属性对将创建和管理池的编排器和IT人员可用。然后，更高等级的编排器可以利用来自池的节点，知道它们将具有期望的质量/特性以满足所限定的节点角色，而无需关心节点的备份服务器、节点位于何处、节点如何被映像，或者节点上有什么映像。以此方式，应用开发者能够集中于响应经由NEM通知的生命周期状态并且相应地重新配置其解决方案工作负载。

解决方案模型312还可以被用于指定与集成有NEM的工具/产品相关联的解决方案配置和/或定制设置。解决方案模型312可以被定制为给定解决方案，以解决由解决方案工作负载(例如，工作负载104)执行的不同类型的处理。

在本示例的上下文中，示出的解决方案模型312包括类对象(例如，服务器类314和VM类320)、节点角色316、和启动角色318。类对象可以被用于描述资源的分类(例如，服务器模型和配置编号或VM资源配置)。每个节点可以与特定角色(例如，节点角色316)相关联。角色的数目和类型特定于解决方案的类型，并且可以由管理用户通过SAAS门户(例如，SAAS门户114)来限定，该SAAS门户调用解决方案管理API(例如，API 220中的一个API)，该解决方案管理API可以转而对解决方案模型312内的对象执行适当的CRUD操作。出于说明的目的，在实现存储解决方案的上下文中，节点角色的示例可以包括网关节点、存储协议转换器节点、和数据存储节点的角色。其他解决方案可以更通常地限定节点角色(例如，Kubernetes主节点与Kubernetes工作者节点)。节点角色316可以包括描述针对相关联资源的启动配置(例如，服务器引导配置)的启动角色。在一些实现中，可以为针对给定角色的节点的最小能力、容量、和/或配置(例如，在计算资源、存储资源、和/或存储资源方面)建立标准。例如，结合MLOps解决方案，管理用户可以指定针对将用于执行推理处理的推理节点的图形处理单元(GPU)和/或最小数目的CPU核心的需求。

库存模型322可以被用于限定和持久化基础设施细节，以便选择和创建用于针对解决方案工作负载部署的基础设施。信息技术(IT)管理方或高等级编排器可以经由SAAS门户直接或间接地利用库存API(例如，API 220中的一个API)利用关于基础设施112内的机架和由机架容纳的服务器的信息来初始化库存。

对与计算环境(例如，计算环境100)相关联的基础设施的改变应当被记录到库存API中，以使在线库存保持最新，例如，具有计算环境内可用的BM/VM基础设施的库存。库存模型322还可以被用于跟踪针对每个节点角色的当前映像。当解决方案被释放时，可以建立用于解决方案模型312中的节点角色的当前映像。随着时间的推移，随着新映像可用于解决问题(例如，安全漏洞)和/或提供增强，库存API可以被用于跟踪针对应当用于解决方案的每个节点角色的最新映像。

在本示例的上下文中，库存模型322被示为包括表示服务器324、VM 328、和机架326的对象。服务器324可以具有特定服务器类(例如，服务器类314)和特定节点角色(例如，节点角色316)，并且可以与容纳对应物理服务器的特定机架(例如，机架326)相关联。类似地，VM 328可以具有特定VM类(VM类320)并且与特定节点角色(例如，节点角色316)相关联。使用该三层模型，给定的节点(例如，节点310)可以被映射到备份服务器(BM或VM)，反之亦然。

状态模型

图4根据示例示出了图示状态模型400的示图。状态模型400表示图2的状态模型238的非限制性示例。NEM(例如，NEM 210)可以使用状态模型400来表示逻辑资源对象(例如，节点和节点的池)的当前状态。在一个示例中，状态模型400内的状态转换由模型和状态管理器确定，经由状态模型持久化，然后用于触发：(i)基础设施插件功能，例如经由应用编排工具对工作负载(例如，工作负载104)的通知，以及(iii)潜在的附加编排。

NEM可以采用不可变节点方法，这意味着由基于工作负载的编排通过从其池中释放(删除)节点来处理诸如更新、重启、信任违反、中断、或故障的状态改变。从池中删除节点可以触发NEM内的进一步状态改变和附加保留编排，例如表1(下文)中描述的删除处理。状态模型400的使用简化了对逻辑资源对象的状态改变的基于工作负载的编排关系。例如，如表1(下文)所示，基于工作负载的编排可以被构造为响应于池等级处放大的状态改变(例如，放大可以意味着池中的所有节点状态中的最高优先级状态可以被用于该池，从而简化对池和要处理的节点的标识)、标识池内的待解决的节点、执行适当的预处理(例如，池扩展，工作负载疏散等)、后处理(例如，池清理)、以及释放和获取由状态改变指示的资源。在一个示例中，要在池或节点上执行的保留的预处理操作集和/或后处理操作集可以由管理用户针对每个节点状态来建立。

在一个示例中，在NEM内实现的模型和状态管理器(例如，模型和状态管理器235)可以负责确定和编排与逻辑资源对象(例如，节点和节点的池)相关联的状态改变，该状态改变是由应用编排工具(例如，应用编排108)、管理用户、和/或基础设施插件所采取的动作或所执行的操作引起的。在本示例的上下文中，节点状态可以被设置为可用状态404、正常状态406、替换状态408、移除状态410、故障状态412、或中断状态414。在示例中，立即模式标志也可以是节点状态的部分，以指示要对替换状态和移除状态采取的动作的立即程度。

当在NEM内通过库存改变或消费者保留来创建新节点时，相应地供应底层服务器(例如，在BM服务器的情况下)，并且节点开始于可用状态404。在可用状态404中，节点被提供并且准备好由工作负载使用，但是还没有与池相关联。当节点被分配给池时，节点被转换到正常状态406。从正常状态406，节点可以转换到替换状态408、移除状态410、或故障状态412。

例如，响应于确定节点要立即被替换(例如，立即模式为真)或在工作负载方便时(立即模式为假)被替换，可以将节点转换到替换状态408。当应当立即执行替换时，例如在释放热修复之后(例如，其中紧急补丁将被应用于工作负载中的服务器)并且应当立即地更新和重新启动服务器之后，立即模式可以被设置为真。当可以在工作负载方便时执行替换时，例如当替换状态是根据定期安排的维护窗口时，立即模式可以被设置为假。响应于例如由应用编排工具108经由消费API从其池中删除节点，并且在成功完成删除处理(例如，重新映像、重启、和BIOS配置)时，可以将节点放回到可用状态404中。

例如，响应于确定节点要立即被移除(例如，立即模式为真)或在工作负载方便时(立即模式为假)被移除，可以将节点转换到移除状态410。当应该立即执行移除时，例如由于计划外的中断或信任违反，立即模式可以被设置为真。当可以在工作负载的方便下执行移除时，例如，当移除状态是根据定期安排的维护窗口时，立即模式可以被设置为假。响应于例如由应用编排工具108经由消费API从其池中删除节点，并且在成功完成删除处理(例如，重映像)时，在IT管理方完成检查之前，可以将节点置于中断状态414。

例如，响应于确定备份服务器已发生故障或信任服务器已被破解，节点可以被转换到故障状态412。响应于节点被置于故障状态410，NEM可以自动地删除节点并且自动地将节点和备份服务器转换到故障状态414。

如上所述，节点可以从移除状态410或故障状态412转换到中断状态414。在本示例的上下文中，处于中断状态414的节点不被自动地重映像并且被置于可用状态404。相反，期望IT管理方在节点可以被放回到可用状态404之前，检查备份服务器并且批准其重用。从中断状态414，IT管理方可以删除节点(例如，如果故障不能被补救)或将其返回到可用状态404(例如，在成功补救故障时)。

在本示例的上下文中，NEM逻辑资源对象状态具有优先级(例如，在表1(下文)中，状态以优先级从顶部的最低优先级到底部的最高优先级的增加的优先级的示例顺序被列出)，并且池状态以优先级顺序放大。在池状态放大的示例中，给定池的状态(池状态)可以基于给定池内的节点的相应状态(节点状态)的最严重状态而被确定。以这种方式，基于工作负载的编排可以有效地轮询或监听池状态(例如，具有相对较少数目的池，通常少于五个)以触发状态改变编排，而不是在节点等级处轮询或监听(例如，具有通常大得多数量的节点)。

表1响应于从其池中删除节点的示例节点状态和删除处理

/>

/>

NEM处理

图5根据示例示出了图示由NEM执行的处理的流程图。该处理可以使用例如但不限于图2的NEM 210来实现，以促进针对异构基础设施(例如，基础设施112)上的工作负载(例如，工作负载104)的生命周期管理。

在框510处，维护消费模型，消费模型中异构基础设施以概括形式被表示为逻辑资源对象。在一个示例中，逻辑资源对象包括节点和节点的池。每个节点可以具有例如在NEM的对象模型(例如，对象模型300)的解决方案模型(例如，解决方案模型312)内限定的节点角色(例如，节点角色316)。相应节点角色可以指示节点可操作以基于节点的相应属性向工作负载(例如，工作负载104中的一个工作负载)提供的特定功能。节点的属性可以在节点的相应计算配置、存储、和/或网络资源方面被表达。

在框520处，维护状态模型，通过该状态模型，逻辑资源对象在多个状态之中转换。响应于逻辑资源对象的转换，可以向与工作负载相关联的应用编排工具(例如，应用编排工具108)提供通知。多个状态和转换可以如上参考图4所述。

在框530处，通过提供消费API(例如，API 220中的一个API)来抽象应用编排工具与由工作负载利用的异构基础设施的元素的交互，通过该消费API，对管理异构基础设施的生命周期的请求参考逻辑资源对象而被表达。例如，如上参考图3所述，消费API可以支持节点和节点的池上的各种CRUD操作、管理操作、和生命周期实现。

图6根据另一示例示出了图示由NEM执行的处理的流程图。该处理可以使用例如但不限于图2的NEM 210来实现，以促进基础设施(例如，基础设施112)内的异构计算资源上的针对工作负载(例如，工作负载104)的生命周期管理。

在框610处，提供消费API以从应用编排工具(例如，应用编排工具108)接收对管理针对工作负载的异构计算资源的生命周期的请求。在示例中，应用编排工具可以使用消费API来经由与逻辑资源对象(例如，节点和节点的池)的交互来间接地管理和/或操纵底层基础设施。

在框620处，通过产生对集成基础设施插件进行调用以执行与请求相关联的操作，实现请求。例如，创建节点集或保留节点集以与特定池相关联可以触发NEM，以立即或在后台使BM供应工具或虚拟化工具(视情况而定)供应对应的BM或VM基础设施。

在框630处，响应于调用的完成，更新表示针对工作负载的异构计算资源的生命周期的对象模型和/或状态模型。例如，响应于BM或VM基础设施的供应的完成，取决于节点的状态，保留的节点可以从可用状态(例如，可用状态404)被转换到正常状态(例如，正常状态406)。

在框640处，通知应用编排工具，对状态模型内的异构计算资源的状态改变。例如，如上参考图4所述，可以通知应用编排工具(例如，经由来自通知器(例如，通知器232)或基于REST的轮询的自动通知)关于的节点状态改变，该节点状态改变指示需要替换、移除、或恢复故障节点(例如，由于执行热修复、映像更新的可用性、或定期安排的维护、或由于检测到服务器故障)。

虽然在参考图5至图6描述的示例的上下文中，包括了多个枚举的框，但是应当理解，其他示例可以包括在枚举的框之前、之后和/或、之间的附加的框。类似地，在一些示例中，所枚举的框中的一个或多个框可以被省略或以不同的顺序被执行。

计算机系统

图7根据第一示例示出了的计算机系统的框图。在图7所示的示例中，计算机系统700包括耦合到非暂态、利用指令编码的机器可读介质720的处理资源710，以执行本文所述的一个或多个过程。计算机系统700可以是服务器、服务器集群、计算机设备、工作站、融合系统、超融合系统等。计算机系统700可以被包括在特定计算环境(例如，云计算环境100)之中的要管理的基础设施(例如，基础设施112)中。在其他示例中，计算机系统700可以在云中(例如，公共云)并且与要管理的基础设施(例如，基础设施112)通信，或者可以是与要管理的基础设施在相同数据中心内的管理服务器。

处理资源710可以包括微控制器、微处理器、CPU核、GPU核，ASIC、FPGA、和/或适合于从机器可读介质720取回和/或执行指令以执行与本文所述的各种示例相关的功能的其它硬件设备。附加地或备选地，处理资源710可以包括用于执行本文描述的指令的功能的电子电路。

机器可读介质720可以是适合于存储可执行指令的任何介质。机器可读介质720的非限制性示例包括RAM、ROM、EEPROM、闪存、硬盘驱动器、光盘等。机器可读介质720可以是非暂态介质，其中术语“非暂态”不包括暂态传播信号。如图7所示，机器可读介质720被布置在计算机系统700内，在这种情况下，可以认为可执行指令“安装”或“嵌入”在计算机系统700上。备选地，机器可读介质720可以是便携式(例如，外部)存储介质，并且可以是“安装包”的部分。存储在机器可读介质720上的指令可以用于至少部分实现本文描述的方法中的一个或多个方法。

在本示例的上下文中，机器可读介质720被编码有可执行指令集730至750。应当理解，在备选实现中，被包括在一个框内的可执行指令和/或电子电路的部分或全部可以被包括在图中所示的不同框中或未示出的不同框中。

指令730在执行时可以使处理资源710维护消费模型，消费模型中异构基础设施以概括形式被表示为逻辑资源对象，包括节点和多个节点的池。在一个示例中，指令730可以用于执行图5的框510。

指令740在执行时可以使处理资源710维护状态模型，通过该状态模型，逻辑资源对象在多个状态之中转换，并且响应于状态模型，通知被提供到与工作负载相关联的应用编排工具。在一个示例中，指令740可以用于执行图5的框520。

指令750在执行时可以使处理资源710通过提供API来抽象应用编排工具与由工作负载利用的异构基础设施的交互，通过该API，对管理异构基础设施的生命周期的请求参考逻辑资源对象而被表达。在一个示例中，指令750可以用于执行图5的框530。

在以上描述中，阐述了许多细节以提供对本文公开的主题的理解。然而，可以实践实现而不用一些或所有这些细节。其它实现可以包括对上述细节的修改和变型。所附权利要求旨在覆盖这些修改和变型。

Claims (20)

1.一种方法，所述方法包括：

维护消费模型，所述消费模型中异构基础设施以概括形式被表示为逻辑资源对象，所述逻辑资源对象包括节点和所述节点的多个池，其中所述节点具有相应节点角色，所述相应节点角色指示所述节点可操作以基于所述节点的相应属性向工作负载提供的特定功能；

维护状态模型，通过所述状态模型，所述逻辑资源对象在多个状态之中被转换，并且响应于所述状态模型，通知被提供到与所述工作负载相关联的应用编排工具；以及

通过提供应用编程接口API来抽象所述应用编排工具与由所述工作负载利用的所述异构基础设施的子集的交互，通过所述应用编程接口，用于管理所述异构基础设施的所述子集的生命周期的请求参考所述逻辑资源对象而被表达。

2.根据权利要求1所述的方法，还包括：通过产生对集成基础设施插件的调用以执行与所述请求相关联的操作，实现所述请求。

3.根据权利要求2所述的方法，其中所述集成基础设施插件包括裸机供应工具和虚拟化工具。

4.根据权利要求1所述的方法，还包括：向所述应用编排工具通知状态模型改变。

5.根据权利要求1所述的方法，其中所述相应属性在所述节点的相应能力、容量、或者配置方面被表达。

6.根据权利要求1所述的方法，还包括：提供保留系统，通过所述保留系统，所述节点与所述多个池相关联。

7.根据权利要求6所述的方法，其中所述节点与所述多个池的关联促进将所述节点作为具有一致的自动化生命周期管理操作和状态的组进行管理。

8.根据权利要求1所述的方法，还包括：作为后台进程的部分并且在与所述多个池相关联之前，供应具有特定节点角色的所述节点的子集，以促进快速可用性以供所述工作负载使用。

9.一种系统，所述系统包括：

处理资源；以及

非暂态计算机可读介质，被耦合到所述处理资源，所述非暂态计算机可读介质具有存储在其中的指令，所述指令在由所述处理资源执行时，使所述处理资源：

提供消费应用编程接口API，以从应用编排工具接收用于管理针对工作负载的异构计算资源的生命周期的请求；

通过产生对集成基础设施插件的调用以执行与所述请求相关联的操作，实现所述请求；

响应于所述调用的完成，更新表示针对所述工作负载的所述异构计算资源的所述生命周期的对象模型或者状态模型；以及

向所述应用编排工具通知所述异构计算资源的状态改变。

10.根据权利要求9所述的系统，其中所述指令还使所述处理资源提供针对由所述应用编排工具经由保留系统管理的工作负载的所述异构计算资源的可用性。

11.根据权利要求10所述的系统，其中所述保留系统将所述异构计算资源与池相关联，以促进将所述异构计算资源作为具有一致的自动化生命周期管理操作和状态的组进行管理。

12.根据权利要求9所述的系统，其中所述集成基础设施插件包括裸机供应工具或者虚拟化工具。

13.一种存储指令的非暂态机器可读介质，所述指令在由计算机系统的处理资源执行时，使所述处理资源：

维护消费模型，所述消费模型中异构基础设施以概括形式被表示为逻辑资源对象，所述逻辑资源对象包括节点和所述节点的多个池，其中所述节点具有相应节点角色，所述相应节点角色指示所述节点可操作以基于所述节点的相应属性/相应质量向工作负载提供的特定功能；

维护状态模型，通过所述状态模型，所述逻辑资源对象在多个状态之中被转换，并且响应于所述状态模型，通知被提供到与所述工作负载相关联的应用编排工具；以及

通过提供应用编程接口API来抽象所述应用编排工具与由所述工作负载利用的所述异构基础设施的子集的交互，通过所述应用编程接口，用于管理所述异构基础设施的所述子集的生命周期的请求参考所述逻辑资源对象而被表达。

14.根据权利要求13所述的非暂态机器可读介质，其中所述指令还使所述处理资源通过产生对集成基础设施插件的调用以执行与所述请求相关联的操作，实现所述请求。

15.根据权利要求14所述的非暂态机器可读介质，其中所述集成基础设施插件包括裸机供应工具和虚拟化工具。

16.根据权利要求14所述的非暂态机器可读介质，其中所述指令还使所述处理资源向所述应用编排工具通知状态模型改变。

17.根据权利要求14所述的非暂态机器可读介质，其中所述相应属性/所述相应质量在所述节点的相应能力、容量、和/或者配置方面被表达。

18.根据权利要求14所述的非暂态机器可读介质，其中所述指令还使所述处理资源利用保留系统以将所述节点与所述多个池相关联。

19.根据权利要求18所述的非暂态机器可读介质，其中所述节点与所述多个池的关联促进将所述节点作为具有一致的自动化生命周期管理操作和状态的组进行管理。

20.根据权利要求14所述的非暂态机器可读介质，其中所述指令还使所述处理资源作为后台进程的部分并且在与所述多个池相关联之前，供应具有特定节点角色的所述节点的子集，以促进快速可用性以供所述工作负载使用。

Images