DE102022108626A1

DE102022108626A1 - Ausweitung der aufsichtsdienste auf vertrauenswürdige cloud-betreiber-domänen

Info

Publication number: DE102022108626A1
Application number: DE102022108626.7A
Authority: DE
Inventors: Dwight D. Riley; Scott P. Faasse
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2021-10-29
Filing date: 2022-04-08
Publication date: 2023-05-04
Also published as: CN116069584A; US20230132853A1; US11625338B1

Abstract

Ein Überwachungsdienst eines Knotens, der ein intelligentes Ein-/Ausgabe-Peripheriegerät (E/A) enthält, wird in eine Cloud-Operator-Domäne erweitert, die mit dem intelligenten E/A-Peripheriegerät verbunden ist. Der Überwachungsdienst bestimmt den Zustand einer Bereitschaftsanzeige, die von der intelligenten E/A-Peripherie bereitgestellt wird. Basierend auf dem Zustand führt der Überwachungsdienst mindestens eine der folgenden Maßnahmen durch: Regulierung der Verfügbarkeit einer Instanz einer Anwendungsbetriebsumgebung des Knotens oder Bestimmung, ob das intelligente E/A-Peripheriegerät bereit ist, vom Überwachungsdienst konfiguriert zu werden.

Description

HINTERGRUND
Eine Cloud-Architektur kann eine Computersystemdomäne mit mehreren physischen Serverknoten (z. B. Blade-Servern oder rackmontierten Servern) oder „Domänenknoten“ umfassen. Die Domänenknoten definieren eine physische Infrastrukturdomäne des Computersystems. Die physische Infrastrukturdomäne kann von einem zentralen Managementsystem verwaltet werden, das eine softwaredefinierte logische Infrastruktur und Dienste (z. B. softwaredefinierte Rechendienste (SDC), softwaredefinierte Speicherdienste (SDS) und softwaredefinierte Netzwerkdienste (SDN)) orchestriert, die auf den Domänenknoten gehostet werden. Die softwaredefinierte logische Infrastruktur stützt sich auf eine Abstraktionsinfrastrukturebene (z. B. einen Hypervisor für die Abstraktion virtueller Maschinen (VM) oder ein Betriebssystem für die Abstraktion von Containern), um die zentrale Management-Systemsteuerung der Dienste zu ermöglichen.
Figurenliste

1 ist eine schematische Darstellung eines Cloud-Computersystems gemäß einer Beispielimplementierung.
2 zeigt eine beispielhafte Einschaltsequenz für ein intelligentes Ein-/Ausgabegerät (E/A) eines Domänenknotens des Cloud-Computersystems von 1 gemäß einer Beispielimplementierung.
Die 3A, 3B, 3C und 3D zeigen Beispielarchitekturen im Zusammenhang mit Host-Überwachungsdiensten des Domänenknotens gemäß Beispielimplementierungen.
4 ist ein Flussdiagramm, das einen Busaufzählungsprozess darstellt, der von einem Host-Überwachungsdienst gemäß einer Beispielimplementierung verwendet wird.
5 ist ein Flussdiagramm, das einen Prozess darstellt, der von einem Host-Überwachungsdienst verwendet wird, der auf ein Laufzeit-Containerinstanz-Änderungsereignis gemäß einer Beispielimplementierung reagiert.
6 ist ein Flussdiagramm, das einen Prozess darstellt, der von einem intelligenten E/A-Peripheriegerät verwendet wird, um Bereitschaftszustandsanzeigen gemäß einer Beispielimplementierung zu verwalten.
7 ist ein Flussdiagramm, das einen Prozess zur Erweiterung eines Überwachungshostdienstes in eine vertrauenswürdige Cloud-Betreiberdomäne gemäß einer Beispielimplementierung zeigt.
8 ist ein schematisches Diagramm eines Systems, das einen Host enthält, um einen Überwachungsdienst für ein intelligentes E/A-Peripheriegerät gemäß einer Beispielimplementierung durchzuführen.
9 ist eine Illustration eines nicht-transitorischen Speichermediums, das maschinenlesbare Anweisungen speichert, die, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, einen Bereitschaftszustandsindikator eines intelligenten E/A-Peripheriegeräts gemäß einer Beispielimplementierung zu verwalten.

AUSFÜHRLICHE BESCHREIBUNG
Eine Computerplattform, wie z. B. ein Server (z. B. ein Blade-Server oder ein Rack-Server), kann eine Architektur aufweisen (z. B. eine herkömmliche PCbasierte Architektur oder eine „Legacy-Architektur“), die sich durch ein „hostzentriertes“ Steuerungsmodell auszeichnen kann. Bei einem solchen Steuerungsmodell ist die Serversteuerung im Host des Servers verankert. Wie hier verwendet, bezieht sich ein „Host“ auf die Software und Hardware der Computerplattform, die eine oder mehrere Anwendungsbetriebsumgebungen für die Computerplattform bereitstellt. Anders ausgedrückt: Die Serversteuerungen sind in den zentralen Verarbeitungseinheiten (CPUs) des Servers verankert.
Der Server kann ein Rechenknoten eines Cloud-basierten Computersystems oder eines „Cloud-Computersystems“ sein. Die Softwareschicht des Hosts des Rechnerknotens kann die logische Infrastrukturabstraktion und Steuerungsoberflächen über einen Hypervisor-Software-Stack (für virtuelle Maschinen (VMs)) und/oder einen Betriebssystem-Software-Stack (für Container) bereitstellen. Das Ergebnis dieses Host-zentrierten Kontrollmodells ist eine Trennung der administrativen Kontrolle der physischen Infrastruktur des Rechenknotens von der logischen Infrastruktur des Rechenknotens.
Ein zentrales Verwaltungssystem des Cloud-Computersystems kann um eine hierarchische Verwaltungsstruktur herum aufgebaut sein. Auf der untersten Ebene der hierarchischen Verwaltungsstruktur kann der Rechenknoten in zwei unterschiedliche Steuerungsoberflächen unterteilt sein: eine erste Steuerungsoberfläche für die physische Infrastruktur des Rechenknotens und eine zweite Steuerungsoberfläche für die logische Infrastruktur des Rechenknotens. Jede dieser Infrastrukturen kann mit einem eigenen zentralen Verwalter verbunden sein, so dass es zwei deutlich unterschiedliche zugehörige Administratoren geben kann: einen Administrator für die physische Infrastruktur und einen Virtualisierungsadministrator für die logische Infrastruktur. Dementsprechend kann es zwei verschiedene zentrale Verwaltungssoftwarestapel geben, und es kann einen Cloud-Infrastrukturmanager an der Spitze der hierarchischen Verwaltungsstruktur geben, um die Softwarestapel zu vereinheitlichen. Der Cloud-Infrastrukturmanager kann die Rollen des traditionellen Infrastrukturadministrators durch die folgenden unterschiedlichen Cloud-Rollen ersetzen: den Betreiber (für die Kontrolle der physischen und logischen Infrastruktur), den Mieter (für die abstrahierte Instanzkontrolle) und den Infrastruktur-Supporttechniker (für den Support).
Cloud-native Architekturen mögen traditionellen Cloud-Architekturen ähnlich sehen, aber sie unterscheiden sich in einem wesentlichen Aspekt. Cloud-native Architekturen verschmelzen die physische und logische Infrastruktur durch die Verwendung intelligenter Ein-/Ausgabe-Subsysteme (E/A-Subsysteme), hier „intelligente E/A-Peripheriegeräte“ genannt, um Dienste vom Host auszulagern (d. h. die herkömmliche, vom Host durchgeführte Verarbeitung auszulagern) und durch die Isolierung der Knotenverwaltungssteuerung innerhalb der intelligenten E/A-Peripheriegeräte. Die Verschmelzung von physischer und logischer Infrastruktur ändert die Allzwecknatur von Servern mit herkömmlicher Architektur, indem ein unabhängiger Softwarestapel verwendet wird, der in Segmenten verwaltet werden kann (z. B. Segmente, die auf SDC-, SDS- und SDN-Schichten ausgerichtet sind). Dementsprechend wird ein solcher Server hier als segmentierter Server (oder „segmentierter Rechenknoten“) bezeichnet. Dieses segmentierte Steuermodell stellt den Server mit der Legacy-Architektur vor die Herausforderung, dass alle unabhängigen Manager in einen „Bereitschaftszustand“ versetzt werden müssen, bevor die von den intelligenten E/A-Peripheriegeräten bereitgestellten Backend-E/A-Dienste erbracht werden. Diese neue Orchestrierung und Sequenzierung führt zu einer stärker vertikal integrierten (d. h. eng gekoppelten oder vereinheitlichten) Architektur. Während die Cloud-native Architektur eine hierarchische Struktur für die Steuerungsverwaltung verwendet, ist das Ergebnis eine einheitliche Erfahrung rund um drei Steuerrollen: der Betreiber, der Mieter und der Supporttechniker.
Der Begriff „intelligentes E/A-Peripheriegerät“ bezieht sich auf ein Gerät oder eine Komponente der Computerplattform, die eine oder mehrere Funktionen für den Host bereitstellt, die in älteren Architekturen vom Host gesteuert wurden. Im Allgemeinen handelt es sich bei einem intelligenten E/A-Peripheriegerät um einen Hardwareprozessor, dem eine bestimmte Persönlichkeit zugewiesen (z. B. programmiert) wurde. Das intelligente E/A-Peripheriegerät kann einen oder mehrere Backend-E/A-Dienste (oder „vom Host ausgelagerte Dienste“) in Übereinstimmung mit seiner Persönlichkeit bereitstellen. Bei den Backend-E/A-Diensten kann es sich um nicht-transparente oder transparente Dienste handeln. Ein Beispiel für einen nicht-transparenten Host-Dienst ist ein virtueller Hypervisor-Switch-Offload-Dienst, der PCIe-Direkt-E/A (z. B. CPU Input-Output Memory Management Unit (IOMMU) Mapping von physischen und/oder virtuellen PCIe-Gerätefunktionen) ohne Host-Steuerung verwendet. Ein transparenter Host-Backend-E/A-Dienst erfordert keine Änderung der Host-Software. Zu den transparenten Backend-E/A-Diensten gehören beispielsweise netzwerkbezogene Dienste wie Verschlüsselungsdienste, Overlay-Netzwerkzugangsdienste und Firewall-basierte Netzwerkschutzdienste. Im Allgemeinen kann das intelligente E/A-Peripheriegerät eine beliebige Anzahl von transparenten und/oder nicht-transparenten Backend-Netzwerkdiensten für den Host bereitstellen. Zu den netzbezogenen Backend-Diensten gehören beispielsweise Overlay-Netzwerkdienste, virtuelle Vermittlungsdienste, virtuelle Routingdienste und Netzwerkfunktionsvirtualisierungsdienste. Speicherbezogene Backend-Dienste können beispielsweise Backend-Speicher-E/A-Dienste für den Host, wie Speicherbeschleunigungsdienste (z. B. NVMe-basierte Dienste), direkt angeschlossene Speicherdienste oder SAS-Speicherdienste (Serial Attached SCSI) umfassen.
Ein intelligentes E/A-Peripheriegerät kann mit einer anderen Netzwerkkomponente koordiniert werden, um einen oder mehrere Backend-E/A-Dienste bereitzustellen. Bei dem intelligenten E/A-Peripheriegerät kann es sich beispielsweise um einen „intelligenten NIC“ handeln, der mit einem Ethernet-Top-ofthe-Rack-Switch (ToR) verbunden ist. Diese Kombination kann eine Host-Isolierung bieten, indem der Smart NIC in seinem „Sperrzustand“ für physische und virtuelle PCIe-Funktionen (Peripheral Component Interconnect Express) verwendet wird. Hier bezieht sich der „Sperrzustand“ auf die Einschränkung des Host-Zugriffs auf die vollständige Rekonfigurationsfähigkeit des Geräts auf der Grundlage der Ziele des Cloud-Betreibers. Beispielsweise kann der Sperrzustand den Host daran hindern, bestimmte Infrastrukturen zu rekonfigurieren (z. B. Abschalten der Speicherredundanz, Abschalten der GPUs usw.), was sich beispielsweise auf die vertraglichen Verpflichtungen des Cloud-Betreibers gegenüber dem Mieter auswirken könnte. Mit dieser Anordnung kann der ToR-Switch verwendet werden, um Netzwerkdienste wie einen Netzwerkschutzdienst (z. B. einen Firewall-Dienst) oder einen Instanz-Overlay-Dienst (z. B. einen VxLAN-Dienst (Virtual Extensible Local Area Network)) bereitzustellen.
Das intelligente E/A-Peripheriegerät kann eine von vielen verschiedenen physischen Formen annehmen und eine Vielzahl von Backend-E/A-Diensten anbieten. Ein bestimmtes intelligentes E/A-Peripheriegerät kann Netzwerkkonnektivität (z. B. einen Ethernet-Anschluss), mehrere CPU-Kerne, Hardware-Beschleunigungsmodule und eine umfangreiche Programmierumgebung (d. h. eine Umgebung, die die Integration unabhängiger Softwarekomponenten verbessert) bereitstellen. Darüber hinaus kann das intelligente E/A-Peripheriegerät eine Endpunktkonnektivität (z. B. einen oder mehrere PCle-Ports) zu einem In-Band-Kommunikationskanal (z. B. eine PCIe-Verbindung oder ein PCIe-Bus) bieten, auf den der Host zugreifen kann. Als spezifisches Beispiel können die Komponenten eines PCIe-Karten-basierten Smart-I/O-Peripheriegeräts auf einem Leiterplattensubstrat montiert werden, das einen PCIe-Kartenrandanschluss hat, der einen Formfaktor aufweist, der es ermöglicht, das Smart-I/O-Peripheriegerät in einem PCIe-Kartensteckplatz des Servers zu installieren. In Übereinstimmung mit weiteren Implementierungen kann ein Smart-I/O-Peripheriegerät so konstruiert sein, dass es in einem anderen Kartensteckverbinder als einem PCIe-Kartensteckverbinder installiert werden kann, und in Übereinstimmung mit noch weiteren Beispielimplementierungen können Komponenten des Smart-I/O-Peripheriegeräts auf einer Hauptplatine des Servers montiert (z. B. oberflächenmontiert) werden.
Ein Cloud-nativer, segmentierter Rechenknoten mit intelligenten E/A-Peripheriegeräten führt zu einem dualen Verwaltungssteuerungssystem innerhalb des Rechenknotens, das die Steuerung des intelligenten E/A-Geräts von der Steuerung der Host-CPU trennt, indem es eine hardware-abstrahierte Schnittstelle zum Host hinzufügt. Die hardware-abstrahierte Schnittstelle kann dem Host als standardmäßige lokale E/A-Peripherie (d. h. eine nicht intelligente E/A-Peripherie) präsentiert werden.
Der Host kann auf ein intelligentes E/A-Peripheriegerät zugreifen (z. B. auf ein PCIe-basiertes intelligentes E/A-Peripheriegerät mit direkter PCIe-E/A-Kommunikation), um physische Funktionen und virtuelle Funktionen (z. B. physische und virtuelle PCIe-Funktionen) in Host-abstrahierten Anwendungsbetriebsumgebungen abzubilden. Die von der intelligenten E/A-Peripherie bereitgestellten Backend-E/A-Dienste können von der intelligenten E/A-Peripherie unabhängig vom Host vollständig verwaltet werden. Darüber hinaus können die Lebenszyklen dieser Dienste von der intelligenten E/A-Peripherie unabhängig vom Host gesteuert werden.
Daher unterscheidet sich ein segmentierter Rechenknoten, der über eine Cloud-native Infrastrukturarchitektur mit von der Hardware abstrahierten intelligenten E/A-Peripheriegeräten verfügt, von einem nicht segmentierten Rechenknoten mit einer Legacy-Architektur, die auf einer Host-zentrierten Steuerung basiert. Dieser Unterschied führt zu einer Architekturlücke in aktuellen Serverdesigns, sowohl in der Pre-Boot- als auch in der Laufzeitumgebung. Die Architekturlücke stellt eine Herausforderung für die Orchestrierung der Steuerung dar, da der Host nicht mehr die Wurzel der Steuerung ist.
Ein Ansatz zur Lösung dieses Problems und zur Überbrückung der Architekturlücke besteht darin, eine ältere Server-Hardwarearchitektur so zu modifizieren, dass die Steuerung des Servers in einem Dienstprozessor des Servers verankert werden kann. So kann beispielsweise ein Steckplatzanschluss (z. B. ein PCle-Anschluss) der alten Server-Hardwarearchitektur so modifiziert werden, dass er einen Seitenband-Kommunikationskanal mit einem Baseboard Management Controller (BMC) unterstützt. Im Allgemeinen ist der BMC ein Dienstprozessor, der für die Verwaltung der Computerplattform konstruiert ist. Bei diesem Ansatz wird die Steuerung dem BMC übertragen, und die traditionelle Rolle des BMC wird auf die Verwaltung der intelligenten E/A-Peripheriegeräte erweitert, indem der Verwaltungsverkehr über den Seitenband-Kommunikationskanal übermittelt wird. Ein anderer Ansatz zur Überbrückung der Architekturlücke kann darin bestehen, die Hardware-Architektur des Legacy-Servers so zu modifizieren, dass ein zusätzlicher Service-Prozessor, ein Plattform-Controller und eine Root-Steuerung im Plattform-Controller eingebaut werden, so dass der Plattform-Controller sowohl den BMC als auch das intelligente E/A-Peripheriegerät überwacht.
Die oben beschriebenen Ansätze zur Überbrückung der Architekturlücke in einem segmentierten Server erfordern Änderungen an den Architekturen von Servern der nächsten Generation. Die Änderung der Hardware-Architektur von älteren Servern, um intelligente E/A-Peripheriegeräte in Servern der nächsten Generation unterzubringen, bietet jedoch keine Abwärtskompatibilität für bestehende Server.
Gemäß den hier beschriebenen Beispielimplementierungen wird eine Vertrauensdomäne (hier als „Cloud-Mieterdomäne“ bezeichnet) des Hosts eines Servers mit einer hardwareisolierten Vertrauensdomäne (hier als „Cloud-Betreiberdomäne“ bezeichnet) eines intelligenten E/A-Peripheriegeräts des Servers vermischt. Durch diese Vermischung wird sichergestellt, dass die Dienste des Hosts, die an die intelligente E/A-Peripherie ausgelagert werden können, sowohl vor der Inbetriebnahme der Betriebsumgebung als auch nach der Inbetriebnahme der Betriebsumgebung gesichert und kontrolliert werden. Anders ausgedrückt, der Software-Stack des Hosts wird in Übereinstimmung mit den Beispielimplementierungen mit den ausgelagerten Diensten vermischt. Diese Vermischung der vom Host ausgelagerten Dienste mit dem Host-Software-Stack kann sich auf die abstrahierten Anwendungsbetriebsumgebungen (z. B. Bare-Metal-OS-Umgebungen, Hypervisor-VM-Umgebungen und OS-Container-Anwendungen) auswirken, die von der intelligenten E/A-Peripherie unterstützt werden. In Übereinstimmung mit Beispielimplementierungen umfasst ein Server einen Host-Überwachungsdienst (oder „Überwachungsdienst“) für jede Anwendungsbetriebsumgebung.
Für eine Bare-Metal-Anwendungsbetriebsumgebung (d. h. eine Umgebung, in der die Software vollen Zugriff auf die Host-CPU und andere Ressourcen der physischen Plattform hat, die für die Software zugänglich sind) stellt der Server einen Host-Überwachungsdienst bereit, der die Backend-E/A-Dienste, die von der intelligenten E/A-Peripherie bereitgestellt werden, in einer einzigen Sicherheitsvertrauensdomäne mit dem Host-Bereich verbindet. Darüber hinaus kann das Bare-Metal-Betriebssystem gemäß Beispielimplementierungen Hypervisor- und Container-Anwendungsbetriebsumgebungen bereitstellen, und der Server kann entsprechende Hostüberwachungsdienste für diese Umgebungen bereitstellen. Die Host-Überwachungsdienste bieten die Möglichkeit, die Architekturlücke auszugleichen, die durch die Undurchsichtigkeit der Architektur des intelligenten E/A-Peripheriegeräts entsteht.
Die Verwendung von Host-Überwachungsdiensten zur Verwaltung von Smart-I/O-Peripheriegeräten kann zu Problemen führen, da sich Smart-I/O-Peripheriegeräte anders verhalten als herkömmliche Peripheriegeräte. Beispielsweise kann ein bestimmter Host-Überwachungsdienst eine PCIe-Bus-Enumeration durchführen, und das intelligente E/A-Peripheriegerät kann eine PCIe-Karte sein. Gemäß dem PCIe-Standard sollte ein PCIe-Bus-Gerät auf eine gültige Konfigurationsanforderung innerhalb eines Zeitlimits von einer Sekunde nach dem Zurücksetzen oder Einschalten des PCle-Bus-Geräts reagieren. Reagiert das PCIe-Bus-Gerät nicht innerhalb der Zeitspanne von einer Sekunde auf eine gültige Konfigurationsanforderung, so gilt das PCIe-Bus-Gerät traditionell als ausgefallen.
Ein intelligentes E/A-Peripheriegerät kann jedoch relativ komplexer sein als ein herkömmliches PCIe-Busgerät, das keine intelligenten E/A-Dienste bietet. Aufgrund dieser Komplexität kann ein voll funktionsfähiges, PCIe-basiertes Smart-I/O-Peripheriegerät nicht in der Lage sein, innerhalb des Zeitlimits von einer Sekunde zu reagieren, nachdem das Smart-I/O-Peripheriegerät eingeschaltet oder zurückgesetzt wurde. Anders als herkömmliche PCIe-Busgeräte kann ein intelligentes E/A-Peripheriegerät eine relativ komplexe Architektur aufweisen, beispielsweise eine Architektur, die ein komplexes Multi-Core-Verarbeitungssystem und Hardware-Beschleuniger-Engines (z. B. Kryptographie-Engines und Paketprüfungs-Engines) umfasst. Das intelligente E/A-Peripheriegerät, das auf einen Startvorgang reagiert, kann außerdem über das Netzwerk von einem Domänenmanager gesteuert werden, um ein physisches Infrastrukturinventar zu bestimmen und logische Domänenverbindungen, wie SDN-, SDC- und SDS-Verbindungen, einzurichten. Aufgrund dieser Komplexität kann das intelligente E/A-Peripheriegerät (im Vergleich zu einem nicht intelligenten PCIe-E/A-Peripheriegerät) relativ lange brauchen, um nach dem Einschalten oder Zurücksetzen des intelligenten E/A-Peripheriegeräts reaktionsbereit zu sein.
Bei einem intelligenten E/A-Peripheriegerät kann es auch zu einer erheblichen, unbestimmten Verzögerung kommen, wenn Konfigurationsänderungen am intelligenten E/A-Peripheriegerät vorgenommen werden, z. B. Änderungen, bei denen die logischen Verbindungen geändert werden oder das intelligente E/A-Peripheriegerät anderweitig Änderungen an seinen Backend-E/A-Diensten vornimmt. Beispielsweise kann die Anzahl der Verarbeitungskerne, die einer VM-Instanz zugewiesen sind, erhöht werden; und aufgrund dieser Änderung kann eine Overlay-Netzwerkverbindung für einen Backend-E/A-Dienst hinzugefügt werden, der von der VM-Instanz verwendet wird. Das Hinzufügen der Overlay-Netzwerkverbindung kann beispielsweise bedeuten, dass das intelligente E/A-Peripheriegerät eine virtuelle Funktion, die vom intelligenten E/A-Peripheriegerät bereitgestellt wird, konfiguriert oder rekonfiguriert. Dementsprechend kann es beim intelligenten E/A-Peripheriegerät zu einer relativ langen Verzögerung kommen, bis die virtuelle Funktion einsatzbereit ist.
Dementsprechend kann ein intelligentes E/A-Peripheriegerät aufgrund seiner relativen Komplexität möglicherweise nicht so reagieren, wie man es von herkömmlichen E/A-Peripheriegeräten erwartet.
Gemäß Beispielimplementierungen stellt ein intelligentes E/A-Peripheriegerät eine Bereitschaftsanzeige zur Verfügung, auf die ein Host-Überwachungsdienst zugreifen kann, um festzustellen, ob das intelligente E/A-Peripheriegerät bereit ist oder nicht. In diesem Zusammenhang bedeutet die „Bereitschaft“ des intelligenten E/A-Peripheriegeräts in Übereinstimmung mit Beispielimplementierungen im Allgemeinen, ob das intelligente E/A-Peripheriegerät bereit ist, mit dem Host fortzufahren. Beispielsweise kann die Bereitschaftsanzeige anzeigen, ob ein Konfigurationsbereich des intelligenten E/A-Peripheriegeräts bereit ist, von einem Host-Überwachungsdienst konfiguriert zu werden oder nicht. Ein weiteres Beispiel ist, dass die Bereitschaftsanzeige anzeigt, ob eine bestimmte Funktion des intelligenten E/A-Peripheriegeräts verfügbar ist oder nicht.
Als spezifischeres Beispiel kann ein Host-Überwachungsdienst als Reaktion auf das Einschalten oder Zurücksetzen des Servers als Teil der Busaufzählung das Vorhandensein von Peripheriegeräten (z. B. PCIe-Bus-Peripheriegeräte) erkennen und für jedes erkannte Peripheriegerät einen Konfigurationsbereich des Peripheriegeräts mit den Adressen des zugewiesenen Speicherbereichs und/oder E/A-Bereichs einrichten. Nach der Erkennung des Vorhandenseins des intelligenten E/A-Peripheriegeräts kann der Host-Überwachungsdienst beispielsweise auf eine Bereitschaftsanzeige des intelligenten E/A-Peripheriegeräts zugreifen, um festzustellen, ob sich das intelligente E/A-Peripheriegerät in einem Zustand befindet, der es dem Host-Überwachungsdienst erlaubt, mit dem Einrichten des Konfigurationsbereichs des intelligenten E/A-Peripheriegeräts fortzufahren oder nicht. Der Host-Überwachungsdienst kann daher die Einrichtung der Konfiguration solange zurückhalten, bis das intelligente E/A-Peripheriegerät die Bereitschaftsanzeige auf einen Zustand setzt, der es dem Host-Überwachungsdienst erlaubt, mit der Einrichtung fortzufahren.
Als weiteres Beispiel kann ein intelligentes E/A-Peripheriegerät eine Single-Root-Input-Output-Virtualisierung (SR-IOV) bieten, die Sätze virtueller Funktionen für entsprechende physische Funktionen des intelligenten E/A-Peripheriegeräts bereitstellt. Ein Hypervisor-basierter Host-Überwachungsdienst kann z. B. als Reaktion auf die Aktivierung einer VM-Instanz die Nutzung eines E/A-Dienstes, der von der intelligenten E/A-Peripherie bereitgestellt werden soll, durch die VM-Instanz sperren. Wie hierin weiter beschrieben, kann die Sperrung des E/A-Dienstes so lange gelten, bis das intelligente E/A-Peripheriegerät einen oder mehrere Bereitschaftszustandsindikatoren setzt, die mit virtuellen und/oder physischen Funktionen verbunden sind, die mit dem E/A-Dienst verknüpft sind, um anzuzeigen, dass die Funktion(en) bereit sind, verwendet zu werden.
Daher ermöglichen die Bereitschaftsindikatoren gemäß Beispielimplementierungen die Ausweitung von Host-Überwachungsdiensten auf die Domäne des Cloud-Betreibers, um intelligente E/A-Peripheriegeräte zu verwalten, ohne dass ältere Serverarchitekturen geändert werden müssen und ohne dass starre Zeitvorgaben gelten, die die komplexe Natur der intelligenten E/A-Peripheriegeräte nicht berücksichtigen. In Übereinstimmung mit Beispielimplementierungen kann die Ausweitung von Host-Überwachungsdiensten in die Cloud-Betreiberdomäne die vertikale Integration von Host-Software (z. B. Host-Software, die zur Ausführung der Host-Überwachungsdienste ausgeführt wird, Smart-I/O-Peripherie-Hardware und Smart-I/O-Peripherie-Software) beinhalten. Bei dieser vertikalen Integration kann die Hardware des intelligenten E/A-Peripheriegeräts beispielsweise so konstruiert sein, dass sie einen Registerraum verwaltet, in dem Bits gespeichert werden, die entsprechende Bereitschaftsanzeigen darstellen. Ein Software-Servicestack des intelligenten E/A-Peripheriegeräts kann so aufgebaut sein, dass er die Bereitschaftsindikatoren verwaltet. Die Ausweitung von Host-Überwachungsdiensten in die Domäne des Cloud-Betreibers kann die Modifizierung der Hardware des intelligenten E/A-Peripheriegeräts beinhalten (z. B. die Modifizierung eines Registerraums zur Speicherung von Bits, die entsprechende Bereitschaftszustandsindikatoren darstellen). Darüber hinaus kann die Ausweitung von Host-Überwachungsdiensten auf die Cloud-Betreiberdomäne die Modifizierung der Software des intelligenten E/A-Peripheriegeräts umfassen (z. B. die Modifizierung eines Software-Services-Stacks des intelligenten E/A-Peripheriegeräts), um die Bereitschaftszustandsindikatoren zu verwalten.
Unter Bezugnahme auf 1, als spezifischeres Beispiel, kann ein Cloudbasiertes Computersystem 100, das mit einem bestimmten Cloud-Betreiber verbunden ist, Multi-Tenant-Cloud-Dienste für mehrere Kunden oder Tenants anbieten. Bei den Cloud-Diensten kann es sich um eine beliebige Anzahl verschiedener Cloud-Dienste handeln, z. B. Software as a Service (SaaS), Infrastructure as a Service (laaS), Platform as a Service (PaaS) und so weiter. Darüber hinaus können die Cloud-Dienste je nach Implementierung mit einer von mehreren verschiedenen Cloud-Infrastrukturen verbunden sein, z. B. einer öffentlichen Cloud, die allen potenziellen Nutzern über ein öffentliches Netz zur Verfügung steht, einer privaten Cloud mit begrenztem Zugang, die über ein privates Netz bereitgestellt wird (z. B. Cloud-Dienste, die von einem Rechenzentrum vor Ort bereitgestellt werden), oder einer hybriden Cloud, die eine Kombination aus öffentlichen und privaten Clouds ist.
Die Mieter können auf die Domänenknoten 110 (z. B. Rechenknoten) des Cloud-Computersystems 100 über Cloud-Clients (z. B. Laptops, Desktop-Computer, Smartphones, Tablet-Computer, tragbare Computer usw.) zugreifen. Wie in 1 dargestellt, können die Domänenknoten 110 durch eine physische Netzwerkstruktur 184 miteinander verbunden sein. Im Allgemeinen kann die physische Netzwerkstruktur 184 mit einem oder mehreren Typen von Kommunikationsnetzwerken verbunden sein, wie (als Beispiele) Fibre-Channel-Netzwerke, Gen-Z-Fabrics, dedizierte Managementnetzwerke, lokale Netzwerke (LANs), Weitverkehrsnetzwerke (WANs), globale Netzwerke (z. B. das Internet), drahtlose Netzwerke oder eine beliebige Kombination davon. Wie in 1 dargestellt, können die Domänenknoten 110 durch logische Verbindungen 194, wie SDN-, SDC- und SDS-Verbindungen, miteinander verbunden sein.
Wie ebenfalls in 1 dargestellt, kann ein Domänenknotenmanager 190 (oder „Knotenmanager 190“) mit der physischen Netzwerkstruktur 184 und den logischen Verbindungen 194 verbunden sein. Je nach der jeweiligen Implementierung kann sich der Knotenmanager 190 auf dem Domänenknoten 110-1, auf einem anderen Domänenknoten 110, auf einem dedizierten Verwaltungsknoten, über mehrere Knoten des Cloud-Computersystems 100 verteilt usw. befinden. Im Allgemeinen enthält der Knotenmanager 190 physische Hardwareressourcen und logische Softwareressourcen zur Verwaltung der Domänenknoten 110. In Übereinstimmung mit einigen Implementierungen kann der Knotenmanager 190 mit einer Datenbank verbunden sein, die Daten speichert, die sich auf die Domänenknoten 110 beziehen, wie z. B. Daten, die Domänenknotenkonfigurationen, Telemetrieprotokolle, Prüfprotokolle usw. darstellen. Der Knotenmanager 190 kann eine Orchestrierungs-Engine enthalten, die den Betrieb von Blattmanagern des Cloud-Computersystems 100 verwaltet, um die Lebenszyklen zu steuern und die Blattressourcen (z. B. die hier beschriebenen intelligenten Eingabe-/Ausgabe-Peripheriegeräte 180) des Systems 100 zu konfigurieren. In Übereinstimmung mit einigen Implementierungen kann der Knotenmanager 190 absichtsbasierte Befehle (z. B. Redfish-Befehle) mit einem oder mehreren Hersteller-Root-Managern (nicht dargestellt) kommunizieren. Der Hersteller-Root-Manager enthält physische Hardwareressourcen und logische Softwareressourcen, um die beabsichtigten Befehle in herstellerspezifische Befehle für die Blattressourcen zu übersetzen, die mit einem bestimmten Hersteller verbunden sind, und diese herstellerspezifischen Befehle können von Blattressourcen-Managern (nicht dargestellt) für die Blattressourcen verarbeitet werden. Abhängig von der jeweiligen Implementierung können die Hersteller-Root-Manager und Blattressourcen-Manager auf einem oder mehreren administrativen Knoten angeordnet sein, auf einem oder mehreren Domänenknoten 110-1 verteilt sein und so weiter.
Bei dem Domänenknoten 110-1 kann es sich gemäß den Beispielimplementierungen um eine Computerplattform handeln. In diesem Zusammenhang bezieht sich eine „Computerplattform“ auf eine Einheit, die ein Chassis und auf dem Chassis montierte Hardware umfasst, wobei die Hardware in der Lage ist, maschinenausführbare Anweisungen (oder „Software“) auszuführen. Ein Blade-Server ist ein Beispiel für eine Computerplattform in Übereinstimmung mit einer Beispielimplementierung. Bei der Computerplattform kann es sich jedoch gemäß weiteren Implementierungen auch um eine andere Plattform als einen Blade-Server handeln, z. B. um einen Rack-Server, einen Client, einen Desktop, ein Smartphone, ein Speicher-Array, einen Laptop-Computer, einen Tablet-Computer und so weiter.
Bei Beispielimplementierungen, bei denen die Computerplattform ein Blade-Server ist, kann der Server einen Rahmen oder ein Chassis haben; eine oder mehrere Hauptplatinen können an dem Chassis befestigt sein; und jede Hauptplatine kann ein oder mehrere Multicore-Halbleiterpakete (oder „Sockel“ oder „Chips“) der Zentraleinheit (CPU) enthalten. In Übereinstimmung mit Beispielimplementierungen kann der Blade-Server einen Formfaktor, mechanische Verriegelung(en) und entsprechende elektrische Anschlüsse aufweisen, damit der Server-Blade in eine entsprechende Server-Blade-Öffnung oder einen Steckplatz in einem rackmontierten Blade-Gehäuse eingebaut und daraus entfernt werden kann.
In Übereinstimmung mit Beispielimplementierungen kann der Domänenknoten 110-1 eine Architektur mit Cloud-Segmenten aufweisen, in der intelligente E/A-Peripheriegeräte 180 des Domänenknotens 110-1 verschiedene logische Verbindungssegmente unabhängig vom Host des Domänenknotens 110-1 steuern können. Wie in 1 dargestellt, kann der Domänenknoten 110-1 eine oder mehrere Anwendungsbetriebsumgebungen 120 bereitstellen, die sich innerhalb einer Cloud-Tenant-Domäne 111 befinden. Im Allgemeinen können Tenant-Anwendungsinstanzen (z. B. VM-Instanzen, Container-Instanzen, nicht-virtualisierte Anwendungsinstanzen usw.) in den Anwendungsbetriebsumgebungen 120 ausgeführt werden. Im Allgemeinen können die Anwendungsbetriebsumgebungen 120 sowohl virtualisierte als auch nicht-virtualisierte Umgebungen darstellen.
Bei einer Anwendungsbetriebsumgebung 120 kann es sich beispielsweise um eine Bare-Metal-Umgebung des Betriebssystems (OS) handeln (eine „OS-Bare-Metal-Anwendungsbetriebsumgebung“), die Anwendungsinstanzen enthält, die Zugriff auf die nicht abstrahierten physischen Ressourcen des Domänenknotens 110-1 haben. Ein weiteres Beispiel: Eine Anwendungsbetriebsumgebung 120 kann eine OS-Container-Bare-Metal-Anwendungsbetriebsumgebung sein, in der Anwendungsinstanzen innerhalb von Container-Instanzen ausgeführt werden können. Ein weiteres Beispiel: Eine Anwendungsbetriebsumgebung 120 kann eine OS-Bare-Metal/VM-Umgebung sein, in der Anwendungsinstanzen innerhalb von VM-Instanzen oder außerhalb von VM-Instanzen ausgeführt werden können. Ein weiteres Beispiel: Eine Anwendungsbetriebsumgebung 120 kann eine OS-Container-Bare-Metal/VM-Umgebung sein, in der Anwendungsinstanzen innerhalb von Container-Instanzen, innerhalb von VMs oder außerhalb einer VM- oder Container-Instanz ausgeführt werden können.
In diesem Zusammenhang bezieht sich eine „virtuelle Maschine“ oder „VM“ (auch „virtuelle Gastmaschine“, „virtuelle Maschineninstanz“ oder „virtuelle Gastmaschineninstanz“ genannt) auf eine virtuelle Umgebung, die als Abstraktion auf Maschinenebene oder als virtuelles Computersystem fungiert und über eigene physische Ressourcen (z. B. CPU(s), Systemspeicher, Netzwerkschnittstelle(n) und Speicher) verfügt. Darüber hinaus kann die VM über eine eigene Abstraktion eines Betriebssystems verfügen; und im Allgemeinen ist die VM eine virtuelle Abstraktion der Hardware- und Softwareressourcen des Domänenknotens 110-1. Der Lebenszyklus (z. B. die Bereitstellung und Beendigung) der VM kann von einem Virtual Machine Monitor (VMM) oder Hypervisor 167 des Domänenknotens 110-1 verwaltet werden.
Ein „Container“ (auch „instanziierter Container“, „Containerinstanz“ oder „Softwarecontainer“ genannt), wie er hier verwendet wird, bezieht sich im Allgemeinen auf eine virtuelle Laufzeitumgebung für eine oder mehrere Anwendungen und/oder Anwendungsmodule, und diese virtuelle Laufzeitumgebung ist so aufgebaut, dass sie eine Schnittstelle zu einem Betriebssystemkern bildet. Ein Container für eine bestimmte Anwendung kann z. B. den ausführbaren Code für die Anwendung und ihre Abhängigkeiten, wie Systemtools, Bibliotheken, Konfigurationsdateien, ausführbare Dateien und Binärdateien für die Anwendung, enthalten. In Übereinstimmung mit Beispielimplementierungen enthält der Container eine Schnittstelle zur Einbindung des Betriebssystemkerns, aber nicht den Betriebssystemkern. So kann eine bestimmte Computerplattform beispielsweise mehrere Container enthalten, die sich einen Betriebssystemkern über entsprechende Betriebssystem-Kernel-Mount-Schnittstellen teilen. Docker-Container und rkt-Container sind Beispiele für Software-Container.
Gemäß Beispielimplementierungen kann jede Anwendungsbetriebsumgebung 120 über eine Betriebssystem- oder Hypervisor-Schnittstelle 121 (als „Betriebssystem-Hypervisor-Schnittstelle 121“ bezeichnet) verfügen, und gemeinsam können die Betriebssystem-Hypervisor-Schnittstellen 121 eine Tenant-Workload-Isolationsbarriere 197 zwischen der Cloud-Tenant-Domäne 111 und einer Cloud-Betreiberdomäne 113 des Domänenknotens 110-1 bilden. In Übereinstimmung mit Beispielimplementierungen wird die Cloud-Tenant-Domäne 111 als nicht vertrauenswürdige Domäne des Cloud-Computing-Systems 100 betrachtet, da die Domäne 111 mit Cloud-Tenant-Software verbunden ist. Die Cloud-Operator-Domäne 113 kann als vertrauenswürdige Domäne in Bezug auf die Cloud-Tenant-Domäne 111 betrachtet werden.
In Übereinstimmung mit Beispielimplementierungen umfasst die Cloud-Betreiberdomäne 113 eine gemischte physische und logische Infrastruktur, einschließlich physischer Hardware und vertrauenswürdiger Überwachungssoftwarekomponenten. Die Komponenten, die mit den hier beschriebenen Überwachungsdiensten verbunden sind, sind von den Arbeitslasten der Mieter durch die Arbeitslast-Isolationsbarriere 197 und eine Arbeitslast-Isolationsbarriere 198 getrennt, die durch die Host-Schnittstellen der intelligenten E/A-Peripheriegeräte 180 gebildet wird. Die physischen Hardwarekomponenten, die mit den Überwachungsdiensten verbunden sind, können beispielsweise eine oder mehrere CPUs 116 und Speicherkomponenten umfassen, die einen Systemspeicher 118 bilden. Gemäß Beispielimplementierungen handelt es sich bei dem Systemspeicher 118 und anderen hier erörterten Speichern um nicht transitorische Speichermedien, die aus Halbleiterspeichergeräten, Memristor-basierten Speichergeräten, magnetischen Speichergeräten, Phasenänderungsspeichergeräten, einer Kombination von Geräten aus einer oder mehreren dieser Speichertechnologien usw. gebildet werden können. Der Systemspeicher kann sowohl aus flüchtigen als auch aus nichtflüchtigen Speichervorrichtungen bestehen.
Zu den vertrauenswürdigen Überwachungssoftwarekomponenten der Cloud-Betreiberdomäne 113 können beispielsweise ein Hypervisor 167, ein Basis-Eingabe/Ausgabe-Betriebssystem (BIOS) 165, ein Unified Extensible Firmware Interface (UEFI) und ein Betriebssystem 163 gehören. Wie ebenfalls in 1 dargestellt, befinden sich die intelligenten E/A-Peripheriegeräte 180 innerhalb der Cloud-Betreiberdomäne 113. Die Cloud-Operator-Domäne 113 kann gemäß Beispielimplementierungen einen oder mehrere Host-Überwachungsdienste enthalten, die von vertrauenswürdigen Überwachungssoftwarekomponenten bereitgestellt werden. Beispielsweise kann die Cloud-Operator-Domäne 113 gemäß Beispielimplementierungen einen Pre-Boot-Überwachungsdienst 156 und einen oder mehrere Host-Überwachungsdienste enthalten, die während der Post-Boot- oder Laufzeit des Domänenknotens 110-1 arbeiten.
Insbesondere können die Host-Laufzeitüberwachungsdienste in Übereinstimmung mit einigen Implementierungen einen OS-Container-Laufzeitüberwachungsdienst 150, einen Hypervisor-VM-Laufzeitüberwachungsdienst 152 und einen OS-Bare-Metal-Laufzeitüberwachungsdienst 154 umfassen. Im Allgemeinen können die Host-Überwachungsdienste, wie hier beschrieben, eine Vielzahl von Zwecken für den Domänenknoten 110-1 erfüllen, die die Architekturlücke zwischen dem hostzentrierten Kontrollmodell und dem cloud-nativen Kontrollmodell überbrücken. Als Beispiele können die Host-Überwachungsdienste in Übereinstimmung mit Beispielimplementierungen die intelligenten E/A-Peripheriegeräte 180 konfigurieren; kontrollieren, wann Sperrungen von E/A-Diensten, die von den intelligenten E/A-Peripheriegeräten 180 bereitgestellt werden, auf der Grundlage von Bereitschaftszustandsindikatoren, die von den intelligenten E/A-Peripheriegeräten 180 bereitgestellt werden, aufgehoben werden; Ressourcen der intelligenten E/A-Peripheriegeräte 180 bereitstellen; einen Nachweis der Betriebszustände der intelligenten E/A-Peripheriegeräte 180 erbringen; Prüfprotokolle für die intelligenten E/A-Peripheriegeräte 180 abgleichen; und so weiter.
Gemäß einer Beispielimplementierung bietet das intelligente E/A-Peripheriegerät 180 eine oder mehrere Bereitschaftszustandsanzeigen (RSI). Eine RSI repräsentiert einen entsprechenden Bereitschaftszustand des intelligenten E/A-Peripheriegeräts 180 und kann von einem Host-Überwachungsdienst abgerufen werden, um den Bereitschaftszustand des intelligenten E/A-Peripheriegeräts 180 zu bestimmen. Die „Bereitschaft“ des intelligenten E/A-Peripheriegeräts 180 kann beispielsweise die Bereitschaft des intelligenten E/A-Peripheriegeräts 180 sein, von einem Host-Überwachungsdienst konfiguriert zu werden; die Bereitschaft des intelligenten E/A-Peripheriegeräts 180, fortzufahren, nachdem ein von dem Peripheriegerät bereitgestellter E/A-Dienst oder eine von dem Peripheriegerät 180 erstellte logische Verbindung geändert oder erstellt wurde; die Bereitschaft einer physischen oder virtuellen Funktion des intelligenten E/A-Peripheriegeräts 180; usw.
Die RSIs können RSIs für physische Funktionen und/oder virtuelle Funktionen des intelligenten E/A-Peripheriegeräts 180 sein. Insbesondere bietet das intelligente E/A-Peripheriegerät 180 gemäß Beispielimplementierungen eine oder mehrere physische Funktions-RSI 182, wobei jede physische Funktions-RSI 182 einen Bereitschaftszustand einer entsprechenden physischen Funktion (z. B. einer physischen PCle-Funktion) des intelligenten E/A-Peripheriegeräts 180 darstellt. In Übereinstimmung mit Beispielimplementierungen kann das intelligente E/A-Peripheriegerät 180 eine oder mehrere virtuelle Funktions-RSI 183 bereitstellen, wobei jede virtuelle Funktions-RSI 183 einen Bereitschaftszustand einer entsprechenden virtuellen Funktion (z. B. einer virtuellen PCIe-Funktion) des intelligenten E/A-Peripheriegeräts 180 darstellt.
Wie weiter unten beschrieben, kann ein Host-Überwachungsdienst eine oder mehrere Aktionen durchführen, die auf RSIs beruhen, die von den intelligenten E/A-Peripheriegeräten 180 bereitgestellt werden. Beispielsweise kann ein Host-Überwachungsdienst den Start einer VM-Instanz oder einer Container-Instanz so lange aufhalten, bis ein RSI, der einer virtuellen Funktion oder einer physischen Funktion für diese Instanz entspricht, anzeigt, dass die Funktion verfügbar oder bereit ist. Ein weiteres Beispiel: Der Host-Überwachungsdienst kann als Reaktion auf einen RSI-Zustand die Nutzung eines bestimmten E/A-Dienstes, der von einem intelligenten E/A-Peripheriegerät bereitgestellt wird, für eine Instanz sperren, während das intelligente E/A-Peripheriegerät den E/A-Dienst rekonfiguriert, und die Sperre aufheben (und so der Instanz die Nutzung des E/A-Dienstes ermöglichen), wenn sich der RSI-Zustand so ändert, dass er anzeigt, dass der E/A-Dienst bereit ist. Ein weiteres Beispiel: Ein Host-Überwachungsdienst kann mit dem Einrichten eines Konfigurationsbereichs eines intelligenten E/A-Peripheriegeräts 180 warten, bis ein RSI anzeigt, dass das intelligente E/A-Peripheriegerät 180 bereit ist, mit der Konfiguration fortzufahren.
In Übereinstimmung mit einigen Implementierungen kann ein Host-Überwachungsdienst die RSIs direkt von den intelligenten E/A-Peripheriegeräten 180 lesen. In Übereinstimmung mit weiteren Implementierungen kann jedoch ein Dienstprozessor des Domänenknotens 110-1, wie z. B. ein Baseboard Management Controller (BMC) 123, die RSI für die intelligenten E/A-Peripheriegeräte 180 überwachen und einen Registerraum 128 des BMC 123 mit Werten aktualisieren, die die RSI-Zustände darstellen. Der Registerraum 128 kann beispielsweise ein oder mehrere Register enthalten, wobei die registrierten Bitfelder verschiedenen RSI entsprechen, die die jeweiligen RSI-Zustände anzeigen. Der Host-Überwachungsdienst kann beispielsweise den BMC-Registerraum 128 über einen Seitenband-Kommunikationskanal lesen, um einen bestimmten RSI-Zustand zu bestimmen.
In Übereinstimmung mit einigen Implementierungen werden alle Fehlermeldungen für den Domänenknoten 110-1 an das BMC 123 weitergeleitet. Darüber hinaus kann das BMC 123 in Übereinstimmung mit Beispielimplementierungen „Hot-Plug-Benachrichtigungen“ vom Host (z. B. dem Betriebssystem 163 oder Hypervisor 167) als Reaktion auf entsprechende Instanzänderungen erhalten. Eine „Hot-Plug-Benachrichtigung“, wie sie hier verwendet wird, bezieht sich auf eine Benachrichtigung, dass ein bestimmter Backend-E/A-Dienst des intelligenten E/A-Peripheriegeräts 180 in Wartestellung versetzt werden soll. Diese Unterbrechung des Dienstes erfolgt, während das intelligente E/A-Peripheriegerät 180 eine Rekonfiguration durchführt, um die Instanzänderung zu berücksichtigen. Die BMC 123 kann in Übereinstimmung mit Beispielimplementierungen Daten in ihrem Registerraum 128 speichern, die das Halten eines bestimmten Dienstes darstellen, der von der intelligenten E/A-Peripherie 180 bereitgestellt wird. Wie hierin verwendet, bezieht sich eine „Instanzänderung“ (oder ein „Instanzänderungsereignis“) auf eine Änderung, die mit einer Instanz (z. B. einer VM-Instanz oder einer Container-Instanz) verbunden ist, die einer Änderung in einer oder mehreren Konfigurationen eines intelligenten E/A-Peripheriegeräts 180 entspricht. Eine Instanzänderung kann beispielsweise mit einer Konfigurationsänderung für eine virtuelle Funktion oder eine physische Funktion eines intelligenten E/A-Peripheriegeräts 180, einem Start einer Instanz, einer Beendigung einer Instanz, einer Zuweisung von Verarbeitungsressourcen (z. B. Kerne) an eine Instanz, einer Freigabe von Ressourcen für eine Instanz usw. verbunden sein.
Gemäß Beispielimplementierungen kann der Host-Überwachungsdienst als Reaktion auf eine Instanzänderung die Nutzung eines oder mehrerer betroffener E/A-Dienste durch die Instanz stilllegen, bis das intelligente E/A-Peripheriegerät die Konfigurationsänderungen vornimmt, um die Instanzänderung zu berücksichtigen. Wie hier weiter beschrieben, stellt der Host-Überwachungsdienst in Übereinstimmung mit Beispielimplementierungen den normalen Betrieb der Instanz wieder her (z. B. wird die Sperrung der Nutzung der E/A-Dienste durch die Instanz aufgehoben), wenn eine oder mehrere entsprechende RSI anzeigen, dass die entsprechende(n) Konfigurationsänderung(en) des intelligenten E/A-Peripheriegeräts 180 vorhanden ist (sind), um die Ausführung der Instanz fortzusetzen.
Im Allgemeinen ist ein „BMC“ ein spezialisierter Dienstprozessor, der den physischen Zustand eines Servers, Knotens oder einer anderen Hardware-Einheit mit Hilfe von Sensoren überwacht und mit einem Verwaltungssystem über ein Verwaltungsnetz kommuniziert. Der BMC kann mit Anwendungen, die auf der Betriebssystemebene ausgeführt werden, über einen IOCTL-Schnittstellentreiber (Input/Output Controller), eine REST-Anwendungsprogrammschnittstelle (API) oder einen anderen Systemsoftware-Proxy kommunizieren, der die Kommunikation zwischen dem BMC und den Anwendungen erleichtert. Die BMC kann auf Hardware-Ebene auf Hardware-Geräte der Hardware-Einheit zugreifen, einschließlich eines Systemspeichers, lokaler Speicher und so weiter. Die BMC kann in der Lage sein, die Hardware-Geräte direkt zu verändern. Die BMC kann unabhängig von den Betriebssysteminstanzen der Hardware-Einheit arbeiten. Der BMC kann sich auf einer Hauptplatine oder einer Hauptleiterplatte der Hardware-Einheit befinden. Die Tatsache, dass die BMC auf der Hauptplatine montiert oder anderweitig mit der Hauptplatine verbunden oder an ihr angebracht ist, verhindert nicht, dass die BMC als „getrennt“ von den Prozessoren betrachtet wird, die von der BMC überwacht/verwaltet werden. Wie hier verwendet, verfügt ein BMC über Verwaltungsfunktionen für Teilsysteme der Hardware-Einheit und ist von einer Verarbeitungsressource getrennt, auf der ein Betriebssystem des Computergeräts ausgeführt wird.
Unabhängig von ihrer besonderen Form oder Implementierung kann die BMC 123 einen oder mehrere eingebettete Prozessoren 124 enthalten, die maschinenausführbare Anweisungen 125 (die in einem Speicher 126 der BMC 123 gespeichert sind) ausführen, um Aktionen der BMC 123, wie hier beschrieben, durchzuführen. In Übereinstimmung mit Beispielimplementierungen können diese Aktionen die Kommunikation mit den intelligenten E/A-Peripheriegeräten 180 zum Lesen der RSI 182 und 183 umfassen. In Übereinstimmung mit Beispielimplementierungen kann die BMC 123 eine oder mehrere Anwendungsprogrammierschnittstellen (APIs) zum Lesen der RSI 182 und 183 bereitstellen. Beispielsweise kann ein Host-Überwachungsdienst eine API-Anforderung für einen bestimmten RSI-Wert an die BMC 123 senden, und der Prozessor 124 der BMC 123 kann als Reaktion auf die API-Anforderung den RSI-Wert lesen und den gelesenen RSI-Wert in einer entsprechenden API-Antwort bereitstellen. In Übereinstimmung mit weiteren Implementierungen kann die BMC 123 die RSI-Werte regelmäßig lesen und die RSI-Werte in dem Registerraum 128 der BMC 123 speichern. Ein Host-Überwachungsdienst kann z. B. ein bestimmtes Registerbit im Registerraum 128 lesen, um den Zustand eines bestimmten RSI zu bestimmen. Ein oder mehrere Prozessoren 124 der BMC 123 können in Übereinstimmung mit Beispielimplementierungen maschinenausführbare Anweisungen 125 zum Zweck des Empfangs und der Verwaltung von Hot-Plug-Benachrichtigungen vom Host ausführen.
Die BMC 123 kann die oben beschriebenen Aufgaben als Teil ihrer Verwaltungsebene wahrnehmen. Die BMC 123 kann eine Vielzahl anderer Verwaltungsdienste als die oben beschriebenen bereitstellen, wie z. B. die Überwachung von Sensoren (z. B. Temperatursensoren, Lüfterdrehzahlsensoren), die Überwachung des Betriebssystemstatus, die Überwachung des Energiestatus, die Steuerung des Ein- und Ausschaltens des Computersystems, die Protokollierung von Computersystemereignissen, die Ermöglichung der Fernverwaltung des Computersystems, die Durchführung von Wiederherstellungsvorgängen nach einem Ausfall des Betriebssystems oder des Computersystems und so weiter. In Übereinstimmung mit einigen Implementierungen kann die BMC 123 auch eine Sicherheitsebene haben, in der die BMC 123 verschiedene sicherheitsbezogene Funktionen für den Domänenknoten 110-1 ausführt, wie z. B. die Validierung von Firmware, bevor die Firmware vom Prozessor 124 geladen und ausgeführt werden darf; das Speichern, Erzeugen und Bereitstellen von kryptografischen Schlüsseln und so weiter.
In Übereinstimmung mit Beispielimplementierungen kann das intelligente E/A-Peripheriegerät 180 einen oder mehrere Hardware-Verarbeitungskerne 187 enthalten, die in einem Speicher 181 des Peripheriegeräts 180 gespeicherte Anweisungen 189 ausführen, um die hier beschriebenen Funktionen auszuführen. Auf diese Weise können die Befehle 189 in Übereinstimmung mit einigen Implementierungen mit einem Softwarestapel des intelligenten E/A-Peripheriegeräts 180 verbunden sein. Im Allgemeinen können ein oder mehrere Prozessoren 187 den Softwarestapel ausführen, um die Zustände der RSIs 182 und 183 zu verwalten und einen oder mehrere Backend-E/A-Dienste für das intelligente E/A-Peripheriegerät 180 bereitzustellen. In Übereinstimmung mit Beispielimplementierungen können ein oder mehrere Prozessoren 187 die Anweisungen 189 ausführen, um einen Beispielprozess 600 (6) zur Verwaltung der RSI-Zustände durchzuführen. Das intelligente E/A-Peripheriegerät 180 kann ferner einen oder mehrere Hardwarebeschleuniger 175 (z. B. P4-Hardware-Engines) enthalten, um eine Vielzahl von Funktionen wie Verschlüsselung, Entschlüsselung, Paketprüfung (z. B. Paketprüfung für einen verteilten Firewall-Dienst) usw. durchzuführen. Es wird darauf hingewiesen, dass das intelligente E/A-Peripheriegerät 180 eine Vielzahl unterschiedlicher Architekturen haben kann, einschließlich Komponenten, die in 1 nicht dargestellt sind. Neben anderen Komponenten kann das intelligente E/A-Peripheriegerät 180 einen oder mehrere Netzwerkschnittstellen-Controller (NICs) 186 enthalten, die entsprechende Ports (z. B. Ethernet-Ports) für die Kommunikation mit der physischen Netzwerkstruktur 184 enthalten. In Übereinstimmung mit Beispielimplementierungen bilden die intelligenten E/A-Peripheriegeräte eine Netzwerkisolationsbarriere 199 des Domänenknotens 110-1.
Wie in 1 dargestellt, kann das intelligente E/A-Peripheriegerät 180 in Übereinstimmung mit Beispielimplementierungen einen Konfigurationsraum 179, wie z. B. einen PCIe-Konfigurationsraum, enthalten, der von einem Host-Überwachungsdienst eingerichtet oder konfiguriert wird, wie hierin weiter beschrieben.
In Übereinstimmung mit einigen Implementierungen umfasst das intelligente E/A-Peripheriegerät 180 einen Registerraum 177, der Bitfelder enthält, die entsprechende RSls darstellen (z. B. physische Funktionen RSls 182 und virtuelle Funktionen RSls 183). In Übereinstimmung mit Beispielimplementierungen kann der Registerraum 177 durch die Host-Überwachungsdienste zugänglich sein (z. B. kann der Registerraum 177 durch einen In-Band-Kommunikationsbus, wie einen PCIe-Bus, zugänglich sein). In Übereinstimmung mit weiteren Implementierungen kann der Registerraum 177 für die BMC 123 über einen Seitenband-Kommunikationsbus zugänglich sein (z. B. kann der Registerraum 177 über einen Serial Peripheral Interface (SPI)-Bus oder einen erweiterten SPI (eSPI)-Bus zugänglich sein).
In Übereinstimmung mit einigen Implementierungen kann der Registerraum 177 Daten speichern, die angeben, ob das intelligente E/A-Peripheriegerät 180 offline ist. Beispielsweise können in einigen Implementierungen ein oder mehrere Prozessoren 187 des intelligenten E/A-Peripheriegeräts 180 Anweisungen 189 ausführen, um die Offline-Anzeige zu verwalten. Insbesondere kann bei einigen Implementierungen eine Einheit (z. B. eine CPU 116 oder BMC 123), die den Zustand einer RSI 182 oder 183 liest, das Lesen des Zustands durch Schreiben eines entsprechenden Bestätigungsbits (z. B. eines Bits des Registerraums 177) bestätigen. Dadurch kann das intelligente E/A-Peripheriegerät 180 feststellen, ob das Peripheriegerät 180 in einer Plattform installiert ist, die die RSI verwendet. Nachdem das intelligente E/A-Peripheriegerät 180 beispielsweise seine Einschaltsequenz durchlaufen hat, kann das intelligente E/A-Peripheriegerät 180 ein Bestätigungsbit lesen, das einem RSI entspricht (z. B. ein RSI, das der Primärfunktion Null entspricht, wie hierin weiter erläutert), um festzustellen, ob ein Zustand des RSI-Zustands gelesen wurde. Wenn das intelligente E/A-Peripheriegerät 180 beispielsweise feststellt, dass der Zustand nicht bestätigt wurde und der Konfigurationsraum 179 des intelligenten E/A-Peripheriegeräts 180 nicht eingerichtet wurde, kann das intelligente E/A-Peripheriegerät 180 ein Offline-Bit setzen, um anzuzeigen, dass das intelligente E/A-Peripheriegerät 180 sich selbst offline genommen hat.
Unter Bezugnahme auf 3A in Verbindung mit 1 arbeitet der Pre-Boot-Überwachungsdienst 156 während der Pre-Boot- oder Pre-Operating-Systemumgebung des Domänenknotens 110-1 (d. h. der Umgebung des Domänenknotens 110-1). Eine CPU 116 kann BIOS- oder UEFI-Anweisungen ausführen, um den Pre-Boot-Überwachungsdienst 156 bereitzustellen, und die Bereitstellung des Pre-Boot-Überwachungsdienstes 156 kann die Kommunikation der CPU 116 mit dem intelligenten E/A-Peripheriegerät 180 und dem BMC 123 beinhalten. Der Pre-Boot-Überwachungsdienst 156 kann in Übereinstimmung mit Beispielimplementierungen die Sichtbarkeit der Ressourcen des Domänenknotens 110-1 für den Mandanten einrichten. Ressourcen können aus verschiedenen Gründen vor einem Mieter verborgen werden, z. B. weil der Mieter nicht für die Ressourcen zahlen möchte, um die Qualität des Dienstes zu kontrollieren (da die Freigabe der Ressourcen die Leistung des Domänenknotens 110-1 beeinträchtigen kann) usw. In Übereinstimmung mit einigen Implementierungen kann die Pre-Boot-Überwachung 156 die Sichtbarkeit bestimmter physischer Funktionen und/oder virtueller Funktionen des intelligenten E/A-Peripheriegeräts 180 entsprechend steuern, so dass die Funktion(en) dem Knotenmanager 190 nicht ausgesetzt sind. Bei den ausgeblendeten Ressourcen kann es sich um eine beliebige Anzahl verschiedener Ressourcen handeln, wie z. B. Geräte (z. B. Grafikverarbeitungseinheiten (GPUs), CPUs, NVMe-Laufwerke usw.), Speicher oberhalb einer bestimmten Kapazität, CPU-Kernfrequenz oberhalb eines bestimmten Grenzwerts und so weiter. Im Allgemeinen nimmt der Pre-Boot-Überwachungsdienst 156 eine Bestandsaufnahme der logischen und physischen Infrastrukturressourcen vor, steuert die Sichtbarkeit der Ressourcen des Domänenknotens 110-1 und richtet die Anwendungsbetriebsumgebungen 120 ein. Der Pre-Boot-Überwachungsdienst 156 sucht in Übereinstimmung mit Beispielimplementierungen nach dem Knotenmanager 190 (z. B. sucht der Pre-Boot-Überwachungsdienst 156 über ein verschlüsseltes Overlay-Netzwerk) und bindet den Domänenknoten 110-1 zur Steuerung an den Knotenmanager 190.
Als Teil der Durchführung des Pre-Boot-Überwachungsdienstes 156 kann die CPU 116 zum Beispiel einen PCIe-Konfigurationsraum des intelligenten E/A-Peripheriegeräts 116 einrichten und einen Betriebszustand des intelligenten E/A-Peripheriegeräts 116 bestimmen. Zum Beispiel kann die CPU 116 feststellen, ob das intelligente E/A-Peripheriegerät 180 aktiv oder offline ist. Als Teil des Pre-Boot-Überwachungsdienstes 156 kann die CPU 116 weitere Aktionen durchführen, wie z. B. die Einrichtung der Anwendungsbetriebsumgebungen 120, den Abgleich von Prüfprotokollen, die Überprüfung des Nachweises eines Betriebszustands und so weiter.
Als Teil des Pre-Boot-Überwachungsdienstes 156 kann die CPU 116 eine Busaufzählung durchführen (z. B. eine PCIe-Busaufzählung), die die Erkennung des Vorhandenseins von Smart-I/O-Peripheriegeräten 180 und die Einrichtung eines Buskonfigurationsraums (z. B. eines PCle-Konfigurationsraums) für jedes erkannte Smart-I/O-Peripheriegerät umfasst. Als spezifischeres Beispiel kann die Smart-I/O-Peripherie 180 in Übereinstimmung mit einigen Implementierungen eine PCIe-Smart-I/O-Peripherie 180 sein, die ein Gerät 0, Funktion 0 (hier „Primärfunktion Null“ genannt) hat. Das intelligente E/A-Peripheriegerät 180 steuert einen Bitwert (d. h. eine physikalische Funktion RSI 182) eines Steuerkonfigurationsregisters, das mit der Primärfunktion Null verbunden ist, um anzuzeigen, ob das gesamte intelligente E/A-Peripheriegerät 180 bereit ist, konfiguriert zu werden. Wie hier weiter beschrieben, kann ein solcher Bitwert für die PCIe-Busaufzählung nützlich sein, damit ein Busaufzählungsdienst bestimmen kann, ob er mit der Konfiguration der intelligenten E/A-Peripherie 180 fortfahren soll, nachdem er das Vorhandensein der intelligenten E/A-Peripherie 180 erkannt hat. In Übereinstimmung mit weiteren Implementierungen kann das intelligente E/A-Peripheriegerät 180 eine physische RSI 182 bereitstellen, die sich von einer RSI unterscheidet, die der Primärfunktion Null zugeordnet ist, um darzustellen oder anzuzeigen, ob das intelligente E/A-Peripheriegerät 180 bereit ist, konfiguriert zu werden. Beispielsweise kann der Host-Überwachungsdienst 156 in einigen Implementierungen als Reaktion auf die RSI der physikalischen Funktion Null, die anzeigt, dass das intelligente E/A-Peripheriegerät 180 konfigurationsbereit ist, in den Konfigurationsbereich des intelligenten E/A-Peripheriegeräts 180 schreiben, um den Speicherbereich und/oder E/A-Bereich für das intelligente E/A-Peripheriegerät 180 einzurichten.
Wie in 2 in Verbindung mit 1 gezeigt, kann das intelligente E/A-Peripheriegerät 180 aufgrund seiner relativen Komplexität möglicherweise nicht innerhalb einer bestimmten vorgegebenen Zeit (z. B. dem einen festgelegten PCIe-Zeitlimit) für die Konfiguration bereit sein. 2 zeigt eine Einschaltsequenz 200 für ein intelligentes E/A-Peripheriegerät 180 gemäß einer Beispielimplementierung. Wie in 2 dargestellt, erfolgt die Einschaltsequenz über einen Zeitraum von 204 und beinhaltet eine Interaktion zwischen dem Knotenmanager 190 (z. B. einem Knotenmanager des Cloud-Management-Systems) und dem intelligenten E/A-Peripheriegerät. Nach dem Einschalten oder Zurücksetzen des intelligenten E/A-Peripheriegeräts 180 durchläuft das Peripheriegerät 180 eine erste Phase 204, in der das intelligente E/A-Peripheriegerät seine physische Infrastruktur konfiguriert. Dies kann z. B. das Einrichten von Prüfprotokollen, das Einrichten von Telemetrieprotokollen, das Bestimmen eines Sicherheitszustands, das Einrichten einer Arbeits-Basismessung usw. umfassen. Als nächstes richtet das intelligente E/A-Peripheriegerät 180 in einer SDN-Konfigurationsphase 208 seine SDN-Verbindungen zu einem oder mehreren Overlay-Netzwerken ein. Dies kann das Einrichten von Ausfallsicherheitsprotokollen, das Einrichten von Leistungsprotokollen und das Auswerten eines Sicherheitsstatus umfassen. Anschließend kann das intelligente E/A-Peripheriegerät 180 in einer SDS-Konfigurationsphase 212 die SDS-Verbindungen einrichten. Die Phase 212 kann die Bestimmung von Speicherkapazitäten, die Einrichtung von Isolierungen und Zugriff sowie die Bewertung des Sicherheitsstatus umfassen. In einer SDC-Phase 216 kann das intelligente E/A-Peripheriegerät 180 eine Anzahl von Instanzen virtueller Kerne bestimmen, Parameter virtueller Speicherinstanzen bestimmen, Anzahl und Typen von Netzwerkinstanzen bestimmen und einen Sicherheitszustand bewerten. In Übereinstimmung mit Beispielimplementierungen ist das intelligente E/A-Peripheriegerät 180 am Ende der SDC-Phase 216 bereit, vom Pre-Boot-Host-Überwachungsdienst 156 konfiguriert zu werden. In einer anschließenden Dienstkonfigurationsphase 220, die in 2 dargestellt ist, kann das intelligente E/A-Peripheriegerät 180 einen oder mehrere Backend-E/A-Dienste einrichten, die von dem intelligenten E/A-Peripheriegerät 180 bereitgestellt werden sollen. Diese Einrichtung kann die Instanzbereitstellung und -reihenfolge, die Einrichtung von Instanzprüfungs- und Telemetrieprotokollen, die Einrichtung von Instanzclustern, die Einrichtung von Failover-Clustern, die Einrichtung von Instanzdatenreplikation, die Bewertung von Instanzzertifizierungen und Compliance usw. umfassen.
In 4 ist ein Busaufzählungsprozess 400 dargestellt, der vom Host-Überwachungsdienst 156 als Reaktion auf ein Einschalten oder Zurücksetzen der Computerplattform 110-1 verwendet werden kann. Unter Bezugnahme auf 4 in Verbindung mit 1 und 3A kann der Prozess 400 bei einem Einschalten oder Zurücksetzen des Domänenknotens 110-1 zum Zwecke der Erkennung und Konfiguration von Busgeräten eingeleitet werden. Genauer gesagt, erkennt der Host-Überwachungsdienst 156 in Übereinstimmung mit Beispielimplementierungen das intelligente E/A-Peripheriegerät 180 (Block 402).
In einigen Implementierungen kann das intelligente E/A-Peripheriegerät 180 beispielsweise eine PCIe-Buskarte sein. Im Allgemeinen kann der Host-Überwachungsdienst 156 bei der PCle-Bus-Aufzählung versuchen, eine Herstelleridentifikation (ID) und eine Geräte-ID für verschiedene Kombinationen aus Busgerät, Busnummer und physikalischer Funktion zu lesen, um entsprechende PCle-Busgeräte zu erkennen. Hier bezieht sich ein „PCIe-Busgerät“ auf eine bestimmte physikalische PCIe-Funktion. Da alle PCIe-Karten die Primärfunktion Null implementieren (d. h. die physikalische Funktion 0 für Gerät 0), kann der Host-Überwachungsdienst 156 in Übereinstimmung mit Beispielimplementierungen versuchen, eine Busgeräte-ID und eine Hersteller-ID für die Primärfunktion Null für alle Busnummern und Busgerätenummern zu lesen, um PCIe-Busgeräte zu erkennen.
In Übereinstimmung mit Beispielimplementierungen bestimmt der Host-Überwachungsdienst 156 als Reaktion auf die Erkennung des intelligenten E/A-Peripheriegeräts 180 den Zustand des physischen RSI 182, der der Primärfunktion Null entspricht (Block 404). Basierend auf dem Zustand der RSI 182 kann der Host-Überwachungsdienst 156 dann bestimmen (Entscheidungsblock 408), ob das intelligente E/A-Peripheriegerät 180 bereit ist, konfiguriert zu werden.
Genauer gesagt kann der Host-Überwachungsdienst 156 in Übereinstimmung mit Beispielimplementierungen den Konfigurationsraum 179 ( 1) des Smart-I/O-Peripheriegeräts 180 auf der Grundlage von Konfigurationskriterien programmieren oder konfigurieren, die das Smart-I/O-Peripheriegerät 180 über Daten im Konfigurationsraum 179 bereitstellt. Bei Implementierungen, in denen das intelligente E/A-Peripheriegerät 180 eine PCle-Karte ist, kann das intelligente E/A-Peripheriegerät 180 beispielsweise über Basisadressregister (BARs) des Konfigurationsraums 280 entsprechende Speicherkriterien für die verschiedenen entsprechenden physikalischen Funktionen des intelligenten E/A-Peripheriegeräts 180 übermitteln. Auf diese Weise kann das intelligente E/A-Peripheriegerät 180 zum Beispiel für eine bestimmte physikalische Funktion die Zuweisung von Speicherplatz oder E/A-Raum sowie die bestimmte Menge an Speicher und/oder E/A-Raum anfordern. Wenn das intelligente E/A-Peripheriegerät 180 anfänglich hochfährt, kann das intelligente E/A-Peripheriegerät 180 jedoch nach dem Einschalten oder Zurücksetzen für eine gewisse Zeit nicht bereit sein, die angeforderten Speicherkriterien zu präsentieren, und das intelligente E/A-Peripheriegerät 180 kann nicht bereit sein, dass sein Konfigurationsraum 280 durch den Host-Überwachungsdienst 156 programmiert wird. Durch Überwachung der entsprechenden physikalischen Funktion RSI 182 kann der Host-Überwachungsdienst 156 bestimmen, wann er mit der Konfiguration des Konfigurationsraums 280 fortfahren muss.
Daher kommuniziert der Host-Überwachungsdienst 156 nach der Feststellung (Entscheidungsblock 408), dass das intelligente E/A-Peripheriegerät 180 bereit ist, mit der Konfiguration fortzufahren, gemäß Block 412 mit dem intelligenten E/A-Peripheriegerät 180 über den In-Band-Kommunikationskanal 211, um die vom intelligenten E/A-Peripheriegerät 180 angeforderten Konfigurationskriterien zu bestimmen. Gemäß Block 416 richtet der Host-Überwachungsdienst 156 den Konfigurationsbereich 280 des intelligenten E/A-Peripheriegeräts 180 basierend auf den angeforderten Konfigurationskriterien ein.
Wie in 3B gezeigt, kann der Host-Überwachungsdienst 150 gemäß Beispielimplementierungen mit einem Bare-Metal-Betriebssystem mit direkter E/A-Anwendungsbetriebsumgebung 120 verbunden sein. In diesem Beispiel kann ein O/S-Container-Laufzeit-Hostüberwachungsdienst 150 auf eine Anzeige des BMC 123 reagieren, dass ein bestimmtes Konfigurationsänderungsereignis bei einer Containerinstanz 324 aufgetreten ist. Als Reaktion auf das Container-Änderungsereignis kann der Host-Überwachungsdienst 150 einen Prozess 500 durchführen, der in 5 dargestellt ist.
Unter Bezugnahme auf 5 in Verbindung mit 1 und 3B kann der Prozess 500 als Reaktion auf ein Ereignis zur Änderung einer Laufzeit-Containerinstanz durchgeführt werden, wie z. B. die Erstellung einer Containerinstanz, die Beendigung einer Containerinstanz, die Zuweisung weiterer Kerne zu einer Containerinstanz usw. Diese Änderungen können Konfigurationsänderungen für eine oder mehrere physische oder virtuelle Funktionen des intelligenten E/A-Peripheriegeräts 180 entsprechen. Zum Beispiel kann eine bestimmte virtuelle Funktion einer neuen Container-Instanz zugewiesen werden, eine neue SDN-Verbindung kann eingerichtet werden, eine SDN-Verbindung kann entfernt werden, eine virtuelle Funktion kann einer anderen Container-Instanz neu zugewiesen werden, usw.
Gemäß dem Prozess 500 versetzt der Host-Überwachungsdienst 150 die Container-Instanz in einen ruhenden Betriebsmodus (Block 501), um das Änderungsereignis zu berücksichtigen (d. h. die Container-Instanz wird stillgelegt). In diesem Zusammenhang bedeutet das Versetzen der Containerinstanz in den Ruhezustand, dass die Operationen der Containerinstanz, die von dem Änderungsereignis betroffen sind, stillgelegt oder ausgeschaltet werden. Anders ausgedrückt: Durch die Ruhigstellung kann die Nutzung eines oder mehrerer E/A-Dienste, die von dem Änderungsereignis betroffen sind, durch die Containerinstanz auf Eis gelegt werden. Beispielsweise kann das Änderungsereignis einer Neukonfiguration einer bestimmten virtuellen Funktion der intelligenten E/A-Peripherie entsprechen, und das Versetzen der Containerinstanz in einen ruhenden Betriebsmodus kann das Anhalten des Sendens von Arbeitslasttransaktionen an eine virtuelle Funktion und das Ablassen oder Entfernen aller ausstehenden Transaktionen, die auf eine Antwort von der virtuellen Funktion warten, beinhalten. Gemäß Block 502 kommuniziert der Host-Überwachungsdienst 150 mit dem intelligenten E/A-Peripheriegerät 180, um eine Konfigurationsänderung in einem oder mehreren Diensten, die vom intelligenten E/A-Peripheriegerät 180 bereitgestellt werden, einzuleiten. Um diese Änderungen vorzunehmen, kann das intelligente E/A-Peripheriegerät 180 eine unbestimmte Zeitspanne benötigen. Dementsprechend bestimmt der Host-Überwachungsdienst 150 in Übereinstimmung mit Beispielimplementierungen den Zustand der entsprechenden RSI 182 und/oder 183 (Block 504) und ermittelt auf der Grundlage des Zustands, ob die geänderte(n) Funktion(en) bereit sind (Entscheidungsblock 508). Wenn sie bereit sind, schaltet der Host-Überwachungsdienst 150 gemäß Block 512 die Containerinstanz wieder in den normalen Betriebsmodus zurück, in dem die Containerinstanz die Funktion(en), die von der Konfigurationsänderung betroffen waren, wieder nutzt.
In ähnlicher Weise kann ein bestimmter Hypervisor-VM-Laufzeit-Hostüberwachungsdienst 152 in Verbindung mit einem Hypervisor mit direkter E/A-Anwendungsbetriebsumgebung 120 arbeiten (siehe 3C). Auf diese Weise kann der Host-Überwachungsdienst 152 als Reaktion auf ein Konfigurationsänderungsereignis bei einer bestimmten VM-Instanz 344 einen Prozess durchführen, um Operationen der VM-Instanz 344, die von dem Konfigurationsänderungsereignis betroffen sind, stillzulegen, bis die entsprechende(n) RSI anzeigt oder darstellt, dass der/die entsprechende(n) Backend-E/A-Dienst(e) bereit ist/sind; und wenn dies eintritt, bringt der Host-Überwachungsdienst 152 die VM-Instanz 344 wieder in einen normalen Modus zurück. In Übereinstimmung mit weiteren Implementierungen kann der Hypervisor mit direkter E/A-Anwendungsbetriebsumgebung 120 von 3C durch eine kernelbasierte Virtualisierungsumgebung ersetzt werden, wie z. B. eine kernelbasierte virtuelle Maschine (KVM), die ein Modul des Linux-Kernels ist.
3D zeigt einen OS-Bare-Metal-Laufzeit-Host-Überwachungsdienst 154, der in Verbindung mit einer Bare-Metal-O/S-Instanz-basierten Betriebsumgebung 120 arbeitet. Beispielsweise kann der Host-Überwachungsdienst 154 BIOS-bezogene und/oder UEFI-bezogene Konfigurationsdienste durchführen, die die von den intelligenten E/A-Peripheriegeräten 180 bereitgestellten RSI verwenden. Beispielsweise kann das BMC 123 in Übereinstimmung mit einigen Implementierungen eine Hot-Plug-Benachrichtigung als Reaktion darauf erhalten, dass ein bestimmtes kartenbasiertes Smart-I/O-Peripheriegerät 180 in den Domänenknoten 110-1 eingebaut oder aus ihm entfernt wird, während der Domänenknoten 110-1 eingeschaltet ist und sich in der Laufzeitumgebung befindet. In diesem Beispiel kann sich der Host-Überwachungsdienst 154 auf eine RSI des Smart-I/O-Peripheriegeräts 180 stützen, um einen Konfigurationsraum des Peripheriegeräts 180 einzurichten, ähnlich wie bei Prozess 400 (4). In Übereinstimmung mit Beispielimplementierungen kann der Host-Überwachungsdienst 154 andere BIOS-bezogene oder UEFI-bezogene Überwachungsdienste für die intelligenten E/A-Peripheriegeräte 180 durchführen.
Zurück zu 1: In Übereinstimmung mit Beispielimplementierungen können ein oder mehrere Rechenkerne 187 des intelligenten E/A-Peripheriegeräts 180 die Anweisungen 189 zum Zweck der Verwaltung der RSI 182 und 183 gemäß einem Prozess 600 ausführen, der in 6 dargestellt ist. Unter Bezugnahme auf 6 in Verbindung mit 1 kann der Prozess 600 als Reaktion auf eine Konfiguration oder Neukonfiguration von logischen Verbindungen und/oder Backend-E/A-Diensten, die von der intelligenten E/A-Peripherie 180 bereitgestellt werden, durchgeführt werden. Gemäß dem Prozess 600 schreibt (schreiben) der (die) Verarbeitungskern(e) 187 Daten in den Registerraum 177 (Block 602), um den Zustand (die Zustände) eines oder mehrerer RSI 182 und/oder 183 zu ändern, die von der Konfiguration betroffen sind, um anzuzeigen, dass die entsprechenden physischen und/oder virtuellen Funktionen nicht bereit sind. Der (die) Verarbeitungskern(e) 187 kann (können) dann die Konfiguration gemäß Block 604 durchführen. Wenn der (die) Verarbeitungskern(e) 187 feststellt (Entscheidungsblock 606), dass die Funktion(en) bereit ist (sind), dann schreibt (schreiben) der (die) Verarbeitungskern(e) 187 Daten in den Registerraum 177 (Block 612), um den (die) von der Konfiguration betroffenen RSI-Zustand(e) zu ändern, um anzuzeigen, dass die entsprechende(n) Funktion(en) bereit ist (sind).
Bezugnehmend auf 7 beinhaltet ein Prozess 700 in Übereinstimmung mit Beispielimplementierungen, dass mindestens ein Hardwareprozessor eines Hosts erste Anweisungen ausführt (Block 704), die mit einer Anwendungsbetriebsumgebung verbunden sind und mit einer nicht vertrauenswürdigen Cloud-Mieterdomäne verbunden sind. Die Anwendungsbetriebsumgebung verwendet einen Dienst eines intelligenten Eingabe/Ausgabe-Peripheriegeräts (E/A); und der Dienst des intelligenten E/A-Peripheriegeräts ist mit einer vertrauenswürdigen Cloud-Betreiberdomäne verbunden. Der Prozess 700 umfasst die Erweiterung (Block 708) eines Überwachungsdienstes des Hosts in die vertrauenswürdige Cloud-Betreiberdomäne. Das Erweitern des Überwachungsdienstes beinhaltet, dass der (die) Hardwareprozessor(en) zweite Anweisungen ausführt (ausführen), um das intelligente E/A-Peripheriegerät zu überwachen. Die Überwachung des intelligenten E/A-Peripheriegeräts umfasst die Konfiguration des intelligenten E/A-Peripheriegeräts durch den (die) Hardwareprozessor(en) und die Bestimmung eines Zustands einer Bereitschaftsanzeige, die von dem intelligenten E/A-Peripheriegerät bereitgestellt wird. Die Überwachung des intelligenten E/A-Peripheriegeräts umfasst ferner die Bestimmung, ob das intelligente E/A-Peripheriegerät auf der Grundlage des Zustands bereit ist, konfiguriert zu werden.
Wie in 8 dargestellt, enthält ein System 800 gemäß Beispielimplementierungen einen Anschluss 804 und einen Knoten 812. Der Anschluss 804 nimmt ein intelligentes Ein-/Ausgabe-Peripheriegerät (E/A) auf. Das intelligente E/A-Peripheriegerät soll einen E/A-Dienst bereitstellen, der mit einer vertrauenswürdigen Cloud-Betreiberdomäne verbunden ist. Der Knoten 812 umfasst mindestens eine zentrale Verarbeitungseinheit (CPU) 816 und einen Speicher 820. Die CPU(s) 816 führen Anweisungen 822 aus, die mit einer Anwendungsbetriebsumgebung und einer nicht vertrauenswürdigen Cloud-Mieterdomäne verbunden sind. Die CPU(s) 816 führen Anweisungen 824 aus, die mit der vertrauenswürdigen Cloud-Betreiberdomäne verbunden sind, um einen Überwachungsdienst für das intelligente E/A-Peripheriegerät als Reaktion auf eine Änderung in einer Instanz durchzuführen, die mit der Anwendungsbetriebsumgebung verbunden ist. Die Änderung entspricht einer Konfigurationsänderung des intelligenten E/A-Peripheriegeräts. Als Teil des Überwachungsdienstes führen die CPU(s) die Anweisungen 824 aus, um einen Zustand eines Bereitschaftszustandsindikators zu bestimmen, der vom intelligenten E/A-Peripheriegerät bereitgestellt wird, und auf der Grundlage des Zustands eine Verfügbarkeit der Instanz zu regulieren.
Bezugnehmend auf 9 speichert ein nichttransitorisches Speichermedium 910 gemäß Beispielimplementierungen maschinenlesbare erste Anweisungen 914, die, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, einen Eingabe/Ausgabe (E/A)-Dienst bereitzustellen, der mit einer vertrauenswürdigen Cloud-Betreiberdomäne und mit einem intelligenten E/A-Peripheriegerät verbunden ist. Die Anweisungen 914 veranlassen die Maschine, wenn sie von der Maschine ausgeführt werden, einen Bereitschaftszustandsindikator des intelligenten E/A-Peripheriegeräts zu verwalten, auf den ein Überwachungsdienst eines Hosts zugreifen kann und der einen Bereitschaftszustand des intelligenten E/A-Peripheriegeräts darstellt. Der Überwachungsdienst ist mit der vertrauenswürdigen Cloud-Betreiberdomäne verbunden. Der Host stellt eine Instanz bereit, die mit einer Anwendungsbetriebsumgebung verbunden ist und der nicht vertrauenswürdigen Cloud-Mieterdomäne zugeordnet ist. Die Instanz verwendet den E/A-Dienst. Die Anweisungen 914 veranlassen, wenn sie von der Maschine ausgeführt werden, dass die Maschine als Reaktion auf ein Konfigurationsereignis den Bereitschaftszustandsindikator dazu veranlasst, anzuzeigen, dass eine Funktion, die mit dem E/A-Dienst verbunden ist und von der intelligenten E/A-Peripherie bereitgestellt wird, nicht verfügbar ist. Darüber hinaus bewirken die Anweisungen 914, wenn sie von der Maschine ausgeführt werden, dass die Maschine eine mit der Funktion verbundene Konfiguration ändert und als Reaktion auf die Änderung der Konfiguration, die abgeschlossen ist, bewirkt, dass die Bereitschaftszustandsanzeige anzeigt, dass die Funktion verfügbar ist.
In Übereinstimmung mit Beispielimplementierungen umfasst das intelligente E/A-Peripheriegerät ein Busgerät. Die Konfiguration des intelligenten E/A-Peripheriegeräts umfasst das Einrichten eines Konfigurationsraums des intelligenten E/A-Peripheriegeräts als Teil eines Busaufzählungsprozesses. Ein besonderer Vorteil besteht gemäß einigen Implementierungen darin, dass für einen segmentierten Domänenknoten mit einer intelligenten E/A-Peripherie eine Architekturlücke zwischen einem hostzentrierten Steuerungsmodell und einer Cloud-nativen Architektur überbrückt werden kann, ohne dass eine Legacy-Server-Hardware geändert werden muss.
In Übereinstimmung mit Beispielimplementierungen umfasst das intelligente E/A-Gerät ein Busgerät, das mit einer primären physikalischen Funktion verbunden ist. Die Überwachung des intelligenten E/A-Peripheriegeräts umfasst ferner, dass der Überwachungsdienst das Vorhandensein des Busgeräts erkennt. Das Bestimmen des Zustands der Bereitschaftsanzeige beinhaltet das Bestimmen eines Zustands einer Bereitschaftsanzeige, die mit der primären physikalischen Funktion verbunden ist. Ein besonderer Vorteil besteht gemäß einigen Implementierungen darin, dass für einen segmentierten Domänenknoten mit einer intelligenten E/A-Peripherie eine Architekturlücke zwischen einem hostzentrierten Steuerungsmodell und einer Cloud-nativen Architektur überbrückt werden kann, ohne dass eine Legacy-Server-Hardware geändert werden muss.
Gemäß Beispielimplementierungen umfasst die Ausführung der zweiten Anweisungen die Ausführung von BIOS-Befehlen (Basic Input/Output System) oder UEFI-Befehlen (Unified Extensible Firmware Interface) durch den/die Hardwareprozessor(en). Ein besonderer Vorteil besteht gemäß einigen Implementierungen darin, dass für einen segmentierten Domänenknoten mit einer intelligenten E/A-Peripherie eine Architekturlücke zwischen einem hostzentrierten Steuerungsmodell und einer Cloud-nativen Architektur überbrückt werden kann, ohne dass eine Legacy-Server-Hardware geändert werden muss.
In Übereinstimmung mit Beispielimplementierungen durchläuft das intelligente E/A-Peripheriegerät als Reaktion auf das Einschalten oder Zurücksetzen eine Einschaltsequenz, und der Bereitschaftszustandsindikator entspricht einer mit der Einschaltsequenz verbundenen Verzögerung. Ein besonderer Vorteil besteht gemäß einigen Implementierungen darin, dass für einen segmentierten Domänenknoten mit einem intelligenten E/A-Peripheriegerät eine Architekturlücke zwischen einem hostzentrierten Steuerungsmodell und einer Cloud-nativen Architektur überbrückt werden kann, ohne dass eine Legacy-Server-Hardware geändert werden muss.
In Übereinstimmung mit Beispielimplementierungen konfiguriert das intelligente E/A-Peripheriegerät in der Einschaltsequenz logische Verbindungen und einen mit den logischen Verbindungen verbundenen Dienst. Ein besonderer Vorteil besteht gemäß einigen Implementierungen darin, dass für einen segmentierten Domänenknoten mit einem intelligenten E/A-Peripheriegerät eine Architekturlücke zwischen einem hostzentrierten Steuerungsmodell und einer Cloud-nativen Architektur überbrückt werden kann, ohne dass eine Legacy-Server-Hardware geändert werden muss.
In Übereinstimmung mit Beispielimplementierungen zeigt der Indikator für den Bereitschaftszustand an, ob eine Konfigurationsänderung abgeschlossen ist. Als Reaktion auf eine Änderung in der Instanz wird die Nutzung des E/A-Dienstes durch die Instanz angehalten. Als Reaktion auf den Zustand, der anzeigt, dass die Konfigurationsänderung abgeschlossen ist, wird die Sperre aufgehoben. Ein besonderer Vorteil besteht gemäß einigen Implementierungen darin, dass für einen segmentierten Domänenknoten mit einem intelligenten E/A-Peripheriegerät eine Architekturlücke zwischen einem hostzentrierten Steuerungsmodell und einer Cloud-nativen Architektur überbrückt werden kann, ohne dass eine Legacy-Server-Hardware geändert werden muss.
Gemäß Beispielimplementierungen ist die Änderung in der Instanz ein Start der Instanz, eine Beendigung der Instanz oder eine Änderung in einer Ressourcenzuweisung für die Instanz. Ein besonderer Vorteil besteht gemäß einigen Implementierungen darin, dass für einen segmentierten Domänenknoten mit einer intelligenten E/A-Peripherie eine Architekturlücke zwischen einem hostzentrierten Steuerungsmodell und einer Cloud-nativen Architektur überbrückt werden kann, ohne dass eine Legacy-Server-Hardware geändert werden muss.
Gemäß Beispielimplementierungen ist die Konfigurationsänderung eine Änderung, die mindestens eine virtuelle Funktion des mit der Instanz verbundenen intelligenten E/A-Peripheriegeräts oder eine physische Funktion des mit der Instanz verbundenen intelligenten E/A-Peripheriegeräts betrifft. Ein besonderer Vorteil besteht gemäß einigen Implementierungen darin, dass für einen segmentierten Domänenknoten mit einem intelligenten E/A-Peripheriegerät eine Architekturlücke zwischen einem hostzentrierten Steuerungsmodell und einer Cloud-nativen Architektur überbrückt werden kann, ohne dass eine Legacy-Server-Hardware geändert werden muss.
Gemäß Beispielimplementierungen liest ein Baseboard-Management-Controller den Zustand der Bereitschaftsanzeige aus und stellt dem Überwachungsdienst eine Darstellung des Zustands zur Verfügung. Ein besonderer Vorteil besteht gemäß einigen Implementierungen darin, dass für einen segmentierten Domänenknoten mit einer intelligenten E/A-Peripherie eine Architekturlücke zwischen einem hostzentrierten Steuerungsmodell und einer Cloud-nativen Architektur überbrückt werden kann, ohne dass eine ältere Serverhardware geändert werden muss.
In Übereinstimmung mit Beispielimplementierungen speichert ein Baseboard-Management-Controller eine Darstellung des Zustands in einem Registerraum des Baseboard-Management-Controllers. Ein besonderer Vorteil besteht gemäß einigen Implementierungen darin, dass für einen segmentierten Domänenknoten mit einer intelligenten E/A-Peripherie eine Architekturlücke zwischen einem hostzentrierten Steuerungsmodell und einer Cloud-nativen Architektur überbrückt werden kann, ohne dass eine Legacy-Server-Hardware geändert werden muss.
In Übereinstimmung mit Beispielimplementierungen empfängt ein Baseboard-Management-Controller eine Benachrichtigung über die Konfigurationsänderung und benachrichtigt den Überwachungsdienst als Reaktion auf den Empfang der Benachrichtigung. Ein besonderer Vorteil besteht gemäß einigen Implementierungen darin, dass für einen segmentierten Domänenknoten mit einer intelligenten E/A-Peripherie eine Architekturlücke zwischen einem hostzentrierten Steuerungsmodell und einer Cloud-nativen Architektur überbrückt werden kann, ohne dass eine Legacy-Server-Hardware geändert werden muss.
In Übereinstimmung mit Beispielimplementierungen ist die Instanz eine VM-Instanz. Ein Betriebssystem sperrt die Nutzung des E/A-Dienstes durch die VM-Instanz. Als Reaktion auf den Zustand, der angibt, dass die Konfigurationsänderung abgeschlossen ist, wird die Sperre aufgehoben. Ein besonderer Vorteil besteht gemäß einigen Implementierungen darin, dass für einen segmentierten Domänenknoten mit einer intelligenten E/A-Peripherie eine Architekturlücke zwischen einem hostzentrierten Steuerungsmodell und einer Cloud-nativen Architektur überbrückt werden kann, ohne dass eine Legacy-Server-Hardware geändert werden muss.
Gemäß den Beispielimplementierungen ist die Instanz eine Container-Instanz. Ein Hypervisor sperrt die Nutzung des E/A-Dienstes durch die Container-Instanz. Als Reaktion auf den Zustand, der angibt, dass die Konfigurationsänderung abgeschlossen ist, wird die Sperre aufgehoben. Ein besonderer Vorteil besteht gemäß einigen Implementierungen darin, dass für einen segmentierten Domänenknoten mit einer intelligenten E/A-Peripherie eine Architekturlücke zwischen einem hostzentrierten Steuerungsmodell und einer Cloud-nativen Architektur überbrückt werden kann, ohne dass eine Legacy-Server-Hardware geändert werden muss.
Gemäß Beispielimplementierungen bietet das intelligente E/A-Peripheriegerät eine einzige Root-Input-Output-Virtualisierung (SR-IOV), und die Änderung der Konfiguration entspricht einer virtuellen Funktion der SR-IOV. Ein besonderer Vorteil besteht gemäß einigen Implementierungen darin, dass für einen segmentierten Domänenknoten mit einer intelligenten E/A-Peripherie eine Architekturlücke zwischen einem hostzentrierten Steuerungsmodell und einer Cloud-nativen Architektur überbrückt werden kann, ohne dass eine Legacy-Server-Hardware geändert werden muss.
In Übereinstimmung mit Beispielimplementierungen wird ein Fehler des Überwachungsdienstes bei der Konfiguration des intelligenten E/A-Peripheriegeräts erkannt, und als Reaktion auf den erkannten Fehler werden Daten in einem Registerraum des intelligenten E/A-Peripheriegeräts gespeichert, die anzeigen, dass das intelligente E/A-Peripheriegerät offline ist. Ein besonderer Vorteil besteht gemäß einigen Implementierungen darin, dass für einen segmentierten Domänenknoten mit einem intelligenten E/A-Peripheriegerät eine Architekturlücke zwischen einem hostzentrierten Steuerungsmodell und einer Cloud-nativen Architektur überbrückt werden kann, ohne dass eine Legacy-Server-Hardware geändert werden muss.
In Übereinstimmung mit Beispielimplementierungen ist das Konfigurationsereignis ein Ereignis, das mit dem Einschalten oder Zurücksetzen der intelligenten E/A-Peripherie verbunden ist. Ein besonderer Vorteil besteht gemäß einigen Implementierungen darin, dass für einen segmentierten Domänenknoten mit einem intelligenten E/A-Peripheriegerät eine Architekturlücke zwischen einem hostzentrierten Steuerungsmodell und einer Cloud-nativen Architektur überbrückt werden kann, ohne dass eine Legacy-Server-Hardware geändert werden muss.
In Übereinstimmung mit Beispielimplementierungen ist das Konfigurationsereignis mit einer Instanz einer Anwendungsbetriebsumgebung des Hosts verbunden. Ein besonderer Vorteil besteht gemäß einigen Implementierungen darin, dass für einen segmentierten Domänenknoten mit einer intelligenten E/A-Peripherie eine Architekturlücke zwischen einem hostzentrierten Steuerungsmodell und einer Cloud-nativen Architektur überbrückt werden kann, ohne dass eine Legacy-Server-Hardware geändert werden muss.
Obwohl die vorliegende Offenbarung in Bezug auf eine begrenzte Anzahl von Implementierungen beschrieben wurde, werden Fachleute, die über die Vorteile dieser Offenbarung verfügen, zahlreiche Modifikationen und Variationen davon schätzen. Es ist beabsichtigt, dass die beigefügten Ansprüche alle derartigen Modifikationen und Variationen abdecken.

Claims

Ein Verfahren, das Folgendes umfasst: mindestens einen Hardwareprozessor eines Knotens, der erste Anweisungen ausführt, die mit einer Anwendungsbetriebsumgebung verbunden sind und mit einer nicht vertrauenswürdigen Cloud-Tenant-Domäne verbunden sind, wobei die Anwendungsbetriebsumgebung einen Dienst eines intelligenten Eingabe/Ausgabe-Peripheriegeräts (E/A) verwendet und der Dienst mit einer vertrauenswürdigen Cloud-Betreiberdomäne verbunden ist; und Erweitern eines Überwachungsdienstes des Knotens in die vertrauenswürdige Cloud-Betreiberdomäne, wobei: Erweitern des Überwachungsdienstes, wobei der mindestens eine Hardwareprozessor zweite Befehle ausführt, um das intelligente E/A-Peripheriegerät zu überwachen; und die Überwachung des intelligenten E/A-Peripheriegeräts den mindestens einen Hardwareprozessor einschließt, der das intelligente E/A-Peripheriegerät konfiguriert, einen Zustand eines Bereitschaftszustandsindikators bestimmt, der von dem intelligenten E/A-Peripheriegerät bereitgestellt wird, und basierend auf dem Zustand bestimmt, ob das intelligente E/A-Peripheriegerät bereit ist, konfiguriert zu werden.
Das Verfahren nach Anspruch 1, wobei: das intelligente E/A-Peripheriegerät umfasst ein Busgerät; und das Konfigurieren des intelligenten E/A-Peripheriegeräts das Einrichten eines Konfigurationsraums des intelligenten E/A-Peripheriegeräts als Teil eines Busaufzählungsprozesses umfasst.
Das Verfahren nach Anspruch 1, wobei: das intelligente E/A-Gerät umfasst ein Busgerät, das mit einer primären physikalischen Funktion verbunden ist; die Überwachung der intelligenten E/A-Peripherie umfasst ferner, dass der Überwachungsdienst das Vorhandensein des Busgeräts erfasst; und die Bestimmung des Zustands des Bereitschaftszustandsindikators die Bestimmung eines Zustands eines Bereitschaftszustandsindikators umfasst, der mit der primären physikalischen Funktion verbunden ist.
Verfahren nach Anspruch 1, wobei die Ausführung der zweiten Befehle umfasst, dass der mindestens eine Hardware-Prozessor mindestens einen der Befehle BIOS (Basic Input/Output System) oder UEFI (Unified Extensible Firmware Interface) ausführt.
Verfahren nach Anspruch 1, wobei das intelligente E/A-Peripheriegerät als Reaktion auf das Einschalten oder Zurücksetzen eine Einschaltsequenz durchläuft und der Bereitschaftszustandsindikator einer mit der Einschaltsequenz verbundenen Verzögerung entspricht.
Verfahren nach Anspruch 5, wobei das intelligente E/A-Peripheriegerät in der Einschaltsequenz logische Verbindungen und einen mit den logischen Verbindungen verbundenen Dienst konfiguriert.
Ein System, bestehend aus: einen Anschluss zur Aufnahme eines intelligenten Ein-/Ausgabe-Peripheriegeräts (E/A), wobei das intelligente E/A-Peripheriegerät einen E/A-Dienst bereitstellt, der mit einer vertrauenswürdigen Cloud-Betreiberdomäne verbunden ist; einen Knoten, der mindestens eine zentrale Verarbeitungseinheit (CPU) und einen Speicher umfasst, wobei die mindestens eine CPU erste Anweisungen ausführt, die mit einer Anwendungsbetriebsumgebung verbunden sind und mit einer nicht vertrauenswürdigen Cloud-Mieterdomäne verbunden sind, und die mindestens eine CPU zweite Anweisungen ausführt, die mit der vertrauenswürdigen Cloud-Betreiberdomäne verbunden sind, um: Durchführen eines Überwachungsdienstes für das intelligente E/A-Peripheriegerät als Reaktion auf eine Änderung in einer Instanz, die mit der Anwendungsbetriebsumgebung verbunden ist, wobei die Änderung einer Konfigurationsänderung des intelligenten E/A-Peripheriegerätes entspricht; und als Teil des Überwachungsdienstes den Zustand eines Bereitschaftsindikators bestimmen, der von der intelligenten E/A-Peripherie bereitgestellt wird, und auf der Grundlage des Zustands die Verfügbarkeit der Instanz regeln.
Das System nach Anspruch 7, wobei der Bereitschaftszustandsindikator anzeigt, ob die Konfigurationsänderung abgeschlossen ist, und die zweiten Befehle, wenn sie von der mindestens einen CPU ausgeführt werden, die mindestens eine CPU ferner veranlassen: als Reaktion auf die Änderung in der Instanz eine Funktion für die Verwendung des E/A-Dienstes durch die Instanz anhalten; und als Reaktion auf den Zustand, der angibt, dass die Konfigurationsänderung abgeschlossen ist, den Halt aufheben.
Das System nach Anspruch 7, wobei die Änderung der Instanz einen Start der Instanz, eine Beendigung der Instanz oder eine Änderung einer Ressourcenzuweisung für die Instanz umfasst.
Das System nach Anspruch 7, wobei die Konfigurationsänderung eine Änderung umfasst, die mindestens eine virtuelle Funktion des mit der Instanz verbundenen intelligenten E/A-Peripheriegeräts oder eine physische Funktion des mit der Instanz verbundenen intelligenten E/A-Peripheriegeräts betrifft.
Das System nach Anspruch 7, das ferner umfasst: eine Basisplatinen-Verwaltungssteuerung, um den Zustand der Bereitschaftsanzeige zu lesen und eine Darstellung des Zustands an den Überwachungsdienst zu liefern.
Das System nach Anspruch 11, wobei der Basisplatinen-Verwaltungscontroller eine Darstellung des Zustands im Registerraum des Basisplatinen-Verwaltungscontrollers speichert und die zweiten Anweisungen, wenn sie von der mindestens einen CPU ausgeführt werden, die mindestens eine CPU veranlassen, auf den Registerraum zuzugreifen, um die Darstellung zu lesen.
Das System nach Anspruch 7, das ferner umfasst: einen Baseboard-Management-Controller, um eine Benachrichtigung über die Änderung der Konfiguration zu empfangen und den Überwachungsdienst als Reaktion auf den Empfang der Benachrichtigung zu benachrichtigen.
Das System nach Anspruch 7, wobei: die Instanz umfasst eine Instanz einer virtuellen Maschine; und die zweiten Anweisungen, wenn sie von der mindestens einen CPU ausgeführt werden, ein Betriebssystem veranlassen, die Verwendung des E/A-Dienstes durch die Instanz der virtuellen Maschine anzuhalten, und als Reaktion auf den Zustand, der angibt, dass die Konfigurationsänderung abgeschlossen ist, die Anhaltung aufheben.
Das System nach Anspruch 7, wobei: die Instanz umfasst eine Container-Instanz; und die zweiten Anweisungen, wenn sie von der mindestens einen CPU ausgeführt werden, einen Hypervisor dazu veranlassen, die Verwendung des E/A-Dienstes durch die Containerinstanz anzuhalten, und als Reaktion auf den Zustand, der angibt, dass die Konfigurationsänderung abgeschlossen ist, die Anhaltung aufheben.
Das System nach Anspruch 7, wobei das intelligente E/A-Peripheriegerät eine einzelne Root-Input-Output-Virtualisierung (SR-IOV) bereitstellt und die Konfigurationsänderung einer virtuellen Funktion der SR-IOV entspricht.
Ein nicht-übertragbares Speichermedium zum Speichern von maschinenlesbaren Anweisungen, die, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen,: einen Eingabe-/Ausgabedienst (E/A) bereitstellen, der einer vertrauenswürdigen Cloud-Betreiberdomäne zugeordnet ist und mit einem intelligenten E/A-Peripheriegerät verbunden ist; Verwalten eines Bereitschaftszustandsindikators des intelligenten E/A-Peripheriegeräts, wobei der Bereitschaftszustandsindikator für einen Überwachungsdienst eines Hosts zugänglich ist und einen Bereitschaftszustand des intelligenten E/A-Peripheriegeräts darstellt, wobei die Überwachungsdienste mit der vertrauenswürdigen Cloud-Betriebsdomäne verbunden sind, der Host eine Instanz bereitstellt, die mit einer Cloud-Tenant-Anwendungsbetriebsumgebung verbunden ist und mit einer nicht vertrauenswürdigen Cloud-Tenant-Domäne verbunden ist, und die Instanz den E/A-Dienst verwendet; und als Reaktion auf ein Konfigurationsereignis den Bereitschaftszustandsindikator veranlassen, darzustellen, dass eine Funktion, die mit dem E/A-Dienst verbunden ist und von dem intelligenten E/A-Peripheriegerät bereitgestellt wird, nicht verfügbar ist, eine mit der Funktion verbundene Konfiguration ändern und als Reaktion auf die Änderung der Konfiguration, die abgeschlossen ist, den Bereitschaftszustandsindikator veranlassen, darzustellen, dass die Funktion verfügbar ist.
Das Speichermedium nach Anspruch 17, wobei die Befehle, wenn sie von der Maschine ausgeführt werden, ferner die Maschine veranlassen, einen Fehler des Überwachungsdienstes bei der Konfiguration des intelligenten E/A-Peripheriegeräts zu erkennen und als Reaktion auf den erkannten Fehler Daten in einem Registerraum des intelligenten E/A-Peripheriegeräts zu speichern, die anzeigen, dass das intelligente E/A-Peripheriegerät offline ist.
Das Speichermedium nach Anspruch 17, wobei das Konfigurationsereignis ein Ereignis umfasst, das mit einem Einschalten oder Zurücksetzen des intelligenten E/A-Peripheriegeräts verbunden ist.
Das Speichermedium nach Anspruch 17, wobei das Konfigurationsereignis mit einer Instanz einer Anwendungsbetriebsumgebung des Hosts verbunden ist.