DE102018004046A1 - Nichtflüchtiger Speicher-Express über Fabric (NVMeOF) unter Verwendung eines Volumenverwaltungsgeräts - Google Patents

Nichtflüchtiger Speicher-Express über Fabric (NVMeOF) unter Verwendung eines Volumenverwaltungsgeräts Download PDF

Info

Publication number
DE102018004046A1
DE102018004046A1 DE102018004046.2A DE102018004046A DE102018004046A1 DE 102018004046 A1 DE102018004046 A1 DE 102018004046A1 DE 102018004046 A DE102018004046 A DE 102018004046A DE 102018004046 A1 DE102018004046 A1 DE 102018004046A1
Authority
DE
Germany
Prior art keywords
nvme
compute node
storage devices
software
fabric
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102018004046.2A
Other languages
English (en)
Inventor
Mohan J. Kumar
Murugasamy Nachimuthu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE102018004046A1 publication Critical patent/DE102018004046A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H04L41/0897—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities by horizontal or vertical scaling of resources, or by migrating entities, e.g. virtual resources or entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/26—Special purpose or proprietary protocols or architectures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Human Computer Interaction (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Nichtflüchtiger Speicher-Express über Fabric (NVMeoF) unter Verwendung von Volumenverwaltungsgerät(VMD)-Schemas und zugeordnete Verfahren, Systemen und Software. Die Schemata werden in einer Rechenzentrumsumgebung implementiert, die Rechenressourcen in Recheneinschüben und Speicherressourcen aufweisen, die sich in Speicher-Pool-Einschüben befinden, die über einen Fabric kommunikativ gekoppelt sind. Rechenressourcen werden als Rechenknoten oder virtuelle Maschinen/Behälter erstellt, die auf Rechenknoten laufen, um entfernte Speichergeräte in Speicher-Pool-Einschüben zu nutzen, während die entfernten Speichergeräte als lokale NVMe-Speichergeräte einem Ausführen von Software auf den Rechenknoten ausgesetzt werden. Dies wird durch Virtualisieren der Speicherinfrastruktur des Systems durch Verwendung von auf Hardware basierenden Komponenten, auf Firmware basierenden Komponenten oder einer Kombination aus auf Hardware/Firmware basierenden und auf Software basierenden Komponenten ermöglicht. Die Schemata unterstützen die Nutzung von entfernten NVMe-Speichergeräten unter Verwendung eines NVMeOF-Protokolls und/oder benutzen Nicht-NVMe-Speichergeräte unter Verwendung von NVMe-Emulation.

Description

  • STAND DER TECHNIK
  • Die Verfügbarkeit und Verwendung von „Cloud“-Computing ist in den letzten Jahren exponentiell gewachsen. Unter einem herkömmlichen Datenverarbeitungsansatz führen Benutzer Softwareanwendungen auf ihren eigenen Rechnern aus und/oder greifen auf Softwaredienste zu, die sich auf lokalen Servern befinden (wie etwa Servern, die von einem Geschäftsunternehmen betrieben werden). Im Gegensatz dazu sind beim Cloud-Computing die Datenverarbeitungs- und Speicherressourcen „in der Cloud“, das heißt, sie sind physisch in einer entfernten Einrichtung gehostet, auf die über ein Rechnernetzwerk zugegriffen wird, wie etwa das Internet. Auf Rechen- und Speicherressourcen, die von einem Cloud-Betreiber gehostet werden, kann über „Dienste“ zugegriffen werden, die im Allgemeinen als Cloud-basierte Dienste, Webdienste oder einfach Dienste bezeichnet werden.
  • Cloud-basierte Dienste werden typischerweise von einem Rechenzentrum gehostet, das die physische Anordnung von Servern aufweist, die sich zu einer Cloud oder einem bestimmten Teil einer Cloud zusammensetzen. Rechenzentren setzen allgemein eine physische Hierarche aus Rechen-, Netzwerk- und geteilten Speicherressourcen ein, um eine Skalierung der Arbeitslastanforderungen zu unterstützen. 1 zeigt einen Teil einer beispielhaften physischen Hierarche in einem Rechenzentrum 100, das eine Anzahl L von Pods 102 und eine Anzahl M von Racks 104 aufweist, die jeweils Schlitze für eine Anzahl N von Fächern 106 aufweisen. Jedes Fach 106 kann wiederum mehrere Schlitten 108 aufweisen. Zur besseren Erläuterung ist jeder Pod 102, jedes Rack 104, und jedes Fach 106 mit einer entsprechenden Kennung bezeichnet, wie etwa Pod 1, Rack 2, Fach 1B usw. Auf Fächer kann auch mit Einschüben Bezug genommen werden und Schlitten können auch verschiedene Formen, wie etwa Module oder Knoten, haben. Zusätzlich zu der Fach- und Schlittenkonfiguration, können Racks unter Verwendung von Gehäusen vorgesehen sein, in denen verschiede Formen von Servern installiert sind, wie etwa Blade-Server-Gehäuse und Server-Blades. Während der Begriff „Einschub“ hierin benutzt wird, werden Fachleute auf dem Gebiet erkennen, dass Einschübe und Gehäuse im Allgemeinen analoge Begriffe sind.
  • Im oberen Teil jedes Racks 104 ist ein jeweiliger Top-of-Rack(ToR; Rackoberteil)-Switch 110 dargestellt, der auch mit einer ToR-Switch-Nummer gekennzeichnet ist. Im Allgemeinen stehen ToR-Switches 110 sowohl für ToR-Switches als auch eine beliebige andere Schalteinrichtung, die ein Umschalten zwischen Racks 104 unterstützt. Es ist in der Praxis üblich, diese Switches als ToR-Switches zu bezeichnen, unabhängig davon, ob sie sich physisch an dem Oberteil eines Racks befinden oder nicht (auch wenn sie dies im Allgemeinen tun).
  • Jeder Pod 102 weist ferner einen Pod-Switch 112 auf, an den die ToR-Switches 110 des Pods gekoppelt sind. Pod-Switches 112 sind wiederum an einen Rechenzentrum(DC)-Switch 114 gekoppelt. Die Rechenzentrum-Switches können hierarchisch an dem Oberteil des Rechenzentrum-Switches sitzen oder es kann eine oder mehrere zusätzliche Ebenen geben, die nicht gezeigt sind. Zur besseren Erläuterung sind die Hierarchien, die hierin beschrieben werden, physische Hierarchien, die physische LANs verwenden. In der Praxis ist es üblich, virtuelle LANs bereitzustellen, die zugrunde liegende physische LAN-Schalteinrichtungen benutzen.
  • Die Cloud-gehosteten Dienste sind im Allgemeinen in Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) und Infrastructure-as-a-Service (IaaS) kategorisiert. SaaS-Dienste, die allgemein auch Webdienste und Cloudanwendungsdienste genannt werden, ermöglichen einen Zugriff auf Dienste, die auf Rechenzentrumsservern laufen, über eine Netzwerkverbindung und Client-seitige Schnittstelle, wie etwa einen Webbrowser. Weit bekannte Beispiele für SaaS-Dienste umfassen E-Mail-Webdienste (z.B. Google Gmail, Microsoft Hotmail, Yahoo mail), Microsoft Office 365, Salesforce.com und Google docs. PaaS, auch bekannt als Cloud-Plattformdienste, werden für Anwendungen und andere Bereitstellungen benutzt, während sie Cloud-Komponenten für Software bereitstellen. Beispiele für PaaS umfassen Amazon Web Services (AWS) Elastic Beanstalk, Windows Azure und Google App Engine.
  • IaaS sind Dienste zum Zugreifen auf, Überwachen und Verwalten von entfernten Rechenzentrumsinfrastrukturen, wie etwa (virtualisierte oder Bare-Metal-) Rechner, Speicher, Netzwerke und Netzwerkdienste (z.B. Firewalls). Anstatt ihre eigene physische Hardware zu kaufen und zu betreiben, können Benutzer IaaS je nach Verbrauch ankaufen. Zum Beispiel bieten AWS und Windows Azure jeweils die Benutzung von Amazon- und Microsoft-Rechenzentrumsressourcen auf einer Ressourcenzuordnungs-/verbrauchsbasis an. Amazon Elastic Compute Cloud (EC2) ist ein zentraler Teil von AWS.
  • Die IaaS-Nutzung für einen gegebenen Kunden umfasst typischerweise eine Zuordnung von Rechenzentrumsressourcen. Zum Beispiel kann ein typischer AWS-Benutzer die Benutzung einer von 24 unterschiedlichen EC2-Instanzen anfragen, die von einer t2.nano-Instanz mit 0,5 Gigabyte (GB) Speicher, 1 Core/variable Cores/Recheneinheiten und keinem Instanzspeicher bis zu einer hsl.8xlarge mit 117 GB Speicher, 16/35 Cores/Recheneinheiten und 48000 GB Instanzspeicher reichen können. Jede zugeordnete EC2-Instanz verbraucht bestimmte physische Rechenzentrumsressourcen (z.B. Rechen-, Datenspeicher). Gleichzeitig können Rechenzentrumsracks eine Vielzahl von unterschiedlichen Konfigurationen unterstützen. Für eine maximale Ressourcenzuordnung muss der IaaS-Betreiber nachverfolgen, welche Ressourcen in welchem Rack verfügbar sind.
  • Figurenliste
  • Die vorangegangenen Aspekte und viele der damit einhergehenden Vorteile dieser Erfindung werden ohne Weiteres hervorgehen, wenn Letztere unter Bezugnahme auf die nachfolgende ausführliche Beschreibung besser verstanden wird, wobei diese in Verbindung mit den beigefügten Zeichnungen steht, wobei gleiche Bezugszeichen gleiche Teile in den verschiedenen Ansichten bezeichnen, solange nichts anderes spezifiziert wird:
    • 1 ist eine schematische Darstellung einer herkömmlichen physischen Rackkonfiguration in einem Rechenzentrum,
    • 2 ist eine schematische Darstellung einer Rack Scale Design (RSD)-Konfiguration in einem Rechenzentrum gemäß einer Ausführungsform,
    • 3 ist ein Blockdiagramm einer RSD-Verwaltungsarchitektur gemäß einer Ausführungsform,
    • 4 ist eine schematische Darstellung, die weitere Einzelheiten eines RSD-Racks zeigt, das Pooled System Management Engines (PSMEs) implementiert,
    • 5 ist eine schematische Darstellung, die einen Überblick über einen entfernten Speicherzugriffsmechanismus gibt, bei dem Server befähigt sind, auf NVMe-Speichergeräte über einen Fabric mit niedriger Latenz zuzugreifen,
    • 5a ist eine schematische Darstellung, die eine alternative Implementierung des Schemas von 5 darstellt, bei der eine NVMe-Emulation implementiert ist, um einen Zugriff auf Nicht-NVMe-Speichergeräte über den Fabric mit niedriger Latenz zu ermöglichen,
    • 6 ist eine schematische Darstellung einer Implementierungsumgebung, die mehrere CPU-Schlitten und Speichereinschübe aufweist, die über einen Fabric kommunikativ gekoppelt sind, gemäß einer Ausführungsform,
    • 6a ist eine schematische Darstellung, die eine Implementierungsumgebung zeigt, die einen Ethernet-Fabric einsetzt, gemäß einer Ausführungsform,
    • 7 ist eine schematische Darstellung, die ein Zugriffsschema eines virtualisierten Speichers darstellt, bei dem entfernte Speichergeräte auf einem Ziel einem Betriebssystem auf einem Starter als lokale Speichergeräte ausgesetzt sind, wobei eine NVMe-Funktion in einer Netzwerkschnittstellensteuerung (NIC) implementiert ist,
    • 7a ist eine schematische Darstellung, die ein Zugriffsschema eines virtualisierten Speichers darstellt, bei dem entfernte Speichergeräte auf einem Ziel einem Betriebssystem auf einem Starter als lokale Speichergeräte ausgesetzt sind, wobei eine NVMe-Funktion in einem Fabric Controller implementiert ist,
    • 7b ist eine schematische Darstellung, die eine Änderung der Ausführungsform von 7 darstellt, bei der auf ein Beurteilen von Nicht-NVMe-Speichergeräten auf dem Ziel unter Verwendung von NVMe-Emulation zugegriffen wird,
    • 7c ist eine schematische Darstellung, die ein Zugriffsschema eines virtualisierten Speichers darstellt, bei dem entfernte Speichergeräte auf einem Ziel einem Betriebssystem auf einem Starter als lokale Speichergeräte ausgesetzt sind, wobei eine NVMe-Funktion in einem feldprogrammierbaren Gate-Array (FPGA) implementiert ist,
    • 8 stellt eine Architektur und ein zugeordnetes Prozessflussdiagramm dar, bei dem eine Virtualisierung von lokalen und entfernten NVMe-Speichergeräten durch Erweiterungen mit einem Prozessor in Kombination mit Firmware- und Software-Treibern implementiert ist,
    • 8a ist eine schematische Darstellung, die die Architektur von 8 darstellt, die einen Starter bereitstellt, der auf entfernte Speichergeräte auf einem Ziel zugreift, und die ferner eine virtualisierte I/O-Hierarchie darstellt, die einem Betriebssystem ausgesetzt ist, das auf dem Starter läuft,
    • 9 ist ein Flussdiagramm, das Vorgänge darstellt, die während einer Initialisierung eines Rechenknotens durchgeführt werden, gemäß einer Ausführungsform,
    • 10 ist eine schematische Darstellung, die eine auf Firmware basierende Erweiterung darstellt, die benutzt wird, um eine Speicher-Virtualisierungsschicht zu unterstützen, die physische Speichergeräte abstrahiert und sie als virtuelle Geräte einem Ausführen von Software auf dem Rechenknoten aussetzt, wobei die Software einen Hypervisor und mehrere virtuelle Maschinen aufweist,
    • 10a ist eine schematische Darstellung, die eine Erweiterung der Ausführungsform von 10 darstellt, die eine Softwarevirtualisierungserweiterung als Teil des Hypervisors einsetzt,
    • 11 ist eine schematische Darstellung, die eine Erweiterung der Ausführungsform von 10 darstellt, die eine Betriebssystem-Virtualisierungsschicht und mehrere Behälter einsetzt,
    • 11a ist eine schematische Darstellung, die eine Erweiterung der Ausführungsform von 11a darstellt, die eine Softwarevirtualisierungserweiterung als Teil der Betriebssystem-Virtualisierungsschicht einsetzt, und
    • 12 ist ein Flussdiagramm, das Vorgänge und Logik zum Implementieren eines Zugriffsschemas eines virtualisierten Speichers darstellt, das mit einer oder mehreren der Ausführungsformen benutzt werden kann, die hierin dargelegt sind.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Ausführungsformen von nichtflüchtigem Speicher-Express über Fabric (NVMeOF) unter Verwendung von Volumenverwaltungsgerät(VMD)-Schemas und zugeordneten Verfahren, Systemen und Software werden hierin beschrieben. In der folgenden Beschreibung werden zahlreiche spezifische Einzelheiten ausgeführt, um ein gründliches Verständnis über die Ausführungsformen der Erfindung bereitzustellen. Fachleute auf dem Gebiet werden jedoch erkennen, dass die Erfindung ohne eine oder mehrere der spezifischen Einzelheiten ausgeführt werden kann, oder mit anderen Verfahren, Komponenten, Materialien usw. In anderen Beispielen sind bekannte Strukturen, Materialien oder Vorgänge nicht gezeigt oder ausführlich beschrieben, um zu vermeiden, dass Aspekte der Erfindung verdeckt werden.
  • Bezugnahmen in dieser Spezifizierung auf „eine Ausführungsform“ bedeuten, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder Eigenschaft, das/die in Verbindung mit der Ausführungsform beschrieben wird, in mindestens einer Ausführungsform der vorliegenden Erfindung enthalten ist. Daher bezieht sich der Ausdruck „in einer Ausführungsform“ an verschiedenen Stellen dieser Spezifizierung nicht notwendigerweise auf die gleiche Ausführungsform. Des Weiteren können bestimmte Merkmale, Strukturen oder Eigenschaften in einer geeigneten Weise in einer oder mehreren Ausführungsformen kombiniert sein.
  • Zur Verdeutlichung können einzelne Komponenten in den Figuren hierin auch mit ihren Kennungen in den Figuren anstelle eines bestimmten Bezugszeichens bezeichnet werden. Zudem können Bezugszeichen, die einen bestimmten Komponententyp bezeichnen (im Gegensatz zu einer bestimmten Komponente), mit einem Bezugszeichen gezeigt werden, auf das ein „(Typ)“ folgt, das „typisch“ bedeutet. Es versteht sich, dass die Konfiguration dieser Komponenten für ähnliche Komponenten typisch ist, die existieren können, aber aus Gründen der Einfachheit und Verdeutlichung nicht in den Figuren gezeigt sind, oder andere ähnliche Komponenten, die nicht mit separaten Bezugszeichen bezeichnet sind. Umgekehrt ist „(Typ)“ nicht so auszulegen, dass die Komponente, das Element usw. typischerweise benutzt wird, um eine offenbarte Funktion, Umsetzung, Zweck usw. zu bezeichnen.
  • Vor kurzem hat INTEL® Corporation eine neue Rackarchitektur eingeführt, die Rack Scale Design (RSD) heißt (ehemals Rack Scale Architecture genannt). Rack Scale Design ist eine logische Architektur, die Rechen-, Speicher- und Netzwerkressourcen aufteilt und die Fähigkeit einführt, diese Ressourcen für eine effizientere Nutzung von Ressourcen zu bündeln. Es vereinfacht die Ressourcenverwaltung und stellt die Fähigkeit bereit, Ressourcen dynamisch basierend auf einer Arbeitslast-spezifischen Nachfrage zusammenzustellen.
  • RSD verwendet Rechen-, Fabric-, Speicher und Verwaltungsmodule, die zusammenarbeiten, um eine auswählbare Konfiguration einer breiten Palette an virtuellen Systemen zu ermöglichen. Das Design verwendet vier Grundsäulen, die basierend auf den Benutzerbedürfnissen konfiguriert werden können. Diese umfassen 1) einen Pod-Manager (PODM) zur Verwaltung mehrerer Racks, umfassend Firmware- und Software-Anwendungsprogrammierschnittstellen (APIs), die ein Verwalten von Ressourcen und Richtlinien ermöglichen und die Hardware darunter und die Orchestrationsschicht darüber über eine Standardschnittstelle aussetzen, 2) einen System-Pool aus Rechen-, Netzwerk- und Speicherressourcen, der selektiv basierend auf Arbeitslastanforderungen zusammengestellt werden kann, 3) einen Pod-weiten Speicher, der auf verbundenem Speicher aufbaut, der Speicheralgorithmen nutzt, um eine Palette von Nutzungen zu unterstützen, die als Ressourcen mit mehreren Racks oder Speicherhardware und Rechenknoten mit lokalem Speicher bereitgestellt werden, und 4) einen konfigurierbaren Netzwerkfabric für Hardware, Verbindungen mit Kabeln und Rückwandplatinen und für Verwaltungssoftware, um eine Palette von kosteneffizienten Netzwerktopologien zu unterstützen, einschließlich aktuelle Top-of-Rack-Switch-Entwürfe und verteilte Switches in den Plattformen.
  • Eine beispielhafte RSD-Umgebung 200 ist in 2 dargestellt. RSD-Umgebung 200 weist mehrere Rechenracks 202 auf, die jeweils einen Top-of-Rack(ToR)-Switch 204, einen Pod-Manager 206 und mehrere System-Pool-Einschübe aufweisen. Im Allgemeinen können System-Pool-Einschübe Rechen-Pool-Einschübe und Speicher-Pool-Einschübe aufweisen. Optional können System-Pool-Einschübe auch Datenspeicher-Pool-Einschübe und Input/Output(I/O; Eingang/Ausgang)-Pool-Einschübe aufweisen. In der dargestellten Ausführungsform weisen die System-Pool-Einschübe einen INTEL® XEON® Rechen-Pool-Einschub 208 und einen INTEL® ATOM™ Rechen-Pool-Einschub 210, einen Speicher-Pool-Einschub 212, einen Datenspeicher-Pool-Einschub 214 und einen I/O-Pool-Einschub 216 auf. Jeder der System-Pool-Einschübe ist mit ToR-Switch 204 über eine Hochgeschwindigkeitsverbindung 218 verbunden, wie etwa eine 40 Gigabit/Sekunde (Gb/s) oder 100 Gb/s Ethernet-Verbindung oder eine 100+ Gb/s Siliziumphotonik (SiPh) optische Verbindung. In einer Ausführungsform umfasst eine Hochgeschwindigkeitsverbindung 218 eine 800 Gb/s SiPh optische Verbindung.
  • Mehrere der Rechenracks 200 können miteinander über ihre ToR-Switches 204 verbunden sein (z.B. mit einem Switch auf Pod-Ebene oder einem Rechenzentrum-Switch), wie durch Verbindungen mit einem Netzwerk 220 dargestellt ist. In einigen Ausführungsformen werden Gruppen von Rechenracks 202 als separate Pods über Pod-Manager 206 verwaltet. In einer Ausführungsform wird ein einziger Pod-Manager benutzt, um alle Racks in dem Pod zu verwalten. Alternativ können verteilte Pod-Manager für Pod-Verwaltungsvorgänge benutzt werden.
  • RSD-Umgebung 200 weist ferner eine Verwaltungsschnittstelle 222 auf, die benutzt wird, um verschiedene Aspekte der RSD-Umgebung zu verwalten. Dies umfasst ein Verwalten der Rackkonfiguration mit entsprechenden Parametern, die als Rackkonfigurationsdaten 224 gespeichert sind.
  • 3 zeigt eine Ausführungsform einer RSD-Verwaltungsarchitektur 300. Die RSD-Verwaltungsarchitektur weist mehrere Software- und Firmware-Komponenten auf, die in einer geschichteten Architektur konfiguriert sind, die eine Orchestrationsschicht 302, eine RSD-Podverwaltungsgrundlage-API (Anwendungsprogrammierschnittstelle), einen Pod-Manager 306 und eine RSD-Verwaltungsfirmware-API 308 aufweist. Die untere Schicht einer RSD-Verwaltungsarchitektur weist eine Rechenplattform-Verwaltungskomponente 310, eine Speicherverwaltungskomponente 312, eine Rackverwaltungskomponente 314 und eine Netzwerk-Switch-Verwaltungskomponente 316 auf.
  • Die Rechenplattform-Verwaltungskomponente 310 führt Vorgänge durch, die Recheneinschüben zugeordnet sind, und weist einen System-Pool, ein Verwaltungssystem, eine Knotenverwaltung, eine Switch-Konfiguration und einen Startdienst auf. Speicherverwaltungskomponente 312 ist konfiguriert, um eine Vorgangsverwaltung von Speicher-Pool-Einschüben zu unterstützen. Rackverwaltungskomponente 314 ist konfiguriert, um die Racktemperatur zu verwalten und Untersysteme anzutreiben. Netzwerk-Switch-Verwaltungskomponente weist einen verteilten Switch-Manager auf.
  • INTEL® Rack Scale Design ist ausgelegt, um den Fokus von der Plattformarchitektur von einzelnen Servern zu einer konvergenten Infrastruktur umzulenken, die aus Recheneinheit, Netzwerk und Speicher besteht, wie oben ausgeführt wird und in 2 dargestellt ist. Die Ressourcenverwaltung wird auf der Rackebene und Podebene durchgeführt. Der Fokus auf der Ressourcenverwaltung auf Rackebene erfordert auch eine Verwaltung von Umgebungen auf Rackebene, wie etwa Energie- und Kühlzonen sowie ein Bereitstellen einer Vertrauenskette auf Rackebene für relative Ortinformationen. Diese Rolle wird durch ein Rackverwaltungsmodul (Rack Management Module; RMM) zusammen mit einem Unterrackeinheit-Manager (die Einschubeinheiten in der RSD-Terminologie) erfüllt, der Pooled System Management Engine (PSME) heißt. Die Verwaltungselemente von RSD, RMM und der PSMEs sind mit einem privaten Netzwerk verbunden, das von außerhalb des Racks nicht zugänglich ist, wie in 4 gezeigt und unten ausgeführt wird.
  • 4 zeigt eine Ausführungsform einer Rackkonfiguration 400, die Rackverwaltungs- und Rackkonfigurationskomponenten einsetzt, die über ein privates Rackverwaltungsnetzwerk kommunizieren. Die Rackverwaltungs- und Rackkonfigurationskomponenten weisen ein RMM 402 auf, das in Kommunikation an einen Rackverwaltung-Switch 404 über eine Verbindung 406 gekoppelt ist. Ein jeweiliger PSME 408 ist jedem von fünf System-Pool-Einschüben 410 zugeordnet. Jeder PSME 408 ist mit einem Rackverwaltung-Switch 404 über eine Verbindung 412 verbunden. Der Rackverwaltung-Switch ist auch mit einem POD-Manager 206 verbunden. In der dargestellten Ausführungsform weist jeder System-Pool-Einschub 1 und 2 mehrere Rechenknoten 500 auf, während die System-Pool-Einschübe 3, 4 und 5 jeweils mehrere Speicherressourcen 414, mehrere Datenspeicherressourcen 415 und mehrere IO-Beschleunigungsressourcen 416 aufweisen.
  • In einer Rechenzentrumsumgebung, wie dem RSD, ist die Rechenzentrum-Verwaltungssoftware imstande, aus verschiedenen Rackressourcen (eine) Instanz(en) oder einen Rechenknoten zusammenzustellen, die/der Benutzerleistungsanforderungen erfüllt/en. Im Allgemeinen führt die Zuordnung von Ressourcen, um den Leistungsergebnissen in einer ineffizienten Nutzung der Rackressourcen zu entsprechen, zu höheren Gesamtbetriebskosten (TCO) und einer niedrigeren Kapitalrendite (ROI).
  • Aktuelle Unternehmens/Cloud-Rechnersysteme haben flüchtige Datenspeicher, zum Beispiel DRAM (Dynamic Random Access Memory) und nichtflüchtige Speicherklassendatenspeicher, wie etwa 3D-Crosspoint-Technologie (3D XPOINT™) DIMMs (Dual In-line Memory Modules), die lokal innerhalb des Rechenknotens angeordnet sind. Es können auch andere Datenspeichertypen verwendet werden.
  • Nichtflüchtige Datenspeicher sind Speichermedien, die keine Energie erfordern, um den Datenzustand, der durch das Medium gespeichert wird, aufrechtzuerhalten. Nicht beschränkende Beispiele für nichtflüchtige Datenspeicher können einen beliebigen von Folgenden oder eine Kombination davon umfassen: Festkörperspeicher (wie etwa planare oder 3D NAND-Flash-Speicher oder NOR-Flash-Speicher), 3D-Crosspoint-Speicher, Speichergeräte, die Chalkogenid-Phasenänderungsmaterial (z.B. Chakogenid-Glas) benutzen, Byte-adressierbare nichtflüchtige Speichergeräte, ferroelektrische Datenspeicher, SiliziumOxid-Nitrid-Oxid-Silizium(SONOS)-Datenspeicher, Polymer-Datenspeicher (z.B. ferroelektrischer Polymer-Datenspeicher), ferroelektrischer Transistorspeicher mit wahlfreiem Zugriff (Fe-TRAM), ovonischer Datenspeicher, Nanodraht-Datenspeicher, elektrisch löschbarer programmierbarer Festwertspeicher (EEPROM), andere verschiedene Typen von nichtflüchtigen Direktzugriffsspeichern (RAMs) und Datenspeicher mit magnetischem Speicher. In einigen Ausführungsformen kann ein 3D-Crosspoint-Speicher eine stapelbare Crosspoint-Architektur mit weniger Transistor sein, in der Speicherzellen an der Schnittstelle von Wortleitungen und Bitleitungen sitzen und einzeln adressierbar sind und in der ein Bitspeicher auf einer Änderung des Volumenwiderstands basiert. In bestimmten Ausführungsformen kann ein Speichermodul mit nichtflüchtigem Speicher einem oder mehreren Standards entsprechen, die von dem Joint Electron Device Engineering Council (JEDEC) erlassen wurden, wie etwa JESD218, JESD219, JESD220-1, JESD223B, JESD223-1 oder anderen geeigneten Standards (die JEDEC-Standards, die hierin zitiert werden, sind auf www.jedec.org abrufbar).
  • Flüchtige Speicher sind Speichermedien, die Energie erfordern, um den Datenzustand aufrechtzuerhalten, der in dem Medium gespeichert ist. Beispiele für flüchtige Speicher können verschiede Typen von Direktzugriffsspeichern (RAM) umfassen, wie etwa dynamische Direktzugriffsspeicher (DRAM) oder statische Direktzugriffsspeicher (SRAM). Ein bestimmter Typ von DRAM, der in einem Speichermodul genutzt werden kann, ist synchroner dynamischer Direktzugriffsspeicher (SDRAM). In bestimmten Ausführungsformen entspricht der DRAM der Speichermodule einem Standard, der vom JEDEC erlassen wurde, wie etwa JESD79F für Doppelte Datenrate (DDR) SDRAM, JESD79-2F für DDR2 SDRAM, JESD79-3F für DDR3 SDRAM oder JESD79-4A für DDR4 SDRAM (diese Standards sind auf www.jedec.org verfügbar). Diese Standards (und ähnliche Standards) können als DDR-basierte Standards bezeichnet werden und Kommunikationsschnittstellen von Speichergeräten, die diese Standards umsetzen, können als DDR-basierte Schnittstellen bezeichnet werden.
  • Das Rack-Scale-System benutzt diese Rechenknoten und Speicherknoten (nichtflüchtigen Speicher, SATA und NVM-Express(NVMe)-Speichergeräte usw.), um ein System basierend auf Benutzerbedürfnissen zusammenzustellen. In Ausführungsformen, die unten beschrieben werden, wird auf NVMe-Speichergeräte in Speicherknoten (auch bekannt als Speicher-Pool-Einschübe) von Rechenplattformen über einen Fabric mit niedriger Latenz unter Verwendung eines NVMe-Over-Fabric(NVMe-OF)-Protokolls zugegriffen. In Verbindung mit dem Zugriff auf NVMe-Speichergeräte über den Fabric, sind NVMe-Geräte hergestellt, um einem Betriebssystem als lokal angebundene Geräte (d.h. an die Rechenplattformen angebunden) angezeigt zu werden, auf die durch bestehende Software zugegriffen werden kann, wie etwa Anwendungen, ohne eine Änderung der Software zu erfordern. Wie unten ausführlich beschrieben wird, wird die vorangegangene Funktionalität über ein auf Hardware basierendes Schema, ein primär auf Software basierendes Schema und ein kombiniertes Hardware- und Firmware-Schema implementiert.
  • Ein Überblick, der NVMe-Speicheraspekte des Konzepts darstellt, wird in 5 gegeben. Unter dem Mechanismus ist jeder von mehreren Rechenknoten, wie etwa Servern 500, befähigt, auf NVMe-Speichergeräte 502-1 ... 502-6 in einem Speicher-Pool-Einschub 704 über einen Fabric 506 und einen Fabric-Switch 508 zuzugreifen. Speicher-Pool-Einschub 704 weist ferner einen Speicherverteiler 510 mit einem Fabric-Anschluss 512 und einer NVMe-Treiberschnittstelle 514 auf. Ein PSME 516 ist auch an einen Speicherverteiler 510 gekoppelt; im Allgemeinen kann der PSME entweder in einem Speicher-Pool-Einschub (wie gezeigt) integriert sein oder außerhalb des Speicher-Pool-Einschubs liegen.
  • In einer Ausführungsform umfasst der Fabric mit niedriger Latenz einen INTEL® Omni-Path-Fabric, der die INTEL® Omni-Path Architecture (OPA) einsetzt. OPA setzt eine Host-Fabric-Schnittstelle (HFI) an jedem Fabric-Endpunkt und einen Fabric-Switch ein, der benutzt wird, um Fabric-Pakete entlang von Strecken zwischen Fabric-Endpunkten weiterzuleiten. In einer anderen Ausführungsform umfasst der Fabric mit niedriger Latenz ein Ethernet-Netzwerk, das Hochgeschwindigkeitsethernetverbindungen (z.B. 100 Gigabit pro Sekunde) und Ethernet-Switches benutzt. Zur besseren Darstellung sind Fabric-Switches gezeigt, die je nach Implementierungskontext Omni-Path-Fabric-Switches oder Ethernet-Switches entsprechen. Zusätzlich zu Omni-Path- und Ethernet-Fabrics können andere existierende und zukünftige Netzwerktechnologien in einer ähnlichen Weise zu der benutzt werden, die hierin beschrieben und dargestellt ist.
  • Zusätzlich zur Verwendung von NVMe-Speichergeräten in Speicher-Pool-Geräten können Ausführungsformen Nicht-NVMe-Speichergeräte in Kombination mit NVMe-Gerätemulation benutzen. Eine Ausführungsform dieses Ansatzes ist in 5a gezeigt, die der Ausführungsform ähnelt, die in 5 gezeigt ist, ausgenommen den folgenden Unterschieden. Speicher-Pool-Einschub 504 wurde durch einen Speicher-Pool-Einschub 504a ersetzt, der Speichergeräte 503-1 ... 503-6 aufweist. Im Allgemeinen können verschiedene Typen von Speichergeräten benutzt werden, einschließlich, aber nicht nur, Solid-State-Festplatten (SSDs), Magnetplattenlaufwerke und optische Speichergeräte. Speicher-Pool-Einschub 504a weist ferner einen Speicherverteiler 510a auf, der eine Speichergerätschnittstelle 514a aufweist, die konfiguriert ist, um eine Schnittstelle zu Speichergeräten 503-1 ... 503-6 herzustellen.
  • Nach einem Aspekt eines Nicht-NVMe-Speichergeräteschemas wird Software- und/oder Firmware, die NVMe-Emulation bereitstellt, entweder am Speicherverteiler 510a, in Servern 500 oder einer Kombination der beiden implementiert (d.h. ein Teil der NVMe-Emulation wir durch Software und/oder Firmware in einem Server 500 durchgeführt und ein anderer Teil wird durch Software und/oder Firmware in Speicherverteiler 510a durchgeführt). Bei einer emulierten NVMe-Speichergerätimplementierung befähigt die NVMe-Emulation eine bestehende NVMe-Software, wie etwa NVMe-Gerätetreiber, die auf einem Server laufen, auf Nicht-NVMe-Speichergeräte über Fabric 506 zuzugreifen, ohne jegliche Änderungen an den NVMe-Gerätetreibern zu erfordern.
  • Eine beispielhafte NVMeOF-Speicherarchitektur 600, die einer Ausführungsform einer Implementierung in einer RSD-Umgebung entspricht, ist in 6 gezeigt. NVMeOF-Speicherarchitektur 600 weist mehrere CPU-Schlitten 602-1 - 602-M auf, die auch als Schlitten 1, Schlitten 2 ... Schlitten M gekennzeichnet sind. Jeder CPU-Schlitten 602 weist einen oder mehrere Rechenknoten 604 auf, die eine oder mehrere CPUs und Speicher und eine HFI 606 aufweisen. Jeder CPU-Schlitten 602 ist mit einem PSME 610 über eine Hochgeschwindigkeitsverbindung 612 verbunden, wie etwa eine Hochgeschwindigkeitsethernetverbindung oder eine SiPh optische Verbindung.
  • Jede HFI 606 ist mit einem OPA-Fabric verbunden, der mehrere Fabric-Verbindungen 614 und einen Fabric-Switch 616 aufweist. Der OPA-Fabric ermöglicht eine Hochgeschwindigkeitskommunikation mit niedriger Latenz zwischen Rechenknoten 604 und einem Paar Speicher-Pool-Einschüben 618-1 und 618-2. Jeder Speicher-Pool-Einschub 618-1 und 618-2 weist eine HFI 620 und einen Speicherverteiler 622 auf, der an mehrere NVMe-Speichergeräte 624 über eine PCIe-Verbindungshierarchie gekoppelt ist. Ein Speicher-Pool-Einschub kann auch eine CPU 626 aufweisen. In einer Ausführungsform ist ein Speicherverteiler als System auf einem Chip implementiert, der eine CPU (nicht gezeigt) aufweist. Jeder Speicher-Pool-Einschub 618-1 und 618-2 ist an einen jeweiligen PSME 628 und 630 gekoppelt, während PSMEs 610, 628 und 630 mit einem POD-Manager 632 verbunden sind.
  • 6a zeigt eine Ausführungsform mit NVMeOF-Speicherarchitektur 600a, die einen Hochgeschwindigkeitsethernet-Fabric anstatt des OPA-Fabrics benutzt, der in 6 gezeigt ist. Im Allgemeinen ähneln sich Aspekte von NVMeOF-Speicherarchitekturen 600 und 600a, ausgenommen von den Unterschieden, die Komponenten mit einem angehängten ,a' an ihren Bezugszeichen entsprechen. Diese Komponenten umfassen CPU-Schlitten 602a-1 - 602a-M, die jetzt Netzwerkschnittstellensteuerungen (NICs) 606a anstatt HFIs 606 aufweisen, einen Ethernet-Switch 616a anstatt von Fabric-Switch 616, und Speicher-Pool-Einschübe 618a-1 und 618a-2, die jetzt NICs 620a anstatt HFIs 620 aufweisen.
  • Zusätzlich zu den gezeigten Fabrics können auch andere Fabric-Typen verwendet werden, einschließlich InfiniBand- und Gen-Z-Fabrics. Im Allgemeinen würden die primären Unterschiede aus der Ersetzung von InfiniBand Host Controller Adaptors (HCAs) anstelle der dargestellten Fabric Controller für InfiniBand-Fabrics und Gen-Z-Schnittstellen anstelle der Fabric Controller für Gen-Z-Fabrics bestehen.
  • Beispielhafte Netzwerk-/Fabric Controller-Implementierung von NVMeOF unter Verwendung von VMD
  • 7 zeigt eine Ausführungsform einer auf Hardware basierenden Implementierung von NVMeOF unter Verwendung von VMD. Bei der Implementierung ist ein Rechenknoten 700 in Kommunikation mit einem Speicherknoten 702 über einen Fabric verbunden, der Fabric-Verbindungen 704 und 706 und einen Fabric-Switch 708 aufweist. Wie gezeigt ist, ist Rechenknoten 700 ein „Starter“, während Speicherknoten 702 ein „Ziel“ ist.
  • Rechenknoten 700 weist einen Prozessor 710 auf, der einen Kernabschnitt 712 aufweist, der mehrere Prozessorkerne 714 und PCle-Root-Controller 716 aufweist. Der Einfachheit halber sind zusätzliche Einzelheiten des Prozessors 710, Caches, Verbindungen, (eine) Speichersteuerung(en) und PCIe-Schnittstellen nicht gezeigt. PCIe-Root-Controller 716 ist an eine PCIe-basierte NVMe-Laufwerkschnittstelle 718 und an eine PCIe-basierte Netzwerkschnittstellensteuerung 720 gekoppelt.
  • Speicherknoten 702 ist im Allgemeinen darstellerisch für eine aggregierte Speichereinrichtung in der Systemarchitektur, wie etwa einen Speicher-Pool-Einschub unter RSD, und weist eine Netzwerkschnittstelle 722, einen Speicherverteiler 724 und eine NVMe-Laufwerkschnittstelle 726 auf, die an N NVMe-Speichergeräte gekoppelt ist, die NVMe-Speichergeräte 728, 730 und 732 umfassen. Speicherknoten 702 ist auch derart dargestellt, dass er einen optionalen Prozessor 734 mit einem oder mehreren Kernen 736 aufweist.
  • Im Allgemeinen kann ein gegebener Rechenknoten lokale und/oder entfernte Speicherressourcen benutzen. Wie hierin verwendet wird, ist eine „lokale“ Speicherressource ein Speichergerät, das direkt an einen Rechenknoten gekoppelt ist, wie etwa über eine Speichergerätschnittstelle. Im Gegensatz dazu entspricht ein „entferntes“ Speichergerät einem Speichergerät, auf das über einen Fabric zugegriffen wird, wie etwa Speichergeräte in Speicher-Pool-Einschüben. In der dargestellten Ausführungsform ist Rechenknoten 700 an zwei lokale NVMe-Speichergeräte 738 und 740 gekoppelt, die an NVMe-Laufwerkschnittstelle 718 gekoppelt sind. Diese NVMe-Speichergeräte sind auch mit NVMe L1 (lokal 1) und NVMe L2 (lokal 2) gekennzeichnet.
  • Rechenknoten 700 ist auch konfiguriert, um auf zwei virtuelle NVMe-Speichergeräte 742 und 744 zuzugreifen, die mit NVMe V1 (virtuell 1) und NVMe V2 (virtuell 2) gekennzeichnet sind. Hinsichtlich des Ausführens von Software auf Rechenknoten 700 sind virtuelle NVMe-Speichergeräte 742 und 744 lokale NVMe-Laufwerke, die direkt mit dem Rechenknoten verbunden sind. In Wirklichkeit sind virtuelle NVMe-Speichergeräte 742 und 744 jeweils physisch implementierte NVMe-Speichergeräte 728 und 730.
  • In der Ausführungsform von 7 ist die Virtualisierung von NVMe-Speichergeräten primär in Hardware als Teil einer eingebetteten Funktion in NIC 720 implementiert. Wie dargestellt ist, weist NIC 720 zwei eingebettete Funktionen auf: eine Netzwerkfunktion 746 und eine NVMe-Funktion 748. Netzwerkfunktion 746 umfasst eine eingebettete Logik und Funktionalität, die durch einen herkömmlichen NIC implementiert ist, um Netzwerk- oder Fabric-Vorgänge zu unterstützen. Zum Beispiel weist in einer Implementierung, bei der NIC ein Ethernet-NIC ist, Netzwerkfunktion 746 auf Hardware basierenden Einrichtungen zum Handhaben der physischen (PHY) und Medienzugriffskanal(MAC)-Schichten für das anwendbare Ethernet-Protokoll auf.
  • Die NVMe-Funktion entspricht einer hinzugefügten (zu dem NIC) Funktionalität, um eine Virtualisierung von NVMe-Speichergeräten zu unterstützen. Zum darstellerischen Zweck sind virtuelle NVMe-Speichergeräte 742 und 744 gezeigt, die mit NVMe-Funktion 748 verbunden sind; in Wirklichkeit gibt es keine NVMe-Speichergeräte, die mit NVMe-Funktion 748 verbunden sind. Gleichzeitig legt die NVMe-Funktion das Vorhandensein derartiger NVMe-Speichergeräte gegenüber einem Betriebssystem als Teil der aufgezählten PCIe-Gerätehierarchie frei.
  • Im Einzelnen wird während eines Systemstarts die PCIe-Geräte- und Verbindungshierarchie als Teil von herkömmlichen PCIe-Vorgängen aufgezählt. Jedes PCIe-Gerät im System wird aufgezählt und die Informationen, die den aufgezählten PCIe-Geräten entsprechen, werden dem Betriebssystem ausgesetzt, das auf dem Rechenknoten läuft. In der Ausführungsform von 7 weist die Software ein Betriebssystem (OS) 750 und einen NIC + NVMe-Treiber 752 auf. NIC + NVMe-Treiber sind als Softwareschnittstelle zwischen NIC 720 und OS 750 implementiert. Während des PCIe-Aufzählungsprozesses setzt NCI + NVMe-Treiber 752 (gegenüber OS 750) NIC 720 als zwei separate Geräte aus: 1) einen NIC, und 2) eine NVMe-Schnittstelle, die mit zwei lokalen NVMe-Speichergeräten verbunden ist.
  • Ein Abschnitt 751 der aufgezählten PCIe-Gerätehierarchie ist unten auf der linken Seite von 7 gezeigt und weist PCIe-Root-Controller 716, NVMe-Laufwerkschnittstelle 718, die mit lokalen NVMe-Laufwerken L1 und L2 verbunden ist, einen NIC 754 und eine NVMe-Laufwerkschnittstelle 756, die mit (virtualisierten) lokalen NVMe-Laufwerken L3 und L4 verbunden ist, auf. Daher ist hinsichtlich des Betriebssystems 750 Rechenknoten 700 direkt an vier lokale NVMe-Laufwerke L1, L2, L3 und L4 gekoppelt.
  • 7a zeigt eine Ausführungsform einer auf Hardware basierenden Implementierung von NVMeOF unter Verwendung von VMD, das einen Omni-Path-Fabric benutzt. Wie durch Komponenten angezeigt ist, die die gleichen Bezugszeichen teilen, ähneln sich die Ausführungsformen von 7 und 7a, mit dem primären Unterschied, dass in 7 ein Ethernet-Fabric eingesetzt wird und dass in 7a ein Omni-Path-Fabric eingesetzt wird.
  • Folglich ist bei der Ausführungsform von 7a ein Starter, der einen Rechenknoten 700a umfasst, kommunikativ an ein Ziel gekoppelt, das einen Speicherknoten 702a umfasst, über einen Omni-Path-Fabric, der Verbindungen 705 und 707 und einen Fabric-Switch 709 aufweist. NIC 720 wurde durch einen Fabric Controller 721 ersetzt und Netzwerkschnittstelle 722 wurde durch einen Fabric Controller 723 ersetzt. Wie ferner dargestellt ist, weist Fabric Controller 721 eine Netzwerkfunktion 746a und eine NVMe-Funktion 748a auf und ist an HFI 758 gekoppelt. Fabric Controller 723 ist an HFI 760 gekoppelt. Wie im linken unteren Teil von 7a gezeigt ist, weisen die Softwarekomponenten Betriebssystem 750, einen HFI + NVMe-Treiber 753 und einen aufgezählten PCIe-Hierarchieabschnitt 751a auf, der PCIe-Root-Controller 716, NVMe-Laufwerkschnittstelle 718, die mit lokalen NVMe-Laufwerken L1 und L2 verbunden ist, einen HFI/Fabric Controller 762 und eine NVMe-Laufwerkschnittstelle 756, die mit (virtualisierten) lokalen NVMe-Laufwerken L3 und L4 verbunden ist, aufweist. Wie bei der Ausführungsform von 7 ist hinsichtlich von Betriebssystem 750 Rechenknoten 700 direkt an vier lokale NVMe-Laufwerke L1, L2, L3 und L4 gekoppelt.
  • 7b zeigt eine Erweiterung zu der Ausführungsform von 7, die die Nutzung von Nicht-NVMe-Speichergeräten durch NVMe-Emulation unterstützt. Wie dargestellt ist, weist ein Speicherknoten 702b eine Speichergerätschnittstelle 726b auf, die an einen Speicherverteiler 724 gekoppelt (oder darin integriert) und an N Speichergeräte gekoppelt ist, die als Speichergeräte 729, 731 und 733 dargestellt sind. NVMe-Emulation ist durch NVMe-Emulationsblock 764 implementiert. Wie oben unter Bezugnahme auf 5a dargelegt wurde, kann NVMe-Emulation unter Verwendung von Software und/oder Firmware in einem Speicher-Pool-Einschub oder Speicherknoten, Software und/oder Firmware in einem Rechenknoten oder Server oder unter Verwendung einer Kombination aus beidem implementiert werden.
  • Zusätzlich zum Implementieren der NVMe-Funktion in einem NIC oder Fabric Controller ist in einer Ausführungsform die NVMe-Funktion in einem feldprogrammierbaren Gate-Array implementiert. Im Allgemeinen kann der FPGA entweder auf dem Prozessorsystem auf einem Chip (SoC) (z.B. einem eingebetteten IP-Block) oder als separate Komponente auf der Plattform implementiert werden. Bei einer Ausführungsform erscheint der FPGA (gegenüber der Software und/oder Komponenten auf der Plattform) als eines oder mehrere physisch angebrachte Speichergeräte, wie etwa eine oder mehrere SSDs. Zum Beispiel kann der FPGA an eine I/O-Schnittstelle „angebracht“ sein, wie etwa, aber nicht ausschließlich, eine PCle-Schnittstelle. Bei einer Ausführungsform einer PCle-Implementierung stellt der FPGA Aufzählungsinformationen während des Plattformstartens bereit, die anzeigen, dass er eine Speichergerätsteuerung ist, die mit einem oder mehreren Speichergeräten verbunden ist. In Wirklichkeit ist der FPGA jedoch nicht mit einem beliebigen Speichergerät verbunden, sondern weist eine Speichervirtualisierungslogik auf, um eine NVMe-Funktion zu implementieren, um auf entfernte Speichergeräte in entfernten Speicherknoten zuzugreifen, auf die über den Fabric zugegriffen wird.
  • 7c zeigt einen Rechenknoten 700c, der einen FPGA 749 aufweist, in dem eine NVMe-Funktion748c implementiert ist. Wie gezeigt ist, setzt der FPGA 749 virtuelle NVMe-Speichergeräte 742 und 744 der Plattform aus, während sich die tatsächlichen physischen Speichergeräte in Speicherknoten 702 befinden. In der dargestellten Ausführungsform ist FPGA mit PCIe-Root-Controller 716 verbunden (es wird angemerkt, dass der FPGA mit einem Root-Anschluss (nicht gezeigt) verbunden sein kann, der wiederum mit dem PCIe-Root-Controller verbunden ist). In einer Ausführungsform ist die Verbindung zwischen PCIe-Root-Controller (oder einem PCIe-Root-Anschluss) und FPGA 749 eine PCIe-Verbindung 751. Andere Verbindungstypen zwischen Prozessor 710 und FPGA 749 können implementiert werden, die auch eine Universal-Path-Interconnect(UPI)-Verbindung, eine Intel®-Accelerator-Verbindung und eine Gen-Z-Verbindung umfassen. Optional kann es eine Verbindung zwischen FPGA 749 und dem NIC 720c geben, wie durch eine optionale Verbindung 753 dargestellt ist.
  • Im Allgemeinen kann FPGA im Werk programmiert werden oder er kann während eines Systemstarts oder während einer Laufzeit unter Verwendung von bekannten Techniken zum Programmieren von FPGAs und ähnlichen programmierbaren Logikgeräten programmiert werden. Zum Beispiel wird in einem Ansatz ein Bitstrom für den FPGA heruntergeladen, wobei der Bitstrom Anweisungen zum Programmieren der Gates in dem FPGA enthält.
  • Beispielhafte Prozessor-basierte Implementierung von NVMeOF unter Verwendung von VMD
  • Gemäß den Aspekten einiger Ausführungsformen werden Volumenverwaltungsgerät(VMD)-Komponenten benutzt, um einen Speicherzugriff zu virtualisieren. VMD ist eine neue Technologie, die verwendet wird, um eine PCIe-Verwaltung zu verbessern. VMD ordnet die gesamten PCIe-Bäume seinem eigenen Adressraum zu, der durch einen VMD-Treiber gesteuert wird und im BIOS aktiviert ist (zu einer x4 Root-Anschluss-PCIe-Granularität in einer Ausführungsform). Das Betriebssystem zählt die VMD-Geräte auf und die OS-Aufzählung für die angebrachten untergeordneten Geräte endet dort. Eine Steuerung der Gerätedomäne geht an einen VMD-Gerätetreiber weiter, der von untergeordneten Geräten unabhängig ist. Ein VMD-Treiber richtet die Domäne (Aufzählen von untergeordneten Geräten) ein und räumt den Weg des Fast Path für untergeordnete Geräte. Ein VMD-Treiber kann zusätzliche untergeordnete Gerätetreiber laden, die sich dem VMD bewusst sind, gegenüber den jeweiligen untergeordneten Geräten.
  • Unterbrechungen durch untergeordnete Geräte werden von dem Betriebssystem als VMD-Unterbrechungen erfasst und zuerst an die Interrupt Service Routine (ISR) des VMD-Treiber weitergeleitet. Ein VMD-Treiber kann das Signal an die ISR des entsprechenden Treibers des untergeordneten Geräts neu ausgeben.
  • Eine Architektur und ein zugeordnetes Prozessdiagramm 800 für eine Ausführungsform einer VMD-Implementierung ist in 8 gezeigt. Die Architektur ist in einen Softwareabschnitt geteilt, der in dem oberen Teil des Diagramms dargestellt ist, und in einen Hardwareabschnitt, der in dem unteren Teil des Diagramms dargestellt ist. Der Softwareabschnitt weist einen Standard-NIC-Treiber 802 und einen NVMe-VMD-Treiber 804 auf. Der NVMe-VMD-Treiber weist einen NIC-Treiber 806, einen NVMe-Treiber 808 und einen VMD-Treiber 810 auf. NVMe-VMD-Treiber 804 kann auch optionale Leistungssteigerungen 811 aufweisen.
  • Der Hardwareabschnitt von Diagramm 800 stellt einen „Nichtkern“ 812 dar, der im Allgemeinen den Abschnitt eines Prozessors SoC aufweist, der kein Teil des Prozessorkerns ist, der die Prozessorkerne und Prozessor-Caches aufweist (z.B. Caches von Ebene 1 und Ebene 2). Nichtkern 812 weist einen VMD-Block 814, eine Brücke 816 und drei PCIe-Root-Anschlüsse (RPs) 818, 820 und 822 mit 4 Leitungen (x4) auf. Nichtkern 812 weist ferner einen PCIe-Root-Komplex auf, der nicht gezeigt ist, um Verwirrungen zu vermeiden.
  • Der Hardwareabschnitt weist ferner einen NIC 824 und eine NVMe-Solid-State-Festplatte (SSD) 826 auf. NIC 824 weist zwei Funktionen 828 und 830 auf, die jeweils mit „Func0“ und „Func1“ bezeichnet sind. NIC 824 weist ferner einen Ethernet-Anschluss auf, der mit einem Ethernet-Fabric 834 über eine Ethernet-Verbindung 836 verbunden ist. Der Hardwareabschnitt weist auch Plattform-Firmware (FW) auf, die einen NVMe/VMD-Unified-Extensible-Firmware-lnterface(UEFI)-Treiber 838 aufweist.
  • Eine Ausführungsform eines Vorgangs zum Konfigurieren eines Rechenknotens (z.B. Server), der als Starter arbeitet und die Architektur von Diagramm 800 einsetzt, geht wie folgt vor, wobei Vorgänge durch eingekreiste Nummern 1-4 dargestellt sind. In einem ersten Vorgang ist ein PCIe-Root-Anschluss mit 8 Leitungen (x8) automatisch in zwei Root-Anschlüsse mit 4 Leitungen verzweigt. Wie dargestellt ist, ist der x4 Root-Anschluss 818 mit FuncO verbunden, während x4 Root-Anschluss 820 mit Func1 von NIC 824 verbunden ist. Dies befähigt Funcl unter VMD 814 zu sein und FuncO Standard-NIC-Treiber 820 zu nutzen, wodurch NIC 820 befähigt wird, Standard-NIC-Vorgänge zu unterstützen.
  • In einem zweiten Vorgang reagiert NVMe-VMD-UEFI-Treiber 838 auf eine Starterentdeckung. NVMe-VMD-UEFI-Treiber 838 ist eine Erweiterung der Firmware der Plattform und als Teil der UEFI-Firm geladen, die auf der Plattform während Startvorgängen bereitgestellt wird. Während des Vorgangs speichert NVMe-VMD-UEFI-Treiber 838 die MAC-Adresse des Starters in einem Flash-Speicher (nicht gezeigt). NVMe-VMD-UEFI-Treiber 838 setzt auch VMD 814 dem Betriebssystem aus.
  • Nach dem UEFI-Firmwareladen werden Betriebssystem-Startvorgänge eingeleitet, die ein Laden von auf Software basierenden Treibern umfassen. Wie in Vorgang ,3' gezeigt ist, sieht das OS den VID/DID (virtueller Identifizierer, Geräteidentifizierer) von VMD 814 und lädt NVMe-VMD-Treiber 804. Der NVMe-VMD-Treiber abstrahiert den inneren Betrieb der NVMe-Virtualisierung von den Softwarenutzern (d.h. Softwarekomponenten, die benutzt werden, um auf ein NVMe-Speichergerät zuzugreifen). Die Abstrahierung wird in einer Weise durchgeführt, die keine Änderungen am bestehenden Benutzercode erfordert. Beim Laden zählt der NVMe-VMD-Treiber 804 die VMD-Domäne (für VMD 814) auf. Er findet NIC 824, Brücke 816 und NVMe-SSD 826 und lädt jeweilige Softwaretreiber (nicht gezeigt). NVMe-VMD-Treiber 804 kann auch optionale Leistungssteigerungen 811 laden (falls sie unterstützt werden).
  • 8a zeigt ein System, das die Komponenten von Architektur 800 aufweist, die in einem Starter 840 implementiert sind, der an ein Ziel kommunikativ gekoppelt ist, das einen Speicherknoten 702 umfasst, über einen Fabric, der einen Fabric-Switch 709 aufweist. Wie bei vorherigen Ausführungsformen kann Starter 840 sowohl auf lokale NVMe-SSD 826 als auch entfernte NVMe-Laufwerke zugreifen, während er die entfernten NVMe-Laufwerke als lokale Speichergeräte aussetzt. Zum Beispiel, wie durch die I/O-Hierarchie 841 gezeigt ist, „sieht“ das Betriebssystem einen PCI-Root-Controller 842, an den NIC 824 und VMD 814 gekoppelt sind. Wie ferner gezeigt ist, erscheinen dem Betriebssystem jede SSD 826 und die zwei entfernten NVMe-Laufwerke 1 und 2 als lokale NVMe-Laufwerke 844 und 846.
  • 9 zeigt ein Flussdiagramm 900, das Vorgänge darstellt, die während einer Initialisierung von Rechenknoten gemäß einer Ausführungsform durchgeführt werden. In einem Block 902 wird die Hardware des Rechenknotens initialisiert. Während dieses Prozesses wird die Firmware des Rechenknotens geladen und ein Kommunikationskanal wird konfiguriert, der nicht erfordert, dass ein Betriebssystem auf dem Rechenknoten läuft. Dies ermöglicht, die Konfigurationsinformationen der Speicherressource an den Rechenknoten zu kommunizieren.
  • In einem Block 904 werden die Rechenknotenressourcen zusammengestellt, einschließlich einer Zuordnung von entfernten Speichergeräten. Zum Beispiel wird bei einem Prozessfluss ein IaaS-Kunde die Nutzung eines Rechenknotens mit bestimmten Ressourcen anfragen und der Rechenknoten wird durch den POD-Manager zusammengestellt. In einem Block 906 kommuniziert der POD-Manager Ressourcenkonfigurationsinformationen an den PSME, der an den Rechenknoten angebracht ist (oder andersartig an den Rechen-Pool-Einschub für den Rechenknoten kommunikativ gekoppelt ist). Der PSME kommuniziert dann die Ressourcenkonfigurationsinformationen an die Firmware, die auf der Rechenknotenhardware läuft, über den Kommunikationskanal, der in Block 904 eingerichtet ist.
  • In einem Block 904 konfiguriert die Firmware eine Starter-Ziel-Gerätezuordnung. Diese enthält Informationen zum Zuordnen von entfernten Speichergeräten als lokale Speichergeräte für den Rechenknoten. In einem Block 910 wird das OS gestartet. Nachfolgend werden die entfernten Speichergeräte, die dem Rechenknoten zugeordnet sind, dem OS als lokale NVMe-Geräte ausgesetzt.
  • Es wird angemerkt, dass der Prozessfluss in Flussdiagramm 900 beispielhaft und nicht beschränkend ist. Zum Beispiel wird in einer anderen Ausführungsform die Starter-Ziel-Konfigurationszuordnung durch einen auf Software basierenden Treiber anstatt einer Firmwareeinrichtung behalten. Zum Beispiel behält bei Architektur 800 der NVMe-VMD-Treiber 804 die Starter-Ziel-Zuordnungsinformationen.
  • Beispielhafte Firmware-Speicher-Virtualisierungsschicht-Implementierung von NVMeOF unter Verwendung von VMD
  • Gemäß den Aspekten einiger Ausführungsformen wird eine auf Firmware basierende Erweiterung benutzt, um eine Speicher-Virtualisierungsschicht zu unterstützen, die physische Speichergeräte abstrahiert und sie als virtuelle Geräte einem Ausführen von Software auf dem Rechenknoten aussetzt. Eine Ausführungsform dieses Schemas ist in 10 gezeigt, die einen Rechenknoten 1000 aufweist, der einen Starter umfasst, der an Speicherknoten 1002 über einen Fabric gekoppelt ist, der Fabric-Verbindungen 704 und 706 und einen Fabric-Switch 708 aufweist. Wie durch gleich nummerierte Komponenten in 7 und 10 dargestellt ist, weist Rechenknoten 100 einen Prozessor 710 mit einem Kern 712 mit mehreren Kernen 714 und einen PCIe-Root-Controller 716 auf, an den eine PCIe-basierte NVMe-Laufwerkschnittstelle 718 gekoppelt ist. Wie ferner gezeigt ist, sind ein Paar lokaler NVMe-Laufwerke 738 und 740 an NVMe-Laufwerkschnittstelle 718 gekoppelt.
  • Rechenknoten 1000 weist ferner Plattform-Firmware mit einer Speichervirtualisierungserweiterung 1004 auf. Diese ist eine auf Firmware basierende Komponente, die eine Abstraktionsschicht zwischen lokalen und entfernten physischen Speichergeräten durch Virtualisieren der Speichergeräte implementiert, wobei sie einem Ausführen von Software auf dem Rechenknoten ausgesetzt werden, wie etwa einem Betriebssystem, als lokale NVMe-Speichergeräte. Wie ferner gezeigt ist, weist die Plattform-Firmware mit einer Speichervirtualisierungserweiterung 1004 eine Starter-Ziel-Konfigurationszuordnung 1006 auf, die Informationen zum Zuordnen von virtuellen Laufwerken zu ihren physischen Gegenstücken aufweist.
  • Speicherknoten 1002 ähnelt Speicherknoten 702 und weist eine Netzwerkschnittstelle 722, einen Speicherverteiler 724 und eine NVMe-Laufwerkschnittstelle 726 auf, an die mehrere NVMe-Speichergeräte gekoppelt sind, wie durch NVMe-Laufwerke 1008, 1010 und 1012 dargestellt ist. Wie zuvor kann Speicherknoten 1002 ferner einen optionalen Prozessor 734 aufweisen. Speicherknoten 1002 weist auch eine Starter-Ziel-Konfigurationszuordnung 1014 auf.
  • Wie oben dargelegt wurde, virtualisiert die Plattform-Firmware mit Speichervirtualisierungserweiterung die physischen Speicherressourcen und setzt sie als lokale NVMe-Speichergeräte einem Ausführen von Software auf der Plattform aus. In der Ausführungsform von 10 weist die Software einen Typ-1-Hypervisor 1016 auf. Die Typ-1-Hypervisor, die auch als „Bare-Metal“-Hypervisor bekannt sind, laufen direkt auf Plattformhardware ohne ein Betriebssystem und werden benutzt, um die physischen Ressourcen der Plattform zu abstrahieren. Wie ferner gezeigt ist, hostet Hypervisor 1016 mehrere virtuelle Maschinen, die als VM1 ... VMN dargestellt sind. Jede der VM1 und VMN arbeitet mit einem jeweiligen Betriebssystem, das einen NVMe-Treiber 1018 aufweist, der Teil des Betriebssystemkernels (K) ist, und betreibt eine oder mehrere Anwendungen in dem Benutzerraum (U) des Betriebssystems.
  • Bei der Ausführungsform von 10 werden virtuelle Maschinen anstatt physischen Rechenknoten zusammengestellt. Wie zuvor wird dies in einer Ausführungsform durch den POD-Manager und einen PSME ermöglicht, der an den Rechenknoten kommunikativ gekoppelt ist. Des Weiteren, während einer Initialisierung der Rechenknotenhardware, wird ein Kommunikationskanal konfiguriert, der dem PSME erlaubt, Konfigurationsinformationen zu Plattform-Firmware mit Speichervirtualisierungserweiterung 1004 zu fördern. Dies umfasst eine Zuordnung von lokalen und entfernten Speicherressourcen zu den virtuellen Maschinen VM1 ... VMN.
  • Wie in der 10 gezeigt ist, wurden lokales NVMe-Laufwerk 738 und entferntes NVMe-Laufwerk 1008 VM1 als lokale virtuelleNVMe-Laufwerke 1020 und 1022 zugeordnet. In der Zwischenzeit wurden lokales NVMe-Laufwerk 740 und entfernte NVMe-Laufwerke 1010 und 1012 VMN als virtuelleNVMe-Laufwerke 1024, 1026 und 1028 zugeordnet. In Verbindung mit der Zuordnung von physischen Speicherressourcen zu virtuellen Maschinen werden jede Starter-Ziel-Konfigurationszuordnung 1006 und Starter-Ziel-Konfigurationszuordnung 1014 mit Zuordnungen zwischen den virtuellen NVMe-Laufwerken und entfernten NVMe-Laufwerken aktualisiert, auf die über das Ziel (Speicherknoten 1002) zugegriffen wird.
  • Die primäre Nutzung von Starter-Ziel-Konfigurationszuordnung 1006 ist die Zuordnung von Speicherzugriffsanfragen von den NVMe-Treibern 1018 an entfernte NVMe-Laufwerke. Intern werden die Speicherzugriffsanfragen in Fabric-Paketen eingekapselt, die an das Ziel über den Fabric gesendet werden. Für einen Ethernet-Fabric werden diese Anfragen in Ethernet-Paketen eingekapselt, die über den Ethernet-Fabric über Ethernet-Rahmen übertragen werden. Für andere Fabric-Typen werden Speicherzugriffsanfragen in dem Fabric-Paket/Rahmen eingekapselt, das/der auf den Fabric anwendbar ist.
  • Die Zuordnungsinformationen in Starter-Ziel-Konfigurationszuordnung 1014 werden an dem Ziel für einen anderen Zweck genutzt. Das Ziel benutzt die Starter-Ziel-Zuordnungsinformationen, um sicherzustellen, dass auf jedes der Speichergeräte des Ziels nur durch die VM(s) zugegriffen werden kann, denen jedes Speichergerät zugeordnet wurde. Zum Beispiel, in der Konfiguration, die in 10 gezeigt ist, wenn VM1 versucht, auf entferntes NVMe-Laufwerk 1010 zuzugreifen, würde das Ziel die Zuordnungsinformationen in Starter-Ziel-Konfigurationszuordnung 1014 prüfen, bestimmen, dass VM1 kein erlaubter Starter für entferntes NVMe-Laufwerk 1010 ist, und die Zugriffsanfrage ablehnen.
  • 10a zeigt eine Ausführungsform, die der ähnelt, die in 10 gezeigt und oben dargelegt wird, mit Ausnahme davon, dass die Funktionalität von Plattform-Firmware mit einer Speichervirtualisierungserweiterung 1004 jetzt als Software-Speichervirtualisierungserweiterung 1004a in einem Hypervisor 1106 implementiert ist, der Teil der Plattformsoftware ist anstatt der Plattform-Firmware. In einer Weise, die der oben Beschriebenen ähnelt, wird eine Starter-Ziel-Konfigurationszuordnung 1006 durch Software-Speichervirtualisierungserweiterung 1004a aufrechterhalten. Wie zuvor, bezüglich Betriebssystem 1 ... N, werden virtuelleNVMe-Laufwerke 1022, 1026 und 1028 lokalen Speichergeräten ausgesetzt.
  • Zusätzlich zum Unterstützen von virtuellen Maschinen unter Verwendung der Plattform-Firmware mit Speichervirtualisierungserweiterungsschema werden auch Behälterbasierte unterstützt. Ein Ausführungsbeispiel einer Implementierungsarchitektur ist in 11 gezeigt. Wie dargestellt ist, sind alle Hardwarekomponenten (einschließlich Firmware) gleich. Die primären Unterschiede zwischen den Ausführungsformen von 10 und 11 sind, dass Hypervisor 1016 mit einer OS-Virtualisierungsschicht 1100 ersetzt wurde und VM1 ... VMN mit Behälter1 ... BehälterN ersetzt wurden. In der dargestellten Ausführungsform ist die OS-Virtualisierungsschicht 1100 auf der Plattformhardware in einer Weise laufend dargestellt, die einem Typ-1-Hypervisor ähnelt. In einem alternativen Schema kann ein Betriebssystem (nicht gezeigt) auf der Plattformhardware laufen, wobei die OS-Virtualisierungsschicht auf dem Betriebssystem läuft. In diesem Fall ist die Speicherabstraktion zwischen Plattform-Firmware mit Speichervirtualisierungserweiterung 1004 und dem Betriebssystem anstatt zwischen der Plattform-Firmware mit Speichervirtualisierungserweiterung 1004 und der OS-Virtualisierungsschicht.
  • 11a zeigt eine Erweiterung des Schemas in 11, wobei die Funktionalität von Plattform-Firmware mit Speichervirtualisierungserweiterung 1104 als Software-Speichervirtualisierungserweiterung 1004b implementiert ist, die in einer OS-Virtualisierungsschicht 1100a implementiert ist, die Teil der Plattformsoftware ist.
  • 12 zeigt ein Flussdiagramm 1200, das Vorgänge und Logik zum Umsetzen eines Zugriffsschemas eines virtualisierten Speichers darstellt, das mit einer oder mehreren der Ausführungsformen benutzt werden kann, die oben ausgeführt sind. In einem Block 1202 wird eine Lese- oder Schreib-Speicherzugriffsanfrage von einem Betriebssystem-NVMe-Treiber empfangen. In einem Block 1204 wird die Anfrage von der Speichervirtualisierungseinrichtung auf der Plattformhardware oder -software empfangen. Zum Beispiel ist in der Ausführungsform von 7, 7a, 7b und 10 und 11 die Einrichtung, die die Anfrage empfängt, eine auf Firmware basierende Einrichtung, während in den Ausführungsformen von 8 und 8a, 10a und 11a die Einrichtung eine auf Software basierende Einrichtung ist. In der Ausführungsform von 7c ist die Speichervirtualisierungseinrichtung in FPGA 749 implementiert.
  • In einem Block 1206 wird eine Speichergerätsuche durchgeführt, um zu bestimmen, ob das Speichergerät, auf das zuzugreifen ist, ein lokales Gerät oder ein entferntes Gerät ist. In einer Ausführungsform weist die Starter-Ziel-Zuordnung Zuordnungsinformationen für lokale Speichergeräte sowie entfernte Speichergeräte auf und diese Zuordnungsinformationen werden benutzt, um das Speichergerät und seinen Ort zu bestimmen. Wie in einem Entscheidungsblock 1208 gezeigt ist, wird eine bestimmt, ob das Speichergerät lokal oder entfernt ist. Wenn es ein lokales Gerät ist, geht die Logik zu einem Block 1210 über, in dem auf das lokale Speichergerät zugegriffen wird. Wenn die Zugriffsanfrage eine Schreib-Anfrage ist, werden die Daten, die mit der Anfrage geliefert werden, auf das Speichergerät geschrieben. Wenn die Zugriffsanfrage eine Lese-Anfrage ist, werden die Daten von dem Speichergerät gelesen und wiederum an den NVMe-Treiber zurückgeleitet, um die Anfrage zu bearbeiten.
  • Wenn die Suche in Block 1206 erkennt, dass das Gerät ein entferntes Gerät ist, geht die Logik zu einem Block 1212 über, in dem das Ziel erkannt wird. Die Zugriffsanfrage wird dann in einem Fabric-Paket (oder mehreren Fabric-Paketen, wenn anwendbar) eingekapselt und das/die Fabric-Paket/e wird/werden von dem Starter über den Fabric zu dem Ziel, das identifiziert ist, gesendet. In einem Block 1214 wird die Anfrage von dem Ziel empfangen. Das Ziel entkapselt die Zugriffsanfrage und sucht den Starter in seiner Starter-Ziel-Zuordnung, um zu bestimmen, ob es dem Starter erlaubt ist, auf das Speichergerät zuzugreifen, das in der Anfrage identifiziert ist, wie durch einen Entscheidungsblock 1216 dargestellt ist. Wenn die Antwort NEIN ist, geht die Logik zu einem Endblock 1218 über, in dem der Zugriff verweigert wird. Als Option können Informationen, die die Anfrage als abgelehnt identifizieren, an den Anfrager (nicht gezeigt) zurückgeleitet werden.
  • Wenn der Zugriff gewährt wird, geht die Logik zu einem Entscheidungsblock 1220 über, in dem eine Bestimmung getroffen wird, ob die Zugriffsanfrage ein Lese- oder Schreibzugriff ist. Wenn es sich um Schreibzugriff handelt, geht die Logik zu Block 1222 über, in dem die Daten auf das anwendbare Speichergerät auf dem Ziel geschrieben werden. Wenn die Antwort zu dem Entscheidungsblock 1220 ein Lesezugriff ist, werden die Daten von dem anwendbaren Speichergerät gelesen und an den Starter in einem oder mehreren Fabric-Paketen zurückgeleitet, die über den Fabric gesendet werden, wie in Block 1224 gezeigt ist. Die Lesedaten in dem/n empfangenen Fabric-Paket/en werden dann in einem Block 1226 entkapselt und die Lesedaten werden zu dem OS-NVMe-Treiber zurückgeleitet, um die Leseanfrage zu bearbeiten.
  • In Bezug auf ein Zugreifen auf virtuelle NVMe-Speichergeräte 742 und 744 funktioniert die Ausführungsform von 7c in einer ähnlichen Weise wie der, die in Flussdiagramm 1200 dargestellt ist, mit dem folgenden Unterschied. Software, die auf dem Rechenknoten läuft, gibt eine Speichergerät-Lese- oder Schreib-Anfrage durch einen Speichergerättreiber oder dergleichen aus, um auf Daten zuzugreifen, die logisch auf einem von virtuellen NVMe-Speichergeräten 742 oder 744 gespeichert sind. Die Lese- oder Schreib-Anfrage wird über PCIe-Root-Controller 716 an FPGA 749 geleitet. Als Reaktion auf ein Empfangen der Anfrage erzeugt NVMe-Funktion 748c in FPGA 749 eine Netzwerknachricht, die die Netzwerkadresse von Speichermodus 702 als Ziel identifiziert, und umfasst die Lese- oder Schreibanfrage, die über den Fabric über NIC 720c zu senden ist. In einer Ausführungsform wird die Netzwerknachricht über die PCIe-Verbindungsstruktur auf Rechenknoten 700c geroutet. Alternativ wird die Netzwerknachricht über Verbindung 751 an NIC 720c gesendet. An dieser Stelle werden die Vorgänge von Blöcken 1212, 1214, 1216, 1218, 1220, 1222, 1224 und 1226 in einer ähnlichen Weise zu der durchgeführt, die oben beschrieben und in Flussdiagramm 1200 dargestellt ist.
  • Weitere Aspekte des Gegenstands, der hierin beschrieben wird, werden in den folgenden nummerierten Klauseln ausgeführt:
    1. 1. Verfahren, das durch einen Rechenknoten implementiert wird, der an einen entfernten Speicherknoten über einen Fabric kommunikativ gekoppelt ist, wobei der entfernte Speicherknoten mehrere entfernte Speichergeräte aufweist, auf die durch den Rechenknoten über den Fabric zugegriffen wird, wobei das Verfahren Folgendes umfasst:
      • Bestimmen eines oder mehrerer entfernter Speichergeräte, die dem Rechenknoten zugeordnet wurden, und
      • Aussetzen jedes des einen oder der mehreren entfernten Speichergeräte einem Ausführen von Software auf dem Rechenknoten als Speichergerät mit lokalem nichtflüchtigem Speicher-Express (NVMe).
    2. 2. Verfahren nach Klausel 1, das ferner ein Senden von Daten zwischen dem Rechenknoten und dem entfernten Speicherknoten unter Verwendung eines NVMe-Over-Fabric(NVMe-OF)-Protokolls umfasst.
    3. 3. Verfahren nach Klausel 1 oder 2, wobei jedes des einen oder der mehreren entfernten Speichergeräte, das dem Betriebssystem als lokales NVMe-Speichergerät ausgesetzt wird, ein entferntes NVMe-Speichergerät ist.
    4. 4. Verfahren nach einer der vorhergehenden Klauseln, wobei der Rechenknoten ein lokales NVMe-Speichergerät aufweist, auf das über einen NVMe-Treiber zugegriffen wird, der konfiguriert ist, um auf lokale NVMe-Speichergeräte zuzugreifen, und die Software ein Betriebssystem umfasst, das auf dem Rechenknoten läuft, ferner umfassend Ermöglichen des Betriebssystems, auf das eine oder die mehreren entfernten Speichergeräte über den NVMe-Treiber zuzugreifen.
    5. 5. Verfahren nach einer der vorhergehenden Klauseln, wobei die Software ein Betriebssystem umfasst, das auf physischer Rechenknotenhardware läuft, und wobei jedes des einen oder der mehreren entfernten Speichergeräte dem Betriebssystem als lokales NVMe-Speichergerät durch Verwendung einer auf Hardware basierenden Komponente in der physischen Rechenknotenhardware ausgesetzt wird.
    6. 6. Verfahren nach Klausel 5, wobei die auf Hardware basierende Komponente eine Netzwerkschnittstellensteuerung oder einen Fabric Controller umfasst.
    7. 7. Verfahren nach einer der vorhergehenden Klauseln, wobei die Software ein Betriebssystem umfasst, das auf physischer Rechenknotenhardware läuft, und wobei ein Aussetzen jedes des einen oder der mehreren entfernten Speichergeräte dem Ausführen von Software auf dem Rechenknoten als lokales NVMe-Speichergerät durch eine Kombination aus einer oder mehreren auf Hardware basierenden Komponenten in der physischen Rechenknotenhardware und einer oder mehreren auf Software basierenden Komponenten implementiert wird.
    8. 8. Verfahren nach Klausel 7, wobei die eine oder mehreren auf Software basierenden Komponenten einen NVMe-Volumenverwaltungsgerät(VMD)-Treiber aufweisen.
    9. 9. Verfahren nach Klausel 8, wobei der NVMe-VMD-Treiber einen Netzwerkschnittstellensteuerung(NIC)-Treiber, einen NVMe-Treiber und einen VMD-Treiber aufweist.
    10. 10. Verfahren nach Klausel 8, wobei der Rechenknoten einen Prozessor mit einer VMD-Komponente aufweist und wobei die eine oder mehreren auf Hardware basierenden Komponenten die VMD-Komponente aufweisen.
    11. 11. Verfahren nach einer der vorhergehenden Klauseln , das ferner Folgendes umfasst:
      • Virtualisieren einer physischen Speicherzugriffsinfrastruktur, die sowohl lokale als auch entfernte Speicherressourcen mit Plattform-Firmware aufweist, die eine Speichervirtualisierungserweiterung aufweist, und
      • Aussetzen über eines einer Plattform-Firmware, eines feldprogrammierbaren Gate-Arrays (FPGA) und einer auf Software basierenden Hypervisor- oder Betriebssystem-Virtualisierungsschicht, jedes des einen oder der mehreren entfernten Speichergeräte einem Ausführen von Software auf dem Rechenknoten als lokales NVMe-Speichergerät.
    12. 12. Rechenknoten, der konfiguriert ist, um in einer Rechenzentrumsumgebung implementiert zu sein, die mehrere Einschübe aufweist, die miteinander über einen Fabric verbunden sind, wobei die mehreren Einschübe einen Speicher-Pool-Einschub mit mehreren entfernten Speichergeräten aufweisen und über den Fabric an einen Rechenknoteneinschub kommunikativ gekoppelt sind, in dem der Rechenknoten konfiguriert ist, um installiert zu sein, wobei der Rechenknoten Folgendes umfasst:
      • einen Prozessor,
      • einen Speicher, der an den Prozessor gekoppelt ist, und
      • einen Fabric Controller oder eine Netzwerkschnittstellensteuerung (NIC), die an den Prozessor wirkgekoppelt und konfiguriert ist, um auf den Fabric zuzugreifen,
      • wobei, wenn der Rechenknoten in dem Rechenknoteneinschub installiert ist und arbeitet, der Rechenknoten konfiguriert ist, um jedes von einem oder mehreren der mehreren entfernten Speichergeräte einem Ausführen von Software auf dem Rechenknoten als Speichergerät mit lokalem nichtflüchtigem Speicher-Express(NVMe) auszusetzen.
      • 13. Rechenknoten nach Klausel 12, wobei der Rechenknoten konfiguriert ist, um mit dem Speicher-Pool-Einschub unter Verwendung eines NVMe-Over-Fabric(NVMe-OF)-Protokolls zu kommunizieren.
      • 14. Rechenknoten nach Klausel 12 oder 13, wobei jedes des einen oder der mehreren entfernten Speichergeräte, die der Software als lokales NVMe-Speichergerät ausgesetzt sind, ein entferntes NVMe-Speichergerät ist.
      • 15. Rechenknoten nach einer der Klauseln 12-14, wobei die Software ein Betriebssystem umfasst, das einen NVMe-Treiber aufweist, der konfiguriert ist, um auf lokale NVMe-Speichergeräte zuzugreifen, ferner umfassend:
        • mindestens ein lokales NVMe-Speichergerät,
        • wobei der Rechenknoten konfiguriert ist, um das mindestens eine lokale NVMe-Speichergerät und jedes des einen oder der mehreren entfernten Speichergeräte als mehrere lokale NVMe-Speichergeräte auszusetzen und den NVMe-Treiber einzusetzen, um auf jedes des mindestens einen lokalen NVMe-Speichergeräts und das eine oder die mehreren entfernten Speichergeräte zuzugreifen.
      • 16. Rechenknoten nach einer der Klauseln 12-14, wobei der Fabric Controller oder die NIC eingebettete Hardware aufweist, die konfiguriert ist, um das eine oder die mehreren entfernten Speichergeräte der Software als lokale NVMe-Speichergeräte auszusetzen.
      • 17. Rechenknoten nach einer der Klauseln 12-14, wobei der Rechenknoten eine Kombination aus einer oder mehreren auf Hardware basierenden Komponenten und einer oder mehreren auf Software basierenden Komponenten aufweist, die konfiguriert sind, um bei einem Starten eines Betriebssystems das eine oder die mehreren entfernten Speichergeräte dem Betriebssystems als ein lokales NVMe-Speichergerät auszusetzen.
      • 18. Rechenknoten nach Klausel 17, wobei die eine oder mehreren auf Software basierenden Komponenten einen NVMe-Volumenverwaltungsgerät(VMD)-Treiber umfassen.
      • 19. Rechenknoten nach Klausel 18, wobei der NVMe-VMD-Treiber einen Netzwerkschnittstellensteuerung(NIC)-Treiber, einen NVMe-Treiber und einen VMD-Treiber aufweist.
      • 20. Rechenknoten nach Klausel 18, wobei der Rechenknoten einen Prozessor mit einer VMD-Komponente aufweist und wobei die eine oder mehreren auf Hardware basierenden Komponenten die VMD-Komponente aufweisen.
      • 21. Rechenknoten nach Klausel 12, wobei der Rechenknoten ferner Folgendes umfasst:
        • Plattform-Firmware, die eine Speichervirtualisierungserweiterung aufweist, und
        • Software, die eine einer Hypervisor- oder Betriebssystem-Virtualisierungsschicht umfasst,
        • und wobei der Rechenknoten ferner konfiguriert ist, um
        • eine physische Speicherzugriffsinfrastruktur zu virtualisieren, die das eine oder die mehreren entfernten Speichergeräte aufweist, und
        • das eine oder die mehreren entfernten Speichergeräte der Hypervisor- oder der Betriebssystem-Virtualisierungsschicht als lokale NVMe-Speichergeräte auszusetzen.
      • 22. Rechenknoten nach einer der Klauseln 12-14, der ferner einen feldprogrammierbaren Gate-Array (FPGA) umfasst, der konfiguriert ist, um das eine oder die mehreren entfernten Speichergeräte der Software als lokale NVMe-Speichergeräte auszusetzen.
      • 23. Rechenknoten nach Klausel 12, wobei der Rechenknoten ferner Folgendes umfasst:
        • Software, die eine einer Hypervisor- oder Betriebssystem-Virtualisierungsschicht mit Speichervirtualisierungserweiterung umfasst, die konfiguriert ist, um
        • eine physische Speicherzugriffsinfrastruktur zu virtualisieren, die das eine oder die mehreren entfernten Speichergeräte aufweist, und
        • jedes des einen oder der mehreren entfernten Speichergeräte einem Betriebssystem in einer virtuellen Maschine oder Behälter, die von der Hypervisor- oder Betriebssystem-Virtualisierungsschicht gehostet sind, als lokale NVMe-Speichergeräte auszusetzen.
      • 24. System, das Folgendes umfasst:
        • mehrere Einschübe, die miteinander über einen Fabric verbunden sind, wobei die mehreren Einschübe einen Speicher-Pool-Einschub mit mehreren entfernten Speichergeräten aufweisen und über den Fabric an einen Rechenknoteneinschub kommunikativ gekoppelt sind, der mehrere Rechenknoten aufweist, wobei mindestens einer der mehreren Rechenknoten Folgendes aufweist:
          • einen Prozessor,
          • einen Speicher, der an den Prozessor gekoppelt ist, und
          • einen Fabric Controller oder eine Netzwerkschnittstellensteuerung (NIC), die an den Prozessor wirkgekoppelt und konfiguriert ist, um auf den Fabric zuzugreifen,
          • wobei, wenn der Rechenknoten arbeitet, der Rechenknoten konfiguriert ist, um jedes des einen oder der mehreren der mehreren entfernten Speichergeräte einem Ausführen von Software auf dem Rechenknoten als Speichergerät mit lokalem nichtflüchtigem Speicher-Express(NVMe) auszusetzen.
      • 25. System nach Klausel 24, das ferner Folgendes umfasst:
        • eine Recheneinschubverwaltungseinrichtung, die an den POD-Manager und Rechenknoten kommunikativ gekoppelt ist,
        • wobei das System ferner konfiguriert ist, um
        • eine Anfrage von einem Infrastructure-as-a-Service(IaaS)-Kunden zu erhalten, der die Nutzung von Rechenressourcen und Speicherressourcen anfragt, die über das System verfügbar sind,
        • einen Rechenknoten zu erstellen, um ein oder mehrere entfernte Speichergeräte als lokale NVMe-Treiber zu nutzen, und
        • Konfigurationsinformationen über die Recheneinschubverwaltungseinrichtung zu dem Rechenknoten zu kommunizieren, wobei eine Nutzung des einen oder der mehreren entfernten Speichergeräte als lokale NVMe-Laufwerke spezifiziert wird.
      • 26. System nach Klausel 24 oder 25, wobei der Rechenknoten konfiguriert ist, um auf das eine oder die mehreren entfernten Speichergeräte durch Verwendung eines NVMe-Over-Fabric(NVMe-OF)-Protokolls zuzugreifen.
      • 27. System nach einem der Ansprüche 24-26, wobei der Rechenknoten ein Starter ist und der Speicher-Pool-Einschub ein Ziel ist und wobei das System ferner konfiguriert ist, um:
        • Starter-Ziel-Zuordnungsinformationen zu implementieren, die entfernte Speichergeräte, die von dem Rechenknoten genutzt werden, so zuordnen, dass auf sie von dem Speicher-Pool-Einschub zugegriffen wird, und
        • die Starter-Ziel-Zuordnungsinformationen einzusetzen, um einen Zugriff auf die entfernten Speichergeräte zu ermöglichen.
      • 28. System nach einer der Klauseln 24-27, wobei der Rechenknoten konfiguriert ist, um mit dem Speicher-Pool-Einschub unter Verwendung eines NVMe-Over-Fabric(NVMeOF)-Protokolls zu kommunizieren.
      • 29. System nach einer der Klauseln 24-28, wobei jedes des einen oder der mehreren entfernten Speichergeräte, die der Software als lokale NVMe-Speichergeräte ausgesetzt sind, ein entferntes NVMe-Speichergerät ist.
      • 30. System nach einer der Klauseln 24-28, wobei die Software ein Betriebssystem umfasst, das einen NVMe-Treiber aufweist, der konfiguriert ist, um auf lokale NVMe-Speichergeräte zuzugreifen, und einen Rechenknoten, der ferner Folgendes umfasst:
        • mindestens ein lokales NVMe-Speichergerät,
        • wobei der Rechenknoten konfiguriert ist, um das mindestens eine lokale NVMe-Speichergerät und jedes des einen oder der mehreren entfernten Speichergeräte als mehrere lokale NVMe-Speichergeräte auszusetzen und den NVMe-Treiber einzusetzen, um auf jedes des mindestens einen lokalen NVMe-Speichergeräts und das eine oder die mehreren entfernten Speichergeräte zuzugreifen.
      • 31. System nach einer der Klauseln 24-28, wobei der Fabric Controller oder NIC eingebettete Hardware aufweist, die konfiguriert ist, um das eine oder die mehreren entfernten Speichergeräte der Software als lokale NVMe-Speichergeräte auszusetzen.
      • 32. System nach einer der Klauseln 24-28, wobei der Rechenknoten eine Kombination aus einer oder mehreren auf Hardware basierenden Komponenten und einer oder mehreren auf Software basierenden Komponenten aufweist, die konfiguriert sind, um bei einem Starten eines Betriebssystems jedes des einen oder der mehreren entfernten Speichergeräte dem Betriebssystem als lokale NVMe-Speichergeräte auszusetzen.
      • 33. System nach Klauseln 32, wobei die eine oder mehreren auf Software basierenden Komponenten einen NVMe-Volumenverwaltungsgerät(VMD)-Treiber umfassen.
      • 34. System nach Klausel 33, wobei der NVMe-VMD-Treiber einen Netzwerkschnittstellensteuerung(NIC)-Treiber, einen NVMe-Treiber und einen VMD-Treiber aufweist.
      • 35. System nach Klausel 33, wobei der Rechenknoten einen Prozessor mit einer VMD-Komponente aufweist und wobei die eine oder mehrere auf Hardware basierenden Komponenten die VMD-Komponente aufweisen.
      • 36. System nach einer der Klauseln 24-29, wobei der Rechenknoten ferner Folgendes umfasst:
        • Plattform-Firmware, die eine Speichervirtualisierungserweiterung aufweist, und
        • Software, die eine einer Hypervisor- oder Betriebssystem-Virtualisierungsschicht umfasst,
        • und wobei der Rechenknoten ferner konfiguriert ist, um
        • eine physische Speicherzugriffsinfrastruktur zu virtualisieren, die das eine oder die mehreren entfernten Speichergeräte aufweist, und
        • das eine oder die mehreren entfernten Speichergeräte der Hypervisor- oder der Betriebssystem-Virtualisierungsschicht als lokale NVMe-Speichergeräte auszusetzen.
      • 37. System nach einer der Klauseln 24-29, das ferner einen feldprogrammierbaren Gate-Array (FPGA) umfasst, der konfiguriert ist, um das eine oder die mehreren entfernten Speichergeräte der Software als lokale NVMe-Speichergeräte auszusetzen.
      • 38. System nach einer der Klauseln 24-29, wobei der Rechenknoten ferner Folgendes umfasst:
        • Software, die eine einer Hypervisor- oder Betriebssystem-Virtualisierungsschicht mit Speichervirtualisierungserweiterung umfasst, die konfiguriert ist, um
        • eine physische Speicherzugriffsinfrastruktur zu virtualisieren, die das eine oder die mehreren entfernten Speichergeräte aufweist, und
        • jedes des einen oder der mehreren entfernten Speichergeräte einem Betriebssystem in einer virtuellen Maschine oder Behälter, die von der Hypervisor- oder Betriebssystem-Virtualisierungsschicht gehostet sind, als ein lokales NVMe-Speichergerät auszusetzen.
      • 39. Nicht vorübergehendes maschinenlesbares Medium mit Anweisungen, die darauf gespeichert sind, das konfiguriert ist, um durch einen Prozessor in einem Rechenknoten in einer Rechenzentrumumgebung ausgeführt zu werden, die mehrere Einschübe aufweist, die miteinander über einen Fabric verbunden sind, wobei die mehreren Einschübe einen Speicher-Pool-Einschub mit mehreren entfernten Speichergeräten aufweisen und über den Fabric an einen Rechenknoteneinschub kommunikativ gekoppelt sind, in dem der Rechenknoten installiert ist, wobei der Rechenknoten einen Fabric Controller oder eine Netzwerkschnittstellensteuerung (NIC) aufweist, die an den Prozessor wirkgekoppelt und konfiguriert sind, um auf den Fabric zuzugreifen, wobei die Anweisungen konfiguriert sind, um bei einem Ausführen durch den Prozessor jedes des einen oder der mehreren entfernten Speichergeräte einem Ausführen von Software auf dem Rechenknoten als Speichergeräte mit lokalem nichtflüchtigem Speicher-Express (NVMe) auszusetzen.
      • 40. Nicht vorübergehendes maschinenlesbares Medium nach Klausel 39, wobei die Anweisungen Firmware-Anweisungen sind.
      • 41. Nicht vorübergehendes maschinenlesbares Medium nach Klausel 40, wobei das Ausführen von Software auf dem Rechenknoten, dem gegenüber das eine oder die mehreren entfernten Speichergeräte als lokale NVMe-Speichergeräte ausgesetzt sind, einen Hypervisor umfasst.
      • 42. Nicht vorübergehendes maschinenlesbares Medium nach Klausel 40, wobei das Ausführen von Software auf dem Rechenknoten, dem gegenüber das eine oder die mehreren entfernten Speichergeräte als lokale NVMe-Speichergeräte ausgesetzt sind, ein Betriebssystem umfasst.
      • 43. Nicht vorübergehendes maschinenlesbares Medium nach Klausel 40, wobei das Ausführen von Software auf dem Rechenknoten, dem gegenüber das eine oder die mehreren entfernten Speichergeräte als lokale NVMe-Speichergeräte ausgesetzt sind, eine Betriebssystem-Virtualisierungsschicht umfasst.
      • 44. Nicht vorübergehendes maschinenlesbares Medium nach Klausel 39, wobei die Anweisungen Softwareanweisungen sind, die einen Hypervisor umfassen.
      • 45. Nicht vorübergehendes maschinenlesbares Medium nach Klausel 39, wobei die Anweisungen Softwareanweisungen sind, die eine Betriebssystem-Virtualisierungsschicht umfassen.
      • 46. Nicht vorübergehendes maschinenlesbares Medium nach Klausel 39, wobei jedes des einen oder der mehreren entfernten Speichergeräte, die der Software als lokale NVMe-Speichergeräte ausgesetzt sind, ein entferntes NVMe-Speichergerät ist.
  • Obwohl einige Ausführungsformen in Bezug auf bestimmte Implementierungen beschrieben wurden, sind andere Implementierungen gemäß einigen Ausführungsformen möglich. Zudem müssen die Anordnung und/oder Reihenfolge von Elementen oder Merkmalen, die in den Zeichnungen dargestellt sind und/oder hierin beschrieben werden, nicht in der bestimmten Weise angeordnet werden, die dargestellt ist und beschrieben wird. Viele andere Anordnungen sind gemäß einigen Ausführungsformen möglich.
  • In jedem System, das in einer Figur gezeigt ist, können die Elemente in einigen Fällen ein gleiches Bezugszeichen oder ein anderes Bezugszeichen haben, um darauf hinzudeuten, dass die dargestellten Elemente unterschiedlich und/oder ähnlich sein können. Ein Element kann jedoch flexibel genug sein, um unterschiedliche Implementierungen zu haben und mit ein paar oder allen Systemen zu funktionieren, die hierin gezeigt und beschrieben sind. Die verschiedenen Elemente, die in den Figuren gezeigt sind, können gleich oder unterschiedlich sein. Auf was als erstes Element Bezug genommen wird und was als zweites Element genannt wird, ist willkürlich.
  • In der Beschreibung und den Ansprüchen können die Begriffe „gekoppelt“ und „verbunden“ zusammen mit ihren Derivaten benutzt werden. Es ist zu verstehen, dass diese Begriffe nicht als Synonyme füreinander auszulegen sind. In bestimmten Ausführungsformen kann „verbunden“ benutzt werden, um anzugeben, dass zwei oder mehr Elemente in einem direkten physischen oder elektrischen Kontakt miteinander sind. „Gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente in direktem physischen oder elektrischen Kontakt sind. „Gekoppelt“ kann jedoch auch bedeuten, dass zwei oder mehr Elemente nicht in direktem Kontakt miteinander sind, sondern zusammenwirken oder miteinander in Wechselwirkung treten.
  • Eine Ausführungsform ist eine Implementierung oder ein Beispiel der Erfindungen. Bezugnahmen in der Spezifizierung auf „eine Ausführungsform“, „einige Ausführungsformen“ oder „andere Ausführungsformen“ bedeuten, dass ein bestimmtes Merkmal, eine Struktur oder Eigenschaft, das/die in Verbindung mit den Ausführungsformen beschrieben wird, in mindestens ein paar Ausführungsformen enthalten ist, aber nicht notwendigerweise in allen Ausführungsformen der Erfindungen. Die verschiedenen Verwendungen von „eine Ausführungsform“ oder „einige Ausführungsformen“ beziehen sich nicht alle notwendigerweise auf die gleichen Ausführungsformen.
  • Nicht alle Komponenten, Merkmale, Strukturen, Eigenschaften usw., die hierin beschrieben und dargestellt sind, müssen in einer bestimmten Ausführungsform oder in bestimmten Ausführungsformen enthalten sein. In der Spezifizierung „kann“ oder „könnte“ eine Komponente, ein Merkmal oder eine Eigenschaft enthalten sein, zum Beispiel muss die bestimmte Komponente, das Merkmal, die Struktur oder Eigenschaft nicht enthalten sein. Wenn die Spezifizierung oder der Anspruch „ein“ Element betrifft, bedeutet das nicht, dass nur eines des Elements vorliegt. Wenn die Spezifizierung oder die Ansprüche „ein zusätzliches“ Element nennen, schließt das nicht aus, dass mehr als eines des zusätzlichen Elements vorliegt.
  • Buchstaben, wie etwa ,M' und ,N', in der vorangegangenen ausführlichen Beschreibung und den Zeichnungen werden benutzt, um eine ganze Zahl zu bezeichnen, und die Benutzung eines bestimmten Buchstabens beschränkt sich nicht auf bestimmte Ausführungsformen. Des Weiteren kann der gleiche Buchstabe in separaten Ansprüchen verwendet werden, um separate ganze Zahlen zu bezeichnen, oder es können unterschiedliche Buchstaben benutzt werden. Zudem kann die Benutzung eines bestimmten Buchstabens in der ausführlichen Beschreibung zu dem Buchstaben in einem Anspruch passen oder nicht, der den gleichen Gegenstand in der ausführlichen Beschreibung betrifft.
  • Wie oben dargelegt wurde, können verschiedene Aspekte der Ausführungsformen hierin durch entsprechende Software- und/oder Firmware-Komponenten und -Anwendungen ermöglicht werden, wie etwa Software und/oder Firmware, die durch einen eingebetteten Prozessor oder dergleichen ausgeführt wird. Daher können Ausführungsformen dieser Erfindung als Softwareprogramme, Softwaremodule, Firmware und/oder verteilte Software benutzt werden oder diese unterstützen, die in einer Art von Prozessor, Prozessorkern oder eingebetteter Logik oder einer virtuellen Maschine ausgeführt werden, die auf einem Prozessor oder Kern laufen oder andersartig implementiert oder realisiert sind, oder innerhalb eines computerlesbaren oder maschinenlesbaren nicht vorübergehenden Speichermediums. Ein computerlesbares oder maschinenlesbares nicht vorübergehendes Speichermedium weist einen beliebigen Mechanismus zum Speichern oder Übertragen von Informationen in einer lesbaren Form durch eine Maschine (z.B. einen Rechner) auf. Zum Beispiel weist ein computerlesbares oder maschinenlesbares nicht vorübergehendes Speichermedium einen beliebigen Mechanismus auf, der Informationen in einer durch einen Rechner oder eine Rechenmaschine (z.B. Rechengerät, elektronisches System usw.) zugänglichen Form, wie etwa beschreibbaren/nicht beschreibbaren Medien (z.B. Festwertspeicher(ROM), Direktzugriffsspeicher (RAM), Magnetplattenspeichermedien, optischen Speichermedien, Flash-Speicher-Geräten usw.) bereitstellt (d.h. speichert und/oder überträgt). Der Inhalt kann direkt ausführbar („Objekt“ oder „ausfuhrbares“ Formular), ein Quellcode oder anderer Code („Delta“- oder „Patch“-Code) sein. Ein computerlesbares oder maschinenlesbares nicht vorübergehendes Speichermedium kann auch einen Speicher oder eine Datenbank aufweisen, von dem/der Inhalte heruntergeladen werden können. Das computerlesbare oder maschinenlesbare nicht vorübergehende Speichermedium kann auch ein Gerät oder Produkt aufweisen, das Inhalte hat, die darauf zu einem Zeitpunkt oder Lieferpunkt gespeichert wurden. Daher kann ein Liefern eines Geräts mit gespeicherten Inhalten oder ein Anbieten von Inhalten zu Herunterladen über ein Kommunikationsmedium als Bereitstellen eines Herstellungsartikels betrachtet werden, der ein computerlesbares oder maschinenlesbares nicht vorübergehendes Speichermedium mit einem derartigen Inhalt umfasst, der hierin beschrieben wurde.
  • Verschiedene Komponenten, auf die oben als Prozesse, Server oder Werkzeuge Bezug genommen wurde, die hierin beschrieben sind, können ein Mittel zum Durchführen der beschriebenen Funktionen sein. Die Vorgänge und Funktionen, die durch verschiedene Komponenten, die hierin beschrieben sind, durchgeführt werden, können durch ein Ausführen von Software auf einem Verarbeitungselement über eingebettete Hardware oder dergleichen oder eine beliebige Kombination aus Hardware und Software implementiert werden. Derartige Komponenten können als Softwaremodule, Hardwaremodule, Hardware für spezielle Zwecke (z.B. anwendungsspezifische Hardware, ASICs, DSPs usw.), eingebettete Steuerungen, festverdrahtete Schaltungen, Hardwarelogik usw. implementiert werden. Softwareinhalte (z.B. Daten, Anweisungen, Konfigurationsinformationen usw.) können über einen Herstellungsartikel bereitgestellt werden, der ein computerlesbares oder maschinenlesbares nicht vorübergehendes Speichermedium aufweist, das Inhalte bereitstellt, die Anweisungen darstellen, die ausgeführt werden können. Die Inhalte können dazu führen, dass ein Rechner verschiedene Funktionen/Vorgänge ausführt, die hierin beschrieben sind.
  • Wie hierin verwendet wird, kann eine Liste von Gegenständen, die durch den Begriff „mindestens eine/s/r von“ verbunden sind, eine beliebige Kombination aus den aufgelisteten Begriffen bedeuten. Zum Beispiel kann der Ausdruck „mindestens eine/s/r von A, B oder C“ A; B; C; A und B; A und C; B und C oder A, B und C bedeuten.
  • Die Beschreibung oben von dargestellten Ausführungsformen der Erfindung, einschließlich dessen, was in der Zusammenfassung beschrieben ist, ist nicht als vollständig auszulegen, oder um die Erfindung auf die präzise Form zu beschränken, die offenbart wird. Während spezifische Ausführungsformen und Beispiele der Erfindung hierin zum darstellerischen Zweck beschrieben werden, sind verschiedene äquivalente Veränderungen innerhalb des Umfangs der Erfindung möglich, wie Fachleute auf dem Gebiet erkennen werden.
    Diese Veränderungen können an der Erfindung vor dem Hintergrund der ausführlichen Beschreibung oben vorgenommen werden. Die Begriffe, die in den folgenden Ansprüchen benutzt werden, sind nicht auszulegen, um die Erfindung auf die spezifischen Ausführungsformen zu beschränken, die in der Spezifizierung und den Zeichnungen offenbart sind. Stattdessen ist der Umfang der Erfindung gänzlich durch die folgenden Ansprüche zu bestimmen, die gemäß etablierten Lehren von Anspruchsauslegungen auszulegen sind.

Claims (25)

  1. Verfahren, das durch einen Rechenknoten implementiert wird, der an einen entfernten Speicherknoten über einen Fabric kommunikativ gekoppelt ist, wobei der entfernte Speicherknoten mehrere entfernte Speichergeräte aufweist, auf die durch den Rechenknoten über den Fabric zugegriffen wird, wobei das Verfahren Folgendes umfasst: Bestimmen eines oder mehrerer entfernter Speichergeräte, die dem Rechenknoten zugeordnet wurden, und Aussetzen jedes des einen oder der mehreren entfernten Speichergeräte einem Ausführen von Software auf dem Rechenknoten als Speichergerät mit lokalem nichtflüchtigem Speicher-Express (NVMe).
  2. Verfahren nach Anspruch 1, das ferner ein Senden von Daten zwischen dem Rechenknoten und dem entfernten Speicherknoten unter Verwendung eines NVMe-Over-Fabric(NVMe-OF)-Protokolls umfasst.
  3. Verfahren nach Anspruch 1 oder 2, wobei jedes des einen oder der mehreren entfernten Speichergeräte, das dem Betriebssystem als lokales NVMe-Speichergerät ausgesetzt wird, ein entferntes NVMe-Speichergerät ist.
  4. Verfahren nach einem der vorhergehenden Ansprüche, wobei der Rechenknoten ein lokales NVMe-Speichergerät aufweist, auf das über einen NVMe-Treiber zugegriffen wird, der konfiguriert ist, um auf lokale NVMe-Speichergeräte zuzugreifen, und die Software ein Betriebssystem umfasst, das auf dem Rechenknoten läuft, ferner umfassend Ermöglichen des Betriebssystems, auf das eine oder die mehreren entfernten Speichergeräte über den NVMe-Treiber zuzugreifen.
  5. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Software ein Betriebssystem umfasst, das auf physischer Rechenknotenhardware läuft, und wobei jedes des einen oder der mehreren entfernten Speichergeräte dem Betriebssystem als lokales NVMe-Speichergerät durch Verwendung einer auf Hardware basierenden Komponente in der physischen Rechenknotenhardware ausgesetzt wird.
  6. Verfahren nach Anspruch 5, wobei die auf Hardware basierende Komponente eine Netzwerkschnittstellensteuerung oder einen Fabric Controller umfasst.
  7. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Software ein Betriebssystem umfasst, das auf physischer Rechenknotenhardware läuft, und wobei ein Aussetzen jedes des einen oder der mehreren entfernten Speichergeräte dem Ausführen von Software auf dem Rechenknoten als lokales NVMe-Speichergerät durch eine Kombination aus einer oder mehreren auf Hardware basierenden Komponenten in der physischen Rechenknotenhardware und einer oder mehreren auf Software basierenden Komponenten implementiert wird.
  8. Verfahren nach Anspruch 7, wobei die eine oder mehreren auf Software basierenden Komponenten einen NVMe-Volumenverwaltungsgerät(VMD)-Treiber aufweisen.
  9. Verfahren nach Anspruch 8, wobei der NVMe-VMD-Treiber einen Netzwerkschnittstellensteuerung(NIC)-Treiber, einen NVMe-Treiber und einen VMD-Treiber aufweist.
  10. Verfahren nach Anspruch 8, wobei der Rechenknoten einen Prozessor mit einer VMD-Komponente aufweist und wobei die eine oder mehreren auf Hardware basierenden Komponenten die VMD-Komponente aufweisen.
  11. Verfahren nach einem der vorhergehenden Ansprüche, das ferner Folgendes umfasst: Virtualisieren einer physischen Speicherzugriffsinfrastruktur, die sowohl lokale als auch entfernte Speicherressourcen mit Plattform-Firmware aufweist, die eine Speichervirtualisierungserweiterung aufweist, und Aussetzen, über eines einer Plattform-Firmware, eines feldprogrammierbaren Gate-Arrays (FPGA) und einer auf Software basierenden Hypervisor- oder Betriebssystem-Virtualisierungsschicht, jedes des einen oder der mehreren entfernten Speichergeräte einem Ausführen von Software auf dem Rechenknoten als lokales NVMe-Speichergerät.
  12. Rechenknoten, der konfiguriert ist, um in einer Rechenzentrumsumgebung implementiert zu sein, die mehrere Einschübe aufweist, die miteinander über einen Fabric verbunden sind, wobei die mehreren Einschübe einen Speicher-Pool-Einschub mit mehreren entfernten Speichergeräten aufweisen und über den Fabric an einen Rechenknoteneinschub kommunikativ gekoppelt sind, in dem der Rechenknoten konfiguriert ist, um installiert zu sein, wobei der Rechenknoten Folgendes umfasst: einen Prozessor, einen Speicher, der an den Prozessor gekoppelt ist, und einen Fabric Controller oder eine Netzwerkschnittstellensteuerung (NIC), die an den Prozessor wirkgekoppelt und konfiguriert ist, um auf den Fabric zuzugreifen, wobei, wenn der Rechenknoten in dem Rechenknoteneinschub installiert ist und arbeitet, der Rechenknoten konfiguriert ist, um jedes von einem oder mehreren der mehreren entfernten Speichergeräte einem Ausführen von Software auf dem Rechenknoten als Speichergerät mit lokalem nichtflüchtigem Speicher-Express (NVMe) auszusetzen.
  13. Rechenknoten nach Anspruch 12, wobei der Rechenknoten konfiguriert ist, um mit dem Speicher-Pool-Einschub unter Verwendung eines NVMe-Over-Fabric(NVMe-OF)-Protokolls zu kommunizieren.
  14. Rechenknoten nach Anspruch 12 oder 13, wobei jedes des einen oder der mehreren entfernten Speichergeräte, die der Software als lokales NVMe-Speichergerät ausgesetzt sind, ein entferntes NVMe-Speichergerät ist.
  15. Rechenknoten nach einem der Ansprüche 12-14, wobei die Software ein Betriebssystem umfasst, das einen NVMe-Treiber aufweist, der konfiguriert ist, um auf lokale NVMe-Speichergeräte zuzugreifen, ferner umfassend: mindestens ein lokales NVMe-Speichergerät, wobei der Rechenknoten konfiguriert ist, um das mindestens eine lokale NVMe-Speichergerät und jedes des einen oder der mehreren entfernten Speichergeräte als mehrere lokale NVMe-Speichergeräte auszusetzen und den NVMe-Treiber einzusetzen, um auf jedes des mindestens einen lokalen NVMe-Speichergeräts und das eine oder die mehreren entfernten Speichergeräte zuzugreifen.
  16. Rechenknoten nach einem der Ansprüche 12-14, wobei der Fabric Controller oder die NIC eingebettete Hardware aufweist, die konfiguriert ist, um das eine oder die mehreren entfernten Speichergeräte der Software als lokale NVMe-Speichergeräte auszusetzen.
  17. Rechenknoten nach einem der Ansprüche 12-14, wobei der Rechenknoten eine Kombination aus einer oder mehreren auf Hardware basierenden Komponenten und einer oder mehreren auf Software basierenden Komponenten aufweist, die konfiguriert sind, um bei einem Starten eines Betriebssystems das eine oder die mehreren entfernten Speichergeräte dem Betriebssystems als lokale NVMe-Speichergeräte auszusetzen.
  18. Rechenknoten nach Anspruch 17, wobei die eine oder mehreren auf Software basierenden Komponenten einen NVMe-Volumenverwaltungsgerät(VMD)-Treiber umfassen.
  19. Rechenknoten nach Anspruch 18, wobei der NVMe-VMD-Treiber einen Netzwerkschnittstellensteuerung(NIC)-Treiber, einen NVMe-Treiber und einen VMD-Treiber aufweist.
  20. Rechenknoten nach Anspruch 18, wobei der Rechenknoten einen Prozessor mit einer VMD-Komponente aufweist und wobei die eine oder mehreren auf Hardware basierenden Komponenten die VMD-Komponente aufweisen.
  21. Rechenknoten nach Anspruch 12, wobei der Rechenknoten ferner Folgendes umfasst: Plattform-Firmware, die eine Speichervirtualisierungserweiterung aufweist, und Software, die eine einer Hypervisor- oder Betriebssystem-Virtualisierungsschicht umfasst, und wobei der Rechenknoten ferner konfiguriert ist, um eine physische Speicherzugriffsinfrastruktur zu virtualisieren, die das eine oder die mehreren entfernten Speichergeräte aufweist, und das eine oder die mehreren entfernten Speichergeräte der Hypervisor- oder der Betriebssystem-Virtualisierungsschicht als lokale NVMe-Speichergeräte auszusetzen.
  22. System, das Folgendes umfasst: mehrere Einschübe, die miteinander über einen Fabric verbunden sind, wobei die mehreren Einschübe einen Speicher-Pool-Einschub mit mehreren entfernten Speichergeräten aufweisen und über den Fabric an einen Rechenknoteneinschub kommunikativ gekoppelt sind, der mehrere Rechenknoten aufweist, wobei mindestens einer der mehreren Rechenknoten Folgendes aufweist: einen Prozessor, einen Speicher, der an den Prozessor gekoppelt ist, und einen Fabric Controller oder eine Netzwerkschnittstellensteuerung (NIC), die an den Prozessor wirkgekoppelt und konfiguriert ist, um auf den Fabric zuzugreifen, wobei, wenn der Rechenknoten arbeitet, der Rechenknoten konfiguriert ist, um jedes des einen oder der mehreren der mehreren entfernten Speichergeräte einem Ausführen von Software auf dem Rechenknoten als lokales nichtflüchtiges Speicher-Express(NVMe)-Speichergerät auszusetzen.
  23. System nach Anspruch 22, das ferner Folgendes umfasst: eine Recheneinschubverwaltungseinrichtung, die an den POD-Manager und den Rechenknoten kommunikativ gekoppelt ist, wobei das System ferner konfiguriert ist, um eine Anfrage von einem Infrastructure-as-a-Service(laaS)-Kunden zu erhalten, der die Nutzung von Rechenressourcen und Speicherressourcen anfragt, die über das System verfügbar sind, einen Rechenknoten zu erstellen, um ein oder mehrere entfernte Speichergeräte als lokale NVMe-Laufwerke zu nutzen, und Konfigurationsinformationen über die Recheneinschubverwaltungseinrichtung zu dem Rechenknoten zu kommunizieren, wobei eine Nutzung des einen oder der mehreren entfernten Speichergeräte als lokale NVMe-Laufwerke spezifiziert wird.
  24. System nach Anspruch 22 oder 23, wobei der Rechenknoten konfiguriert ist, um auf das eine oder die mehreren entfernten Speichergeräte durch Verwendung eines NVMe-Over-Fabric(NVMe-OF)-Protokolls zuzugreifen.
  25. System nach einem der Ansprüche 22-24, wobei der Rechenknoten ein Starter ist und der Speicher-Pool-Einschub ein Ziel ist und wobei das System ferner konfiguriert ist, um: Starter-Ziel-Zuordnungsinformationen zu implementieren, die entfernte Speichergeräte, die von dem Rechenknoten genutzt werden, so zuordnen, dass auf sie von dem Speicher-Pool-Einschub zugegriffen wird, und die Starter-Ziel-Zuordnungsinformationen einzusetzen, um einen Zugriff auf die entfernten Speichergeräte zu ermöglichen.
DE102018004046.2A 2017-05-18 2018-05-18 Nichtflüchtiger Speicher-Express über Fabric (NVMeOF) unter Verwendung eines Volumenverwaltungsgeräts Pending DE102018004046A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/599,020 US10958729B2 (en) 2017-05-18 2017-05-18 Non-volatile memory express over fabric (NVMeOF) using volume management device
US15/599,020 2017-05-18

Publications (1)

Publication Number Publication Date
DE102018004046A1 true DE102018004046A1 (de) 2018-11-22

Family

ID=64272365

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102018004046.2A Pending DE102018004046A1 (de) 2017-05-18 2018-05-18 Nichtflüchtiger Speicher-Express über Fabric (NVMeOF) unter Verwendung eines Volumenverwaltungsgeräts

Country Status (2)

Country Link
US (1) US10958729B2 (de)
DE (1) DE102018004046A1 (de)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220103490A1 (en) * 2020-09-28 2022-03-31 Vmware, Inc. Accessing multiple external storages to present an emulated local storage through a nic
US11593278B2 (en) 2020-09-28 2023-02-28 Vmware, Inc. Using machine executing on a NIC to access a third party storage not supported by a NIC or host
US11606310B2 (en) 2020-09-28 2023-03-14 Vmware, Inc. Flow processing offload using virtual port identifiers
US11636053B2 (en) 2020-09-28 2023-04-25 Vmware, Inc. Emulating a local storage by accessing an external storage through a shared port of a NIC
US11829793B2 (en) 2020-09-28 2023-11-28 Vmware, Inc. Unified management of virtual machines and bare metal computers
US11863376B2 (en) 2021-12-22 2024-01-02 Vmware, Inc. Smart NIC leader election
US11899594B2 (en) 2022-06-21 2024-02-13 VMware LLC Maintenance of data message classification cache on smart NIC
US11928367B2 (en) 2022-06-21 2024-03-12 VMware LLC Logical memory addressing for network devices
US11928062B2 (en) 2022-06-21 2024-03-12 VMware LLC Accelerating data message classification with smart NICs
US11962518B2 (en) 2020-06-02 2024-04-16 VMware LLC Hardware acceleration techniques using flow selection
US11995024B2 (en) 2021-12-22 2024-05-28 VMware LLC State sharing between smart NICs
US12021759B2 (en) 2020-11-06 2024-06-25 VMware LLC Packet processing with hardware offload units

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10733137B2 (en) * 2017-04-25 2020-08-04 Samsung Electronics Co., Ltd. Low latency direct access block storage in NVME-of ethernet SSD
US11102294B2 (en) * 2017-06-09 2021-08-24 Samsung Electronics Co., Ltd. System and method for supporting energy and time efficient content distribution and delivery
US20190102287A1 (en) * 2017-09-29 2019-04-04 Intel Corporation Remote persistent memory access device
US10649921B2 (en) * 2018-07-30 2020-05-12 Hewlett Packard Enterprise Development Lp Composable serial console and KVM with remote accessibility
US11405455B2 (en) * 2018-11-27 2022-08-02 Ovh Us Llc Elastic scaling in a storage network environment
CN111722786A (zh) * 2019-03-21 2020-09-29 阿里巴巴集团控股有限公司 基于NVMe设备的存储系统
US11064020B2 (en) 2019-06-25 2021-07-13 Western Digital Technologies, Inc. Connection load distribution in distributed object storage systems
US11343308B2 (en) 2019-06-25 2022-05-24 Western Digital Technologies, Inc. Reduction of adjacent rack traffic in multi-rack distributed object storage systems
US11809252B2 (en) 2019-07-29 2023-11-07 Intel Corporation Priority-based battery allocation for resources during power outage
CN111459417B (zh) * 2020-04-26 2023-08-18 中国人民解放军国防科技大学 一种面向NVMeoF存储网络的无锁传输方法及系统
US11720413B2 (en) * 2020-06-08 2023-08-08 Samsung Electronics Co., Ltd. Systems and methods for virtualizing fabric-attached storage devices
US11611540B2 (en) * 2020-07-01 2023-03-21 Vmware, Inc. Protection of authentication data of a server cluster
US20220229569A1 (en) * 2021-01-20 2022-07-21 Samsung Electronics Co., Ltd. Systems, methods, and apparatus for storage query planning
US11689621B2 (en) * 2021-07-02 2023-06-27 Korea Advanced Institute Of Science And Technology Computing device and storage card
CN114826902B (zh) * 2022-06-08 2024-01-16 中国农业银行股份有限公司 一种跨地域运维数据的存储方法及装置

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9256383B2 (en) * 2010-03-16 2016-02-09 Amplidata Nv Device driver for use in a data storage system
US9430372B2 (en) * 2011-09-30 2016-08-30 Intel Corporation Apparatus, method and system that stores bios in non-volatile random access memory
CN103946765B (zh) * 2011-11-22 2017-11-17 英特尔公司 协同处理器以及系统性能和功率管理
US9430412B2 (en) * 2013-06-26 2016-08-30 Cnex Labs, Inc. NVM express controller for remote access of memory and I/O over Ethernet-type networks
US9785355B2 (en) * 2013-06-26 2017-10-10 Cnex Labs, Inc. NVM express controller for remote access of memory and I/O over ethernet-type networks
US10063638B2 (en) * 2013-06-26 2018-08-28 Cnex Labs, Inc. NVM express controller for remote access of memory and I/O over ethernet-type networks
US9294567B2 (en) * 2014-05-02 2016-03-22 Cavium, Inc. Systems and methods for enabling access to extensible storage devices over a network as local storage via NVME controller
US9529773B2 (en) * 2014-05-02 2016-12-27 Cavium, Inc. Systems and methods for enabling access to extensible remote storage over a network as local storage via a logical storage controller
US9430268B2 (en) * 2014-05-02 2016-08-30 Cavium, Inc. Systems and methods for supporting migration of virtual machines accessing remote storage devices over network via NVMe controllers
US10069749B1 (en) * 2014-09-23 2018-09-04 EMC IP Holding Company LLC Method and apparatus for disaggregated overlays via application services profiles
US9712619B2 (en) * 2014-11-04 2017-07-18 Pavilion Data Systems, Inc. Virtual non-volatile memory express drive
US9565269B2 (en) * 2014-11-04 2017-02-07 Pavilion Data Systems, Inc. Non-volatile memory express over ethernet
US10348574B2 (en) * 2015-08-17 2019-07-09 Vmware, Inc. Hardware management systems for disaggregated rack architectures in virtual server rack deployments
US9921997B2 (en) * 2016-04-01 2018-03-20 Intel Corporation Mechanism for PCIE cable topology discovery in a rack scale architecture environment
US10390114B2 (en) * 2016-07-22 2019-08-20 Intel Corporation Memory sharing for physical accelerator resources in a data center
US10277677B2 (en) * 2016-09-12 2019-04-30 Intel Corporation Mechanism for disaggregated storage class memory over fabric
US10687434B2 (en) * 2016-12-30 2020-06-16 Intel Corporation Mechanisms for SAS-free cabling in rack scale design
US20180191721A1 (en) * 2016-12-31 2018-07-05 Intel Corporation Mechanisms to enable secure virtual namespaces in disaggregated storage targets
US20190171601A1 (en) * 2017-12-03 2019-06-06 Intel Corporation Mechanisms for fpga chaining and unified fpga views to composed system hosts
US10649921B2 (en) * 2018-07-30 2020-05-12 Hewlett Packard Enterprise Development Lp Composable serial console and KVM with remote accessibility

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11962518B2 (en) 2020-06-02 2024-04-16 VMware LLC Hardware acceleration techniques using flow selection
US11824931B2 (en) 2020-09-28 2023-11-21 Vmware, Inc. Using physical and virtual functions associated with a NIC to access an external storage through network fabric driver
US11736566B2 (en) 2020-09-28 2023-08-22 Vmware, Inc. Using a NIC as a network accelerator to allow VM access to an external storage via a PF module, bus, and VF module
US11829793B2 (en) 2020-09-28 2023-11-28 Vmware, Inc. Unified management of virtual machines and bare metal computers
US11716383B2 (en) * 2020-09-28 2023-08-01 Vmware, Inc. Accessing multiple external storages to present an emulated local storage through a NIC
US11593278B2 (en) 2020-09-28 2023-02-28 Vmware, Inc. Using machine executing on a NIC to access a third party storage not supported by a NIC or host
US11736565B2 (en) 2020-09-28 2023-08-22 Vmware, Inc. Accessing an external storage through a NIC
US11792134B2 (en) 2020-09-28 2023-10-17 Vmware, Inc. Configuring PNIC to perform flow processing offload using virtual port identifiers
US11875172B2 (en) 2020-09-28 2024-01-16 VMware LLC Bare metal computer for booting copies of VM images on multiple computing devices using a smart NIC
US11636053B2 (en) 2020-09-28 2023-04-25 Vmware, Inc. Emulating a local storage by accessing an external storage through a shared port of a NIC
US11606310B2 (en) 2020-09-28 2023-03-14 Vmware, Inc. Flow processing offload using virtual port identifiers
US20220103490A1 (en) * 2020-09-28 2022-03-31 Vmware, Inc. Accessing multiple external storages to present an emulated local storage through a nic
US12021759B2 (en) 2020-11-06 2024-06-25 VMware LLC Packet processing with hardware offload units
US11863376B2 (en) 2021-12-22 2024-01-02 Vmware, Inc. Smart NIC leader election
US11995024B2 (en) 2021-12-22 2024-05-28 VMware LLC State sharing between smart NICs
US11899594B2 (en) 2022-06-21 2024-02-13 VMware LLC Maintenance of data message classification cache on smart NIC
US11928367B2 (en) 2022-06-21 2024-03-12 VMware LLC Logical memory addressing for network devices
US11928062B2 (en) 2022-06-21 2024-03-12 VMware LLC Accelerating data message classification with smart NICs

Also Published As

Publication number Publication date
US10958729B2 (en) 2021-03-23
US20180337991A1 (en) 2018-11-22

Similar Documents

Publication Publication Date Title
DE102018004046A1 (de) Nichtflüchtiger Speicher-Express über Fabric (NVMeOF) unter Verwendung eines Volumenverwaltungsgeräts
US11086520B2 (en) Method and apparatus for dynamically allocating storage resources to compute nodes
DE112020006859T5 (de) Beibehaltung von speicher-namensraum-identifizierern für die migration von virtualisierten ausführungsumgebungen im laufenden betrieb
CN109565523B (zh) 用于结构上的解聚的存储级存储器的机制
DE112020007201T5 (de) Speicherzuordnung für verteilte Verarbeitungsvorrichtungen
DE102020125046A1 (de) Konfigurationsschnittstelle zum auslagern von fähigkeiten an eine netzwerkschnittstelle
US11023258B2 (en) Self-morphing server platforms
DE102022107621A1 (de) Resourcenauswahl, die zum teil auf der arbeitslast basiert
DE112017000337T5 (de) Spezifizieren eines disaggregierten Datenverarbeitungssystems
CN111328392B (zh) 部分供应的虚拟机的部署
EP3688596B1 (de) Computerprogrammprodukt, system und verfahren zur verwaltung des zugriffs auf speicherressourcen von mehreren anwendungen
DE112020006967T5 (de) Performanceüberwachung für kurzlebige funktionen
DE102010001985A1 (de) Vorrichtung zum Schalten des Betriebs einer virtuellen Maschine zwischen mehreren Computern, die der gleichen Computerplattform zugeordnet sind, und entsprechende Schaltverfahren
US9882775B1 (en) Dependent network resources
DE112012003342T5 (de) Dynamisches Anpassen und Begrenzen der Größe des Netzwerkadapterspeichers zur Speicherung von Umsetzungseinträgen für virtuelle Funktionen
CN108139937B (zh) 多根i/o虚拟化系统
DE112020006858T5 (de) Dynamische interrupt-bereitstellung
DE112020000280B4 (de) Transparente interpretation von gastbefehlen in einer sicheren virtuellen maschinenumgebung
DE102019127285A1 (de) Verfahren und Vorrichtung zur sicheren Datenzentrumsüberbrückung in einem Multi-Tenant-System
DE112017001806T5 (de) Ein mechanismus zur entdeckung von pcie-kabeltopologien in einer rack-scale-architekturumgebung
DE112020000289T5 (de) Abfrage und überlassung von sicherem speicher
DE112021001408T5 (de) Verwendung kohärent verbundener schnittstellen in einem netzwerkstapelrahmen
DE102020129690A1 (de) Semiflexibler paketzusammenführungs-steuerweg
DE112016006308T5 (de) Erweiterte virtuelle Funktionsfähigkeiten in einer virtualisierten Netzwerkumgebung
DE112016007292T5 (de) Technologien für paravirtualisierte netzwerkvorrichtungswarteschlangen und speicherverwaltung

Legal Events

Date Code Title Description
R012 Request for examination validly filed