DE102022108636A1

DE102022108636A1 - Lebenszyklusmanagement für workloads in heterogenen infrastrukturen

Info

Publication number: DE102022108636A1
Application number: DE102022108636.4A
Authority: DE
Inventors: Bryan P. Murray; Mark Perreira; Jayashree Sundarachar Beltur
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2021-11-24
Filing date: 2022-04-08
Publication date: 2023-05-25
Also published as: CN116166413A; US20230161643A1

Abstract

Die hier beschriebenen Beispiele beziehen sich auf die Bereitstellung eines poolbasierten automatisierten Lebenszyklusmanagements der Infrastruktur über abstrahierte Ressourcen. Einem Beispiel zufolge wird ein Verbrauchsmodell gepflegt, in dem heterogene Infrastruktur in einer verallgemeinerten Form als logische Ressourcenobjekte dargestellt wird, einschließlich Knoten und Pools der Knoten. Die Knoten verfügen über entsprechende Knotenrollen, die die spezifische Funktionalität angeben, die die Knoten auf der Grundlage der jeweiligen Attribute/Eigenschaften der Knoten für eine Arbeitslast bereitstellen können. Es wird ein Zustandsmodell verwaltet, durch das die logischen Ressourcenobjekte zwischen den Zuständen übergehen und auf das hin Benachrichtigungen an ein mit dem Workload verbundenes AnwendungsOrchestrierungstool bereitgestellt werden. Die Interaktionen des Anwendungsorganisationswerkzeugs mit der von der Arbeitslast genutzten heterogenen Infrastruktur werden abstrahiert, indem eine API bereitgestellt wird, über die Anforderungen zur Verwaltung eines Lebenszyklus der heterogenen Infrastruktur mit Bezug auf die logischen Ressourcenobjekte ausgedrückt werden.

Description

HINTERGRUND
Die Verwaltung des Lebenszyklus von Anwendungen und Infrastrukturen kann sich auf ein breites Spektrum von Aktivitäten beziehen, zu denen u. a. die Erkennung, Bereitstellung, Aktualisierung, Patching, Änderungsverwaltung, Konfigurationsverwaltung und die Verwaltung von Sicherheitslücken gehören. Einige Aktivitäten des Lebenszyklusmanagements, wie z. B. die Durchführung von Upgrades und die Patch-Verwaltung, waren traditionell mit manuellen, sich wiederholenden Aufgaben verbunden, die anfällig für Konfigurations- und Implementierungsfehler sind, was nun durch verschiedene Cloud-Automatisierungstools und Lebenszyklusmanagement-Software für die Durchführung eines automatisierten Lebenszyklusmanagements behoben wird.
Ein automatisiertes Lebenszyklusmanagement kann zur effizienten Verwaltung von Anwendungen in einer Cloud-Computing-Infrastruktur eingesetzt werden. Automatisiertes Lebenszyklusmanagement in Kombination mit Cloud-nativem Anwendungsdesign (z. B. Anwendungen, die so konzipiert sind, dass sie von Änderungen im Lebenszyklus der Computerinfrastruktur unabhängig sind) ist die Norm für einige Lebenszyklusmanagementkonzepte.
Figurenliste
Die hierin beschriebenen Aspekte sind beispielhaft und nicht einschränkend in den Figuren der beigefügten Zeichnungen dargestellt, in denen sich gleiche Bezugsziffern auf ähnliche Elemente beziehen.

1 zeigt ein Blockdiagramm einer Cloud-Computing-Umgebung gemäß einem Beispiel.
2 zeigt ein Blockdiagramm eines NEM (Node Environment Manager) gemäß einem Beispiel.
3 zeigt ein Diagramm, das ein Objektmodell gemäß einem Beispiel illustriert.
4 zeigt ein Diagramm, das ein Zustandsmodell gemäß einem Beispiel illustriert.
5 zeigt ein Flussdiagramm, das die von einem NEM durchgeführte Verarbeitung gemäß einem Beispiel illustriert.
6 zeigt ein Flussdiagramm, das die Verarbeitung durch einen NEM gemäß einem anderen Beispiel veranschaulicht.
7 zeigt ein Blockdiagramm eines Computersystems gemäß einem Beispiel.

DETAILLIERTE BESCHREIBUNG
Die hier beschriebenen Beispiele beziehen sich auf die Bereitstellung eines poolbasierten automatisierten Lebenszyklusmanagements der Infrastruktur über abstrahierte Ressourcen. Während die Verwaltung des Lebenszyklus der Infrastruktur in der Regel unabhängig vom Lebenszyklus einer Anwendung erfolgt, gibt es Fälle, in denen eine Anwendung in den Lebenszyklus der zugrundeliegenden Datenverarbeitungsinfrastruktur integriert werden muss, die mit einer Cloud vergleichbar sein kann oder auch nicht, und die nicht unabhängig und ohne Rücksicht auf den Lebenszyklus der Anwendung verwaltet werden kann. Dies ist z. B. der Fall, wenn es sich bei der Anwendung um einen Dienst handelt (z. B. eine dienstähnliche Anwendung (z. B. Software as a Service (SaaS)) zur Erstellung und Verwaltung komplexer Rechnersystemarchitekturen, wie z. B. Clustern. In diesem Fall muss der Lebenszyklus der Datenverarbeitungsinfrastruktur mit der Konfigurationsorchestrierung der Anwendung zusammenarbeiten. Ein weiteres Beispiel ist eine zustandsabhängige Anwendung wie ein Speicherdienst, bei dem die zugrunde liegende Datenverarbeitungsinfrastruktur in die Anwendung integriert werden muss, um bei Bedarf die Wiederherstellung dauerhafter Zustandsinformationen für den Speicherdienst in der Datenverarbeitungsinfrastruktur zu gewährleisten.
Wenn ein Unternehmen eine Cloud-Erfahrung für lokale Arbeitslasten bereitstellen möchte, sind Anwendungs-Orchestrationen verschiedenen Komplexitäten der zugrunde liegenden Computer-Infrastruktur der Cloud-Computing-Umgebung ausgesetzt, darunter beispielsweise Bereitstellungsmechanismen und Ressourcenmanagement-Tools (z. B. KubeVirt - ein Open-Source-Projekt, VMWare vCenter und dergleichen). Zusätzliche Herausforderungen ergeben sich für die Anwendungsorchestrierung im Kontext einer begrenzten Datenverarbeitungsumgebung und/oder einer Datenverarbeitungsumgebung mit heterogener Infrastruktur. Beispielsweise kann ein Standort, eine Installation oder ein Rechenzentrum (hier allgemein als Rechenumgebung bezeichnet) eine begrenzte Anzahl (z. B. 20 bis 80) von Servern umfassen, die jeweils Rechenressourcen (z. B. Rechen-, Speicher- und/oder Netzwerkressourcen) bereitstellen und in einer begrenzten Anzahl (z. B. 1 oder 2) von Racks untergebracht sind. Die in einer bestimmten Computerumgebung verfügbaren Server können auch von verschiedenen Anbietern hergestellt werden, unterschiedliche Modelle darstellen und/oder unterschiedliche Attribute aufweisen, die auch als Qualitäten bezeichnet werden und z. B. Fähigkeiten, Kapazitäten und/oder Konfigurationen umfassen können.
Darüber hinaus können Anwendungen vom Typ Dienst und/oder zustandsabhängige Anwendungen die Überwachung des Status der zugrundeliegenden Infrastruktur beinhalten, die für einen bestimmten Dienst oder eine bestimmte Lösung genutzt wird (z. B. Machine Learning Operations as a Service (MLOpsaaS), Container as a Service (CaaS), Virtual Machine as a Service (VMaaS), Storage as a Service (STaaS) usw.), sowie zugehörige Images zur Handhabung verschiedener Änderungen (z. B. die Verfügbarkeit eines Betriebssystem-Updates, ein geplanter oder ungeplanter Ausfall). Im Allgemeinen wäre es wünschenswert, Anwendungen von derartigen Komplexitäten und infrastrukturspezifischen Details zu isolieren, damit sich die Anwendungen unter anderem auf die für die jeweilige Lösung zentralen Funktionen und Merkmale konzentrieren können.
So wird in den hier beschriebenen Beispielen vorgeschlagen, den Betrieb der Computerinfrastruktur aus der Sicht der Anwendungen zu vereinfachen und zu verallgemeinern, indem ein Software-Framework in Form einer Zwischenschicht eingeführt wird, die logisch zwischen den Anwendungen und ihren jeweiligen Orchestrierungswerkzeugen auf der einen Seite und der Computerinfrastruktur (einschließlich zugehöriger Bereitstellungsmechanismen und Ressourcenverwaltungswerkzeuge) angeordnet ist. Gemäß verschiedenen Beispielen bietet ein Software-Framework ein poolbasiertes Lebenszyklusmanagement von Ressourcen für Anwendungen. Beispielsweise können Elemente einer Recheninfrastruktur als Gruppen ähnlicher Einheiten (z. B. Rechen-, Speicher- und Netzwerkeinheiten, die möglicherweise ähnliche Attribute oder Qualitäten aufweisen) mit konsistenten automatisierten Lebenszyklusmanagementoperationen und -zuständen verwaltet werden.
Wie weiter unten beschrieben, bietet dieser Rahmen (der hier als NEM (Node Environment Manager) bezeichnet werden kann) in einem Beispiel ein System für Ressourcenobjekte und Zustandsmodelle sowie Informationen zur Ressourcenkonfiguration und -inventarisierung, einen Infrastruktur-Plugin-Rahmen für die Integration von maßgeschneiderten Infrastrukturwerkzeugen und Verwaltungsprodukten oder Ressourcenverwaltungsfunktionen für Cloud-Dienste sowie eine Anwendungsprogrammierschnittstelle (API) für Ressourcenverbrauch und Lebenszyklusereignisse. Über die Verbrauchs-API können Anwendungs-Orchestrationen beispielsweise die zugrunde liegende Infrastruktur über Interaktionen mit logischen Ressourcenobjekten (z. B. Knoten und Knotenpools) indirekt verwalten und/oder manipulieren.
Als Teil des NEM-Frameworks steht eine nach Norden gerichtete API für die normalisierte Beschaffung von Ressourcen in einer Cloud-Computing-Umgebung zur Verfügung, indem ein Reservierungssystem für die Beschaffung abstrahierter Rechenressourcen (z. B. Pools, Knoten usw.) verwendet wird, ein Benachrichtigungsmechanismus für Änderungen im Lebenszyklus von Ressourcen, um Integrationen mit Anwendungsorchestrierungstools auszulösen, und eine nach Süden gerichtete API für Infrastruktur-Plugins, um die Integration von Computing-Infrastruktur-Tools und -Diensten (z. B. über verschiedene entwickelte Plugins) zu ermöglichen, die die nach Süden gerichteten API-Aufrufe unterstützen. Auf diese Weise können Werkzeuge zur Anwendungsorchestrierung mit einer einfachen API für den Erwerb von Rechenressourcen ausgestattet werden, ohne dass ein Verständnis der komplexen Details der zugrunde liegenden Recheninfrastruktur der Cloud-Computing-Umgebung, der Bereitstellungsmechanismen und der Verwaltungswerkzeuge erforderlich ist. Darüber hinaus können komplexe Änderungen im Lebenszyklus, wie z. B. ein Betriebssystem-, Firmware- oder Software-Update (entweder auf Bare-Metal-Maschinen/Servern oder virtuellen Maschinen), ein geplanter Ausfall oder eine Störung sowie ein nicht vertrauenswürdiger Start bzw. eine nicht vertrauenswürdige Aktivität, für die Anwendung nahezu transparent gemacht werden. Beispielsweise kann die Anwendung als Reaktion auf Benachrichtigungen von NEM die Neukonfiguration von Anwendungsinstanzen ohne Rücksicht auf die Komplexität der Datenverarbeitungsinfrastruktur oder die Details des Verwaltungstools oder -dienstes organisieren.
Ein oder mehrere Tools zur Anwendungsorchestrierung können über logische Pools von Knoten, die in einem Verbrauchsmodell dargestellt und über Reservierungen erworben werden, auf Rechenressourcen in der Cloud-Computing-Umgebung zugreifen. Die Werkzeuge zur Anwendungsorchestrierung können diese erworbenen Ressourcen konfigurieren, um Instanzen von Anwendungen zu erstellen. Knoten, die logischer Natur sind, können entweder BM-Maschinen oder VMs darstellen, können so definiert werden, dass sie einer Instanz einer Anwendung auf der Grundlage der Attribute des Knotens (z. B. Fähigkeiten, Kapazität und/oder Konfiguration, z. B. in Bezug auf Rechenleistung, Speicherung und/oder Vernetzung) eine bestimmte Funktionalität bieten, und können von einem NEM in einem Pool von Knoten organisiert werden, die während des gesamten Lebenszyklus über integrierte Tools und Verwaltungsprodukte automatisch und gemeinsam verwaltet werden.
In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt, um ein umfassendes Verständnis des hier offengelegten Gegenstands zu ermöglichen. Einem Fachmann wird jedoch klar sein, dass die Umsetzung der hier beschriebenen Aspekte auch ohne einige dieser spezifischen Details durchgeführt werden kann.
Die Begriffe „verbunden“ oder „gekoppelt“ und verwandte Begriffe werden in einem operativen Sinne verwendet und sind nicht unbedingt auf eine direkte Verbindung oder Kopplung beschränkt. So können beispielsweise zwei Geräte direkt oder über ein oder mehrere zwischengeschaltete Medien oder Geräte gekoppelt sein. Ein weiteres Beispiel ist, dass Geräte so gekoppelt sein können, dass Informationen zwischen ihnen ausgetauscht werden können, ohne dass sie eine physische Verbindung miteinander haben. Auf der Grundlage der hierin enthaltenen Offenlegung wird ein Fachmann eine Vielzahl von Möglichkeiten erkennen, wie eine Verbindung oder Kopplung im Sinne der oben genannten Definition besteht.
Terminologie
Wenn es in der Spezifikation heißt, dass ein Bauteil oder ein Merkmal enthalten sein „kann“, „kann“, „könnte“ oder „könnte“, so muss dieses Bauteil oder Merkmal nicht enthalten sein oder das Merkmal aufweisen.
Wie in der vorliegenden Beschreibung und in den folgenden Ansprüchen verwendet, schließt die Bedeutung von „a“, „an“ und „die“ den Plural ein, sofern der Kontext nicht eindeutig etwas anderes vorschreibt. Wie in der vorliegenden Beschreibung verwendet, schließt die Bedeutung von „in“ auch „in“ und „am“ ein, sofern der Kontext nicht eindeutig etwas anderes vorschreibt.
Die Ausdrücke „in einem Beispiel“, „gemäß einem Beispiel“ und dergleichen bedeuten im Allgemeinen, dass das bestimmte Merkmal, die Struktur oder die Eigenschaft, die auf den Ausdruck folgt, in mindestens einem Beispiel der vorliegenden Offenbarung enthalten ist und in mehr als einem Beispiel der vorliegenden Offenbarung enthalten sein kann. Wichtig ist, dass sich solche Ausdrücke nicht unbedingt auf dasselbe Beispiel beziehen.
Wie hier verwendet, bezieht sich der Begriff „Infrastruktur“ im Allgemeinen auf physische Computersysteme (z. B. Rack-Server, Blade-Server, Blades, Storage-Arrays, Storage-Server, hyperkonvergente Plattformen usw.) und/oder virtuelle Computersysteme (z. B. VMs, die auf physischen Computersystemen laufen), die in einer Computerumgebung verfügbar sind. Jede einzelne Komponente oder jedes Infrastrukturelement kann differenzierte Rechenressourcen (z. B. Rechenressourcen (zur Durchführung von Berechnungen), Speicherressourcen (zur Speicherung von Daten) und/oder Netzwerkressourcen (zur Kommunikation von Daten)) zur Nutzung durch die in der Rechenumgebung laufenden Arbeitslasten bereitstellen. Wie bereits erwähnt, kann eine Rechenumgebung vor Ort heterogen sein (z. B. BM-Maschinen und/oder VMs mit unterschiedlichen Rechenressourcen) und/oder eine begrenzte Anzahl von Servern umfassen. In einigen Beispielen kann ein NEM ein Inventar der BM/VM-Infrastruktur in der Anlage führen.
Ein „Knoten“, wie er hier verwendet wird, stellt ein abstrahiertes Element der Infrastruktur oder einen logischen Satz von einer oder mehreren mit der Infrastruktur verbundenen Rechenressourcen dar. Je nach der jeweiligen Implementierung können Knoten BM-Maschinen oder VMs darstellen und so definiert werden, dass sie einer Anwendungsinstanz auf der Grundlage der Knotenattribute (z. B. Fähigkeiten, Kapazität und/oder Konfiguration, z. B. in Bezug auf Rechenleistung, Speicherung und/oder Vernetzung) spezifische Funktionen bieten. In den hier beschriebenen Beispielen kann ein NEM Knoten in Gruppen organisieren, deren Lebenszyklen gemeinsam über integrierte Tools und/oder Managementprodukte verwaltet werden. In einigen Beispielen unterhält das NEM ein Infrastrukturmodell, um die zugrundeliegenden Server (z. B. welches Rack und welcher Server) im Bestand zu verfolgen, der durch die Knoten im Verbrauchsmodell repräsentiert wird.
„Orchestrierung“ bezieht sich im Allgemeinen auf die automatisierte Konfiguration, Verwaltung und/oder Koordinierung von Computersystemen, Anwendungen, Rechenressourcen und/oder Diensten.
Unter „Anwendungsorchestrierung“ oder „Dienstorchestrierung“ versteht man den Prozess der Automatisierung der Bereitstellung, Verwaltung, Skalierung, Vernetzung, Integration und Verfügbarkeit von Anwendungen und/oder Diensten zur Verarbeitung oder Synchronisierung von Daten in Echtzeit. In einigen Fällen bestehen die Anwendungen aus einer Vielzahl von Software-Containern. Ein Container kann einen oder mehrere Workloads enthalten.
Ein Tool zur Anwendungsorchestrierung ist ein Programm (das in der Regel von einem Systemadministrator in einer Cloud-Computing-Umgebung ausgeführt wird), das die Anwendungsorchestrierung implementiert.
Cloud Computing-Umgebung
1 zeigt ein Blockdiagramm einer Cloud-Computing-Umgebung 100 gemäß einem Beispiel. Im Kontext des vorliegenden Beispiels umfasst die Cloud-Computing-Umgebung 100 ein Cloud-Computing-System 102, ein SaaS-Portal 114, über das Benutzer mit verschiedenen Aspekten des Cloud-Computing-Systems 102 interagieren und diese konfigurieren können, sowie externe Anbieter 116 (z. B. BM-Anbieter, Vertrauensanbieter, VM-Anbieter und/oder Speicheranbieter). Das Cloud-Computing-System 102 kann sich vor Ort in einem Rechenzentrum oder einer Kolokation befinden.
In einigen Implementierungen kann die Infrastruktur 112 Eigentum eines Nutzers oder einer Nutzerorganisation sein oder sich in deren Besitz befinden und von einem Infrastrukturanbieter (dessen Kunde der Nutzer oder die Nutzerorganisation ist) verwaltet werden. In einigen Implementierungen kann die Infrastruktur 112 dem Benutzer oder der Organisation des Benutzers (z. B. in einem Rechenzentrum oder einer Kolokation des Benutzers oder der Organisation des Benutzers) vom Infrastrukturanbieter zur Nutzung als Service in einem Pay-per-Use-Finanzmodell bereitgestellt werden. In einigen Implementierungen kann ein unten beschriebener Knotenumgebungsmanager 110 vom Infrastrukturanbieter als Teil der Verwaltung für die Nutzung als Service bereitgestellt werden.
Das Cloud-Computing-System 102 kann eine oder mehrere Arbeitslasten 104 ausführen. Die Arbeitslasten 104 können aus Daten und Anwendungen bestehen, wobei die Infrastruktur 112 den Arbeitslasten 104 Rechenressourcen (z. B. Rechen-, Speicher- und/oder Netzwerkressourcen) zur Verfügung stellt, um Aufgaben auszuführen. Die Arbeitslasten 104 können eine Schnittstelle zur Laufzeit 106 (z. B. eine Laufzeitumgebung mit einem Betriebssystem (OS), einem Virtual Machine Manager (VMM) oder Hypervisor oder anderer Systemsoftware) bilden, um die Rechenressourcen innerhalb der Infrastruktur 112 zu nutzen. Je nach Standort kann die Infrastruktur 112 einen heterogenen Ressourcenpool mit differenzierten Servern und/oder VM-Instanzen sowie anderen elektronischen und/oder mechanischen Komponenten (z. B. Server-Racks (nicht dargestellt), Netzteile (nicht dargestellt) usw.) umfassen.
In einem Beispiel stellt der Knotenumgebungsmanager (NEM) 110 eine Software-Zwischenschicht dar, die logisch zwischen den Anwendungsorchestrierungstools (z. B. dem Anwendungsorchestrierungstool 108), die im Cloud-Computing-System 102 laufen, und der Infrastruktur 112 angeordnet ist. Wie weiter unten beschrieben, kann NEM 110 aus einer Reihe von konzeptionellen Komponenten bestehen, darunter Bestandsverwaltung, Knotenpoolverwaltung, Knotenreservierungsverwaltung, automatisierte Knotenbereitstellungsverwaltung und/oder automatisierte Poolverwaltung. Zusätzlich zu einer Verbrauchs-API kann NEM 110 beispielsweise auch eine Bestands-API bereitstellen, über die ein administrativer Benutzer des Cloud-Computing-Systems 102, der beispielsweise über das SaaS-Portal 114 auf NEM 110 zugreift, einen Bestand an Racks und differenzierten Servern der Infrastruktur 112 verwalten kann, um eine Reihe von Knotenpools für übergeordnete Orchestratoren (z. B. das Anwendungsorchestrierungstool 108) anzubieten.
In einem Beispiel kann das Anwendungsorchestrierungstool 108 vom Verwaltungsbenutzer verwendet werden, um das automatisierte Lebenszyklusmanagement der Infrastruktur 112 für Arbeitslasten 104 zu konfigurieren.
NEM 110 kann eine vereinfachte API für die Ressourcennutzung bereitstellen, die es dem Anwendungsorchestrierungstool 108 ermöglicht, auf einfache Weise Rechenressourcen für die Arbeitslasten 104 zu reservieren, zu erwerben und zu verwalten, die von der Infrastruktur 112 des Cloud-Computing-Systems 102 unterstützt werden, ohne dass Kenntnisse über die komplexen Details der Verwaltung von Rechenressourcen (insbesondere für BM-Ressourcen) erforderlich sind. Wie weiter unten beschrieben, ermöglicht die von der Verbrauchs-API bereitgestellte Abstraktionsebene es Arbeitslasten, Knoten zu erwerben, ohne zu wissen, ob die zugrunde liegenden Server (z. B. zur Bereitstellung der Rechenressourcen) BM-Maschinen oder VMs sind, und indem die Rolle des Knotens bei der Definition eines Pools datengesteuert beschrieben wird. Darüber hinaus kann NEM 110 Arbeitslasten 104 über Zustandsänderungen der Rechenressourcen benachrichtigen, wenn Knoten oder Pools an Lebenszyklusänderungen beteiligt sind (z. B. infolge der Verfügbarkeit von Betriebssystem- oder Software- (SW) oder Firmware-Updates, geplanter oder ungeplanter Ausfälle, nicht vertrauenswürdiger Aktivitäten usw.). Das Anwendungsorchestrierungstool 108 kann dann die Zustandsänderungen durch NEM 110 auflösen, indem es neue Knoten reserviert und erwirbt und alte Knoten aus ihren Pools entfernt (z. B. durch unveränderliche Knotenbehandlung), wodurch eine Abweichung der Arbeitslastkonfiguration und damit auch die Neukonfiguration von Instanzen von Arbeitslasten vermieden werden kann.
In einem Beispiel kann das NEM 110 auch die Bereitstellung von Knoten im Hintergrund automatisieren. Beispielsweise können Knoten mit einer definierten Rolle (z. B. als Teil einer vorbestimmten Arbeitslastkonfiguration) vor ihrer Erfassung (z. B. vor oder in Reaktion auf eine Reservierung) erstellt werden, um die sofortige Verfügbarkeit für die Nutzung durch Arbeitslasten 104 zu erleichtern, sobald diese vom Anwendungsorchestrierungstool 108 erfasst wurden. Dies kann die Leistung der Knotenerfassung verbessern, da der Aufbau von BM-Knoten in der Regel zeitaufwendig ist. Diese Funktion kann auch für den Aufbau von VM-Knoten von Vorteil sein, die im Allgemeinen als schnell bereitzustellen gelten, aber je nach Komplexität des Betriebssystems/der SW in ihren jeweiligen Laufzeitumgebungen auch langsam aufgebaut werden können.
Knoten-Umgebungs-Manager (NEM)
2 zeigt ein Blockdiagramm eines Knotenumgebungsmanagers (NEM) 210 gemäß einem Beispiel. Der NEM 210 ist ein nicht begrenztes Beispiel für den NEM 110 von 1. Im Kontext des vorliegenden Beispiels umfasst NEM 210 nordgebundene APIs 220 (z. B. eine Verbrauchs-API, eine Bestands-API und eine weiter unten beschriebene Lösungskonfigurations-API), ein Ressourcenobjekt- und Zustandsmodellsystem 230 und ein Infrastruktur-Plugin-Framework mit einer südgebundenen API 240.
Das Infrastruktur-Plugin-Framework 240 kann verwendet werden, um verschiedene Tools, Verwaltungsprodukte und/oder Cloud-APIs in Zustands- und Lebenszyklusdefinitionen zu verallgemeinern und zu harmonisieren, die mit dem NEM 210 verbunden sind. Beispielsweise kann das Infrastruktur-Plugin-Framework 240 Tools zur Verwaltung physischer Ressourcen und der Infrastruktur integrieren (z. B. Ressourcenmanager 211 über BM-Plugins (z. B. Bare-Metal-Bereitstellungstools), Vertrauens-Plugins (z. B. Keylime - ein Open-Source-Projekt oder andere TPM-Lösungen (Trusted Platform Module) zur Remote-Boot-Attestierung und Laufzeit-Integritätsmessung), VM-Plugins (z. B. KubeVirt, Kubernetes KVM-Virtualisierungsmanagement oder andere Virtualisierungstools) und/oder Speicher-Plugins) und dergleichen. Während solche Tools und Lösungen alternativ in das NEM 210 eingebettet sein können, hat die Verwendung eines Plugin-Ansatzes in einigen Implementierungen den Vorteil, dass sich das NEM 210 auf die Objekt-/Zustandsverwaltung konzentrieren kann und Anwendungen einfacher und leichter zu erstellen und zu warten sind. Darüber hinaus kann die NEM 210 mit dem Plugin-Ansatz im Laufe der Zeit leichter um weitere Lebenszyklus-Management-Funktionen erweitert werden, und wenn sie in den automatisierten Lebenszyklus von Anwendungs-Orchestrationen integriert wird, können flexible und dauerhafte Anwendungs- und Infrastruktur-Architekturen geschaffen werden.
Das Ressourcenobjekt- und Zustandsmodellsystem 230 umfasst einen Modell- und Zustandsmanager 235, ein Objektmodell 236, ein Zustandsmodell 238, einen Notifier 232, einen Provisioner 233, ein Reservierungssystem 234 und einen Poolmanager 237. In einer Implementierung können das Objektmodell 236 und das Zustandsmodell 238 in GO (einer statisch typisierten, kompilierten Programmiersprache) implementiert, zur Skalierbarkeit als zustandslose Kubernetes-Pods bereitgestellt, über REST-API-Aufrufe (Representational State Transfer) aufgerufen und in einer Datenbank persistiert werden. Wie weiter unten unter Bezugnahme auf 3 beschrieben, kann das Objektmodell 236 mehrere Ebenen haben, darunter: (i) ein Inventarmodell, in dem das Inventar der BM/VM-Infrastruktur, die innerhalb des Cloud-Computing-Systems (z. B. Cloud-Computing-System 102) zur Verwendung durch Arbeitslasten (z. B., (ii) ein Lösungsmodell, das eine Lösungskonfiguration enthält, die mit benutzerdefinierten Einstellungen gemischt ist, die mit Werkzeugen/Produkten verbunden sind, die in das NEM 210 integriert sind, z. B. über das Infrastruktur-Plugin-Framework 240, für eine bestimmte Lösung; und (iii) ein Verbrauchsmodell, das einen Satz logischer Objekte (z. B. Knoten und Knotenpools) enthält, die verwendet werden können, um die tatsächliche Recheninfrastruktur zur Laufzeit durch Anwendungsorchestrierungstools (z. B. das Anwendungsorchestrierungstool 108) indirekt zu manipulieren.)
Auf der Grundlage des Objektmodells 236 können die persistierten logischen Ressourcenobjekte entweder durch REST-API-Aufrufe (z. B. an APIs 220) oder NEM-Hintergrundprozesse automatisch durch die im Zustandsmodell 238 definierten Zustände übergehen, was zu Benachrichtigungen (z. B. generiert durch den Notifier 232) an Anwendungsorchestrierungstools über APIs 220 und/oder Aufrufe an das Infrastruktur-Plugin-Framework 240 führen kann, um geeignete maßgeschneiderte Managementtools oder Cloud-Infrastruktur-APIs aufzurufen.
Wie weiter unten unter Bezugnahme auf 4 beschrieben, kann der Modell- und Zustandsmanager 235 für die Orchestrierung von Zustandsänderungen verantwortlich sein, die logischen Ressourcenobjekten (z. B. Knoten und Knotenpools) aufgrund von Aktionen oder Operationen zugeordnet sind, die von Anwendungsorchestrierungstools, administrativen Benutzern und/oder den Ressourcenmanagern 211 durchgeführt werden, die mit Infrastruktur-Plugins innerhalb des Infrastruktur-Plugin-Frameworks 240 verbunden sind. Unter der Leitung des Modell- und Zustandsmanagers 235 kann das Zustandsmodell 238 die mit den logischen Ressourcenobjekten verbundenen Zustände beibehalten.
Das Reservierungssystem 234 kann für die Bearbeitung von Reservierungsanfragen zuständig sein, die zum Beispiel über eine Verbrauchs-API 220 gestellt werden. Die Verwaltung von Knotenreservierungen kann in Verbindung mit Knotenpools verwendet werden, um die Verfügbarkeit und den Erwerb (möglicherweise mit Schätzungen der Verfügbarkeitszeit) von Knoten für die Durchführung von Lebenszyklusimplementierungen sicherzustellen (z. B. Bereitstellung von Knoten für die Verwendung durch eine Arbeitslast und Entfernung von Knoten, die derzeit von einer Arbeitslast verwendet werden, d. h. unveränderliche Knotenverwaltung). In einigen Beispielen kann eine Reservierung für eine gewünschte Anzahl von Knoten in einem Pool vorgenommen werden, um sicherzustellen, dass eine Aufgabe (z. B. die Erstellung einer Workload-Kontrollebene oder die Skalierung eines Workloads) durchgeführt werden kann, ohne dass die Knoten ausgehen, bevor die Aufgabe abgeschlossen ist. Weitere Einzelheiten zu verschiedenen Beispieltypen von Reservierungen und verschiedenen Beispieltypen von Aktionen, die über das Reservierungssystem 234 durchgeführt werden können, werden weiter unten unter Bezugnahme auf 3 beschrieben.
Der Provisioner 233 kann für die automatische Verwaltung der Knotenbereitstellung zuständig sein. In einem Beispiel umfasst die automatische Verwaltung der Knotenbereitstellung die Sicherstellung, dass Knoten, die zu keinem Knotenpool (verfügbare Knoten) gehören und einer definierten Knotenrolle entsprechen, in einem Bereitstellungszustand mit dem neuesten Betriebssystem-Image/der neuesten Firmware/den neuesten Bios-Einstellungen für diesen Knotentyp gehalten werden. Bei der Erstinstallation in der Datenverarbeitungsumgebung können alle Knoten mit einem Image versehen werden, um sicherzustellen, dass sie über das für die Lösung und den Modelltyp angegebene Image verfügen. Wenn anschließend ein neues Image für einen Modelltyp zur Verfügung gestellt wird, kann das Inventar mit dem aktuellen Image aktualisiert werden. Alle verfügbaren Knoten, die nicht erworben wurden und zu einem bestehenden Pool gehören, können wiederverwendet werden, um sicherzustellen, dass ein Knoten, der von einer Arbeitslast angefordert wird, immer über das neueste Bild für den Modelltyp des Knotens verfügt. Wie weiter unten beschrieben, können Arbeitslasten entscheiden, wann sie bereit sind, das Abbild auf ihren erworbenen Knoten, die zu ihren Knotenpools gehören, zu aktualisieren, und können im Laufe der Zeit einen Knoten auslagern und durch einen verfügbaren Knoten aus dem Bestand ersetzen.
Der Poolmanager 237 kann für die automatische Poolverwaltung zuständig sein. In einem Beispiel umfasst die automatisierte Pool-Verwaltung die automatisierte Verwaltung von Knotenpools, die in Prozesse zur Verwaltung des Lebenszyklus von Arbeitslasten integriert sind, um sicherzustellen, dass Knoten und/oder Knotenpools entweder auf Befehl oder über einen Zeitplan aktualisiert bleiben oder wegen eines Ausfalls entfernt werden können. Wie weiter unten beschrieben, kann ein Poolstatus anzeigen, ob zu dem Pool gehörende Knoten aktualisiert werden müssen oder ob eine Wartung fällig ist. Auf diese Weise kann die Workload-Lifecycle-Automatisierung durch die Pool-Knoten iterieren, um entweder einen Aktualisierungsprozess zu durchlaufen oder den Knoten aus dem Pool zu entfernen, um eine Wartung durchzuführen. Sobald alle Knoten im Pool einen „normalen“ Zustand aufweisen, kann der Pool-Status wieder in den „normalen“ Zustand zurückkehren. Weitere Einzelheiten zu verschiedenen Beispieltypen von Knoten/Pool-Zuständen und Übergängen zwischen den Zuständen werden weiter unten unter Bezugnahme auf 4 beschrieben.
Die verschiedenen Funktionseinheiten (z.B. die APIs 220, der Notifier 232, das Reservierungssystem 234, der Provisioner 233, der Modell- und Zustandsmanager 235 und der Poolmanager 237) des NEM 210, die oben unter Bezugnahme auf 2 beschrieben wurden, und die unten unter Bezugnahme auf die Flussdiagramme der 5-6 beschrieben sind, können in Form von ausführbaren Befehlen implementiert werden, die auf einem nicht transitorischen, maschinenlesbaren Medium (z.B. einem Speicher mit wahlfreiem Zugriff (RAM), einem Festwertspeicher (ROM), einem elektrisch löschbaren, programmierbaren Festwertspeicher (EEPROM), einem Flash-Speicher, einem Plattenlaufwerk oder dergleichen) gespeichert sind und von einer hardwarebasierten Verarbeitungsressource (z.B., ein Mikrocontroller, ein Mikroprozessor, zentrale(r) Verarbeitungskern(e), ein anwendungsspezifischer integrierter Schaltkreis (ASIC), ein feldprogrammierbares Gate-Array (FPGA) oder ähnliches) und/oder in Form anderer Arten von elektronischen Schaltkreisen. Die Verarbeitung kann beispielsweise von einem oder mehreren Computersystemen verschiedener Formen (z. B. Server, Blades, Desktop-Computer, Laptop-Computer) durchgeführt werden, wie dem in 7 beschriebenen Computersystem.
Obiektmodell
3 zeigt ein Diagramm, das ein Objektmodell 300 gemäß einem Beispiel illustriert. Das Objektmodell 300 stellt ein nicht einschränkendes Beispiel des Objektmodells 236 von 2 dar. Das Objektmodell 300 kann als abstraktes und rationalisiertes persistentes Modell dienen, das von einem NEM (z. B. NEM 210) zur Beschreibung von Infrastrukturelementen (z. B. Infrastruktur 112) verwendet wird. Das Objektmodell 300 kann auch von der NEM für den Erwerb oder die Freigabe von Infrastrukturelementen verwendet werden. Das Objektmodell, das auf der Definition von Pools logischer Ressourcenobjekte (z. B. Knoten (z. B. Knoten 310) und Pools (z. B. Pool 308) von Knoten) basiert, ermöglicht die Spezifikation von Qualitäten oder Attributen eines Knotens über ein Knoten- oder Instanztypisierungssystem oder kann dekorative Aspekte ermöglichen, die auf Knoten angewendet werden (z. B. Netzwerkverbindungen, angeschlossene Speichervolumen usw.), wenn sie erworben und einem Pool zugewiesen werden. Rechenressourcen können in Gruppen verwendet werden, wobei ein oder mehrere Aspekte der Eigenschaften von Rechenressourcen (z. B. CPU-Typ, Speichergröße, Servermodell, Gerätetyp usw.) Kernaspekte sein können, während andere (z. B. Speicherressourcen, Blockspeicher, Volumes, Netzwerkressourcen, Netzwerke, virtuelle Netzwerkinfrastrukturkomponenten) kontextabhängig sein können, basierend auf der Nutzung der Kernressource.
Im Zusammenhang mit dem vorliegenden Beispiel umfasst das Objektmodell 300 drei Ebenen, darunter ein Verbrauchsmodell 304, ein Lösungsmodell 312 und ein Bestandsmodell 322. Das Verbrauchsmodell umfasst Reservierungen (z. B. Reservierung 306) und einen Satz logischer Ressourcenobjekte (z. B. Knoten (z. B. Knoten 310) und Pools (z. B. Pool 308) von Knoten), die verwendet werden können, um die tatsächliche Datenverarbeitungsinfrastruktur zur Laufzeit durch Anwendungsorchestrierungstools (z. B. das Anwendungsorchestrierungstool 108) indirekt zu manipulieren. Im Verbrauchsmodell 304 kann eine Reservierung 306 für eine Gruppe von einem oder mehreren Knoten vorgenommen werden, was zur Bildung eines Pools 308 von einem oder mehreren Knoten 310 führt. Eine Verbrauchs-API (z. B. eine der APIs 220) kann Operationen zum Erstellen, Lesen, Aktualisieren und Löschen (CRUD) von Knoten, Pools und Reservierungen unterstützen. Darüber hinaus können andere Verwaltungsvorgänge (z. B. Liste) und Lebenszyklusimplementierungen (Bereitstellung, Skalierung usw.) bereitgestellt werden.
In einigen Beispielen können Reservierungen (z. B. Reservierung 306) einer von mehreren Reservierungstypen sein, um Lebenszyklusmanagement-Implementierungen zu ermöglichen, die Anforderungen des Lebenszyklusbetriebs und die Leistung des Lebenszyklusbetriebs gegen die Auswirkungen auf die Knotenverfügbarkeit in der Computerumgebung abzuwägen. Reservierungen können beispielsweise als sofort, zeitversetzt mit hoher Auswirkung, zeitversetzt mit geringer Auswirkung und zeitversetzt recycelt angegeben werden. Eine sofortige Reservierung eignet sich für Aufgaben mit hoher Priorität (z. B. die Erstellung der Verwaltungsebene für einen Kubernetes-Cluster, bei dem es am besten ist, wenn alle Knoten sofort verfügbar sind). In einem Beispiel schlägt die Erstellung einer sofortigen Reservierung fehl, wenn derzeit weniger Server bereitgestellt werden, als für die Reservierung erforderlich sind. Die Erstellung einer aufgeschobenen High-Impact- oder Low-Impact-Reservierung schlägt fehl, wenn die Gesamtzahl der Server (bereitgestellte oder nicht bereitgestellte) mit derselben Knotenrolle wie der Pool geringer ist als die angeforderte Anzahl. Ein solcher Fehler bedeutet wahrscheinlich, dass dem NEM 210-Bestand weitere Knoten hinzugefügt werden müssen, um die Reservierungsanforderung zu erfüllen. Eine aufgeschobene Reservierung mit hoher Auswirkung kann zunächst bereitgestellte Server reservieren und dann zusätzliche Server beschaffen, die bei Bedarf bereitgestellt werden, um die Anforderung von nicht bereitgestellten Servern zu erfüllen. Diese Art der Reservierung ist für Aufgaben mit mittlerer Priorität geeignet (z. B. Skalierung einer Arbeitslast). Eine aufgeschobene Reservierung mit geringer Auswirkung kann zunächst nicht bereitgestellte Server reservieren und alle verbleibenden Server erhalten, um die Anforderung von bereitgestellten Servern zu erfüllen. Diese Art der Reservierung eignet sich für Aufgaben, bei denen der Zeitfaktor keine große Rolle spielt, z. B. bei einer Image-Aktualisierung von Knoten in einem laufenden Workload. Reservierungen können eine bestimmte Dauer haben. Wenn eine Reservierung nicht innerhalb der Dauer erfüllt wird, kann die Reservierung eine Zeitüberschreitung erleiden, die Reservierung kann gelöscht werden, und die verbleibenden nicht angeforderten
Server können für andere Reservierungen zur Verfügung gestellt werden. Diejenigen Knoten, die vor der Zeitüberschreitung der Reservierung erworben wurden, können im Pool verbleiben.
Das Lösungsmodell 312 kann verwendet werden, um Knotenkriterien (z. B. in Form von Attributen) und die Verwaltung ähnlicher Knoten zu definieren und aufrechtzuerhalten, die für Lebenszyklusimplementierungen von Lösungsworkloads verwendet werden können. Die Attribute können für die Lösung definiert und über die Lösungsmanagement-API für Orchestratoren und IT-Mitarbeiter, die Pools erstellen und verwalten, verfügbar gemacht werden. Orchestratoren auf höherer Ebene können dann Knoten aus dem Pool verwenden, da sie wissen, dass diese die gewünschten Eigenschaften/Merkmale aufweisen, um die definierten Knotenrollen zu erfüllen, ohne sich um den Backing-Server des Knotens, den Standort des Knotens, die Art des Images oder das Image des Knotens kümmern zu müssen. Auf diese Weise können sich Anwendungsentwickler darauf konzentrieren, auf Lebenszykluszustände zu reagieren, die über das NEM mitgeteilt werden, und ihre Lösungs-Workloads entsprechend zu rekonfigurieren.
Das Lösungsmodell 312 kann auch verwendet werden, um die Lösungskonfiguration und/oder benutzerdefinierte Einstellungen zu spezifizieren, die mit in die NEM integrierten Tools/Produkten verbunden sind. Das Lösungsmodell 312 kann auf eine bestimmte Lösung zugeschnitten werden, um die verschiedenen Arten der Verarbeitung durch die Lösungs-Workloads (z. B. die Workloads 104) zu berücksichtigen.
Im Kontext des vorliegenden Beispiels wird das Lösungsmodell 312 mit Klassenobjekten (z. B. einer Serverklasse 314 und einer VM-Klasse 320), einer Knotenrolle 316 und einer Startrolle 318 dargestellt. Die Klassenobjekte können verwendet werden, um eine Klassifizierung einer Ressource zu beschreiben (z. B. ein Servermodell und eine Konfigurationsnummer oder eine VM-Ressourcenkonfiguration). Jeder Knoten kann mit einer bestimmten Rolle verbunden sein (z. B. der Knotenrolle 316). Die Anzahl und die Arten der Rollen sind spezifisch für die Art der Lösung und können von einem administrativen Benutzer über ein SaaS-Portal (z. B. SaaS-Portal 114) definiert werden, das eine Lösungsmanagement-API (z. B. eine der APIs 220) aufruft, die wiederum geeignete CRUD-Operationen an Objekten innerhalb des Lösungsmodells 312 durchführen kann. Zur Veranschaulichung können im Zusammenhang mit der Implementierung einer Speicherlösung Beispiele für Knotenrollen die eines Gateway-Knotens, eines Speicherprotokoll-Übersetzerknotens und eines Datenspeicherknotens sein. Andere Lösungen können Knotenrollen allgemeiner definieren (z. B. Kubernetes-Masterknoten vs. Kubernetes-Arbeitsknoten). Die Knotenrolle 316 kann eine Startrolle enthalten, die die Startkonfiguration (z. B. die Server-Boot-Konfiguration) für die zugehörige Ressource beschreibt. In einigen Implementierungen können Kriterien für Mindestfähigkeiten, -kapazitäten und/oder - konfigurationen (z. B. in Bezug auf Rechenressourcen, Speicherressourcen und/oder Speicherressourcen) für einen Knoten einer bestimmten Rolle festgelegt werden. In Verbindung mit einer MLOps-Lösung kann ein Verwaltungsbenutzer beispielsweise den Wunsch nach einer Grafikverarbeitungseinheit (GPU) und/oder einer Mindestanzahl von CPU-Kernen für einen Inferencing-Knoten angeben, der zur Durchführung der Inferenzverarbeitung verwendet wird.
Das Inventarmodell 322 kann verwendet werden, um Infrastrukturdetails zu definieren und aufrechtzuerhalten, um die Infrastruktur für die Bereitstellung von Lösungs-Workloads auszuwählen und zu erstellen. Ein IT-Administrator oder ein übergeordneter Orchestrator kann direkt oder indirekt über das SaaS-Portal die Inventar-API (z. B. eine der APIs 220) verwenden, um ein Inventar mit Informationen über die Racks innerhalb der Infrastruktur 112 und die in den Racks untergebrachten Server zu initialisieren.
Änderungen an der mit der Datenverarbeitungsumgebung (z. B. Datenverarbeitungsumgebung 100) verbundenen Infrastruktur sollten in der Inventar-API protokolliert werden, um das Online-Inventar auf dem neuesten Stand zu halten, z. B. mit dem Inventar der in der Datenverarbeitungsumgebung verfügbaren BM/VM-Infrastruktur. Das Inventarmodell 322 kann auch verwendet werden, um das aktuelle Image für jede Knotenrolle zu verfolgen. Das aktuelle Image, das für die Knotenrolle im Lösungsmodell 312 zu verwenden ist, kann festgelegt werden, wenn die Lösung freigegeben wird. Wenn im Laufe der Zeit neue Images zur Verfügung gestellt werden, um Probleme zu beheben (z. B. Sicherheitslücken) und/oder Verbesserungen bereitzustellen, kann die Inventar-API verwendet werden, um das neueste Image für jede Knotenrolle zu verfolgen, das für die Lösung verwendet werden sollte.
Im Kontext des vorliegenden Beispiels wird das Bestandsmodell 322 mit Objekten gezeigt, die einen Server 324, eine VM 328 und ein Rack 326 darstellen. Der Server 324 kann eine bestimmte Serverklasse (z. B. Serverklasse 314) und eine bestimmte Knotenrolle (z. B. Knotenrolle 316) haben und kann mit einem bestimmten Rack (z. B. Rack 326) verbunden sein, in dem der entsprechende physische Server untergebracht ist. In ähnlicher Weise kann die VM 328 eine bestimmte VM-Klasse (VM-Klasse 320) haben und mit einer bestimmten Knotenrolle (z. B. Knotenrolle 316) verbunden sein. Mit diesem dreistufigen Modell kann ein bestimmter Knoten (z. B. Knoten 310) dem Backing-Server (BM oder VM) zugeordnet werden und umgekehrt.
Zustandsmodell
4 zeigt ein Diagramm, das ein Zustandsmodell 400 gemäß einem Beispiel illustriert. Das Zustandsmodell 400 stellt ein nicht einschränkendes Beispiel für das Zustandsmodell 238 von 2 dar. Das Zustandsmodell 400 kann von einem NEM (z. B. NEM 210) verwendet werden, um den aktuellen Zustand von logischen Ressourcenobjekten (z. B. Knoten und Knotenpools) darzustellen. In einem Beispiel werden Zustandsübergänge innerhalb des Zustandsmodells 400 durch das Modell und den Zustandsmanager bestimmt, über das Zustandsmodell persistiert und dann verwendet, um Folgendes auszulösen: (i) Infrastruktur-Plugin-Funktionalität, Benachrichtigungen an Arbeitslasten (z. B. Arbeitslasten 104), z. B. über Anwendungsorchestrierungstools, und (iii) potenziell zusätzliche Orchestrierungen.
Das NEM kann einen unveränderlichen Knotenansatz verwenden, was bedeutet, dass Zustandsänderungen wie Aktualisierungen, Neustarts, Vertrauensverletzungen, Ausfälle oder Störungen von der arbeitslastbasierten Orchestrierung durch Freigeben (Löschen) des Knotens aus seinem Pool behandelt werden. Das Löschen eines Knotens aus einem Pool kann weitere Zustandsänderungen und zusätzliche vorbestimmte Orchestrationen innerhalb des NEM auslösen, z. B. die in Tabelle 1 (unten) beschriebene Löschverarbeitung. Die Verwendung des Zustandsmodells 400 vereinfacht Workload-basierte Orchestrierungsbeziehungen zu Zustandsänderungen von logischen Ressourcenobjekten. Wie in Tabelle 1 (unten) dargestellt, kann die Workload-basierte Orchestrierung beispielsweise so strukturiert werden, dass sie auf Zustandsänderungen reagiert, die auf Pool-Ebene verstärkt werden (z. B., verstärkt kann bedeuten, dass der Zustand mit der höchsten Priorität unter allen Knotenzuständen innerhalb eines Pools für diesen Pool verwendet wird, wodurch die Identifizierung von Pools und zu verarbeitenden Knoten vereinfacht wird), den betreffenden Knoten innerhalb des Pools zu identifizieren, eine geeignete Vorverarbeitung (z. B. Poolerweiterung, Workload-Evakuierung usw.), Nachverarbeitung (z. B. Poolbereinigung) und Freigabe und Erfassung von Ressourcen entsprechend der Zustandsänderung durchzuführen. In einem Beispiel kann ein vorbestimmter Satz von Vorverarbeitungs- und/oder Nachverarbeitungsvorgängen, die an einem Pool oder einem Knoten durchzuführen sind, von einem Verwaltungsbenutzer für jeden Knotenzustand festgelegt werden.
In einem Beispiel kann ein Modell- und Zustandsmanager (z. B. Modell- und Zustandsmanager 235), der im NEM implementiert ist, für die Bestimmung und Orchestrierung von Zustandsänderungen verantwortlich sein, die mit logischen Ressourcenobjekten (z. B. Knoten und Knotenpools) verbunden sind und aus Aktionen oder Operationen resultieren, die von Anwendungsorchestrierungstools (z. B. Anwendungsorchestrierung 108), administrativen Benutzern und/oder Infrastruktur-Plugins durchgeführt werden. Im Kontext des vorliegenden Beispiels kann der Knotenzustand auf einen verfügbaren Zustand 404, einen normalen Zustand 406, einen Ersatzzustand 408, einen Entfernungszustand 410, einen ausgefallenen Zustand 412 oder einen Ausfallzustand 414 gesetzt werden. In einem Beispiel kann auch ein Sofortmodus-Flag Teil des Knotenzustands sein, um den Grad der Unmittelbarkeit der zu ergreifenden Maßnahmen für die Zustände Ersetzen und Entfernen anzugeben.
Wenn ein neuer Knoten innerhalb von NEM entweder durch Bestandsänderungen oder Kundenreservierungen erstellt wird, wird der zugrundeliegende Server entsprechend bereitgestellt (z. B. im Falle eines BM-Servers) und der Knoten beginnt im verfügbaren Zustand 404. Im Verfügbarkeitszustand 404 ist der Knoten bereitgestellt und für die Nutzung durch eine Arbeitslast bereit, aber noch nicht mit einem Pool verbunden. Wenn der Knoten einem Pool zugewiesen ist, wird der Knoten in einen normalen Zustand 406 überführt. Vom Normalzustand 406 kann der Knoten in den Ersetzungszustand 408, den Entfernungszustand 410 oder den Ausfallzustand 412 übergehen.
Der Knoten kann z. B. in den Ersetzungszustand 408 übergehen, wenn festgestellt wird, dass der Knoten entweder sofort (z. B. Sofortmodus ist wahr) oder nach Bedarf der Arbeitslast (Sofortmodus ist falsch) ersetzt werden soll. Der Sofortmodus kann auf true gesetzt werden, wenn der Austausch sofort erfolgen soll, z. B. nach der Veröffentlichung eines Hotfixes (z. B. wenn ein dringender Patch auf einen Server in der Arbeitslast angewendet werden soll) und der Server sofort aktualisiert und neu gestartet werden soll. Der sofortige Modus kann auf „false“ gesetzt werden, wenn die Ersetzung nach Belieben des Workloads durchgeführt werden kann, z. B. wenn der Ersetzungszustand mit einem regelmäßig geplanten Wartungsfenster übereinstimmt. Nach dem Löschen des Knotens aus seinem Pool, z. B. durch das Anwendungsorganisationswerkzeug 108 über die Verbrauchs-API, und nach erfolgreichem Abschluss der Löschverarbeitung (z. B. Reimaging, Neustart und BIOS-Konfiguration) kann der Knoten wieder in den verfügbaren Zustand 404 versetzt werden.
Der Knoten kann z. B. in den Entfernungszustand 410 übergehen, wenn festgestellt wird, dass der Knoten entweder sofort (z. B. Sofortmodus ist wahr) oder nach Bedarf der Arbeitslast (Sofortmodus ist falsch) entfernt werden soll. Der Sofortmodus kann auf true gesetzt werden, wenn die Entfernung sofort erfolgen soll, z. B. aufgrund eines ungeplanten Ausfalls oder einer Vertrauensverletzung. Der Sofortmodus kann auf false gesetzt werden, wenn die Entfernung nach Belieben des Workloads durchgeführt werden kann, z. B. wenn der Entfernungszustand in Übereinstimmung mit einem regelmäßig geplanten Wartungsfenster ist. Als Reaktion auf die Löschung des Knotens aus seinem Pool, z. B. durch das Anwendungsorchestrierungstool 108 über die Verbrauchs-API, und nach erfolgreichem Abschluss der Löschverarbeitung (z. B. Reimaging) kann der Knoten bis zum Abschluss der Prüfung durch einen IT-Administrator in den Ausfallzustand 414 versetzt werden.
Der Knoten kann z. B. in den Fehlerzustand 412 übergehen, wenn festgestellt wird, dass der Sicherungsserver ausgefallen ist oder der Vertrauensserver kompromittiert wurde. Als Reaktion darauf, dass ein Knoten in den ausgefallenen Zustand 410 versetzt wird, kann das NEM den Knoten automatisch löschen und den Knoten und den Sicherungsserver automatisch in den Ausfallzustand 414 versetzen.
Wie bereits erwähnt, kann ein Knoten vom Zustand „Entfernen“ (410) oder „Ausfall“ (412) in den Zustand „Ausfall“ (414) übergehen. Im Kontext des vorliegenden Beispiels werden Knoten im Ausfallzustand 414 nicht automatisch wiederhergestellt und in den Verfügbarkeitszustand 404 versetzt. Vielmehr wird erwartet, dass der IT-Administrator den Backup-Server überprüft und für die Wiederverwendung freigibt, bevor der Knoten wieder in den Verfügbarkeitsstatus 404 versetzt werden kann. Aus dem Ausfallzustand 414 kann der IT-Administrator den Knoten löschen (z. B. wenn der Fehler nicht behoben werden kann) oder ihn in den verfügbaren Zustand 404 zurückversetzen (z. B. nach erfolgreicher Behebung des Fehlers).

Im Kontext des vorliegenden Beispiels haben die Zustände der logischen NEM-Ressourcenobjekte eine Prioritätshierarchie (z. B. sind in Tabelle 1 (unten) die Zustände in einer Beispielreihenfolge zunehmender Priorität von der niedrigsten Priorität oben bis zur höchsten Priorität unten aufgelistet), und der Poolzustand wird in der Prioritätsreihenfolge verstärkt. In einem Beispiel für die Verstärkung des Poolzustands kann der Zustand eines bestimmten Pools (Poolzustand) auf der Grundlage des schwerwiegendsten Zustands der jeweiligen Zustände der Knoten (Knotenzustand) innerhalb des bestimmten Pools bestimmt werden. Auf diese Weise können Workload-basierte Orchestrationen Pool-Zustände (z. B. von einer relativ kleinen Anzahl von Pools, typischerweise weniger als fünf) effizient abfragen oder abhören, um Zustandsänderungs-Orchestrationen auszulösen, anstatt auf Knotenebene abzufragen oder abzuhören (z. B. bei einer typischerweise viel größeren Anzahl von Knoten). Tabelle 1 - Beispiel für Knotenzustände und Löschverarbeitung als Reaktion auf die Löschung des Knotens aus seinem Pool

Zustand des Knotens	Sofortiger Modus	Verarbeitung löschen	Absicht	Beispiele
Normal	K.A.	K.A.	Normaler Betriebszustand eines Knotens.	Knoten ist mit einem Pool verbunden
Ersetzen Sie	Falsch	1. Bild 2. Starten Sie neu. 3. Firmware	1. Der Knoten muss innerhalb eines regelmäßig geplanten Wartungsfensters ausgetauscht werden. 2. Die Arbeitslast kann evakuiert werden. 3. Der Pool kann erweitert werden, um Knoten zu ersetzen, oder Knoten können recycelt werden.	1. Bildaktualisierung (Update/Upgrade) 2. Vertrauensbruch.
Ersetzen Sie	Wahr	1. Bild 2. Starten Sie neu. 3. Firmware	1. Der Knoten muss sofort ersetzt werden. 2. Die Arbeitslast kann evakuiert werden. 3. Der Knoten sollte recycelt werden.	1. Image-Aktualisierung/Neustart (Hotfix) 2. Vertrauensbruch.
entfernen	Falsch	1. Bild 2. Untersuchen Sie	1. Der Knoten muss innerhalb eines regelmäßig geplanten Wartungsfensters entfernt werden. 2. Die Arbeitslast kann evakuiert werden. 3. Pool muss erweitert werden, um Knoten zu entfernen, Knoten kann nicht recycelt werden.	1. Ausfall (geplant).
entfernen	Wahr	1. Bild 2. Untersuchen Sie	1. Der Knoten muss sofort entfernt werden. 2. Die Arbeitslast kann evakuiert werden. 3. Pool muss erweitert werden, um Knoten zu entfernen, Knoten kann nicht recycelt werden.	1. Ausfall (sofort) 2. Vertrauensbruch.
Gescheitert	Erzwungen Wahr		1. Der Backing-Server ist ausgefallen und der Knoten wurde sofort von NEM gelöscht. 2. Die Arbeitslast ist verloren gegangen und muss neu aufgebaut werden. 3. Der Pool muss nach dem Ausfall eines Knotens bereinigt und erweitert werden, um die Skalierung des Pools zu gewährleisten.	1. Überwachter Serverausfall. 2. Vertrauen - Server kompromittiert.

NEM-Verarbeitung
5 zeigt ein Flussdiagramm, das die von einem NEM gemäß einem Beispiel durchgeführte Verarbeitung veranschaulicht. Die Verarbeitung kann beispielsweise und ohne Einschränkung unter Verwendung des NEM 210 von 2 implementiert werden, um das Lebenszyklusmanagement für Arbeitslasten (z. B. Arbeitslasten 104) auf heterogener Infrastruktur (z. B. Infrastruktur 112) zu erleichtern.
In Block 510 wird ein Verbrauchsmodell gepflegt, in dem die heterogene Infrastruktur in einer verallgemeinerten Form als logische Ressourcenobjekte dargestellt wird. In einem Beispiel umfassen die logischen Ressourcenobjekte Knoten und Pools von Knoten. Jeder Knoten kann eine Knotenrolle (z. B. Knotenrolle 316) haben, die z. B. in einem Lösungsmodell (z. B. Lösungsmodell 312) eines Objektmodells (z. B. Objektmodell 300) des NEM definiert ist. Die jeweiligen Knotenrollen können auf der Grundlage der jeweiligen Attribute der Knoten eine bestimmte Funktionalität angeben, die die Knoten für einen Workload (z. B. einen der Workloads 104) bereitstellen können. Die Attribute der Knoten können in Form der jeweiligen Berechnungskonfiguration, der Speicher- und/oder Netzwerkressourcen der Knoten ausgedrückt werden.
In Block 520 wird ein Zustandsmodell verwaltet, durch das die logischen Ressourcenobjekte zwischen mehreren Zuständen übergehen. Als Reaktion auf Übergänge der logischen Ressourcenobjekte können Benachrichtigungen an ein mit der Arbeitslast verbundenes Anwendungsorganisationswerkzeug (z. B. das Anwendungsorganisationswerkzeug 108) übermittelt werden. Die mehreren Zustände und Übergänge können wie oben unter Bezugnahme auf 4 beschrieben sein.
In Block 530 werden die Interaktionen des Anwendungsorchestrierungstools mit Elementen der heterogenen Infrastruktur, die von der Arbeitslast genutzt werden, abstrahiert, indem eine Verbrauchs-API (z. B. eine der APIs 220) bereitgestellt wird, über die Anforderungen zur Verwaltung eines Lebenszyklus der heterogenen Infrastruktur mit Bezug auf die logischen Ressourcenobjekte ausgedrückt werden. Wie in beschrieben, kann die Verbrauchs-API beispielsweise verschiedene CRUD-Operationen, Verwaltungsoperationen und Lebenszyklusimplementierungen auf Knoten und Knotenpools unterstützen.
6 zeigt ein Flussdiagramm, das die Verarbeitung durch ein NEM gemäß einem anderen Beispiel veranschaulicht. Die Verarbeitung kann beispielsweise und ohne Einschränkung unter Verwendung des NEM 210 von 2 implementiert werden, um das Lebenszyklusmanagement für Arbeitslasten (z. B. Arbeitslasten 104) auf heterogenen Rechenressourcen innerhalb einer Infrastruktur (z. B. Infrastruktur 112) zu erleichtern.
In Block 610 wird eine Verbrauchs-API bereitgestellt, um von einem Anwendungsorchestrierungstool (z. B. dem Anwendungsorchestrierungstool 108) eine Anforderung zur Verwaltung eines Lebenszyklus heterogener Rechenressourcen für eine Arbeitslast zu erhalten. In einem Beispiel kann das Anwendungsorchestrierungstool die Verbrauchs-API verwenden, um die zugrunde liegende Infrastruktur über Interaktionen mit logischen Ressourcenobjekten (z. B. Knoten und Pools von Knoten) indirekt zu verwalten und/oder zu manipulieren.
In Block 620 wird die Anforderung ausgeführt, indem ein integriertes Infrastruktur-Plugin aufgerufen wird, um einen mit der Anforderung verbundenen Vorgang durchzuführen. So kann z. B. die Erstellung eines Knotensatzes oder die Reservierung eines Knotensatzes für die Zuordnung zu einem bestimmten Pool dazu führen, dass die NEM sofort oder im Hintergrund ein BM-Bereitstellungstool bzw. ein Virtualisierungstool zur Bereitstellung der entsprechenden BM- oder VM-Infrastruktur veranlasst.
In Block 630 werden als Reaktion auf den Abschluss des Aufrufs ein Objektmodell und/oder ein Zustandsmodell aktualisiert, die den Lebenszyklus der heterogenen Rechenressourcen für die Arbeitslast darstellen. Als Reaktion auf den Abschluss der Bereitstellung der BM- oder VM-Infrastruktur können die reservierten Knoten beispielsweise je nach Zustand des Knotens von einem verfügbaren Zustand (z. B. dem verfügbaren Zustand 404) in einen normalen Zustand (z. B. den normalen Zustand 406) übergehen.
In Block 640 wird das Anwendungsorchestrierungstool über Zustandsänderungen an den heterogenen Rechenressourcen innerhalb des Zustandsmodells benachrichtigt. Wie oben unter Bezugnahme auf 4 beschrieben, kann das Anwendungsorchestrierungstool beispielsweise (z. B. über automatische Benachrichtigungen von einem Melder (z. B. Melder 232) oder REST-basiertes Polling) über Knotenzustandsänderungen benachrichtigt werden, die auf die Notwendigkeit hinweisen, einen ausgefallenen Knoten zu ersetzen, zu entfernen oder wiederherzustellen (z. B. als Ergebnis der Durchführung eines Hotfixes, der Verfügbarkeit eines Image-Updates oder einer regelmäßig geplanten Wartung oder aufgrund der Erkennung eines Serverausfalls).
Während im Zusammenhang mit den Beispielen, die unter Bezugnahme auf die 5-6 beschriebenen Beispiele eine Reihe von aufgezählten Blöcken enthalten sind, können andere Beispiele zusätzliche Blöcke vor, nach und/oder zwischen den aufgezählten Blöcken enthalten. Ebenso können in einigen Beispielen ein oder mehrere der aufgezählten Blöcke weggelassen oder in einer anderen Reihenfolge ausgeführt werden.
Computer-System
7 zeigt ein Blockdiagramm eines Computersystems gemäß dem ersten Beispiel. In dem in 7 dargestellten Beispiel umfasst das Computersystem 700 eine Verarbeitungsressource 710, die mit einem nicht transitorischen, maschinenlesbaren Medium 720 gekoppelt ist, das mit Anweisungen zur Durchführung eines oder mehrerer hierin beschriebener Prozesse kodiert ist. Bei dem Computersystem 700 kann es sich um einen Server, einen Server-Cluster, eine Computer-Appliance, eine Workstation, ein konvergentes System, ein hyperkonvergentes System oder Ähnliches handeln. Das Computersystem 700 kann Teil der zu verwaltenden Infrastruktur (z. B. Infrastruktur 112) innerhalb einer bestimmten Computerumgebung (z. B. Cloud-Computing-Umgebung 100) sein. In anderen Beispielen kann sich das Computersystem 700 in einer Cloud (z. B. einer öffentlichen Cloud) befinden und mit der zu verwaltenden Infrastruktur (z. B. der Infrastruktur 112) kommunizieren oder ein Verwaltungsserver in demselben Rechenzentrum wie die zu verwaltende Infrastruktur sein.
Die Verarbeitungsressource 710 kann einen Mikrocontroller, einen Mikroprozessor, CPU-Kern(e), GPU-Kern(e), einen ASIC, einen FPGA und/oder eine andere Hardware-Vorrichtung umfassen, die für den Abruf und/oder die Ausführung von Anweisungen vom maschinenlesbaren Medium 720 geeignet ist, um die Funktionen in Bezug auf verschiedene hier beschriebene Beispiele durchzuführen. Zusätzlich oder alternativ kann die Verarbeitungsressource 710 eine elektronische Schaltung zur Ausführung der Funktionalität der hier beschriebenen Anweisungen enthalten.
Bei dem maschinenlesbaren Medium 720 kann es sich um ein beliebiges Medium handeln, das zur Speicherung ausführbarer Anweisungen geeignet ist. Nicht einschränkende Beispiele für maschinenlesbare Medien 720 sind RAM, ROM, EEPROM, Flash-Speicher, ein Festplattenlaufwerk, eine optische Platte oder Ähnliches. Das maschinenlesbare Medium 720 kann ein nicht-transitorisches Medium sein, wobei der Begriff „nicht-transitorisch“ keine transitorischen Übertragungssignale einschließt. Das maschinenlesbare Medium 720 kann innerhalb des Computersystems 700 angeordnet sein, wie in 7 gezeigt, in welchem Fall die ausführbaren Anweisungen als auf dem Computersystem 700 „installiert“ oder „eingebettet“ angesehen werden können. Alternativ kann das maschinenlesbare Medium 720 ein tragbares (z. B. externes) Speichermedium und Teil eines „Installationspakets“ sein. Die auf dem maschinenlesbaren Medium 720 gespeicherten Anweisungen können nützlich sein, um zumindest teilweise eine oder mehrere der hier beschriebenen Methoden zu implementieren.
Im Zusammenhang mit dem vorliegenden Beispiel ist das maschinenlesbare Medium 720 mit einer Reihe von ausführbaren Anweisungen 730-750 kodiert. Es versteht sich, dass ein Teil oder die Gesamtheit der ausführbaren Anweisungen und/oder elektronischen Schaltungen, die in einem Block enthalten sind, in alternativen Implementierungen in einem anderen in den Figuren dargestellten Block oder in einem anderen nicht dargestellten Block enthalten sein können.
Die Anweisungen 730 können bei der Ausführung bewirken, dass die Verarbeitungsressource 710 ein Verbrauchsmodell pflegt, in dem die heterogene Infrastruktur in einer verallgemeinerten Form als logische Ressourcenobjekte dargestellt wird, einschließlich Knoten und mehrerer Pools der Knoten. In einem Beispiel können die Anweisungen 730 für die Durchführung von Block 510 von 5 nützlich sein.
Die Anweisungen 740 können bei der Ausführung bewirken, dass die Verarbeitungsressource 710 ein Zustandsmodell unterhält, durch das die logischen Ressourcenobjekte zwischen mehreren Zuständen wechseln und auf das hin Benachrichtigungen an ein mit der Arbeitslast verbundenes Anwendungsorchestrierungstool bereitgestellt werden. In einem Beispiel können die Anweisungen 740 für die Durchführung von Block 520 von 5 nützlich sein.
Die Anweisungen 750 können bei ihrer Ausführung bewirken, dass die Verarbeitungsressource 710 die Interaktionen des Anwendungs-Orchestrierungstools mit der von der Arbeitslast genutzten heterogenen Infrastruktur abstrahiert, indem sie eine API bereitstellt, über die Anforderungen zur Verwaltung eines Lebenszyklus der heterogenen Infrastruktur unter Bezugnahme auf die logischen Ressourcenobjekte ausgedrückt werden. In einem Beispiel können die Anweisungen 750 für die Durchführung von Block 530 von 5 nützlich sein.
In der vorstehenden Beschreibung sind zahlreiche Details aufgeführt, um das Verständnis des hierin offengelegten Gegenstands zu erleichtern. Die Umsetzung kann jedoch auch ohne einige oder alle diese Details erfolgen. Andere Ausführungsformen können Modifikationen und Abweichungen von den oben beschriebenen Details enthalten. Es ist beabsichtigt, dass die folgenden Ansprüche solche Modifikationen und Variationen abdecken.

Claims

Ein Verfahren, das Folgendes umfasst: Aufrechterhaltung eines Verbrauchsmodells, in dem eine heterogene Infrastruktur in einer verallgemeinerten Form als logische Ressourcenobjekte dargestellt wird, einschließlich Knoten und einer Vielzahl von Pools der Knoten, wobei die Knoten jeweilige Knotenrollen haben, die eine spezifische Funktionalität anzeigen, die die Knoten betreiben können, um eine Arbeitslast auf der Grundlage der jeweiligen Attribute der Knoten bereitzustellen; Aufrechterhaltung eines Zustandsmodells, durch das die logischen Ressourcenobjekte zwischen einer Vielzahl von Zuständen übergehen und auf das hin Benachrichtigungen an ein mit der Arbeitslast verbundenes Anwendungsorchestrierungstool bereitgestellt werden; und Abstrahieren von Interaktionen durch das Anwendungs-Orchestrierungswerkzeug mit einer Teilmenge der heterogenen Infrastruktur, die von der Arbeitslast genutzt wird, durch Bereitstellen einer Anwendungsprogrammierschnittstelle (API), durch die Anforderungen zur Verwaltung eines Lebenszyklus der Teilmenge der heterogenen Infrastruktur unter Bezugnahme auf die logischen Ressourcenobjekte ausgedrückt werden.
Verfahren nach Anspruch 1, das ferner die Ausführung der Anfragen durch Aufrufe integrierter Infrastruktur-Plugins umfasst, um mit den Anfragen verbundene Operationen durchzuführen.
Verfahren nach Anspruch 2, wobei die integrierten Infrastruktur-Plugins ein Bare-Metal-Bereitstellungswerkzeug und ein Virtualisierungswerkzeug umfassen.
Verfahren nach Anspruch 1, das ferner die Benachrichtigung des Anwendungsorchestrierungstools über Zustandsmodelländerungen umfasst.
Verfahren nach Anspruch 1, wobei die jeweiligen Attribute in Form von jeweiligen Fähigkeiten, Kapazitäten oder Konfigurationen der Knoten ausgedrückt werden.
Das Verfahren nach Anspruch 1 umfasst ferner die Bereitstellung eines Reservierungssystems, über das die Knoten mit der Vielzahl von Pools verbunden sind.
Verfahren nach Anspruch 6, wobei die Zuordnung der Knoten zu den mehreren Pools die Verwaltung der Knoten als Gruppen mit konsistenten automatisierten Lebenszyklusverwaltungsvorgängen und -zuständen erleichtert.
Verfahren nach Anspruch 1, das ferner als Teil eines Hintergrundprozesses und vor der Zuordnung zu der Vielzahl von Pools die Bereitstellung einer Teilmenge der Knoten mit einer bestimmten Knotenrolle umfasst, um die sofortige Verfügbarkeit für die Nutzung durch die Arbeitslast zu erleichtern.
Ein System, das Folgendes umfasst: eine Verarbeitungsressource; und ein nicht-transitorisches, computerlesbares Medium, das mit der Verarbeitungsressource gekoppelt ist und in dem Anweisungen gespeichert sind, die, wenn sie von der Verarbeitungsressource ausgeführt werden, die Verarbeitungsressource veranlassen: eine verbrauchende Anwendungsprogrammierschnittstelle (API) bereitzustellen, um von einem Anwendungsorchestrierungstool eine Anforderung zur Verwaltung eines Lebenszyklus von heterogenen Rechenressourcen für eine Arbeitslast zu erhalten; die Anfrage auszuführen, indem sie ein integriertes Infrastruktur-Plugin aufruft, um einen mit der Anfrage verbundenen Vorgang auszuführen; Aktualisieren eines Objektmodells oder eines Zustandsmodells, das den Lebenszyklus der heterogenen Rechenressourcen für die Arbeitslast darstellt, als Reaktion auf den Abschluss des Aufrufs; und Benachrichtigung des Anwendungsorchestrierungstools über Zustandsänderungen der heterogenen Computerressourcen.
System nach Anspruch 9, wobei die Anweisungen ferner die Verarbeitungsressource veranlassen, die Verfügbarkeit der heterogenen Rechenressourcen für Arbeitslasten bereitzustellen, die von dem Anwendungs-Orchestrierungswerkzeug über ein Reservierungssystem verwaltet werden.
System nach Anspruch 10, wobei das Reservierungssystem die heterogenen Computerressourcen einem Pool zuordnet, um die Verwaltung der heterogenen Computerressourcen als Gruppe mit konsistenten automatisierten Lebenszyklusverwaltungsvorgängen und -zuständen zu erleichtern.
System nach Anspruch 9, wobei das integrierte Infrastruktur-Plugin ein Bare-Metal-Bereitstellungswerkzeug oder ein Virtualisierungswerkzeug umfasst.
Ein nicht-transitorisches maschinenlesbares Medium, das Befehle speichert, die, wenn sie von einer Verarbeitungsressource eines Computersystems ausgeführt werden, die Verarbeitungsressource veranlassen: ein Verbrauchsmodell aufrechtzuerhalten, in dem eine heterogene Infrastruktur in einer verallgemeinerten Form als logische Ressourcenobjekte dargestellt wird, die Knoten und eine Vielzahl von Pools der Knoten einschließen, wobei die Knoten jeweilige Knotenrollen haben, die auf eine spezifische Funktionalität hinweisen, die die Knoten in der Lage sind, einer Arbeitslast auf der Grundlage der jeweiligen Attribute/Qualitäten der Knoten bereitzustellen; ein Zustandsmodell aufrechtzuerhalten, durch das die logischen Ressourcenobjekte zwischen einer Vielzahl von Zuständen übergehen und auf das hin Benachrichtigungen an ein mit der Arbeitslast verbundenes Anwendungsorchestrierungstool bereitgestellt werden; und abstrakte Interaktionen durch das Anwendungsorchestrierungstool mit einer Teilmenge der heterogenen Infrastruktur, die von der Arbeitslast genutzt wird, indem eine Anwendungsprogrammierschnittstelle (API) bereitgestellt wird, über die Anforderungen zur Verwaltung eines Lebenszyklus der Teilmenge der heterogenen Infrastruktur unter Bezugnahme auf die logischen Ressourcenobjekte ausgedrückt werden.
Nichttransitorisches maschinenlesbares Medium nach Anspruch 13, wobei die Anweisungen ferner die Verarbeitungsressource veranlassen, die Anforderungen auszuführen, indem sie Aufrufe an integrierte Infrastruktur-Plugins machen, um mit den Anforderungen verbundene Operationen durchzuführen.
Nichttransitorisches maschinenlesbares Medium nach Anspruch 14, wobei die integrierten Infrastruktur-Plugins ein Bare-Metal-Bereitstellungswerkzeug und ein Virtualisierungswerkzeug umfassen.
Nichttransitorisches maschinenlesbares Medium nach Anspruch 14, wobei die Anweisungen ferner die Verarbeitungsressource veranlassen, das Anwendungsorchestrierungstool über Zustandsmodelländerungen zu informieren.
Nichttransitorisches maschinenlesbares Medium nach Anspruch 14, wobei die jeweiligen Attribute/Qualitäten in Form von jeweiligen Fähigkeiten, Kapazitäten und/oder Konfigurationen der Knoten ausgedrückt werden.
Nichttransitorisches maschinenlesbares Medium nach Anspruch 14, wobei die Anweisungen ferner die Verarbeitungsressource veranlassen, ein Reservierungssystem zu verwenden, um die Knoten mit der Vielzahl von Pools zu verknüpfen.
Nichttransitorisches maschinenlesbares Medium nach Anspruch 18, wobei die Zuordnung der Knoten zu der Vielzahl von Pools die Verwaltung der Knoten als Gruppen mit konsistenten automatisierten Lebenszyklusmanagementoperationen und - zuständen erleichtert.
Nichttransitorisches maschinenlesbares Medium nach Anspruch 14, wobei die Anweisungen ferner die Verarbeitungsressource veranlassen, als Teil eines Hintergrundprozesses und vor der Zuordnung zu der Vielzahl von Pools eine Untergruppe der Knoten mit einer bestimmten Knotenrolle bereitzustellen, um die sofortige Verfügbarkeit für die Verwendung durch die Arbeitslast zu erleichtern.