DE102022126171A1

DE102022126171A1 - Durchsetzung der einhaltung von referenz- betriebszuständen für cloud-computing-basierte compute-appliances

Info

Publication number: DE102022126171A1
Application number: DE102022126171.9A
Authority: DE
Inventors: Dwight D. Riley; Robert W. Noller
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2022-04-28
Filing date: 2022-10-10
Publication date: 2023-11-02
Also published as: CN117009282A; US20230353477A1; US11949583B2

Abstract

Ein Prozess umfasst das Erzwingen der Einhaltung eines Referenzbetriebszustands für eine Recheneinheit. Die Compute Appliance ist Teil eines Cloud-basierten Computersystems. Das Erzwingen der Einhaltung des Referenzbetriebszustands beinhaltet, dass die Compute Appliance als Reaktion auf einen Start der Compute Appliance einen tatsächlichen Rechenzustand der Compute Appliance bestimmt. Der tatsächliche Rechenzustand umfasst eine tatsächliche physische Topologieplatzierung einer Hardwarekomponente der Compute Appliance. Das Bestimmen des tatsächlichen Rechenzustands beinhaltet das Bestimmen der physikalischen Topologieplatzierung der Hardwarekomponente. Das Erzwingen der Übereinstimmung mit dem Referenzbetriebszustand beinhaltet die Überprüfung, ob der tatsächliche Rechenzustand mit dem Referenzrechenzustand übereinstimmt. Die Überprüfung umfasst den Vergleich des tatsächlichen Rechenzustands mit dem Referenzrechenzustand. Das Erzwingen der Einhaltung des Referenzbetriebszustands umfasst als Reaktion auf ein Ergebnis der Überprüfung die Steuerung, ob die Recheneinheit Teil des Cloud-basierten Rechensystems ist.

Description

HINTERGRUND
Eine Cloud-Architektur kann eine Computersystemdomäne mit mehreren physischen Serverknoten (z. B. Blade-Servern oder rackmontierten Servern) oder „Compute Appliances“ umfassen. Die Compute Appliances definieren eine physische Infrastrukturdomäne. 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 Compute Appliances 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 Steuerung der Dienste zu gewährleisten.
KURZBESCHREIBUNG DER ZEICHNUNGEN

ist ein Blockdiagramm einer Compute Appliance, die gemäß einer Beispielimplementierung die Übereinstimmung der Compute Appliance mit einem Referenz-Compute-Status erzwingt.
2 ist eine Illustration eines Prozesses, der von einer Rechenzustandsüberprüfungsmaschine der Rechenanwendung von 1 gemäß einer Beispielimplementierung durchgeführt wird.
ist eine Illustration eines Prozesses, der von einem Domänenmanager durchgeführt wird, um die Übereinstimmung einer Netzwerkinfrastruktur, die mit einer Compute Appliance verbunden ist, mit einem Referenz-Netzwerkinfrastrukturzustand gemäß einer Beispielimplementierung zu erzwingen.
ist ein Flussdiagramm, das den Startvorgang einer Compute Appliance gemäß einer Beispielimplementierung zeigt.
5A ist ein Flussdiagramm eines Prozesses, der von einer Rechenzustandsüberprüfungsmaschine einer Rechenanwendung durchgeführt wird, um einen tatsächlichen Rechenzustand der Rechenanwendung gemäß einer Beispielimplementierung zu bestimmen.
ist ein Flussdiagramm eines Prozesses, der von einer Engine zur Überprüfung des Rechenzustands einer Compute Appliance durchgeführt wird, um die Übereinstimmung der Compute Appliance mit einem Referenz-Rechenzustand gemäß einer Beispielimplementierung zu überprüfen.
6A ist ein Flussdiagramm eines Prozesses, der von der Maschine zur Überprüfung des Netzinfrastrukturzustands durchgeführt wird, um einen tatsächlichen Netzinfrastrukturzustand gemäß einer Beispielimplementierung zu bestimmen.
6B ist ein Flussdiagramm eines Prozesses, der von der Netzwerkinfrastruktur-Zustandsüberprüfungs-Engine ausgeführt wird, um zu kontrollieren, ob eine Compute Appliance einem Cloud-basierten Computersystem beitritt, basierend darauf, ob eine tatsächliche Netzwerkinfrastruktur, die mit der Compute Appliance verbunden ist, mit einem Referenz-Netzwerkinfrastrukturzustand übereinstimmt, gemäß einer Beispielimplementierung.
ist ein Flussdiagramm einer Interrupt-Service-Routine, die auf ein Hot-Plug/Unplug-Ereignis in der Compute Appliance gemäß einer Beispielimplementierung reagiert.
ist ein Flussdiagramm, das einen Prozess zur Erzwingung der Übereinstimmung einer Compute Appliance mit einem Referenzbetriebszustand gemäß einer Beispielimplementierung darstellt.
ist ein Blockdiagramm eines Systems zur Erzwingung der Übereinstimmung eines Knotens mit einem Referenzbetriebszustand gemäß einer Beispielimplementierung.
10 ist eine Illustration eines maschinenlesbaren nicht-übertragbaren Speichermediums, das Anweisungen speichert, die, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, die Übereinstimmung einer Netzwerkinfrastruktur mit einem Referenz-Netzwerkinfrastrukturzustand gemäß einer Beispielimplementierung durchzusetzen.

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 PC-basierte Architektur oder eine „Legacy-Architektur“), die sich durch ein „host-zentriertes“ Steuerungsmodell auszeichnen kann. Bei einem solchen Steuerungsmodell sind die Serversteuerungen im Host des Servers verankert. Wie hier verwendet, bezieht sich der Begriff „Host“ auf den Teil des Servers, der die zentralen Verarbeitungseinheiten (CPUs) und den Hauptspeicher des Systems enthält. Dementsprechend stellt der Host eine Funktion oder einen Dienst durch eine oder mehrere Haupt-CPUs bereit, die maschinenlesbare Anweisungen ausführen. Wenn die Serversteuerungen im Host des Servers verwurzelt sind, bedeutet dies, dass die Serversteuerungen in den Haupt-CPUs des Servers verwurzelt sind.
Bei dem Server kann es sich um einen Rechenknoten eines Cloud-basierten Rechnersystems oder um ein „Cloud-basiertes Rechnersystem“ handeln. Die Softwareschicht des Server-Hosts 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 an der Spitze der hierarchischen Verwaltungsstruktur kann ein Cloud-Infrastrukturmanager stehen, der die Softwarestapel vereinheitlicht. 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 des Servers, das/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-Offloading-Dienst, der PCle-Direkt-EtA (z. B. CPU Input-Output Memory Management Unit (IOMMU) Mapping von physischen und/oder virtuellen PCle-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-of-the-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 Grafikverarbeitungseinheiten (GPUs) usw.), was beispielsweise die vertraglichen Verpflichtungen des Cloud-Betreibers gegenüber dem Mieter beeinträchtigen könnte. Mit dieser Anordnung kann der ToR-Switch zur Bereitstellung von Netzwerkdiensten wie einem Netzwerkschutzdienst (z. B. einem Firewall-Dienst) oder einem Instanz-Overlay-Dienst (z. B. einem VxLAN-Dienst (Virtual Extensible Local Area Network)) verwendet werden.
Das intelligente E/A-Peripheriegerät kann eine von vielen verschiedenen physischen Formen annehmen und eine Vielzahl von Backend-E/A-Diensten bereitstellen. 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. einem PCIe-Link oder -Bus) bereitstellen, auf den der Host zugreifen kann. Als spezifisches Beispiel können die Komponenten eines auf einer PCIe-Karte basierenden intelligenten E/A-Peripheriegeräts auf einem Leiterplattensubstrat montiert werden, das einen PCIe-Kartenrandanschluss mit einem Formfaktor aufweist, der es ermöglicht, das intelligente E/A-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 PCle-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 Server mit intelligenten E/A-Peripheriegeräten führt zu einem dualen Verwaltungssteuerungssystem innerhalb des Servers, das die Steuerung des intelligenten E/A-Geräts von der Steuerung der Host-CPU trennt, indem eine hardware-abstrahierte Schnittstelle zum Host hinzugefügt wird. Die hardware-abstrahierte Schnittstelle kann dem Host als standardmäßiges lokales E/A-Peripheriegerät (d. h. ein nicht intelligentes E/A-Peripheriegerät) 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 PCle-Funktionen) in Maschinenabstraktionen abzubilden (z. B. Bare-Metal- oder virtuelle Maschinenabstraktionen). 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 Server, der über eine Cloud-native Infrastrukturarchitektur mit von der Hardware abstrahierten intelligenten E/A-Peripheriegeräten verfügt, von einem nicht segmentierten Server mit einer Legacy-Architektur, die auf einer Host-zentrierten Steuerung basiert. Dieser Unterschied schafft eine Architekturlücke in den aktuellen Serverdesigns, sowohl für die Pre-Boot- als auch für die 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. Beispielsweise kann ein Steckverbinder (z. B. ein PCle-Steckverbinder) der Legacy-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 sie einen zusätzlichen Service-Prozessor, einen Plattform-Controller und eine Root-Steuerung im Plattform-Controller enthält, so dass der Plattform-Controller sowohl den BMC als auch die intelligente E/A-Peripherie ü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 segmentierten Servers, der als „Compute Appliance“ bezeichnet wird, mit einer hardwareisolierten Vertrauensdomäne (hier als „Cloud-Operator-Domäne“ bezeichnet) einer intelligenten E/A-Peripherie der Compute Appliance 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 Maschinenabstraktionen (z. B. Bare-Metal-OS-Umgebungen und Hypervisor-VM-Umgebungen) auswirken, die von der intelligenten E/A-Peripherie unterstützt werden. In Übereinstimmung mit Beispielimplementierungen umfasst die Compute Appliance Host-Überwachungsdienste, um die Maschinenabstraktionen zu überwachen.
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) kann die Compute Appliance einen Host-Überwachungsdienst bereitstellen, 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 einen Hypervisor bereitstellen, und die Compute Appliance kann entsprechende Host-Überwachungsdienste für die zugehörigen Maschinenabstraktionen bereitstellen. Die Host-Überwachungsdienste bieten die Möglichkeit, die Architekturlücke auszugleichen, die durch die Undurchsichtigkeit der Architektur des intelligenten E/A-Peripheriegeräts entstanden ist.
Eine Compute Appliance kann aufgrund der unbefugten Änderung des „Compute State“ der Compute Appliance Sicherheitslücken aufweisen. In diesem Zusammenhang bezieht sich der „Rechenstatus“ einer Compute Appliance im Allgemeinen auf die Konfiguration der Compute Appliance. Eine Compute Appliance kann speziell für einen bestimmten Zweck konfiguriert sein. Diese Zwecke (und die entsprechenden Konfigurationen) können sehr unterschiedlich sein. So kann eine bestimmte Compute Appliance beispielsweise so konfiguriert sein, dass sie die Beleuchtung eines Stadions steuert, Datenbankverwaltungsdienste für ein Unternehmen bereitstellt, Transaktionen für Finanzinstitute verwaltet und so weiter. Für eine bestimmte Compute Appliance kann eine spezifische Konfiguration oder ein „Referenz-Rechenzustand“ definiert werden, je nach dem besonderen Verwendungszweck oder der Anwendung der Compute Appliance. Der Referenz-Compute-Status kann eine Reihe verschiedener Konfigurationsattribute der Compute-Appliance definieren, wie z. B. ein bestimmtes Inventar an Hardwarekomponenten, physische Topologiepositionen (z. B. bestimmte Steckplatznummern, bestimmte Käfignummern, Verbindungen mit bestimmten Anschlüssen oder Kabelbäumen) für die jeweiligen spezifischen Hardwarekomponenten. Der Referenz-Rechenstatus kann bestimmte Firmware-Versionen definieren, und der Referenz-Rechenstatus kann bestimmte Firmware-Signaturen definieren. Der Referenz-Rechenstatus kann Beziehungen zwischen bestimmten Hardwarekomponenten festlegen (z. B. dass eine bestimmte Gruppe von DIMMs eine bestimmte gleiche Größe oder eine bestimmte Mindestgröße haben muss oder dass eine bestimmte Gruppe von Speicherlaufwerken gleich groß sein oder bestimmte Leistungskriterien erfüllen muss). Der Referenz-Rechenstatus kann angeben, ob eine bestimmte Komponente im laufenden Betrieb angeschlossen oder entfernt werden kann (Hot-Plugging). Der Referenz-Rechenstatus kann Kriterien für den Austausch von Speicherlaufwerken und/oder Speichermodulen im laufenden Betrieb festlegen. Eine Hot-Plug-fähige Komponente kann eine physische oder eine virtuelle Komponente sein. So kann beispielsweise ein PCIe-Adapter (z. B. ein Smart-I/O-Peripheriegerät) als Teil der PCIe-Direkt-I/O-Fähigkeit des Adapters für virtuelle Maschinen unabhängige virtuelle und physische Hot-Plug-Funktionen bieten.
Beispiele für nicht autorisierte Änderungen am Referenz-Rechenstatus einer Compute Appliance sind der Einbau einer autorisierten PCIe-Karte in die Compute Appliance oder der Einbau eines ansonsten autorisierten Dual-Inline-Speichermoduls (DIMM) in einen nicht autorisierten Speichersteckplatz für das DIMM. Ein weiteres Beispiel für eine nicht autorisierte Änderung ist, dass ein bestimmtes DIMM oder ein NVMe-Speicherlaufwerk (Non-Volatile Memory Express) für eine Compute Appliance nicht zugelassen ist, das DIMM oder NVMe-Speicherlaufwerk aber dennoch im laufenden Betrieb in die Compute Appliance eingesteckt werden kann. Ein weiteres Beispiel: Eine bestimmte hot-plug-fähige Komponente (z. B. ein NVMe-Speichergerät oder ein DIMM) kann für die Verwendung in bestimmten Hot-Plug-Anschlüssen der Compute Appliance zugelassen sein, aber die Komponente kann im laufenden Betrieb in einen bestimmten Hot-Plug-Anschluss gesteckt werden, der für die hot-plug-fähige Komponente nicht zugelassen ist.
Eine Möglichkeit, um sicherzustellen, dass ein bestimmter Referenz-Rechenstatus für eine Compute Appliance durchgesetzt wird, besteht darin, einen Techniker vor Ort mit der Einrichtung der Compute Appliance zu beauftragen. Darüber hinaus kann die Compute Appliance in einer sicheren Umgebung platziert werden, um sicherzustellen, dass der Compute-Status der Compute Appliance danach nicht von Unbefugten geändert wird. Diese Sicherheitsmaßnahmen können jedoch für ein modernes Cloud-basiertes Computersystem, das eine beträchtliche Anzahl (z. B. Tausende, Zehntausende oder noch mehr) von Compute Appliances (z. B. Blade-Server) umfasst, die sich in mehreren Rechenzentren befinden können, eher unpraktisch sein.
Gemäß den hier beschriebenen Beispielimplementierungen erzwingt ein Pre-Boot-Überwachungsdienst einer Compute Appliance die Übereinstimmung der Compute Appliance mit einem Referenz-Compute-Status für die Compute Appliance. Genauer gesagt prüft der integrierte Pre-Boot-Überwachungsdienst in Übereinstimmung mit Beispielimplementierungen als Reaktion auf einen Start (z. B. einen Bootvorgang beim Einschalten oder einen durch einen Reset ausgelösten Bootvorgang) der Compute Appliance, ob die Compute Appliance mit einem für die Compute Appliance spezifizierten Referenz-Rechenstatus übereinstimmt. Wenn der Pre-Boot-Überwachungsdienst die Konformität verifiziert, erlaubt der Pre-Boot-Überwachungsdienst der Compute Appliance, mit der Einrichtung von Tenant-Laufzeitumgebungen (z. B. Maschinenabstraktionen) fortzufahren, sich der Flotte anderer Compute Appliances eines Cloud-basierten Computersystems anzuschließen und die Tenant-Laufzeitumgebungen bereitzustellen. Wenn jedoch die Überprüfung durch den Pre-Boot-Überwachungsdienst fehlschlägt, verhindert der Pre-Boot-Überwachungsdienst gemäß Beispielimplementierungen, dass die Compute Appliance irgendwelche Tenant-Laufzeitumgebungen einrichtet oder bereitstellt, und der Pre-Boot-Dienst veranlasst die Compute Appliance, sich sofort von dem Cloud-basierten Computersystem zu isolieren oder zu isolieren.
In Übereinstimmung mit einigen Implementierungen enthält die Compute Appliance einen oder mehrere Laufzeitüberwachungsdienste, die die Übereinstimmung der Compute Appliance mit dem Referenz-Compute-Status in der Laufzeitumgebung der Compute Appliance durchsetzen. Der/die Laufzeitüberwachungsdienst(e) schützt/schützen die Compute Appliance vor Konfigurationsänderungen, die beispielsweise durch ein Hot-Plug-Ereignis (bei dem eine Komponente im laufenden Betrieb in einen Hot-Plug-Anschluss der Compute Appliance eingesteckt wird) oder ein Hot-Unplug-Ereignis (bei dem eine Komponente im laufenden Betrieb von einem Hot-Plug-Anschluss abgezogen wird) auftreten können. Ein Laufzeitüberwachungsdienst kann beispielsweise als Reaktion auf ein Hot-Plug-Ereignis oder ein Hot-Unplug-Ereignis feststellen, ob das Ereignis durch den Referenz-Rechenstatus erlaubt ist. Wenn der Laufzeitüberwachungsdienst feststellt, dass das Ereignis nicht zulässig ist, kann der Laufzeitüberwachungsdienst in Übereinstimmung mit Beispielimplementierungen die Compute Appliance veranlassen, eine oder mehrere geeignete Abhilfemaßnahmen zu ergreifen. Als Beispiele können diese Abhilfemaßnahmen eine oder mehrere der folgenden Maßnahmen umfassen: die Compute Appliance beendet Operationen mit dem Cloud-basierten Computersystem; die Compute Appliance schaltet sich ab; die Compute Appliance wechselt in die Pre-Boot-Umgebung; die Compute Appliance isoliert sich selbst von dem Cloud-basierten Computersystem oder stellt sich selbst unter Quarantäne; die Compute Appliance löscht kryptografisch den Inhalt von persistenten Speichergeräten und Speichergeräten, die mit der Compute Appliance verbunden sind; die Compute Appliance sendet Warnmeldungen an einen Domänenmanager und an einen Systemadministrator; und so weiter.
Nicht autorisierte Änderungen an der Netzwerkinfrastruktur eines Cloud-basierten Computersystems können das Computersystem Sicherheitslücken aussetzen. Beispiele für nicht autorisierte Änderungen am Zustand der Netzwerkinfrastruktur sind der Anschluss eines autorisierten Netzwerk-Switches an eine Compute Appliance oder die Verlegung eines ansonsten autorisierten Netzwerk-Switches an einen nicht autorisierten physischen Ort (z. B. in ein anderes Stockwerk eines Gebäudes als das für den Netzwerk-Switch zugelassene Stockwerk). Ein anderes Beispiel: Eine Compute Appliance kann mit einem autorisierten Netzwerk-Switch verbunden sein, aber die Compute Appliance kann sich an einem anderen als dem autorisierten Standort befinden. Ein weiteres Beispiel: Das Cloud-basierte Computersystem kann eine Skalierungsrichtlinie für das Hoch- oder Runterskalieren von Compute Appliances des Systems haben. In der Richtlinie kann beispielsweise festgelegt sein, dass die Skalierung in Einheiten von jeweils zehn Compute Appliances erfolgen soll. Es kann versucht (und vermutlich vermutet) werden, eine einzelne Compute Appliance zu einem Cloud-basierten Computersystem hinzuzufügen, ohne die erforderlichen Skalierungskriterien zu erfüllen.
Sicherheitsschwachstellen aufgrund unbefugter Änderungen des Rechenzustands oder des Zustands der Netzinfrastruktur können dazu führen, dass die strengen Spezifikationen für den Rechenzustand oder den Zustand der Netzinfrastrukturnicht eingehalten werden, dass Sicherheitsprobleme für die Software des Cloud-Mieters entstehen und dass die Integrität des Cloud-basierten Computersystems gefährdet wird.
In Übereinstimmung mit den hier beschriebenen Beispielimplementierungen enthält der Referenz-Rechenstatus einen Satz komplexer Identifikationen (IDs), die beispielsweise die Attribute bestimmter Hardwarekomponenten und die physischen topologischen Positionen dieser Hardwarekomponenten in der Compute Appliance definieren können.
Die komplexe ID besteht gemäß den Beispielimplementierungen aus zwei Komponenten: einer Anker-ID und einer gemeinsamen ID. Bei der Anker-ID handelt es sich gemäß Beispielimplementierungen um eine eindeutige Kennung für eine bestimmte Komponente (z. B. eine PCle-Karte), wie z. B. eine MAC-Adresse (Media Access Control) der Komponente, eine verschlüsselte MAC-Adresse der Komponente und so weiter. In Übereinstimmung mit einigen Implementierungen kann die Anker-ID eine bestimmte Kategorie oder Klasse von Hardwarekomponenten definieren, ohne eine eindeutige Hardwarekomponente zu identifizieren. Beispielsweise kann die Anker-ID in Übereinstimmung mit Beispielimplementierungen eine minimale Speichergröße für die Hardwarekomponente identifizieren. Ein weiteres Beispiel ist, dass die Anker-ID einen bestimmten Hersteller der Hardwarekomponente identifizieren kann. Als weiteres Beispiel kann die Anker-ID eine minimale Prozessorspezifikation für die Hardwarekomponente identifizieren. Als weiteres Beispiel kann die Anker-ID eine Modellnummer für die Hardwarekomponente oder einen Bereich von Modellnummern für die Hardwarekomponente identifizieren. Als weiteres Beispiel kann die Anker-ID ein bestimmtes Attribut der Hardwarekomponente identifizieren. Ein weiteres Beispiel: Der Anker kann einen Seriennummernbereich für die Hardwarekomponente identifizieren. Im Allgemeinen kann die Anker-ID eine beliebige Anzahl anderer Attribute identifizieren, die der Hardwarekomponente indirekt oder direkt zugeordnet werden können, wie z. B. die maximale Verlustleistung der Hardwarekomponente, ein Bereich elektromagnetischer Interferenzen für die Hardwarekomponente usw.
Die gemeinsame ID identifiziert in Übereinstimmung mit Beispielimplementierungen eine bestimmte physische Topologieplatzierung, die mit der Hardwarekomponente verbunden ist. Eine physische Topologieplatzierung im Zusammenhang mit einer PCIe-Karte kann beispielsweise bedeuten, dass sich die PCle-Karte in Steckplatz 2 des PCle-Eingangs-/Ausgangskäfigs B der Compute Appliance befinden sollte. Da die komplexen IDs die Komponenten und die Platzierung der Komponenten in der physischen Topologie eindeutig identifizieren, können die komplexen IDs verwendet werden, um den Rechenstatus einer Compute Appliance im tatsächlichen Einsatz zu bestätigen.
Der Referenz-Compute-Status kann Daten enthalten, die Konfigurationskriterien für eine Compute-Appliance darstellen, die nicht die komplexen IDs bestimmter Hardwarekomponenten repräsentieren. So kann der Referenz-Rechenstatus beispielsweise eine Richtlinie für die Compute Appliance zur Reaktion auf Hot-Plug-Ereignisse und/oder Hot-Unplug-Ereignisse festlegen. Als weiteres Beispiel kann der Referenz-Rechenstatus eine Richtlinie für den Failover auf redundante Geräte, eine Richtlinie für die Erstellung von Audit-Protokollen, eine Richtlinie für die Behandlung von Programmausführungsabstürzen, eine Mindest-Firmware-Version, eine spezifische Firmware-Version, eine Zugriffskontrollrichtlinie für die Aktualisierung der Firmware usw. angeben.
Der Referenz-Compute-Status für eine bestimmte Compute-Appliance kann durch ein digitales Zertifikat definiert werden, das von einem Administrator mit den entsprechenden Berechtigungsnachweisen unterzeichnet wird. Das Zertifikat kann beispielsweise Daten enthalten, die eine Identität (z. B. eine Seriennummer der Compute Appliance, einen Verweis auf einen Bestätigungsschlüssel eines vertrauenswürdigen Plattformmoduls (TPM) usw.) der Compute Appliance darstellen, und das Zertifikat kann Daten enthalten, die komplexe IDs und andere Konfigurationskriterien für die Compute Appliance darstellen. Das Zertifikat, das den Referenz-Compute-Status definiert, unterscheidet sich von einem Plattformzertifikat, das beispielsweise ein Inventar für einen Server auflistet, ohne anzugeben, wie diese Komponenten tatsächlich physisch in dem Server eingesetzt werden (z. B. ohne Angabe ihrer jeweiligen physischen Topologien) und ohne Angabe anderer Konfigurationskriterien für den Server.
Das Erzwingen der Einhaltung eines Referenz-Rechenzustands durch eine Compute Appliance, so dass die Compute Appliance Laufzeitdienste für den Cloud-Mieter bereitstellt, wenn die Compute Appliance, wie hier beschrieben, nicht konform ist, schützt den Cloud-Mieterbereich (d. h. den Mietbereich der Compute Appliance) und im Allgemeinen das Cloud-basierte Computersystem vor Sicherheitsverletzungen. Dieser Schutz verhindert gemäß den Beispielimplementierungen, dass ein Sicherheitseinbruch stattfindet, im Gegensatz zu einer Sicherheitserkennungsmaßnahme, die erkennt, wenn ein Sicherheitseinbruch (und potenzieller Schaden) bereits stattgefunden hat, so dass Abhilfemaßnahmen ergriffen werden können, um künftige Schäden zu mindern und/oder den Sicherheitseinbruch zu beheben.
In Übereinstimmung mit Beispielimplementierungen kann ein Referenz-Netzwerkinfrastrukturzustand für die Netzwerkinfrastruktur definiert werden, die mit einer bestimmten Compute Appliance verbunden ist. Der Referenzzustand der Netzwerkinfrastruktur definiert eine erwartete Konfiguration für die Netzwerkinfrastruktur, die mit der Compute Appliance verbunden ist. In Übereinstimmung mit Beispielimplementierungen enthält der Referenz-Netzwerkinfrastrukturstatus eine erwartete Adresse (z. B. eine Internetprotokoll (IP)-Adresse) eines Netzwerkzugangspunkts (z. B. eines ToR-Switches, eines Gateways usw.) für die Compute Appliance. Der Netzwerkzugangspunkt kann, muss aber nicht die erste Netzwerkkomponente sein, mit der sich die Compute Appliance verbindet. Beispielsweise kann ein Netzwerkadministrator die Sichtbarkeit einer oder mehrerer Netzwerkkomponenten, die sich am nächsten an der Compute Appliance befinden, für die Compute Appliance einschränken, damit diese Netzwerkkomponenten ausgetauscht werden können, ohne den Betrieb der Compute Appliance zu beeinträchtigen. Eine solche Einschränkung kann sich wiederum darauf auswirken, welche bestimmte Netzwerkkomponente von der Compute Appliance als Netzwerkzugangspunkt angesehen wird. Da der Standort des Netzzugangspunkts Teil des Status der Referenznetzinfrastruktur ist, kann die Compute Appliance an eine bestimmte physische Netzverbindung gebunden sein.
Der Status der Referenznetzinfrastruktur kann auch Standortinformationen enthalten, die mit der Compute Appliance verknüpft sind. Die Standortinformationen können in Übereinstimmung mit Beispielimplementierungen eines oder mehrere der folgenden Standortattribute für den Netzwerkzugangspunkt und/oder die Compute Appliance enthalten: GNSS-Koordinaten (Global Navigation Satellite System), eine Gebäudeadresse (z. B. eine Gebäudenummer der physischen Adresse des Gebäudes), eine Etagennummer (z. B. die 5. Etage) des Gebäudes, in dem sich die Compute Appliance und/oder der Netzwerkzugangspunkt befindet, eine Kennung des Rechenzentrums, eine Höhe (z. B. eine Höhe relativ zum Meeresspiegel) und so weiter. Aufgrund der Standortinformationen kann die Compute Appliance und/oder der Netzwerk-Switch nicht an einen Standort verschoben werden, der von den Standortinformationen des Referenz-Netzwerkinfrastrukturzustands abweicht, selbst wenn sich die physische Netzwerkverbindung gegenüber dem durch den Referenz-Netzwerkinfrastrukturzustand repräsentierten Zustand nicht ändert. Daher kann eine Compute Appliance beispielsweise nicht physisch an einen weniger sicheren, nicht genehmigten Standort verlegt werden und trotzdem mit einem Referenznetzinfrastrukturzustand konform sein, der einen anderen Standort angibt.
Der Status der Referenznetzwerkinfrastruktur kann in Übereinstimmung mit Beispielimplementierungen Daten enthalten, die andere Konfigurationskriterien für die Netzwerkinfrastruktur darstellen, die mit der Compute Appliance verbunden ist. Gemäß Beispielimplementierungen kann der Referenz-Netzwerkinfrastrukturstatus beispielsweise eine Skalierungsrichtlinie für die Netzwerk-Compute-Appliance festlegen. Als weiteres Beispiel kann der Status der Referenznetzwerkinfrastruktur festlegen, dass eine bestimmte Gruppe von Compute Appliances einzeln hinzugefügt werden kann oder dass die bestimmte Gruppe auf einmal zum Cloud-Computing-basierten System hinzugefügt werden kann. Als weiteres Beispiel kann die Referenznetzinfrastruktur Kriterien für eine SDN-Verbindung einer Compute Appliance festlegen. So kann die Referenznetzinfrastruktur beispielsweise eine Mindestbandbreite für eine SDN-Verbindung einer Compute Appliance vorgeben. Solche Mindestbandbreitenkriterien können z. B. zum Schutz vor einem Denial-of-Service-Angriff verwendet werden. Als weiteres Beispiel kann der Status der Referenznetzwerkinfrastruktur Kriterien für eine SDS-Verbindung für die Compute Appliance festlegen. Befindet sich die Compute Appliance beispielsweise in einem Land mit strengen Datenschutzbestimmungen, kann der Referenznetzwerkinfrastrukturzustand festlegen, dass die Datenspeicherung für die Compute Appliance nicht außerhalb dieses Landes erfolgen darf. Als weiteres Beispiel kann der Status der Referenznetzinfrastruktur eine bestimmte SDC-Maschineninstanzsignatur für die Compute Appliance vorgeben.
Bezug nehmend auf 1, als spezifischeres Beispiel, kann ein Cloud-basiertes Computersystem 100, das mit einem bestimmten Cloud-Betreiber verbunden ist, Multi-Tenant-Cloud-Dienste für mehrere Kunden oder Tenants bereitstellen. Bei den Cloud-Diensten kann es sich um eine Reihe 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 über Cloud-Clients (z. B. Laptops, Desktop-Computer, Smartphones, Tablet-Computer, tragbare Computer usw.) auf Compute Appliances 110 (z. B. Rechenknoten) des Cloud-Computersystems 100 zugreifen. Wie in 1 dargestellt, können die Compute Appliances 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 Compute Appliances 110 durch logische Verbindungen 194 (z. B. SDN-, SDC- und SDS-Verbindungen) miteinander verbunden sein, die der physischen Netzwerkstruktur 184 überlagert sind.
In 1 sind Details einer bestimmten Recheneinheit 110-1 des Cloud-basierten Computersystems 100 gemäß Beispielimplementierungen dargestellt. Wie weiter unten beschrieben, verfügt die Compute Appliance 110-1 über integrierte Funktionen, um die Übereinstimmung der Compute Appliance 110-1 mit einem Referenz-Rechenstatus für die Compute Appliance 110-1 zu erzwingen.
Die Compute Appliance 110-1 befindet sich gemäß Beispielimplementierungen zu einem bestimmten Zeitpunkt entweder in einer Pre-Boot-Umgebung oder in einer Laufzeitumgebung. Obwohl in 1 sowohl Pre-Boot-Komponenten als auch Runtime-Komponenten der Compute Appliance 110-1 dargestellt sind, versteht es sich von selbst, dass Pre-Boot-Komponenten nicht in der Runtime-Umgebung vorhanden sind und Runtime-Komponenten nicht in der Pre-Boot-Umgebung vorhanden sind. So wird beispielsweise ein Pre-Boot-Überwachungsdienst 156 der Compute Appliance 110-1 in der Pre-Boot-Umgebung und nicht in der Laufzeitumgebung ausgeführt. Ein weiteres Beispiel ist, dass Tenant-Laufzeitumgebungen 120 und Laufzeitüberwachungsdienste 150 in der Laufzeitumgebung und nicht in der Pre-Boot-Umgebung vorhanden sind.
Gemäß Beispielimplementierungen wird die Compute Appliance 110-1 in der Pre-Boot-Umgebung hochgefahren (z. B. als Reaktion auf ein Einschalten, ein Zurücksetzen, ein über ein Remote-Management-Netzwerk gesteuertes Einschalten, ein Zurücksetzen über ein Remote-Management-Netzwerk usw.). In diesem Zusammenhang bezieht sich die „Pre-Boot-Umgebung“ der Compute Appliance 110-1 auf die Umgebung der Compute Appliance 110-1, bevor die Compute Appliance 110-1 die Tenant-Laufzeitumgebungen) 120 für den/die Cloud-Mieter bereitstellt. Der Pre-Boot-Überwachungsdienst 156 arbeitet in der Pre-Boot-Umgebung. Eine CPU 116 der Compute Appliance 110-1 kann BIOS 165- oder UEFI 169-Befehle ausführen, um zumindest einige Funktionen des Pre-Boot-Überwachungsdienstes 156 bereitzustellen. Diese Funktionen können beinhalten, dass die CPU 116 mit einem oder mehreren intelligenten E/A-Peripheriegeräten 180 der Compute Appliance 110-1 kommuniziert und mit einem BMC 123 der Compute Appliance 110-1 kommuniziert. In Übereinstimmung mit einigen Implementierungen können ein oder mehrere intelligente E/A-Peripheriegeräte 180 in entsprechenden Steckplatzanschlüssen 181 (z. B. PCIe-Anschlüsse) installiert werden.
Der Pre-Boot-Überwachungsdienst 156 kann in Übereinstimmung mit Beispielimplementierungen die Sichtbarkeit der Ressourcen der Compute Appliance 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, weil er die Qualität des Dienstes kontrollieren möchte (da die Freigabe der Ressourcen die Leistung der Compute Appliance 110-1 beeinträchtigen kann) und so weiter. In Übereinstimmung mit einigen Implementierungen kann der Pre-Boot-Überwachungsdienst 156 die Sichtbarkeit bestimmter physischer Funktionen und/oder virtueller Funktionen eines intelligenten E/A-Peripheriegeräts 180 entsprechend steuern, so dass die Funktion(en) dem Domänenmanager 190 nicht angezeigt werden. 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 kann der Pre-Boot-Überwachungsdienst 156 ein Inventar der logischen und physischen Infrastrukturressourcen der Compute Appliance 110-1 erstellen, die Sichtbarkeit der Ressourcen der Compute Appliance 110-1 steuern und die Tenant-Laufzeitumgebungen 120 einrichten. Der Pre-Boot-Überwachungsdienst 156 sucht in Übereinstimmung mit Beispielimplementierungen nach dem Domänenmanager 190 (z. B. sucht der Pre-Boot-Überwachungsdienst 156 über ein verschlüsseltes Overlay-Netzwerk) und bindet die Compute Appliance 110-1 zur Steuerung an den Domänenmanager 190. Als Teil der Durchführung des Pre-Boot-Überwachungsdienstes 156 kann die CPU 116 beispielsweise einen PCIe-Konfigurationsraum für ein oder mehrere intelligente E/A-Peripheriegeräte 180 einrichten.
Gemäß Beispielimplementierungen verfügt der Pre-Boot-Überwachungsdienst 156 über eine Komponente, eine Compute State Verification Engine 157, die die Übereinstimmung der Compute Appliance 110-1 mit einem Referenz-Compute State 138 für die Compute Appliances 110-1 durchsetzt. In Übereinstimmung mit einigen Implementierungen kann die Engine zur Überprüfung des Rechenstatus 157 von einer oder mehreren CPUs 116 bereitgestellt werden, die Host-Betriebssystembefehle 163 ausführen.
Compute Appliances 110 des Cloud-basierten Computersystems 100 können gemäß Beispielimplementierungen eine ähnliche oder dieselbe Architektur wie die Compute Appliance 110-1 haben oder nicht. Darüber hinaus können gemäß Beispielimplementierungen eine oder mehrere dieser anderen Compute Appliances 110 über Funktionen verfügen, mit denen die Einhaltung der jeweiligen Referenzbetriebszustände durch die Compute Appliances 110 erzwungen werden kann, oder auch nicht.
Das Cloud-basierte Computersystem 100 kann einen oder mehrere Domänenmanager 190 umfassen. Der Domänenmanager 190 kann mit der physischen Netzwerkstruktur 184 und den logischen Verbindungen 194 verbunden sein. Abhängig von der jeweiligen Implementierung kann sich der Domänenmanager 190 auf der Compute Appliance 110-1, auf einer anderen Compute Appliance 110, auf einem dedizierten Verwaltungsknoten, über mehrere Knoten des Cloud-Computersystems 100 verteilt und so weiter befinden. Im Allgemeinen enthält der Domänenmanager 190 physische Hardwareressourcen und logische Softwareressourcen für die Verwaltung einer Gruppe von Compute Appliances 110, die als „Domäne“ bezeichnet wird. Das cloudbasierte Computersystem 100 kann eine oder mehrere Domänen haben. In Übereinstimmung mit einigen Implementierungen kann der Domänenmanager 190 mit einer Datenbank verbunden sein, die Daten speichert, die sich auf die Compute Appliances 110 beziehen, wie z. B. Daten, die Compute-Appliance-Konfigurationen, Telemetrieprotokolle, Audit-Protokolle usw. darstellen. Der Domänenmanager 190 kann eine Orchestrierungs-Engine enthalten, die den Betrieb von Blattmanagern des Cloud-Computing-Systems 100 verwaltet, um die Lebenszyklen zu steuern und die Blattressourcen (z. B. die hier beschriebenen intelligenten E/A-Peripheriegeräte 180) des Systems 100 zu konfigurieren. In Übereinstimmung mit einigen Implementierungen kann der Domänenmanager 190 absichtsbasierte Befehle (z. B. Redfish-Befehle) mit einem oder mehreren Vendor 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. Je nach Implementierung können die Hersteller-Root-Manager und die Blattressourcen-Manager auf einem oder mehreren Verwaltungsknoten angeordnet sein, auf einer oder mehreren Compute Appliances 110 verteilt sein und so weiter.
In Übereinstimmung mit Beispielimplementierungen umfasst der Domänenmanager 190 eine Engine zur Überprüfung des Netzwerkinfrastrukturzustands 193. Die Netzwerkinfrastruktur-Zustandsüberprüfungs-Engine 193 erzwingt in Übereinstimmung mit Beispielimplementierungen die Übereinstimmung der Netzwerkinfrastruktur des Cloud-basierten Computersystems mit einem erwarteten oder Referenz-Netzwerkinfrastrukturzustand. Diese Durchsetzung kann in Übereinstimmung mit Beispielimplementierungen die Durchsetzung der Konformität einer Netzwerkinfrastruktur, die mit einer bestimmten Recheneinheit 110 verbunden ist, mit einem Referenz-Netzwerkinfrastrukturzustand für diese Netzwerkinfrastruktur umfassen.
Bei der Recheneinheit 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.
Die Compute Appliance 110-1 kann gemäß weiteren Beispielimplementierungen eine disaggregierte oder verteilte Architektur aufweisen. Auf diese Weise sind die Komponenten der Compute Appliance 110-1 bei diesen Implementierungen nicht auf einer einzigen Computerplattform untergebracht, sondern die Komponenten der Compute Appliance 110-1 können über mehrere Computerplattformen verteilt sein. Außerdem können die Komponenten der Compute Appliance 110-1 über mehrere geografische Standorte verteilt sein (z. B. über mehrere Rechenzentren mit unterschiedlichen geografischen Standorten).
In Übereinstimmung mit Beispielimplementierungen kann die Compute Appliance 110-1 eine Architektur mit Cloud-Segmenten aufweisen, bei der intelligente E/A-Peripheriegeräte 180 der Compute Appliance 110-1 verschiedene logische Verbindungssegmente unabhängig vom Host der Compute Appliance 110-1 steuern können. Die Compute Appliance 110-1 kann eine oder mehrere Tenant-Laufzeitumgebungen 120 bereitstellen, die sich innerhalb einer Cloud-Tenant-Domäne 111 befinden. Bei den Tenant-Laufzeitumgebungen 120 kann es sich beispielsweise um Maschinenabstraktionen handeln, die für einen oder mehrere Cloud-Tenants bereitgestellt werden. Als spezifischere Beispiele können die Tenant-Laufzeitumgebungen 120 eine oder mehrere Bare-Metal-Abstraktionen des Betriebssystems (OS), eine oder mehrere Abstraktionen virtueller Maschinen usw. umfassen.
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 verfügt (z. B. CPU(s), Systemspeicher, Netzwerkschnittstelle(n) und Speicher). 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 der Compute Appliance 110-1. Der Lebenszyklus (z. B. die Bereitstellung und Beendigung) der VM kann von einem Virtual Machine Monitor (VMM) oder Hypervisor 167 der Compute Appliance 110-1 verwaltet werden. Alternativ kann eine VM auch von einer kernelbasierten VM oder „KVM“ verwaltet werden.
In Übereinstimmung mit Beispielimplementierungen kann jede Tenant-Laufzeitumgebung 120 ein Betriebssystem, einen Hypervisor oder eine KVM-Schnittstelle 121 (als „Betriebssystem-/Hypervisor-/KVM-Schnittstelle 121“ bezeichnet) haben, und gemeinsam können die Betriebssystem-/Hypervisor-/KVM-Schnittstellen 121 eine Tenant-Workload-Isolationsbarriere 197 zwischen der Cloud-Tenant-Domäne 111 und einer Cloud-Operator-Domäne 113 der Recheneinheit 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 der 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, werden durch die Isolationsbarriere 197 für die Arbeitslast des Mandanten und eine Isolationsbarriere 198 für die Arbeitslast des Mandanten, die durch die Host-Schnittstellen der intelligenten E/A-Peripheriegeräte 180 gebildet wird, von den Arbeitslasten des Mandanten isoliert. In Übereinstimmung mit Beispielimplementierungen bilden die intelligenten E/A-Peripheriegeräte 180 eine Netzwerkisolationsbarriere 199 der Compute Appliance 110-1. Zu den physischen Hardwarekomponenten, die mit den Überwachungsdiensten verbunden sind, können beispielsweise eine oder mehrere zentrale Verarbeitungseinheiten (CPUs) 116 und Speicherkomponenten gehören, die einen Systemspeicher 118 bilden.
Gemäß Beispielimplementierungen sind der Systemspeicher 118 und andere hier erörterte Speicher nichttransitorische 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. bestehen können. Der Systemspeicher kann sowohl aus flüchtigen als auch aus nichtflüchtigen Speichervorrichtungen bestehen.
Die CPU(s) 116 kann/können maschinenausführbare Befehle 117 ausführen, um verschiedene vertrauenswürdige Überwachungssoftwarekomponenten der Compute Appliance 110-1 zu bilden, wie z. B. ein Basic Input/Output System (BIOS) 165, ein Unified Extensible Firmware Interface (UEFI) 169, ein Host-Betriebssystem 163 und einen Hypervisor 167. 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. So kann die Cloud-Betreiberdomäne 113 beispielsweise einen Pre-Boot-Überwachungsdienst 156 und einen oder mehrere LaufzeitÜberwachungsdienste 150 umfassen, die während der Laufzeit der Recheneinheit 110-1 arbeiten, wie in Beispielimplementierungen beschrieben. Im Allgemeinen können die Überwachungsdienste 150 und 156, wie hier beschrieben, einer Vielzahl von Zwecken für die Compute Appliance 110-1 dienen, die die Architekturlücke zwischen dem hostzentrierten Kontrollmodell und dem Cloud-nativen Kontrollmodell schließen.
Gemäß einigen Implementierungen können die Laufzeit-Hostüberwachungsdienste 150 beispielsweise einen oder mehrere der folgenden Dienste umfassen: einen Hypervisor-VM-Laufzeitüberwachungsdienst 150 (z. B. einen Dienst als privilegierte virtuelle Maschine im Hypervisor) und einen Betriebssystem-Bare-Metal-Laufzeitüberwachungsdienst 150 (z. B. einen vom UEFI 169 und/oder BIOS 165 bereitgestellten Dienst). Der Pre-Boot-Überwachungsdienst 156 kann durch das UEFI 169 und/oder das BIOS 165 bereitgestellt werden. Der Pre-Boot-Überwachungsdienst 156 kann beispielsweise von einem eingebetteten Betriebssystem, wie einem intelligenten Bereitstellungsbetriebssystem, bereitgestellt werden.
In Übereinstimmung mit Beispielimplementierungen bestimmt die Rechenstatus-Verifizierungsmaschine 157 als Reaktion auf einen Start der Rechenanwendung 110-1 einen aktuellen Rechenstatus für die Rechenanwendung 110-1. In Übereinstimmung mit einigen Implementierungen stellt die Rechenzustandsüberprüfungs-Engine 157 eine Sperre bereit, die verhindert, dass die Recheneinheit 110-1 die Mieter-Laufzeitumgebungen 120 bereitstellt, bis die Rechenzustandsüberprüfungs-Engine 157 verifiziert, dass die Recheneinheit 110-1 mit dem Referenz-Rechenzustand übereinstimmt. In Übereinstimmung mit Beispielimplementierungen können Daten, die den Referenzrechenstatus 138 für die Compute Appliance 110-1 darstellen, in einem sicheren Speicher 134 der Compute Appliance 110-1 gespeichert werden. Bei der in 1 dargestellten Beispielimplementierung kann es sich bei dem sicheren Speicher 134 um einen Speicher handeln, dessen Zugriff von einer Sicherheitsgateway-Komponente, wie z. B. einem BMC 123, gesteuert wird. In Übereinstimmung mit weiteren Implementierungen können auch andere sichere Speicher verwendet werden.
In der Laufzeitumgebung der Compute Appliance 110-1 kann ein Laufzeitüberwachungsdienst 150 der Compute Appliance 110-1 die Übereinstimmung der Compute Appliance 110-1 mit dem Referenz-Compute-Zustand als Reaktion auf ein Hot-Plug/Unplug-Ereignis erzwingen, wie hier weiter beschrieben. In Übereinstimmung mit einigen Implementierungen kann der Laufzeitüberwachungsdienst 150 durch eine CPU 116 gebildet werden, die Anweisungen des Betriebssystems 163 ausführt. Das Erzwingen der Übereinstimmung der Compute Appliance 110-1 mit dem Referenz-Compute-Zustand kann beinhalten, dass der Laufzeitüberwachungsdienst 150 eine oder mehrere Maßnahmen ergreift, wenn eine Nichteinhaltung festgestellt wird, wie beispielsweise Maßnahmen, die das Beenden von Operationen der Compute Appliance 110-1 mit dem Cloud-basierten Computersystem 100, das Abschalten der Compute Appliance 110-1 Rückführung der Compute Appliance 110-1 in die Pre-Boot-Umgebung; Isolierung oder Quarantäne der Compute Appliance 110-1 vom Cloud-basierten Computersystem 110-1; Beendigung der Bereitstellung der Tenant-Laufzeitumgebungen 120; kryptografisches Löschen von persistenten Speichergeräten und Speichergeräten auf und in Verbindung mit der Compute Appliance 110-1; und so weiter. In diesem Zusammenhang bezieht sich das „kryptografische Löschen“ eines Geräts auf das Entfernen des Zugriffs auf einen kryptografischen Schlüssel, der die Wiederherstellung des entsprechenden Klartextinhalts ermöglichen würde. Beispielsweise kann ein selbstverschlüsselndes Laufwerk (z. B. ein NVMe-Laufwerk) intern einen Medienzugriffsschlüssel speichern und verwenden, um die im Laufwerk gespeicherten Daten zu verschlüsseln und zu entschlüsseln, und das kryptografische Löschen des selbstverschlüsselnden Laufwerks kann beispielsweise das Entfernen oder Löschen des Medienzugriffsschlüssels des Laufwerks umfassen.
Gemäß einigen Implementierungen werden Ereignisbenachrichtigungen (z. B. Störungsbenachrichtigungen, Fehlerbenachrichtigungen, Hot-Plug-Ereignisse, sicherheitsbezogene Ereignisbenachrichtigungen usw.) für die Compute Appliance 110-1 an einen Management-Controller der Compute Appliance 110-1 weitergeleitet. In den hier beschriebenen Beispielimplementierungen ist der Verwaltungscontroller das BMC 123. In Übereinstimmung mit weiteren Implementierungen kann der Management-Controller jedoch auch eine andere Komponente sein, wie z. B. ein Chassis-Management-Controller, ein Plattform-Controller, der Domänenmanager 190 usw.
Im Allgemeinen ist ein „BMC“, wie hier verwendet, ein spezialisierter Dienstprozessor, der den physischen Zustand eines Servers, Knotens oder einer anderen Hardware-Einheit mit Hilfe von Sensoren überwacht und mit einem Managementsystem über ein Managementnetzwerk kommuniziert. In Übereinstimmung mit Beispielimplementierungen arbeitet der BMC unter der Kontrolle eines Überwachungsdienstes (z. B. Überwachungsdienst 150 oder 156) oder Domänenmanagers (z. B. Domänenmanager 190), der als BMC-Eigentümer dient. 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 usw. 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 maschinenlesbare Anweisungen 125 (die in einem Speicher 126 der BMC 123 gespeichert sind) ausführen, um die hier beschriebenen Aktionen der BMC 123 durchzuführen. In Übereinstimmung mit Beispielimplementierungen können diese Aktionen den Empfang und die Verwaltung von Host-Benachrichtigungen umfassen. Darüber hinaus kann die BMC 123 in Übereinstimmung mit einigen Implementierungen den Zugriff auf den sicheren Speicher 134 steuern. Bei dem sicheren Speicher 134 kann es sich um einen nichtflüchtigen Speicher handeln, und in Übereinstimmung mit Beispielimplementierungen kann der sichere Speicher 134 Daten speichern, die Audit-Protokolle 136 und einen Referenz-Rechenstatus 138 darstellen.
Die Audit-Protokolle 136 können zur Aufzeichnung von Ereignissen mit der Compute Appliance 110-1 verwendet werden. Gemäß Beispielimplementierungen ist das Audit-Protokoll 136 ein Journal oder eine Zusammenfassung mit Daten, die Sicherheits-/Steuerungsaktualisierungen für den Knoteninfrastruktur-Referenzsatz 138 und den Netzwerkinfrastruktur-Referenzsatz 142 beschreiben. Die Audit-Protokolle 136 können als Nachweis des Betriebszustands der Compute Appliance 110-1 verwendet werden, indem die vollständigen aggregierten Audit-Protokollsätze analysiert/verfolgt werden. Gemäß einigen Implementierungen können die Datensätze in den Audit-Protokollen 136 mit einem Zeitstempel versehen sein. In Übereinstimmung mit einigen Implementierungen können die Datensätze in den Audit-Protokollen 136 mit einem von mehreren Werten von einem oder mehreren Betriebszeitmessern 135 (oder „Hobbs-Metern“) versehen oder markiert werden. Beispielsweise kann die BMC 123 in Übereinstimmung mit einigen Implementierungen einen Betriebszeitzähler 135 unterhalten, um die gesamte Betriebszeit der Compute Appliance 110-1 seit der Inbetriebnahme der Compute Appliance 110-1 zu erfassen, und einen weiteren Kilometerzähler 135, um die Gesamtzahl der Stromzyklen der Compute Appliance 110-1 zu erfassen. In Übereinstimmung mit Beispielimplementierungen kann die BMC 123 die Prüfprotokolle 136 führen.
In Übereinstimmung mit einigen Implementierungen kann der Referenz-Rechenstatus 138 eine Aggregationskomponente der Compute Appliance 110-1 zum Sammeln von Netzwerkinfrastruktur-Zustandsinformationen bezeichnen (z. B. Netzwerkinfrastruktur-Referenzzustandsinformationen, die für die Compute Appliance 110-1 spezifisch sind, wie die IP-Adresse des Netzwerkzugangspunkts, Standortinformationen für die Compute Appliance 110-1, SDN-Verbindungsattribute, SDS-Verbindungsattribute usw.) und diese Informationen an den Domänenmanager 190 melden.
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 das Rechengerät 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 einigen Implementierungen kann die BMC 123 die Prüfprotokolle 136 als Teil ihrer Sicherheitsebene verwalten. Gemäß Beispielimplementierungen unterliegt die BMC 123 der Kontrolle eines Überwachungsdienstes (z. B. des Überwachungsdienstes 150 oder 156) oder des Domänenmanagers 190, mit der einzigen Ausnahme, dass die Einhaltung des Referenzrechenstatus 138 nicht überprüft wird. Auf diese Weise kann, wenn die Compute State Verification Engine 157 den Referenz-Compute-Status 138 nicht verifizieren kann (d. h., die Compute Appliance 110-1 entspricht nicht dem Referenz-Compute-Status 138), gemäß Beispielimplementierungen, nachdem die Compute Appliance 110-1 vom Cloud-basierten Computersystem 100 isoliert oder unter Quarantäne gestellt wurde, eine Serveradministratorrolle mit einem Dienstpasswort für die Zwecke der Verwaltung der Compute Appliance 110-1 über die BMC 123 aktiviert werden.
In Übereinstimmung mit Beispielimplementierungen kann das Rechengerät 110-1 einen oder mehrere Sensoren haben, die Daten liefern, die Attribute des Rechengeräts 110-1 darstellen. Beispielsweise kann die Recheneinheit 110-1 in Übereinstimmung mit einigen Implementierungen ein oder mehrere GNSS-Funkgeräte 102 enthalten, die Daten liefern, die einen physischen Standort der Recheneinheit 110-1 oder den physischen Standort einer bestimmten Komponente der Recheneinheit 110-1 darstellen. Als weiteres Beispiel kann das Rechengerät 110-1 in Übereinstimmung mit einigen Implementierungen einen Höhenmesser enthalten, der Daten liefert, die eine Höhe des Rechengeräts 110-1 oder eine Höhe einer bestimmten Komponente des Rechengeräts 110-1 darstellen. Als weiteres Beispiel kann das Rechengerät 110-1 in Übereinstimmung mit einigen Implementierungen einen Manipulationssensor enthalten, der Daten liefert, die anzeigen, ob eine Komponente oder ein Teil des Rechengeräts 110-1 manipuliert wurde. Obwohl in 1 nicht dargestellt, kann die physische Netzwerkstruktur 184 in ähnlicher Weise einen oder mehrere Sensoren umfassen, die Daten liefern, die Attribute (z. B. eine Höhe, GNSS-Koordinaten usw.) eines oder mehrerer Netzwerkgeräte (z. B. Netzwerk-Switches, Gateways, ToR-Switches usw.) der physischen Netzwerkstruktur 184 darstellen.
2 veranschaulicht einen Prozess 200 zur Verifizierung eines Rechenzustands der Recheneinheit 110-1 gemäß einer Beispielimplementierung. Bezug nehmend auf 2 in Verbindung mit 1 umfasst der Prozess 200 die Rechenzustandsverifizierungsmaschine 157, die einen aktuellen Rechenzustand 201 der Recheneinheit 110-1 bestimmt. In Übereinstimmung mit Beispielimplementierungen umfasst der tatsächliche Rechenzustand 201 einen Satz komplexer IDs 210. Jede komplexe ID 210 kann in Übereinstimmung mit Beispielimplementierungen eine Anker-ID 214 und eine gemeinsame ID 212 enthalten. Der tatsächliche Rechenzustand 201 kann zusätzliche Konfigurationsinformationen 215 für die Compute Appliance 110-1 enthalten, wie die Bestimmung einer Aggregationskomponente der Compute Appliance 110-1 zum Sammeln von Daten, die einen für die Compute Appliance 110-1 spezifischen Netzwerkinfrastrukturzustand darstellen, und zum Senden dieser Daten an den Domänenmanager 190; eine oder mehrere Hot-Plug/Unplug-Richtlinien der Compute Appliance 110-1; Richtlinien für elastische Subsysteme (z. B, RAID-Subsysteme) der Compute Appliance 110-1; eine Bestimmung einer Komponente zur Übermittlung der Prüfprotokolle 136 an den Domänenmanager 190; eine kryptografische Löschungsrichtlinie für persistenten Speicher und/oder Speichergeräte; eine Richtlinie zur Behandlung von Programmausführungsabstürzen; eine Mindest-Firmwareversion; eine spezifische Firmwareversion, eine Zugriffskontrollliste, die die Aktualisierung bestimmter Anmeldeinformationen zur Aktualisierung der Firmware autorisiert; und so weiter.
In Übereinstimmung mit Beispielimplementierungen identifiziert die Anker-ID 214 eine entsprechende Komponente der Compute Appliance 110-1. Die Anker-ID 214 kann beispielsweise eines oder mehrere der folgenden Attribute der Komponente enthalten: eine Seriennummer, eine Modellnummer, eine MAC-Adresse (Media Access Control), einen eindeutigen Bezeichner usw. Darüber hinaus kann die Anker-ID 214 gemäß Beispielimplementierungen aus einer Verkettung der vorgenannten Elemente gebildet werden, und gemäß einigen Implementierungen kann diese Verkettung mit einem privaten Teil (oder „privaten Schlüssel“) eines asymmetrischen Schlüssels verschlüsselt werden, so dass der entsprechende öffentliche Teil (oder „öffentliche Schlüssel“) zur Entschlüsselung der Anker-ID 214 in Klartextform verwendet werden kann. Die Anker-ID 214 kann auch eine bestimmte Kategorie oder Klasse von Hardwarekomponenten repräsentieren, ohne eine eindeutige Hardwarekomponente zu identifizieren. Beispielsweise kann die Anker-ID 214 in Übereinstimmung mit Beispielimplementierungen eine minimale Speichergröße für die Hardwarekomponente, einen bestimmten Hersteller der Hardwarekomponente, eine minimale Prozessorspezifikation für die Hardwarekomponente, eine Modellnummer für die Hardwarekomponente, einen Bereich von Modellnummern für die Hardwarekomponente, ein bestimmtes Attribut der Hardwarekomponente, einen Seriennummernbereich für die Hardwarekomponente, eine maximale Verlustleistung für die Hardwarekomponente, einen Bereich für elektromagnetische Interferenzen für die Hardwarekomponente und so weiter identifizieren.
Die gemeinsame ID 212 stellt gemäß Beispielimplementierungen ein physisches topologisches oder räumliches Attribut der Komponente dar. In Übereinstimmung mit Beispielimplementierungen kann das physische topologische Attribut einem Herstellungsprozess-ID-Standort entsprechen (z. B. einem Motherboard-Siebdrucketikett). Als spezifischeres Beispiel zeigt 2 verschiedene Hardwarekomponenten 207 des Rechengeräts 110-1 gemäß Beispielimplementierungen. Zumindest einige der Hardwarekomponenten 207 können sich auf einer Hauptplatine 241 der Recheneinheit 110-1 befinden oder in Bezug auf diese montiert sein. Obwohl die Hauptplatine 241 in 2 als Beispiel dargestellt ist, kann die Compute Appliance 110-1 gemäß Beispielimplementierungen auch andere Leiterplattensubstrate oder Leiterplatten aufweisen, wie Mezzanine-Karten, eine oder zusätzliche Hauptplatinen, Riser-Karten usw., und Hardwarekomponenten, die bestimmten komplexen IDs 210 entsprechen, können auf einer oder mehreren dieser Leiterplatten angeordnet sein.
Bei dem in 2 dargestellten Implementierungsbeispiel werden die NVMe-Geräte 256 in entsprechenden Schächten 251 installiert, die auf der Hauptplatine 241 angebracht sind. Die Schächte 251 können geordnet oder nummeriert sein, so dass ein bestimmtes NVMe-Gerät 256 in Schacht Nummer eins installiert werden kann, ein anderes NVMe-Gerät 256 kann in Schacht Nummer vier installiert werden usw. Es wird darauf hingewiesen, dass einige der Schächte 251 leer sein können, d. h. der Schacht 251 kann kein NVMe-Gerät 256 installiert haben. Die entsprechende komplexe ID 210 für ein NVMe-Gerät 256 umfasst gemäß Beispielimplementierungen eine Anker-ID 214 (z. B. eine verschlüsselte Seriennummer für das NVMe-Gerät 256) und eine gemeinsame ID 212 (z. B. eine Kennung für den bestimmten Schacht 251, in dem das NVMe-Gerät 256 installiert ist). Daher identifiziert die komplexe 10210 für eine bestimmte Komponente der Compute Appliance 110-1 gemäß Beispielimplementierungen die Komponente eindeutig und identifiziert auch den physischen topologischen Standort der Komponente in der Compute Appliance 110-1. Ein NVMe-Gerät 256, das in einem bestimmten Schacht 251 installiert ist, hat eine andere entsprechende gemeinsame ID 212 (und dementsprechend eine andere komplexe ID 210) als die gemeinsame ID 212 für dasselbe NVMe-Gerät 256, wenn es in einem anderen Schacht 251 installiert ist.
Die komplexen IDs 210 können in Übereinstimmung mit Beispielimplementierungen vielen verschiedenen Arten von Komponenten der Compute Appliance 110-1 und ihren entsprechenden physischen topologischen Positionen entsprechen. Zum Beispiel kann der tatsächliche Knoteninfrastruktursatz 201 komplexe IDs 210 für PCIe-Geräte 279 enthalten. Eine bestimmte komplexe ID 210 kann beispielsweise ein entsprechendes PCIe-Gerät 279 sowie einen PCIe-E/A-Käfig 278 und einen PCle-Steckplatz 277, in dem das PCIe-Gerät 279 installiert ist, eindeutig identifizieren.
Ein weiteres Beispiel: Ein anderer Satz komplexer IDs 210 kann DIMMs 263 darstellen. Auf diese Weise kann eine bestimmte komplexe ID 210 eine Anker-ID 214 enthalten, die ein bestimmtes DIMM 263 eindeutig identifiziert, und die entsprechende gemeinsame ID 212 kann eine Bank 260 und einen bestimmten Steckplatz 261 innerhalb der bestimmten Bank 260 identifizieren, in dem das DIMM 263 installiert ist.
Ein weiteres Beispiel: Ein bestimmter Satz komplexer IDs 210 kann mit Serial Attached Small Computer System Interface (SCSI)- oder „SAS“-Geräten 254 verbunden sein. Für diesen Satz komplexer IDs 210 kann die Anker-ID 214 einer bestimmten komplexen ID 210 ein bestimmtes SAS-Gerät 254 eindeutig identifizieren, und die entsprechende gemeinsame ID 212 kann die Nummer eines Schachtes 255 identifizieren, in dem das SAS-Gerät 254 installiert ist.
Ein weiteres Beispiel: Eine bestimmte komplexe ID 210 kann einem Smart Array 268 entsprechen. Auf diese Weise kann die komplexe ID 210 eine Anker-ID 214 enthalten, die das Smart Array 268 eindeutig identifiziert. Die entsprechende gemeinsame ID 212 kann den jeweiligen Käfig 274 identifizieren, in dem das Smart Array 268 installiert ist, sowie eine bestimmte Nummer eines Steckplatzes 270 innerhalb des Käfigs 274.
In Übereinstimmung mit einigen Implementierungen kann eine bestimmte komplexe ID 210 einem Netzwerk-Controller-Seitenband-Interface (NC-SI) Controller 285 entsprechen, und die gemeinsame ID 212 kann den bestimmten Steckplatz 287 repräsentieren, in dem der NC-SI Controller 285 installiert ist.
Gemäß Beispielimplementierungen können eine oder mehrere komplexe IDs 210 Komponenten der Compute Appliance 110-1 entsprechen, die nicht in einem bestimmten Steckplatzanschluss installiert sind. Beispielsweise können gemäß einigen Implementierungen eine oder mehrere komplexe IDs 210 Universal-Serial-Bus-Anschlüssen (USB) 288 entsprechen. Darüber hinaus können gemäß einigen Implementierungen eine oder mehrere komplexe IDs 210 High-Definition Multimedia Interface (HDMI)-Anschlüssen 289, einem oder mehreren Video Graphics Adapter (VGA)-Anschlüssen 290 usw. entsprechen.
Eine oder mehrere komplexe IDs 210 können den Stromversorgungen 292 der Compute Appliance 110-1 entsprechen. Auf diese Weise kann jedes Netzteil 292 mit einem bestimmten Kabelbaumstecker eines geordneten Satzes von Kabelbaumsteckern verbunden sein, und die gemeinsame ID 212 für ein bestimmtes Netzteil 292 kann die bestimmte Kabelbaumnummer für das Netzteil 292 identifizieren. Als weiteres Beispiel können in Übereinstimmung mit einigen Implementierungen eine oder mehrere komplexe IDs 210 den Lüftern 284 der Compute Appliance 110-1 entsprechen. Auf diese Weise können die Lüfter 284 der Compute Appliance 110-1 mit einem anderen Kabelbaum eines Satzes geordneter Kabelbäume verbunden sein. Die gemeinsame ID 212 für einen bestimmten Lüfter 284 steht für die spezifische Kabelbaumnummer, an die der Lüfter 284 angeschlossen ist.
In Übereinstimmung mit weiteren Beispielimplementierungen kann die Compute Appliance 110-1 verschiedene und/oder unterschiedliche Komponenten haben, die hier beschrieben sind, sowie entsprechende komplexe IDs 210 für diese Komponenten.
Wie in 2 dargestellt, umfasst der Prozess 200 zum Überprüfen des Rechenknotenzustands der Rechenanwendung 110-1 in Übereinstimmung mit Beispielimplementierungen die Bestimmung (Entscheidungsblock 224) durch die Rechenzustandsüberprüfungsmaschine 157, ob der tatsächliche Rechenzustand 201 mit dem Referenzrechenzustand 138 übereinstimmt. In Übereinstimmung mit Beispielimplementierungen kann diese Bestimmung beinhalten, dass festgestellt wird, ob jede komplexe ID 220 des Knoteninfrastruktur-Referenzsatzes 138 eine übereinstimmende komplexe ID 210 des tatsächlichen Rechenzustands 201 aufweist. Darüber hinaus kann die Entscheidung 224, ob der tatsächliche Rechenzustand 201 mit dem Referenzrechenzustand 138 übereinstimmt, gemäß Beispielimplementierungen die Feststellung beinhalten, ob es zusätzliche komplexe IDs 210 des tatsächlichen Knoteninfrastruktursatzes 200 gibt, die keine entsprechenden komplexen IDs 220 im Knoteninfrastrukturreferenzsatz 138 haben. Die Entscheidung 224 kann auch beinhalten, dass festgestellt wird, ob die Konfigurationsinformationen 215 des aktuellen Rechenzustands 201 mit den Konfigurationsinformationen 221 des Referenz-Rechenzustands 138 übereinstimmen. In Übereinstimmung mit Beispielimplementierungen können die komplexen IDs und andere Konfigurationselemente eine bestimmte Reihenfolge haben, in der diese Elemente in den Zuständen 201 und 138 erscheinen sollen (z. B. werden DIMMs in der Reihenfolge vor PCIe-Geräten und NVMe-Geräten aufgeführt usw.).
Die Feststellung, ob der tatsächliche Rechenzustand 201 mit dem Referenz-Rechenzustand 138 übereinstimmt, kann die Bestimmung eines Hash-Wertes für den Referenz-Rechenzustand 138 und eines entsprechenden Hash-Wertes für den tatsächlichen Rechenzustand 201 beinhalten. Wenn die Hash-Werte gleich sind, ist in Übereinstimmung mit den Beispielimplementierungen eine Übereinstimmung aufgetreten. Wenn die Hash-Werte unterschiedlich sind, wird davon ausgegangen, dass der tatsächliche Rechenzustand 201 nicht mit dem Referenz-Rechenzustand 138 übereinstimmt. In Übereinstimmung mit weiteren Implementierungen können auch andere Methoden verwendet werden, um festzustellen, ob der tatsächliche Berechnungszustand 201 mit dem Referenzberechnungszustand 138 übereinstimmt.
Wenn der tatsächliche Berechnungszustand 201 mit dem Referenzberechnungszustand 138 übereinstimmt, ist die Überprüfung erfolgreich, wie in der Referenznummer 224 dargestellt. Stimmt der tatsächliche Rechenzustand 201 dagegen nicht mit dem Referenzrechenzustand 138 überein, schlägt die Verifizierung fehl, wie mit der Referenznummer 239 dargestellt.
zeigt einen Prozess 300, der von der Netzwerkinfrastruktur-Zustandsüberprüfungs-Engine 193 des Domänenmanagers 190 verwendet wird, um eine Netzwerkinfrastruktur zu überprüfen, die mit der Compute Appliance 110-1 verbunden ist, in Übereinstimmung mit Beispielimplementierungen. Der Domänenmanager 190 kann einen oder mehrere Hardwareprozessoren 380 (z. B. CPUs) und einen Speicher 384 umfassen, der Anweisungen 388 speichern kann, die, wenn sie vom Domänenmanager 190 ausgeführt werden, den Domänenmanager 190 veranlassen, die hier beschriebenen Aktionen durchzuführen. Darüber hinaus bewirkt die Ausführung der Anweisungen 388 durch den/die Prozessor(en) 380 gemäß Beispielimplementierungen, dass der/die Prozessor(en) 380 die Netzwerkinfrastruktur-Zustandsüberprüfungsmaschine 193 bildet/bilden.
Wie aus 3 in Verbindung mit 1 hervorgeht, kann die Compute Appliance 110-1 gemäß einigen Implementierungen eine von mehreren Compute Appliances sein (z. B. ein Satz von Compute Appliances 100, der Compute Appliances 110-1 und Compute Appliances 110-2, wie in 3 dargestellt, sowie weitere Compute Appliances 110 umfasst), die sich an einem bestimmten physischen Standort 305 (z. B. einem Rechenzentrum) befinden. Eine bestimmte Domäne 304 kann Compute Appliances 110 von einem oder mehreren physischen Standorten 305 umfassen, wie in dargestellt. Die Compute Appliances 110 können im Allgemeinen physisch mit der Netzwerkstruktur 320 verbunden sein. Diese Verbindungen können logische Verbindungen 328 sowie physische und Netzwerkverbindungen 324 umfassen. Wie in dargestellt, werden die logischen Verbindungen 328 und die physischen Netzwerkverbindungen 324 über das intelligente E/A-Peripheriegerät 180 jeder Compute Appliance 110 hergestellt.
In Übereinstimmung mit Beispielimplementierungen kann ein Referenz-Netzwerkinfrastrukturstatus 302 für die Netzwerkinfrastruktur, die mit der Compute Appliance 110-1 verbunden ist, eine Zugangspunkt-IP-Adresse 356 enthalten. Auf diese Weise kann die Zugangspunkt-IP-Adresse 356 gemäß Beispielimplementierungen die IP-Adresse der ersten Netzwerkkomponente sein, die für die Compute Appliance 110-1 sichtbar ist. In Übereinstimmung mit Beispielimplementierungen kann der Netzwerkinfrastruktur-Referenzsatz 142 außerdem Daten enthalten, die Standortinformationen 357 darstellen, die mit der Compute Appliance 110-1 verbunden sind. Die Standortinformationen 357 können, abhängig von der jeweiligen Implementierung, einen Standort der Compute Appliance 110-1, einen Standort des Netzwerkzugangspunkts oder Standorte der Compute Appliance 110-1 und des Netzwerkzugangspunkts darstellen. Die Standortinformationen 357 können beispielsweise ein bestimmtes Stockwerk (z. B. Stockwerk Nummer zwei), eine Büro- oder Zimmernummer, GNSS-Koordinaten, eine Höhe, eine Kennung oder einen Standort des Rechenzentrums, eine Racknummer usw. darstellen.
Der Status der Referenznetzwerkinfrastruktur 302 kann gemäß Beispielimplementierungen weitere Konfigurationsinformationen 358 der mit der Compute Appliance 110-1 verbundenen Netzwerkinfrastruktur enthalten. Beispielsweise können die anderen Konfigurationsinformationen 358 solche Konfigurationsattribute wie eine Skalierungsrichtlinie für die Compute Appliance, Kriterien für eine SDN-Verbindung der Compute Appliance 110-1, Kriterien für eine SDS-Verbindung für die Compute Appliance 110-1, eine Signatur einer SDC-Maschineninstanz für die Compute Appliance 110-1 usw. enthalten.
Gemäß dem Prozess 300 bestimmt die Netzwerkinfrastruktur-Zustandsüberprüfungsmaschine 193 (Entscheidungsblock 360), ob der Referenz-Netzwerkinfrastrukturzustand 302 mit einem tatsächlichen Netzwerkinfrastrukturzustand 349 übereinstimmt. Auf diese Weise kann der tatsächliche Netzwerkinfrastrukturzustand 349 Informationen darstellen, die von der Netzwerkinfrastrukturzustandsüberprüfungsmaschine 193 gesammelt wurden, und solche Informationen wie Daten, die eine tatsächliche IP-Adresse 351 eines Netzwerkzugangspunktgeräts für die Compute Appliance 110-1 darstellen, Daten, die Standortinformationen 353 für die Compute Appliance 110-1 und/oder Standortinformationen für das Netzwerkzugangspunktgerät darstellen, und so weiter enthalten. Darüber hinaus kann der tatsächliche Netzwerkinfrastrukturzustand 349 andere Netzwerkinformationskonfigurationsinformationen 354 enthalten, wie die oben für die anderen Informationen 358 des Referenznetzwerkinfrastrukturzustands 302 diskutierten Kriterien.
Gemäß Beispielimplementierungen kann die Netzinfrastrukturzustandsüberprüfungsmaschine 193 zum Zwecke des Vergleichs des tatsächlichen Netzinfrastrukturzustands 349 mit dem Referenznetzinfrastrukturzustand 302 feststellen, ob die Zugangspunkt-IP-Adresse 351 mit der Zugangspunkt-IP-Adresse 356 übereinstimmt, feststellen, ob die Standortinformationen 353 mit den Standortinformationen 357 übereinstimmen, und feststellen, ob die anderen Netzinfrastrukturinformationen 354 mit den anderen Netzinfrastrukturinformationen 358 übereinstimmen. Eine Übereinstimmung kann z. B. dann nicht gegeben sein, wenn irgendwelche Informationen nicht übereinstimmen, wie z. B. Unterschiede in der IP-Adresse des Zugangspunkts, Unterschiede in den Standortinformationen oder Unterschiede in den anderen Konfigurationsinformationen. Wenn gemäß Entscheidungsblock 360 keine Übereinstimmung auftritt, dann schlägt gemäß Beispielimplementierungen die Überprüfung fehl und der Domänenmanager 190 erlaubt der Compute Appliance 110-1 nicht, dem Cloud-basierten Computersystem 100 beizutreten, wie mit der Referenzzahl 366 dargestellt. Wenn eine Übereinstimmung auftritt, dann besteht die Überprüfung in Übereinstimmung mit Beispielimplementierungen und der Domänenmanager 190 erlaubt dem Rechengerät 110-1, dem Cloud-basierten Computersystem 100 beizutreten, wie mit der Referenznummer 363 dargestellt.
zeigt einen Prozess 400, der von der Engine 157 zur Überprüfung des Rechenzustands der Compute Appliance 110 in Übereinstimmung mit Beispielimplementierungen als Reaktion auf den Start der Compute Appliance 110-1 durchgeführt wird. In Übereinstimmung mit Beispielimplementierungen bestimmt die Rechenstatus-Verifizierungsmaschine 157 (Entscheidungsblock 428), ob der Rechenstatus der Rechenanwendung 110-1 die Überprüfung besteht. Wenn dies nicht der Fall ist, stellt das Rechenstatus-Verifizierungsmodul 157 gemäß Block 407 das Rechengerät 110-1 von dem auf Cloud-Computing basierenden System 100 unter Quarantäne (Block 408) und verhindert, dass das Rechengerät 110-1 zu einer der Mieter-Laufzeitumgebungen 120 wechselt. Darüber hinaus kann die Compute State Verification Engine 157 in Übereinstimmung mit Beispielimplementierungen den Verifikationsfehler protokollieren (Block 408). Auf diese Weise kann die Compute State Verification Engine 157 in Übereinstimmung mit Beispielimplementierungen beispielsweise ein Audit-Protokoll 136 mit einem Eintrag aktualisieren, der den Verifikationsfehler detailliert beschreibt. Darüber hinaus kann die Compute State Verification Engine 157 eine oder mehrere zusätzliche Maßnahmen ergreifen, wie z. B. die Übermittlung (Block 412) einer oder mehrerer Warnmeldungen (z. B. die Übermittlung einer Warnmeldung an einen Systemadministrator für die Compute Appliance 110-1, die Übermittlung einer Warnmeldung an den Domain Manager 190 usw.).
Wenn die Rechenzustandsüberprüfungsmaschine 157 gemäß Entscheidungsblock 428 feststellt, dass das Rechengerät 110-1 dem Referenzrechenzustand 138 entspricht, richtet die Rechenzustandsüberprüfungsmaschine 157 die Mieterlaufzeitumgebung(en) 120 ein (Block 434) und erlaubt dem Rechengerät 110-1, dem Cloud-basierten Computersystem beizutreten, wie in Block 436 dargestellt.
5A zeigt einen Beispielprozess 500, der von der Rechenzustandsüberprüfungsmaschine 157 (1) als Reaktion auf den Start (z. B. das Einschalten oder Zurücksetzen der Compute Appliance 110-1) durchgeführt wird. Unter Bezugnahme auf 5A in Verbindung mit 1 umfasst der Prozess 500 gemäß Beispielimplementierungen die Bestimmung (Block 504) von Anker-Identifikationen von Infrastrukturkomponenten der Compute Appliance 110-1 und die Bestimmung (Block 508) von gemeinsamen Identifikationen von Infrastrukturkomponenten der Compute Appliance 110-1 durch die Compute State Verification Engine 157. Die Compute State Verification Engine 157 kann dann gemäß Block 512 komplexe Identifizierungen auf der Grundlage der Ankeridentifizierungen und der gemeinsamen Identifizierungen bestimmen. Die Engine zur Überprüfung des Rechenzustands 157 kann ferner andere Informationen über den Rechenzustand ermitteln (Block 514), wie hier beschrieben. Die Engine zur Überprüfung des Rechenzustands 157 kann dann Daten generieren (Block 516), die den tatsächlichen Rechenzustand der Rechenanwendung 110-1 darstellen.
5B zeigt einen Beispielprozess 530, der von der Compute State Verification Engine 157 in Übereinstimmung mit Beispielimplementierungen durchgeführt wird, um die Übereinstimmung der Compute Appliance 110-1 mit dem Referenz-Compute State zu überprüfen. Unter Bezugnahme auf 5B in Verbindung mit 1 bestimmt die Compute State Verification Engine 157 in Übereinstimmung mit Beispielimplementierungen (Entscheidungsblock 534), ob ein Referenz-Compute-Infrastrukturzertifikat für die spezifische Compute Appliance 110-1 gültig ist. Bei der Validierung des Zertifikats können je nach der jeweiligen Implementierung mehrere Faktoren oder Kriterien berücksichtigt werden. Zum Beispiel kann die Compute State Verification Engine 157 zunächst eine Signatur des Zertifikats auswerten. Auf diese Weise kann gemäß Beispielimplementierungen ein Administrator, der über die entsprechenden Berechtigungsnachweise für das Rechengerät 110-1 verfügt, einen privaten Teil (oder privaten Schlüssel) eines asymmetrischen kryptografischen Schlüssels, z. B. einen RSA-Schlüssel, besitzen. Der Administrator kann das Zertifikat auf der Grundlage des privaten Schlüssels und des Inhalts des Zertifikats kryptografisch signieren. Der Inhalt des Zertifikats kann z. B. einen Referenz-Rechenstatus für die Recheneinheit 110-1 enthalten. Unter Verwendung des öffentlichen Teils (d. h. des öffentlichen Schlüssels) des RSA-Schlüssels kann die Compute State Verification Engine 157 die Signatur des Zertifikats verifizieren, indem sie einen Hash-Wert für den Inhalt des Zertifikats mit dem öffentlichen Schlüssel bestimmt und den resultierenden Hash-Wert mit der Signatur vergleicht. Wenn diese beiden Hash-Werte gleich sind, wurde die Signatur des Zertifikats gemäß den Beispielimplementierungen validiert.
Die Compute State Verification Engine 157 kann eine oder mehrere zusätzliche Maßnahmen in Betracht ziehen, um das Referenzzertifikat für den Rechenstatus zu validieren, wie es in Beispielimplementierungen vorgesehen ist. Nach der Validierung der Zertifikatsignatur kann die Compute State Verification Engine 157 beispielsweise feststellen, ob der Unterzeichner über die entsprechenden Berechtigungen verfügt, um das Zertifikat auszustellen, ob die Berechtigung des Unterzeichners zur Ausstellung des Zertifikats widerrufen wurde usw. Darüber hinaus kann die Compute State Verification Engine 157 den Inhalt des Zertifikats für die Zwecke der Validierung des Zertifikats überprüfen.
Wenn gemäß Block 538 das Referenzzertifikat für den Rechenstatus nicht gültig ist, protokolliert die Engine 157 zur Überprüfung des Rechenstatus den Fehler bei der Zertifikatsvalidierung und setzt (Block 539) eine Anzeige für die fehlgeschlagene Überprüfung des Rechenstatus, um den Übergang der Compute Appliance 110-1 von der Pre-Boot-Umgebung zur Bereitstellung der Tenant-Laufzeitumgebung(en) 120 zu verhindern. Wenn gemäß Entscheidungsblock 534 das Referenz-Rechenstatus-Zertifikat validiert wird, vergleicht (Block 544) die Rechenstatus-Verifizierungsmaschine 157 den tatsächlichen Rechenstatus mit dem Referenz-Rechenstatus, wie er durch den Inhalt des Zertifikats festgelegt ist. Wenn der tatsächliche Rechenzustand mit dem Referenz-Rechenzustand übereinstimmt, wie in Entscheidungsblock 548 festgestellt, dann protokolliert (Block 540) die Rechenzustands-Verifizierungsmaschine 157 den Rechenzustands-Verifizierungsdurchlauf. Andernfalls, gemäß Entscheidungsblock 548, wenn der Vergleich des tatsächlichen Rechenzustands mit dem Referenzrechenzustand fehlschlägt, dann protokolliert (Block 550) die Rechenzustandsverifizierungsmaschine 157 den Fehler der Rechenzustandsverifizierung und setzt (Block 552) eine Anzeige für die fehlgeschlagene Rechenzustandsverifizierung, um zu verhindern, dass die Rechenanwendung 110-1 von der Pre-Boot-Umgebung in die Tenant-Laufzeitumgebung(en) 120 übergeht.
6A zeigt einen Beispielprozess 600, der von der Netzwerkinfrastruktur-Zustandsüberprüfungsmaschine 193 (1) der Compute Appliance 110-1 gemäß einer Beispielimplementierung durchgeführt wird. Unter Bezugnahme auf 6A in Verbindung mit 1 umfasst der Prozess 600 gemäß Beispielimplementierungen die Bestimmung (Block 604) von IP-Adressen von Netzwerkzugangspunkten für Rechenanwendungen 110 durch die Netzwerkinfrastruktur-Zustandsüberprüfungsmaschine 193 und die Bestimmung (Block 608) von Standortinformationen, die den jeweiligen Rechenanwendungen 110 zugeordnet sind. Gemäß Block 614 kann die Netzwerkinfrastruktur-Zustandsüberprüfungsmaschine 193 in Übereinstimmung mit Beispielimplementierungen andere Netzwerkinfrastruktur-Zustandsinformationen bestimmen, wie z. B. die anderen Netzwerkinfrastrukturinformationen 354 (3) für die Compute Appliances 110. Gemäß Block 616 erzeugt die Netzwerkinfrastruktur-Zustandsüberprüfungsmaschine 193 Daten, die einen tatsächlichen Netzwerkinfrastrukturzustand für die Compute Appliances 110 darstellen.
6B zeigt einen Beispielprozess 650, der von der Netzwerkinfrastruktur-Zustandsüberprüfungs-Engine 193 in Übereinstimmung mit Beispielimplementierungen durchgeführt wird, um einen Zustand einer Netzwerkinfrastruktur, die mit der Compute Appliance 110-1 verbunden ist, zu erzwingen, der mit einem entsprechenden Referenz-Netzwerkinfrastrukturzustand übereinstimmt. In Übereinstimmung mit einigen Implementierungen kann die Netzwerkinfrastruktur-Zustandsüberprüfungsmaschine 193 den Prozess 650 als Teil einer Bestimmung durchführen, ob die Compute Appliance 110-1 dem Cloud-basierten Computersystem 100 beitreten darf. Unter Bezugnahme auf 6B in Verbindung mit 1 empfängt (Block 654) oder greift die Netzwerkinfrastrukturzustands-Verifizierungsmaschine 193 auf Daten zu, die den tatsächlichen Netzwerkinfrastrukturzustand darstellen, und die Netzwerkinfrastrukturzustands-Verifizierungsmaschine 193 vergleicht (Block 662) den tatsächlichen Netzwerkinfrastrukturzustand mit einem Referenznetzwerkinfrastrukturzustand. Wenn die Verifizierungsmaschine 193 für den Netzwerkinfrastrukturzustand auf der Grundlage dieses Vergleichs feststellt (Entscheidungsblock 666), dass der tatsächliche Netzwerkinfrastrukturzustand mit dem Referenznetzwerkinfrastrukturzustand übereinstimmt, dann erlaubt die Verifizierungsmaschine 193 für den Netzwerkinfrastrukturzustand (Block 680) der Recheneinheit 110-1, dem Cloud-basierten Computersystem 100 beizutreten. Andernfalls, wenn die Netzwerkinfrastrukturzustands-Verifizierungsmaschine 193 feststellt (Entscheidungsblock 666), dass der tatsächliche Netzwerkinfrastrukturzustand nicht mit dem Referenznetzwerkinfrastrukturzustand übereinstimmt, dann verhindert die Netzwerkinfrastrukturzustands-Verifizierungsmaschine 193, dass das Rechengerät 110-1 dem Cloud-basierten Computersystem 100 beitritt (Block 670).
Zurück zu 1: Komponenten können potenziell im laufenden Betrieb in Hot-Plug-Anschlüsse der Compute Appliance 110-1 eingesteckt werden, und Komponenten können potenziell im laufenden Betrieb von Hot-Plug-Anschlüssen der Compute Appliance 110-1 abgezogen werden. In diesem Zusammenhang bezieht sich der Begriff „Hot Plugging“ auf die tatsächliche oder simulierte Installation einer Komponente in einem Anschluss der Compute Appliance 110-1, während der Anschluss mit Strom versorgt wird. Dabei kann die „Komponente“ eine tatsächliche Hardwarekomponente oder eine virtuelle Komponente sein. Eine „tatsächliche“ Installation kann z. B. der Installation einer physischen Karte oder eines Adapters in einem physischen Anschluss der Compute Appliance 110-1 entsprechen. Eine „simulierte“ Installation kann z. B. darin bestehen, dass eine Hardwarekomponente (z. B. ein PCle-Adapter) einem Betriebssystem oder Hypervisor anzeigt, dass eine bestimmte Funktion (z. B. eine virtuelle PCIe-Funktion oder eine physische PCIe-Funktion) jetzt verfügbar ist oder aktiviert wurde. „Hot Unplugging“ einer Komponente bezieht sich auf das tatsächliche oder simulierte Entfernen der Komponente aus einem Steckverbinder, während der Steckverbinder mit Strom versorgt wird. Ein „tatsächliches“ Abziehen kann beispielsweise dem Abziehen einer physischen Karte oder eines Adapters von einem physischen Anschluss der Compute Appliance 110-1 entsprechen. Eine „simulierte“ Entfernung kann beispielsweise bedeuten, dass eine Hardwarekomponente (z. B. ein PCle-Adapter) einem Betriebssystem oder Hypervisor mitteilt, dass eine bestimmte Funktion (z. B. eine virtuelle PCIe-Funktion oder eine physische PCIe-Funktion) nicht mehr verfügbar ist oder deaktiviert wurde. Ein Ereignis, das dem Hot-Plugging einer Komponente oder dem Hot-Depugging einer Komponente entspricht, wird hier als „Hot-Plug/Unplug-Ereignis“ bezeichnet. Bei der Komponente kann es sich um eine physische Komponente oder eine virtuelle Komponente handeln.
In Übereinstimmung mit Beispielimplementierungen fängt die BMC 123 ein Hot-Plug/Unplug-Ereignis ab und koordiniert sich mit dem OS-Bare-Metal-Laufzeitüberwachungsdienst 150, um das Ereignis zu behandeln. Genauer gesagt, kann das BMC 123 in Verbindung mit den Komponenten BIOS 165 und Betriebssystem 163 des OS-Bare-Metal-Laufzeitüberwachungsdienstes 156 das Hot-Plug/Unplug-Ereignis für die Compute Appliance 110-1 verarbeiten.
Wenn beispielsweise eine Komponente (z. B. ein USB-Laufwerk) im laufenden Betrieb in einen Anschluss (z. B. einen USB-Anschluss) der Compute Appliance 110-1 eingesteckt wird, erkennt das BMC 123 das Einstecken der Komponente in den Anschluss und alarmiert das BIOS 165. Das BIOS 165 listet die Komponente auf (z. B. weist der Komponente Speicherplatz zu) und informiert das Betriebssystem 163 über das Vorhandensein der Komponente. Das Betriebssystem 163 kann daraufhin die Komponente verwalten. Das Hot-Plug-Ereignis kann mit dem Referenz-Rechenstatus 138 übereinstimmen oder auch nicht. Auf diese Weise kann der Referenz-Rechenzustand 138 eine oder mehrere Bedingungen festlegen. Beispielsweise kann der Referenzrechenzustand 138 festlegen, dass ein bestimmter Hot-Plug-Anschluss Komponenten mit bestimmten Identifikationen, Modellnummern, Seriennummern, Leistungsmerkmalen, vergleichbaren Merkmalen zu anderen installierten Komponenten usw. aufnehmen soll. Ein weiteres Beispiel ist, dass der Referenzrechenzustand 138 festlegen kann, dass ein bestimmter Hot-Plug-Anschluss keine Hot-Plug-Komponenten aufnehmen soll.
Der Laufzeitüberwachungsdienst 150 kann (über seine Betriebssystemkomponente 163) erkennen, wenn eine bestimmte Komponente im laufenden Betrieb abgezogen wird. So kann beispielsweise eine Komponente unerwartet von ihrem Anschluss entfernt werden (d. h. eine „überraschende Entfernung“). In diesem Fall ist das Betriebssystem 163 das erste, das die Trennung erkennt, da das Betriebssystem 163 die Komponente möglicherweise noch verwendet. Je nach Konfiguration der Compute Appliance 110-1 kann die Compute Appliance 110-1 das Hot Unplug-Ereignis aufnehmen oder nicht. Beispielsweise kann die Compute Appliance 110-1 so konfiguriert sein, dass sie von einem DIMM (z. B. einem DIMM, das ausgefallen ist und im laufenden Betrieb ausgesteckt wird) auf ein redundantes DIMM umschaltet. Umgekehrt kann das Hot-Demplugging einer Komponente (z. B. eines DIMM) zum Absturz des Betriebssystems 163 oder der Anwendung führen, die das DIMM verwendet. Das überraschende Entfernen kann mit dem Referenz-Rechenstatus 138 übereinstimmen oder auch nicht.
Ein Hot-Unplug-Ereignis kann vom Betriebssystem 163 erkannt werden oder auch nicht. Beispielsweise kann die Compute Appliance 110-1 mit einem robusten Subsystem (z. B. einem Redundant Array of Inexpensive Disks (RAID)) konfiguriert sein, das redundante physische Komponenten (z. B. Speicherlaufwerke) umfasst, die sich hinter logischen Komponenten (z. B. logischen Einheiten (LUNs)) befinden, so dass bei einem Ausfall einer bestimmten physischen Komponente das Subsystem in einer für das Betriebssystem 163 transparenten Weise auf eine andere physische Komponente umschalten kann. Bei diesem Szenario kann das BMC 123 über das Hot-Unplug-Ereignis benachrichtigt werden. Darüber hinaus kann das Hot-Unplug-Ereignis mit dem Referenzrechenstatus 138 übereinstimmen oder nicht.
Komponenten können aus einer Vielzahl von Gründen im laufenden Betrieb an die Compute Appliance 110-1 angeschlossen und von ihr getrennt werden. Beispielsweise kann ein Speichermodul (z. B. ein DIMM) oder ein Speichergerät (z. B. ein NVMe-Laufwerk) ausfallen oder aufgerüstet werden, das Speichermodul oder das Speichergerät kann in seiner Kapazität herabgestuft werden und so weiter. Der Referenz-Rechenstatus 138 enthält gemäß Beispielimplementierungen Daten, die Informationen enthalten, die für Hot-Plug/Unplug-Ereignisse in der Compute Appliance 110-1 relevant sind. Beispielsweise kann der Referenz-Rechenstatus 138 bestimmte Anschlüsse (z. B. DIMM-Anschlüsse) bezeichnen, bei denen Hot-Plugging und Hot-Demplugging zulässig sind, Hot-Plugging oder Hot-Demplugging von bestimmten Anschlüssen verbieten usw. Ein spezifischeres Beispiel: Bestimmte Steckplätze können beispielsweise mit Redundanzfähigkeiten der Compute Appliance 110-1 verbunden sein. Als spezifischeres Beispiel kann der Referenz-Compute-Status 138 in Übereinstimmung mit Beispielimplementierungen Hot-Plugging oder Hot-Depugging von einem bestimmten Anschluss erlauben und darüber hinaus einen Hersteller, eine spezifische Seriennummer (und damit die erlaubte(n) Komponente(n)), erlaubte Kapazitäten von Komponenten usw. angeben.
zeigt einen Prozess 700, der in Verbindung mit einer Unterbrechungsdienstroutine zur Bearbeitung einer Unterbrechung aufgrund eines Hot-Plug/Unplug-Ereignisses gemäß Beispielimplementierungen durchgeführt wird. In Übereinstimmung mit Beispielimplementierungen kann der Prozess 700 zumindest teilweise von einem Laufzeitüberwachungsdienst 150 durchgeführt werden, und der Prozess 700 kann das BMC 123 einbeziehen. Unter Bezugnahme auf 7 in Verbindung mit 1 umfasst der Prozess 700 in Übereinstimmung mit einigen Implementierungen das Löschen (Block 702) des entsprechenden Unterbrechungsflags und das Bestimmen (Block 704) einer Änderung des tatsächlichen Rechenzustands aufgrund des Hot-Plug/Unplug-Ereignisses. Darüber hinaus kann der Prozess 700 gemäß Block 704 das Aktualisieren des aktuellen Rechenzustands als Ergebnis des Hot-Plug/Unplug-Ereignisses umfassen. Gemäß Entscheidungsblock 710 wird bestimmt, ob die Änderung des aktuellen Rechenzustands durch den Referenz-Rechenzustand erlaubt ist. Mit anderen Worten, in Übereinstimmung mit Beispielimplementierungen kann der Entscheidungsblock 710 die Bestimmung beinhalten, ob das Rechengerät 110-1 immer noch dem Referenz-Rechenzustand entspricht. Ist dies der Fall, wird der Unterbrechungsroutinen-Serviceprozess 700 beendet. Andernfalls stellt der Laufzeitüberwachungsdienst 150 gemäß Block 722 den Betrieb mit dem Cloud-basierten Computersystem 100 ein und stellt die Recheneinheit 110-1 unter Quarantäne. Darüber hinaus kann der Laufzeitüberwachungsdienst 156 in Übereinstimmung mit Beispielimplementierungen gemäß Block 726 das Ereignis protokollieren und eine oder mehrere geeignete Warnmeldungen erzeugen.
Bezug nehmend auf 8 beinhaltet ein Prozess 800 in Übereinstimmung mit Beispielimplementierungen, dass gemäß Block 804 mindestens ein Hardwareprozessor einer Compute Appliance Befehle ausführt, um die Übereinstimmung der Compute Appliance mit einem Referenzbetriebszustand für die Compute Appliance zu erzwingen. Die Compute Appliance ist Teil eines Cloud-basierten Rechensystems. Das Erzwingen der Einhaltung des Referenzbetriebszustands beinhaltet als Reaktion auf einen Start der Compute Appliance das Bestimmen eines tatsächlichen Rechenzustands der Compute Appliance durch die Compute Appliance. Der tatsächliche Berechnungszustand umfasst eine tatsächliche physische Topologieplatzierung einer Hardwarekomponente der Recheneinheit, und die Bestimmung umfasst den Vergleich des tatsächlichen Berechnungszustands mit dem Referenzberechnungszustand. Das Erzwingen der Einhaltung des Referenzbetriebszustands umfasst, in Reaktion auf ein Ergebnis der Überprüfung, die Steuerung durch die Compute Appliance, ob die Compute Appliance Teil des Cloud-basierten Rechensystems ist.
Wie in gezeigt, enthält ein System 900 gemäß Beispielimplementierungen einen Anschluss 904 und einen Knoten 910. Der Anschluss 904 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 Cloud-Betreiberdomäne eines Cloud-basierten Computersystems verbunden ist. Der Knoten 910 umfasst mindestens eine zentrale Verarbeitungseinheit (CPU 920), eine Hardwarekomponente 918 und einen Speicher 914. Die CPU(s) 920 zum Ausführen von Anweisungen 916, die mit einer Tenant-Laufzeitumgebung und einer Cloud-Tenant-Domäne verbunden sind. Die CPU(s) zum Ausführen von Anweisungen 916, um als Reaktion auf ein Hochfahren des Knotens einen tatsächlichen Rechenzustand des Knotens auf der Grundlage einer Kennung der Hardwarekomponente 918 und einer physischen Topologieplatzierung der Hardwarekomponente 918 zu bestimmen. Die CPU(s) 920 führen die Anweisungen 916 aus, um die Übereinstimmung des tatsächlichen Rechenzustands mit einem Referenz-Rechenzustand für den Knoten 910 zu überprüfen. Die Überprüfung der Übereinstimmung mit dem Referenz-Rechenzustand umfasst den Vergleich des tatsächlichen Rechenzustands mit dem Referenz-Rechenzustand. Die CPU(s) 920 führen die Anweisungen 916 aus, um in Reaktion auf das Überprüfungsergebnis zu steuern, ob der Knoten 910 Teil des Cloud-basierten Computersystems ist.
Bezug nehmend auf 10 speichert ein nichttransitorisches Speichermedium 1010 gemäß Beispielimplementierungen maschinenlesbare Anweisungen 1014, die, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, auf Daten zuzugreifen, die einen tatsächlichen Netzwerkinfrastrukturzustand darstellen, der mit einer Compute Appliance verbunden ist. Der tatsächliche Netzwerkinfrastrukturzustand umfasst eine Adresse eines Netzwerkzugangspunkts, der mit der Compute Appliance verbunden ist, und einen physischen Standort, der mit der Compute Appliance verbunden ist. Die Anweisungen 1014 veranlassen, wenn sie von der Maschine ausgeführt werden, die Maschine ferner, die Übereinstimmung des tatsächlichen Netzwerkinfrastrukturzustands mit einem Referenznetzwerkinfrastrukturzustand für die Compute Appliance zu überprüfen. Wenn die Anweisungen 1014 von der Maschine ausgeführt werden, veranlassen sie die Maschine außerdem, als Reaktion auf die Überprüfung zu steuern, ob die Compute Appliance einem Cloud-basierten Computersystem beitreten darf.
In Übereinstimmung mit Beispielimplementierungen umfasst der Prozess ferner die Steuerung, ob die Compute Appliance als Reaktion auf das Ergebnis eine Cloud-Tenant-Laufzeitumgebung einrichtet. Ein besonderer Vorteil ist, dass eine Compute Appliance durch Aktionen, die an Bord der Compute Appliance durchgeführt werden, ein Cloud-Computing-System vor Sicherheitsangriffen schützen kann, die andernfalls von der Compute Appliance ausgehen könnten.
In Übereinstimmung mit Beispielimplementierungen umfasst die Steuerung, ob die Compute Appliance Teil des Cloud-basierten Computersystems ist, das Zulassen der Compute Appliance, Teil des Cloud-basierten Computersystems zu sein. Der Prozess beinhaltet ferner, als Reaktion auf ein Hot-Plug-Ereignis, das mit der Compute-Appliance verbunden ist, während die Compute-Appliance Teil des Cloud-basierten Computersystems ist, zu bestimmen, ob das Hot-Plug-Ereignis erlaubt ist. Das Verfahren umfasst ferner die Steuerung, ob die Compute Appliance als Reaktion auf die Bestimmung, ob das Hot-Plug-Ereignis zulässig ist, Teil des Cloud-basierten Rechensystems bleibt. Ein besonderer Vorteil ist, dass eine Compute Appliance durch Maßnahmen, die an Bord der Compute Appliance ergriffen werden, ein Cloud-Computing-System vor Sicherheitsangriffen schützen kann, die andernfalls von der Compute Appliance ausgehen könnten.
Gemäß Beispielimplementierungen umfasst das Bestimmen, ob das Hot-Plug-Ereignis für die Compute Appliance zulässig ist, das Identifizieren eines Hot-Plug-Verbinders, der dem Hot-Plug-Ereignis zugeordnet ist, und das Bestimmen, ob das Hot-Plug-Ereignis zulässig ist, auf der Grundlage der Identifizierung des Hot-Plug-Verbinders und einer Betriebszustandserzwingungsrichtlinie. Ein besonderer Vorteil ist, dass eine Compute Appliance durch Maßnahmen, die an Bord der Compute Appliance ergriffen werden, ein Cloud-Computing-System vor Sicherheitsangriffen schützen kann, die andernfalls von der Compute Appliance ausgehen könnten.
In Übereinstimmung mit Beispielimplementierungen umfasst die Bestimmung des aktuellen Rechenzustands die Bestimmung eines Komponenteninventars der Compute Appliance. Das Bestimmen des Komponenteninventars umfasst das Bestimmen eines ersten Bezeichners für die Hardwarekomponente. Das Bestimmen des tatsächlichen Rechenzustands umfasst ferner das Bestimmen eines komplexen Bezeichners für die Hardwarekomponente auf der Grundlage des Standorts der physischen Topologie und des ersten Bezeichners. Das Übermitteln der Daten, die den aktuellen Rechenzustand repräsentieren, umfasst das Übermitteln von Daten, die den komplexen Identifikator repräsentieren, an den Verifizierer. Ein besonderer Vorteil ist, dass eine Compute Appliance durch Aktionen, die an Bord der Compute Appliance durchgeführt werden, ein Cloud-Computing-System vor Sicherheitsangriffen schützen kann, die andernfalls von der Compute Appliance ausgehen könnten.
In Übereinstimmung mit Beispielimplementierungen umfasst die erste Kennung eine kryptografische Kennung. Ein besonderer Vorteil besteht darin, dass eine Compute Appliance durch Maßnahmen, die an Bord der Compute Appliance durchgeführt werden, ein Cloud-Computing-System vor Sicherheitsangriffen schützen kann, die andernfalls von der Compute Appliance ausgehen könnten.
In Übereinstimmung mit Beispielimplementierungen umfasst die Compute Appliance eine Vielzahl von Anschlüssen, die in der Lage sind, die Hardwarekomponente aufzunehmen. Die Anschlüsse sind in einer solchen Reihenfolge angeordnet, dass jeder Anschluss einen zugehörigen Index hat, der einen Platz des Anschlusses in der Reihenfolge darstellt, und der Ort der physischen Topologie identifiziert den zugehörigen Index eines Anschlusses, in dem die Hardwarekomponente installiert ist. Ein besonderer Vorteil ist, dass eine Compute Appliance durch Maßnahmen, die an Bord der Compute Appliance ergriffen werden, ein Cloud-Computing-System vor Sicherheitsangriffen schützen kann, die andernfalls von der Compute Appliance ausgehen könnten.
Gemäß Beispielimplementierungen umfasst der Ort der physischen Topologie mindestens eine der folgenden Angaben: eine Nummer des Speicherkäfigs, eine Nummer des Speichersteckplatzes, eine Nummer des Laufwerkskäfigs, eine Nummer des Laufwerksschachts, eine Nummer des Kabelbaums, eine Nummer des Busanschlusses, eine Nummer des Busanschlusskäfigs, eine Anschlussnummer oder eine Nummer des Sockels der Zentraleinheit (CPU). Ein besonderer Vorteil ist, dass eine Compute Appliance durch Maßnahmen, die an Bord der Compute Appliance ergriffen werden, ein Cloud-Computing-System vor Sicherheitsangriffen schützen kann, die andernfalls von der Compute Appliance ausgehen könnten.
In Übereinstimmung mit Beispielimplementierungen umfasst der Prozess als Reaktion auf das Ergebnis die Quarantäne der Compute Appliance vom Cloud-basierten Computersystem. Ein besonderer Vorteil ist, dass eine Compute Appliance durch Maßnahmen, die an Bord der Compute Appliance ergriffen werden, ein Cloud-Computing-System vor Sicherheitsangriffen schützen kann, die andernfalls von der Compute Appliance ausgehen könnten.
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

Verfahren, das Folgendes umfasst: mindestens einen Hardwareprozessor einer Recheneinheit, der Befehle ausführt, um die Übereinstimmung der Recheneinheit mit einem Referenzbetriebszustand für die Recheneinheit zu erzwingen, wobei die Recheneinheit Teil eines Cloud-basierten Rechensystems ist und das Erzwingen der Übereinstimmung mit dem Referenzbetriebszustand umfasst, dass sie auf einen Start der Recheneinheit reagiert: Bestimmen eines tatsächlichen Rechenzustands der Compute Appliance durch die Compute Appliance, wobei der tatsächliche Rechenzustand eine tatsächliche physikalische Topologieplatzierung einer Hardwarekomponente der Compute Appliance umfasst, und das Bestimmen das Bestimmen der physikalischen Topologieplatzierung der Hardwarekomponente umfasst; Überprüfen der Übereinstimmung des tatsächlichen Rechenzustands mit einem Referenz-Rechenzustand für die Rechenvorrichtung, wobei die Überprüfung das Vergleichen des tatsächlichen Rechenzustands mit dem Referenz-Rechenzustand umfasst; und als Reaktion auf ein Ergebnis der Überprüfung, Steuerung durch die Compute Appliance, ob die Compute Appliance Teil des Cloud-basierten Rechensystems ist.
Verfahren nach Anspruch 1, das ferner umfasst: als Reaktion auf das Ergebnis der Überprüfung, Steuerung durch die Compute Appliance, ob die Compute Appliance eine Cloud Tenant-Laufzeitumgebung bereitstellt.
Verfahren nach Anspruch 1, das ferner umfasst: als Reaktion auf das Ergebnis der Überprüfung, Steuerung durch die Compute Appliance, ob die Compute Appliance eine Cloud Tenant-Laufzeitumgebung einrichtet.
Verfahren nach Anspruch 1, wobei die Steuerung, ob die Recheneinheit Teil des Cloud-basierten Rechensystems ist, das Zulassen umfasst, dass die Recheneinheit Teil des Cloud-basierten Rechensystems ist, wobei das Verfahren ferner umfasst: als Reaktion auf ein Hot-Plug-Ereignis oder ein Hot-Depot-Ereignis, das mit der Compute-Appliance verbunden ist, während die Compute-Appliance Teil des Cloud-basierten Computersystems ist, Bestimmen, ob das Hot-Plug-Ereignis oder das Hot-Depot-Ereignis mit dem Referenz-Compute-Zustand übereinstimmt; und Steuern, ob die Compute Appliance Teil des Cloud-basierten Computersystems bleibt, in Reaktion auf die Bestimmung, ob das Hot-Plug-Ereignis oder das Hot-Unplug-Ereignis mit dem Referenz-Compute-Zustand übereinstimmt.
Verfahren nach Anspruch 4, wobei die Bestimmung, ob das Hot-Plug-Ereignis oder das Hot-Unplug-Ereignis mit dem Referenz-Rechenzustand übereinstimmt, umfasst: Bestimmen von Informationen, die das Hot-Plug-Ereignis oder das Hot-Depot-Ereignis beschreiben, wobei die Informationen mindestens eine Identifikation eines Verbinders oder eine Identifikation einer Komponente umfassen, die mit dem Hot-Plug-Ereignis oder dem Hot-Depot-Ereignis verbunden ist; und Bestimmen, ob das Hot-Plug-Ereignis oder das Hot-Unplug-Ereignis mit dem Referenz-Rechenzustand übereinstimmt, basierend auf den Informationen.
Verfahren nach Anspruch 4, das ferner umfasst: als Reaktion auf die Bestimmung, ob das Hot-Plug-Ereignis oder das Hot-Unplug-Ereignis mit dem Referenzzustand übereinstimmt, Ruhigstellen eines Betriebs der Compute Appliance.
Verfahren nach Anspruch 1, wobei das Bestimmen des aktuellen Berechnungszustands umfasst: Bestimmen eines Komponenteninventars der Compute Appliance, wobei das Bestimmen des Komponenteninventars das Bestimmen eines ersten Identifikators für die Hardwarekomponente umfasst; und Bestimmen eines komplexen Bezeichners für die Hardwarekomponente auf der Grundlage des Standorts der physischen Topologie und des ersten Bezeichners.
Verfahren nach Anspruch 7, wobei der erste Identifikator einen kryptographischen Identifikator umfasst.
Verfahren nach Anspruch 1, wobei das Rechengerät eine Vielzahl von Verbindern umfasst, die in der Lage sind, die Hardwarekomponente aufzunehmen, wobei die Vielzahl von Verbindern gemäß einer Reihenfolge angeordnet ist, so dass jeder Verbinder der Vielzahl von Verbindern einen zugehörigen Index hat, der einen Platz des Verbinders in der Reihenfolge darstellt, und der Ort der physikalischen Topologie den zugehörigen Index eines Verbinders der Vielzahl von Verbindern identifiziert, in dem die Hardwarekomponente installiert ist.
Verfahren nach Anspruch 1, wobei der Ort der physikalischen Topologie mindestens eine der folgenden Angaben umfasst: eine Nummer des Speicherkäfigs, eine Nummer des Speichersteckplatzes, eine Nummer des Laufwerkskäfigs, eine Nummer des Laufwerksschachts, eine Nummer des Kabelbaums, eine Nummer des Bussteckers, eine Nummer des Bussteckerkäfigs, eine Anschlussnummer oder eine Nummer des Sockels der zentralen Verarbeitungseinheit (CPU).
Verfahren nach Anspruch 1, wobei die Bestimmung des tatsächlichen Rechenzustands mindestens eine Identifikation der Hardwarekomponente oder eine mit der Hardwarekomponente verbundene Kategorie umfasst.
Verfahren nach Anspruch 1, das ferner umfasst: als Reaktion auf das Ergebnis der Verifizierung, Quarantäne der Compute Appliance von dem Cloud-basierten Computersystem.
System, das Folgendes umfasst: einen Verbinder 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 Cloud-Betreiberdomäne eines Cloud-basierten Computersystems verbunden ist; und einen Knoten, der mindestens eine zentrale Verarbeitungseinheit (CPU), eine Hardwarekomponente und einen Speicher umfasst, wobei die mindestens eine CPU Befehle ausführt, die mit einer Anwendungsbetriebsumgebung verbunden sind und mit einer Cloud-Mieterdomäne verbunden sind, und die mindestens eine CPU Befehle ausführt, um auf einen Start des Knotens zu reagieren: Bestimmen eines tatsächlichen Rechenzustands des Knotens auf der Grundlage einer Kennung der Hardwarekomponente und einer physischen Topologieplatzierung der Hardwarekomponente; Überprüfen der Übereinstimmung des tatsächlichen Rechenzustands mit einem Referenz-Rechenzustand für den Knoten, wobei die Überprüfung das Vergleichen des tatsächlichen Rechenzustands mit dem Referenz-Rechenzustand umfasst; und als Reaktion auf das Ergebnis der Überprüfung zu kontrollieren, ob der Knoten Teil des Cloud-basierten Computersystems ist.
System nach Anspruch 13, wobei der Ort der physischen Topologie eine Steckplatznummer oder eine Käfignummer umfasst, die mit der Hardwarekomponente verbunden ist.
System nach Anspruch 13, wobei die mindestens eine CPU die Befehle ausführt, um als Reaktion auf das Ergebnis der Überprüfung zu bestimmen, dass der Knoten von dem Cloud-basierten Computersystem isoliert wird.
Nicht-übertragbares Speichermedium zum Speichern von maschinenlesbaren Befehlen, die, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen,: Zugriffsdaten, die einen tatsächlichen Netzwerkinfrastrukturzustand darstellen, der mit einer Compute Appliance verbunden ist, wobei der tatsächliche Netzwerkinfrastrukturzustand eine Adresse eines Netzwerkzugangspunkts, der mit der Compute Appliance verbunden ist, und einen physischen Standort, der mit der Compute Appliance verbunden ist, enthält; Überprüfung der Übereinstimmung des tatsächlichen Netzwerkinfrastrukturzustands mit einem Referenznetzwerkinfrastrukturzustand für die Recheneinheit; und als Reaktion auf die Überprüfung zu steuern, ob die Compute Appliance einem Cloud-basierten Computersystem beitreten darf.
Speichermedium nach Anspruch 16, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine außerdem veranlassen,: ein Leistungskriterium einer mit der Compute Appliance verbundenen SDN-Verbindung (Software Defined Network) zu bestimmen, wobei die Überprüfung der Übereinstimmung den Vergleich der Leistungskriterien mit einem Referenzkriterium des Referenznetzinfrastrukturzustands umfasst.
Speichermedium nach Anspruch 16, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine außerdem veranlassen,: einen geografischen Standort zu bestimmen, der mit einer Software Defined Storage (SDS)-Verbindung verbunden ist, die der Compute Appliance zugeordnet ist, wobei die Überprüfung der Übereinstimmung den Vergleich des geografischen Standorts mit einem geografischen Referenzkriterium des Referenznetzinfrastrukturzustands umfasst.
Speichermedium nach Anspruch 16, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine außerdem veranlassen,: eine Signatur eines Software Defined Compute (SDC)-Images der Compute Appliance zu bestimmen, wobei die Überprüfung der Übereinstimmung den Vergleich der Signatur mit einer Referenzsignatur des Referenznetzinfrastrukturzustands umfasst.
Speichermedium nach Anspruch 16, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine außerdem veranlassen,: Bestimmung eines Skalierungskriteriums für eine Recheneinheit im Zustand der Referenznetzinfrastruktur, wobei die Überprüfung der Konformität die Bewertung der Skalierung des Cloud-basierten Computersystems umfasst, das mit der Compute-Appliance verbunden ist, basierend auf den Skalierungskriterien der Compute-Appliance.