DE102022203658A1 - Gerät, Verfahren und Computerprogrammprodukt für effiziente, softwaredefinierte, netzbeschleunigte Verarbeitung unter Verwendung von Speichergeräten, die in Bezug auf einem Host lokal sind - Google Patents

Gerät, Verfahren und Computerprogrammprodukt für effiziente, softwaredefinierte, netzbeschleunigte Verarbeitung unter Verwendung von Speichergeräten, die in Bezug auf einem Host lokal sind Download PDF

Info

Publication number
DE102022203658A1
DE102022203658A1 DE102022203658.1A DE102022203658A DE102022203658A1 DE 102022203658 A1 DE102022203658 A1 DE 102022203658A1 DE 102022203658 A DE102022203658 A DE 102022203658A DE 102022203658 A1 DE102022203658 A1 DE 102022203658A1
Authority
DE
Germany
Prior art keywords
host
storage
nvme
storage device
request
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
DE102022203658.1A
Other languages
English (en)
Inventor
Eliav Bar Ilan
Oren Duer
Maxim Gurtovoy
Liran Liss
Aviad Shaul Yehezkel
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.)
Mellanox Technologies Ltd
Original Assignee
Mellanox Technologies Ltd
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 Mellanox Technologies Ltd filed Critical Mellanox Technologies Ltd
Publication of DE102022203658A1 publication Critical patent/DE102022203658A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/40—Bus structure
    • G06F13/4004—Coupling between buses
    • G06F13/4022—Coupling between buses using switching circuits, e.g. switching matrix, connection or expansion network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/20—Handling requests for interconnection or transfer for access to input/output bus
    • G06F13/28—Handling requests for interconnection or transfer for access to input/output bus using burst mode transfer, e.g. direct memory access DMA, cycle steal
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4204—Bus transfer protocol, e.g. handshake; Synchronisation on a parallel bus
    • G06F13/4221—Bus transfer protocol, e.g. handshake; Synchronisation on a parallel bus being an input/output bus, e.g. ISA bus, EISA bus, PCI bus, SCSI bus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4282—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication
    • G06F15/173—Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star, snowflake
    • G06F15/17306—Intercommunication techniques
    • G06F15/17331—Distributed shared memory [DSM], e.g. remote direct memory access [RDMA]
    • 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/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • 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
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • 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/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/544—Buffers; Shared memory; Pipes
    • 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
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45579—I/O management, e.g. providing access to device drivers or storage
    • 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
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45583—Memory management, e.g. access or allocation
    • 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
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2213/00—Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F2213/0024—Peripheral component interconnect [PCI]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2213/00—Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F2213/0026—PCI express
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Systems (AREA)

Abstract

Ein rechnergestütztes System, das in Verbindung mit einem rechnergestützten Gerät und mit einem Gewebe-Ziel-Dienst in Datenkommunikation mit der rechnergestützten Vorrichtung arbeitet, wobei das System eine Funktionalität, die sich auf dem rechnergestützten Gerät befindet, und eine Funktionalität, die sich auf dem Gewebe-Ziel-Dienst befindet, umfasst, die, wenn sie in Kombination arbeiten, das rechnergestützte Gerät befähigen, den Zugriff auf Daten zu koordinieren.

Description

  • BEREICH DER ERFINDUNG
  • Diese Erfindung bezieht sich im Allgemeinen auf Hardware-Speichergeräte und im Besonderen auf vernetzte Hardware-Speichergeräte.
  • HINTERGRUND
  • Die vernetzte Speicherung ermöglicht mehreren Anwendungs-/Datenbankservern die gemeinsame Nutzung von Speicherplatz auf einem einzigen NAS-Server (Network Attached Storage) oder auf einem Blockspeicher-Controller über ein SAN-Protokoll (Storage Area Network). Zur Unterstützung von NAS- und SAN-Systemen sind verschiedene Speichernetzwerkprotokolle bekannt. Dieselben Speicherboxen können verteilte Dateien (z.B. Network Attached Storage) und Blockspeicherprotokolle unterstützen.
  • DMA (Direct Memory Access) z.B. zwischen GPU-Speicher und Speichergeräten wie NVMe-Speicherlaufwerken ist bekannt und wird z.B. hier beschrieben: news.developer.nvidia.com/gpu-direct-storage-early-access/
  • DMA-Übertragungen werden auch hier beschrieben: docs.nvidia.com/cuda/gpudirect-rdma/index.html#standard-dma-transfer-example-sequence
  • Eine DPU (Data Processing Unit) und ein direkter Speicherzugriff (DMA) bestehen in der Regel aus einer Plattform mit einer Netzwerkschnittstelle, z.B. NVIDIA®'s ConnectX®, und einem programmierbaren Verarbeitungsmodul, z.B. ARM-Cores, das die Verarbeitungsleistung der DPU bereitstellt und programmierbar sein kann. BlueField® (Versionen 1, 2 und 3) sind alles Beispiele für moderne DPUs.
  • DPUs können als eigenständige eingebettete Prozessoren verwendet oder in Netzwerkschnittstellen-Controller integriert werden. Eine DPU kann beispielsweise in eine SmartNIC integriert werden, eine Netzwerkschnittstellensteuerung, die in Servern wie den „Next-Generation-Servern“ verwendet wird, einer Klasse von Servern, die sich im Vergleich zu anderen Servern durch eine höhere Prozessorgeschwindigkeit, verbesserte Verwaltungsfunktionen und eine höhere Energieeffizienz auszeichnen.
  • Die SmartNIC-Technologie wird hier beschrieben:
    • blog.mellanox.com/2018/08/defining-smartnic/
  • Ein Storage Performance Development Kit (SPDK) ist ein Entwicklerkit, das Bausteine für skalierbare, leistungsstarke Speicheranwendungen bereitstellt. Das SPDK bezieht sich auf ein „NVMe over Fabrics Target“, d.h. eine User-Space-Anwendung, die Blockgeräte über „Fabrics“ wie Ethernet, Infiniband oder Fibre Channels präsentiert. Die NVMe-over-Fabrics-Spezifikation definiert Subsysteme, die über verschiedene Transporte exportiert werden können; beachten Sie, dass sowohl RDMA- als auch TCP-Transporte vom SPDK unterstützt werden. Die SPDK-Spezifikation bezeichnet die Software, die diese Subsysteme exportiert, als „Target“ (der für iSCSI verwendete Begriff) und den Client des Targets als „Host“. Es ist bekannt, dass der Linux-Kernel ebenfalls ein NVMe-oF-„Target“ und einen „Host“ implementiert.
  • NVM Express ist, wie hier online beschrieben: nvmexpress.org/about, „eine offene Sammlung von Standards und Informationen, um die Vorteile von nichtflüchtigem Speicher in allen Arten von Computerumgebungen, von mobilen Geräten bis hin zu Rechenzentren, voll auszuschöpfen. Die ursprüngliche NVM Express Work Group...ist das Konsortium, das für die Entwicklung der NVM Express-Spezifikation verantwortlich ist....NVM Express-Standards umfassen:
    • • NVM Express (NVMe)-Spezifikation - Die Registerschnittstelle und der Befehlssatz für an die PCI Express-Technologie angeschlossene Speicher mit Industriestandardsoftware, die für zahlreiche Betriebssysteme verfügbar ist. NVMe gilt weithin als der defacto-Industriestandard für PCIe-SSDs.
    • • NVMe Management Interface (NVMe-MI) Spezifikation - Der Befehlssatz und die Architektur für die Out-of-Band-Verwaltung von NVM Express-Speicher (z. B. Erkennung, Überwachung und Aktualisierung von NVMe-Geräten mithilfe eines BMC).
    • • NVMe over Fabrics (NVMe-oF) Spezifikation - Die Erweiterung von NVM Express, die das Tunneln des NVM Express Befehlssatzes über zusätzliche Transporte jenseits der PCIe-Architektur ermöglicht. Die NVMe-over-Fabrics-Technologie erweitert die Vorteile einer effizienten Speicherarchitektur in den größten Rechenzentren der Welt, indem sie das gleiche Protokoll über verschiedene vernetzte Schnittstellen ermöglicht.“
  • Ampere ist ein Beispiel für eine hochmoderne Grafikprozessor-Mikroarchitektur (GPU), die von NVIDIA® entwickelt wurde und in der BlueField® -2X DPU von NVIDIA® enthalten ist.
  • Die architektonischen Merkmale einer GPU können alle oder eine beliebige Teilmenge der folgenden Merkmale umfassen, die alle für Ampere charakteristisch sind:
    • - CUDA Compute Capability 8.0 für A100 und 8.6 für die GeForce 30-Serie
    • - TSMCs 7-nm-FinFET-Prozess für A100
    • - Kundenspezifische Version von Samsungs 8nm-Prozess (8N) für die GeForce 30-Serie
    • - Tensor-Cores der dritten Generation mit FP16-, bfloat16-, TensorFloat-32- (TF32) und FP64-Unterstützung und Sparsity-Beschleunigung
    • - Raytracing-Kerne der zweiten Generation; gleichzeitiges Raytracing, Schattieren und Rechnen für die GeForce 30-Serie
    • - High Bandwidth Memory 2 (HBM2) auf A100 40GB & A100 80GB
    • - GDDR6X-Speicher für GeForce RTX 3090 und 3080
    • - Doppelte FP32-Kerne pro SM auf GA10x-GPUs
    • - NVLink 3.0 mit einem Durchsatz von 50 Gbit/s pro Paar
    • - PCI Express 4.0 mit SR-IOV-Unterstützung (SR-IOV ist nur für A100 reserviert)
    • - Multi-lnstance-GPU-Virtualisierung (MIG) und GPU-Partitionierungsfunktion in A100 mit Unterstützung von bis zu sieben Instanzen
    • - PureVideo Feature-Set K Hardware-Videodekodierung mit AV1-Hardwaredekodierung für die GeForce 30-Serie und Feature-Set J für A100
    • - 5 NVDEC für A100
    • - Neue hardwarebasierte 5-Kern-JPEG-Dekodierung (NVJPG) mit YUV420, YUV422, YUV444, YUV400, RGBA.
  • Der Stand der Technik, der in Verbindung mit bestimmten Ausführungsformen nützlich ist, wird hier online beschrieben: devops.com/the-nvmf-boogie-how-kubernetesand-nvmf-will-rock.
  • NVM Express Revision 1.2.1 und frühere Revisionen davon sind Dokumente, die eine Schnittstelle auf Registerebene für Hostsoftware zur Kommunikation mit einem nichtflüchtigen Speichersubsystem über PCI Express (NVMe over PCIe) definieren. Die online unter nvmexpress.org/wp-content/uploads/NVMe-over-Fabrics-1_0a-2018.07.23-Ratified.pdf verfügbare Spezifikation definiert Erweiterungen von NVMe, die den Betrieb über andere Interconnects (NVMe over Fabrics) ermöglichen.
  • Die Offenbarungen aller in der Beschreibung erwähnten Veröffentlichungen und Patentdokumente sowie der darin direkt oder indirekt zitierten Veröffentlichungen und Patentdokumente werden hiermit durch Verweis einbezogen, mit Ausnahme von Ausschlussklauseln oder Verzichtserklärungen zum Gegenstand.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Die Erfindung wird durch die Ansprüche definiert. Zur Veranschaulichung der Erfindung werden hier Aspekte und Ausführungsformen beschrieben, die in den Anwendungsbereich der Ansprüche fallen können oder auch nicht.
  • Gemäß bestimmten Ausführungsformen greift ein Host über ein emuliertes Speichergerät auf Daten zu, das teilweise in Software, z.B. DPU-Software, implementiert sein kann. Die Implementierung des emulierten Speichergeräts lokalisiert mindestens einen Teil der Daten, auf die der Host über die Schnittstelle des emulierten Speichergeräts zugreift, als in einem einzelnen angeschlossenen Speichergerät aus einer Reihe von Speichergeräten verfügbar, die lokal an den Host, aber nicht an das DPU angeschlossen sind.
  • Die emulierte Speichergeräte-Implementierung in der DPU-Software greift auf das an den Host angeschlossene (d.h. an den Host angeschlossene) Speichergerät zu, unterstützt durch einen Fabric Target Service (entweder auf dem Host oder ausgelagert), was zu einer Reihe von DMAs führt, darunter 2-3 DMAs (auch DMA-Transfers oder Direktspeicherzugriffstransfers genannt), oder es kann ein einzelner Direktspeicherzugriffstransfer verwendet werden, z.B. wie hier beschrieben.
  • Der Begriff „Target-Service“ oder „Fabric Target Service“ oder „Storage Target Service“, wie er hier verwendet wird, ist in der Regel RDMA-basiert und soll Software und/oder Hardware umfassen, die auf einem Speicherzielgerät im Bereich der Netzwerkblockspeicherung oder des SAN (Storage Area Network) läuft. In der SAN-/Netzwerk-Blockspeicher-Terminologie können der „Initiator“ und das „Ziel“ zwei Seiten solcher Netzwerkverbindungen umfassen: der „Initiator“ kann der Host sein, der in der Regel einen Speicherdienst anfordert und Speicheranfragen, ob Lese- oder Schreibanfragen, initiiert; und das „Ziel“ kann das Speichergerät sein, das die vom Initiator an das Ziel gesendeten Lese- und Schreibanfragen bedient.
  • In bestimmten Ausführungsformen ist das SAN intern, zwischen der DPU und dem Host, der über PCle mit der DPU verbunden ist, und ohne Netzwerkanschluss.
  • Ein besonderer Vorteil bestimmter Ausführungsformen besteht darin, dass anstelle der Entwicklung einer völlig anderen Konnektivität, die es einer DPU ermöglicht, für das lokale Laufwerk eines Hosts bestimmte Anforderungen an den Host zu senden, die hierin beschriebenen Ausführungsformen einen bekannten Dienst verwenden, der wie hierin beschrieben modifiziert ist und typischerweise eine Hardware-Offload-Funktion verwendet, um den Host bei der Funktion als Speicherziel zu unterstützen.
  • Alle oder eine beliebige Untergruppe der folgenden Punkte können Lösungen charakterisieren, die gemäß den Ausführungsformen der vorliegenden Erfindung bereitgestellt werden:
    1. a. Ein NVMe over Fabrics (NVMf)-Initiator im SmartNIC ist so konfiguriert, dass er erkennt (z.B. durch Handshake mit dem Ziel) oder so konfiguriert ist, dass er versteht, dass ein bestimmtes Netzwerk-NVMf-Subsystem-Ziel NVMe-Anfragen (z.B. Submission Queue Entry aka SQEs) und nicht NVMf-Anfragen verarbeiten kann.
    2. b. Der NVMf-Initiator in SmartNIc ist in der Lage, SQE zusammenzustellen und an das NVMf-Ziel zu übergeben, z.B. mit neuen herstellerspezifischen Opcodes.
    3. c. Der SmartNIC-Speicherstack ist in der Lage, die ursprünglichen Hostadressen zu verarbeiten, sie in verschiedene Teilanforderungen aufzuteilen und nur eine geeignete Teilmenge davon statt aller an das lokale physische NVMe-Gerät des Hosts zu senden.
    4. d. Der NVMe-oF-Standard wird dahingehend geändert, dass Netzwerkanfragen, die sich auf den lokalen Systemspeicher beziehen, verarbeitet werden können. In der Regel erkennt die Funktionalität auf dem NVMf-Ziel (z.B. die Software auf dem Ziel), dass es sich bei bestimmten Anfragen um NVMe-SQE und nicht um herkömmliche NVMf-Anfragen handelt, entweder durch Vorkonfiguration des Subsystems oder durch Verwendung herstellerspezifischer Opcodes, die dies signalisieren, oder durch eine andere Angabe innerhalb der SQE selbst.
    5. e. Die NVMf-Zielsoftware kann alle Netzwerkdatenbewegungen überspringen.
    6. f. Die NVMf-Zielsoftware übersetzt herstellerspezifische Opcodes, falls verwendet, in Standard-Opcodes.
    7. g. Die NVMf-Zielsoftware übergibt die resultierende SQE an das physische NVMe-Laufwerk.
  • In der Regel wird ein herstellerspezifischer NVMe-Opcode verwendet, um eine Datenanforderung, z.B. wie hier beschrieben, anzuzeigen. Es können herstellerspezifische READIWRITE-Befehle definiert werden. In einer NVMf-Implementierung wird der Opcode beim Eintreffen solcher herstellerspezifischer Befehle durch den ursprünglichen READ/WRITE-Befehl ersetzt, bevor er direkt an die Festplatte übermittelt wird, wobei auch RDMA-Daten in/aus dem Bereitstellungspuffer umgangen werden.
  • Bestimmten Ausführungsformen zufolge können die vorhandenen Felder „PSDT“ und „SGL-Kennung“ in der SQE verwendet werden, um anzuzeigen, dass sich diese SQE auf den Host-Speicher und nicht auf das Netz bezieht, indem sie auf Werte konfiguriert werden, die nicht „Keyd SGL Data Block descriptor“ lauten, wie dies bei einer herkömmlichen NVMf-Anforderung (mit einer Netzadresse) erforderlich ist.
  • Zumindest die folgenden Ausführungsformen sind vorgesehen:
  • Ausführungsform 1. Ein rechnergestütztes System, das in Verbindung mit einem rechnergestützten Gerät und mit einem Fabric-Target-Service in Datenkommunikation mit dem rechnergestützten Gerät arbeitet, wobei das System umfasst:
    • Funktionalität, die sich auf dem rechnergestützten Gerät befindet; und
    • Funktionalität, die sich auf dem Fabric Target Service befindet,
    die, wenn sie in Kombination arbeiten, es dem rechnergestützten Gerät ermöglichen, den Zugang zu den Daten zu koordinieren.
  • Ausführungsform 2. Das rechnergestützte System gemäß einer der hierin beschriebenen Ausführungsformen, das es einem Host ermöglicht, auf ein emuliertes PCI-Speichergerät zuzugreifen, indem das rechnergestützte Gerät zum Koordinieren der Ausführung einer Host-Anforderung, die an einer emulierten Schnittstelle ankommt, unter Verwendung von weniger als 3 Direktspeicherzugriffsübertragungen (DMA) eingesetzt wird, wobei die Host-Anforderung Daten betrifft, die auf mindestens einem lokal an den Host angeschlossenen Hardwarespeichergerät gespeichert sind oder gespeichert werden sollen, wobei die Daten zwischen dem ursprünglichen Anwendungspuffer des Hosts und dem lokal an den Host angeschlossenen Hardwarespeichergerät übertragen werden.
  • Ausführungsform 3. Das rechnergestützte System gemäß einer der hierin beschriebenen Ausführungsformen, wobei die auf dem rechnergestützten Gerät befindliche Funktionalität dazu dient, mindestens eine der folgenden Aufgaben auszuführen:
    1. a. einem Host ein emuliertes Speichergerät zu präsentieren;
    2. b. vom Host die auf dem emulierten Gerät gestellten Anforderungen abzurufen;
    3. c. die Anfragen zu analysieren;
    4. d. festzustellen, dass ein oder mehrere an den Host angeschlossene Speichergeräte die Quelle oder das Ziel von mindestens einem Teil der Daten sind, auf die sich die Anfrage bezieht, und daraufhin festzustellen, dass das eine oder die mehreren an den Host angeschlossenen Speichergeräte an der Anfrage beteiligt sein sollten; und
    5. e. mindestens einer Anforderung mit einer lokalen Speicheradresse vorzubereiten, die auf den ursprünglichen Puffer im Speicher des Hosts verweist, zum Senden an das/die an den Host angeschlossene(n) Hardware-Speichergerät(e).
  • Ausführungsform 4. Das rechnergestützte System gemäß einer der hierin beschriebenen Ausführungsformen, wobei die Anforderung mit einer lokalen Speicheradresse für ein Netzwerkspeicherprotokoll formatiert ist, und wobei die Funktionalität, die sich auf dem Fabric Target Service befindet, dazu dient:
    1. a. die Anforderung mit einer lokalen Speicheradresse zu erkennen, indem neue Opcodes oder Angaben innerhalb eines bestehenden Opcodes erkannt werden; und/oder
    2. b. dementsprechend eine konventionelle, für ein lokales Speicherprotokoll formatierte Anforderung unter Verwendung von Zeigern auf Originalpuffer, die in der Anforderung mit einer lokalen Speicheradresse empfangen wurden, zu erzeugen; und/oder
    3. c. die konventionelle Anforderung an ein lokal angeschlossenes Speichergerät zu senden, das dem lokalen Speicherprotokoll unterliegt, was das lokal angeschlossene Speichergerät veranlasst, mindestens eine DMA-Übertragung von Daten zwischen Host-Puffern und internem Flash-Speicher einzuleiten.
  • Daher erstellt der Target-Service in der Regel eine Anforderung (auch „herkömmliche“ Anforderung genannt) mit lokalen Host-Speicheradressen, nicht mit Netzwerkadressen, die später auf dem physischen NVMe-Gerät veröffentlicht werden.
  • Ausführungsform 5. Das rechnergestützte System gemäß einer der hierin beschriebenen Ausführungsformen, wobei das rechnergestützte Gerät einen Speichergeräte-Emulator, der ein Speichergerät auf einem PCIe-Bus emuliert, und den Fabric-Target-Service umfasst, und wobei der Speichergeräte-Emulator einen Laufwerksemulator umfasst, der ein Laufwerk auf einem PCIe-Bus emuliert.
  • Ausführungsform 6. Das rechnergestützte System gemäß einer der hier beschriebenen Ausführungsformen, wobei der Laufwerksemulator einen NVMe-Laufwerksemulator umfasst, der ein NVMe-Laufwerk auf einem PCIe-Bus emuliert.
  • Ausführungsform 7. Das rechnergestützte System gemäß einer der hierin beschriebenen Ausführungsformen, wobei der NVMe-Laufwerksemulator eine softwaredefinierte netzbeschleunigte Verarbeitung verwendet.
  • Ausführungsform 8. Das rechnergestützte System gemäß einer der hierin beschriebenen Ausführungsformen, wobei der Fabric-Target-Service von einem Host angeboten wird, der lokal an ein Hardware-Speichergerät angeschlossen ist und auch eine Fabric-Target-Hardware-Offload umfasst, die zumindest einige Funktionen im Namen des Fabric-Target-Services ausführt.
  • Ausführungsform 9. Das rechnergestützte System gemäß einer der hierin beschriebenen Ausführungsformen, wobei das Hardwarespeichergerät ein physisches NVMe-Gerät umfasst, das sich in der gleichen Durchgangsdomäne wie das emulierte PCI-Speichergerät befindet, und wobei der ursprüngliche Anwendungspuffer des Hosts sowohl für das physische NVMe-Gerät als auch für das emulierte PCI-Speichergerät unter Verwendung derselben Adresse beschrieben wird.
  • Ausführungsform 10. Das rechnergestützte System gemäß einer der hierin beschriebenen Ausführungsformen, wobei der ursprüngliche Anwendungspuffer Teil eines Speicherraums einer virtuellen Maschine (VM) ist und wobei das physische NVMe-Gerät auf den ursprünglichen Anwendungspuffer zugreift, indem es die PASID-Technologie (Process Address Space ID) auf der physischen NVMe-Seite verwendet.
  • Ausführungsform 11. Das rechnergestützte System gemäß einer der hierin beschriebenen Ausführungsformen, wobei der ursprüngliche Anwendungspuffer Teil eines Speicherraums einer virtuellen Maschine (VM) ist, und wobei das physische NVMe-Gerät auf den ursprünglichen Anwendungspuffer zugreift, indem es eine IOMMU-Domäne (Input-Output Memory Management Unit) erzeugt, die alle Speicherdomänen mehrerer virtueller Maschinen umfasst, das physische NVMe-Gerät in der IOMMU-Domäne (Input-Output Memory Management Unit) einsetzt und mindestens eine ursprüngliche Adresse in eine Adresse übersetzt, die mit mindestens einem der Speicher der mehreren virtuellen Maschinen übereinstimmt.
  • Ausführungsform 12. Das rechnergestützte System gemäß einer der hierin beschriebenen Ausführungsformen, wobei der ursprüngliche Anwendungspuffer Teil eines Speicherraums einer virtuellen Maschine (VM) ist und wobei das physische NVMe-Gerät auf den ursprünglichen Anwendungspuffer zugreift, indem es ATS (Adressübersetzungsdienst) verwendet, um eine Eingabe-Ausgabe-Speicherverwaltungseinheit (IOMMU) Übersetzung von mindestens einer Adresse bereitzustellen.
  • Bei bestimmten Ausführungsformen wird das emulierte PCI-Speichergerät an die virtuelle Maschine (VM) weitergegeben, während das physische, lokal angeschlossene NVMe-Laufwerk dem Host und nicht der VM gehört.
  • Ausführungsform 13. Das rechnergestützte System gemäß einer der hierin beschriebenen Ausführungsformen und mit einer physischen NVMe-Seite, wobei der ursprüngliche Anwendungspuffer Teil eines Speicherraums oder einer VM-Domäne einer virtuellen Maschine (VM) ist, das emulierte PCI-Speichergerät sich in dieser VM-Domäne befindet und wobei das physische NVMe-Gerät, das sich in der Durchgangs-Host-Domäne und nicht in der VM-Domäne befindet, auf den ursprünglichen Anwendungspuffer zugreift, indem es die PASID-Technologie (Process Address Space ID) auf der physischen NVMe-Seite verwendet.
  • Ausführungsform 14. Das rechnergestützte System gemäß einer der hierin beschriebenen Ausführungsformen, wobei der ursprüngliche Anwendungspuffer Teil eines Speicherraums oder einer VM-Domäne einer virtuellen Maschine ist, das emulierte PCI-Speichergerät sich in der VM-Domäne befindet und wobei das physische NVMe-Gerät auf den ursprünglichen Anwendungspuffer zugreift, indem es eine IOMMU-Domäne (Input-Output Memory Management Unit) erzeugt, die Speicherdomänen mehrerer virtueller Maschinen enthält, Bereitstellen des physischen NVMe-Geräts in der IOMMU-Domäne (Input-Output Memory Management Unit) und Übersetzen mindestens einer ursprünglichen Adresse in eine Adresse, die mit mindestens einem der Speicher der mehreren virtuellen Maschinen übereinstimmt.
  • Ausführungsform 15. Das rechnergestützte System gemäß einer der hierin beschriebenen Ausführungsformen, wobei der ursprüngliche Anwendungspuffer Teil eines Speicherraums einer virtuellen Maschine oder VM-Domäne ist, das emulierte PCI-Speichergerät sich in der VM-Domäne befindet und wobei das physische NVMe-Gerät, das sich eher in einer Durchgangs-Host-Domäne als in der VM-Domäne befindet, auf den ursprünglichen Anwendungspuffer zugreift, indem es ATS (Address Translation Service) verwendet, um eine IOMMU-Übersetzung (Input-Output Memory Management Unit) mindestens einer Adresse bereitzustellen.
  • Ausführungsform 16. Das rechnergestützte System gemäß einer der hier beschriebenen Ausführungsformen, wobei das lokale Speicherprotokoll ein PCI-Speicherprotokoll aus der folgenden Gruppe umfasst: NVMe, Virtio-blk, Virtio-scsi, SCSI, SATA, SAS, IDE.
  • Ausführungsform 17. Das rechnergestützte System gemäß einer der hierin beschriebenen Ausführungsformen, wobei das Netzwerkspeicherprotokoll ein Blockspeichernetzwerkspeicherprotokoll umfasst.
  • Ausführungsform 18. Das rechnergestützte System gemäß einer der hierin beschriebenen Ausführungsformen, wobei das Blockspeichernetzwerkspeicherprotokoll ein RDMA-Netzwerk-Blockspeicherprotokoll (Remote Direct Memory Access) aus der folgenden Gruppe umfasst: NVMe-oF; iSER; und SRP.
  • Ausführungsform 19. Ein Verfahren, das es einem Host ermöglicht, auf ein emuliertes PCI-Speichergerät zuzugreifen, wobei das Verfahren die Verwendung eines rechnergestützten Geräts zur Koordinierung der Ausführung einer Host-Anforderung, die an einer emulierten Schnittstelle ankommt, einschließt, während weniger als drei Direktspeicherzugriffsübertragungen (DMA) verwendet werden, wobei sich die Host-Anforderung auf Daten bezieht, die auf mindestens einem lokal an den Host angeschlossenen Hardware-Speichergerät gespeichert sind oder gespeichert werden sollen.
  • Ausführungsform 20. Das Verfahren gemäß einer der hierin beschriebenen Ausführungsformen, wobei der Host auf das emulierte PCI- Speichergerät unter Verwendung mehrerer direkter Speicherzugriffsübertragungen zugreift, und wobei der Zugriff die Freigabe des rechnergestützten Geräts zur Koordinierung des Zugriffs auf die Daten umfasst.
  • Ausführungsform 21. Das Verfahren gemäß einer der hierin beschriebenen Ausführungsformen, wobei die Daten auf dem Speichergerät gespeichert sind und die Anforderung eine Leseanforderung umfasst, bei der Daten über die Direktspeicherzugriffsübertragungen von dem Speichergerät zum Host übertragen werden.
  • Ausführungsform 22. Das Verfahren gemäß einer der hierin beschriebenen Ausführungsformen, wobei die Anforderung eine Schreibanforderung umfasst und die Daten über die Schreibanforderung auf dem Speichergerät gespeichert werden sollen, um dadurch die Daten über die Direktspeicherzugriffsübertragungen vom Host zum Speichergerät zu übertragen.
  • Ausführungsform 23. Das Verfahren gemäß einer der hierin beschriebenen Ausführungsformen, wobei der Zugriff den Speichergeräteemulator in die Lage versetzt, den Zugriff auf die Daten zu koordinieren, indem zwei direkte Speicherzugriffsübertragungen der Daten verwendet werden.
  • Ausführungsform 24. Das Verfahren gemäß einer der hierin beschriebenen Ausführungsformen, wobei die Funktionalität, die sich auf dem Speichergeräteemulator befindet, dazu dient:
    1. a. dem Host ein emuliertes Speichergerät zu präsentieren;
    2. b. vom Host die auf dem emulierten Gerät gestellten Anforderungen abzurufen;
    3. c. die Anfragen zu analysieren; und
    4. d. eine für ein Netzwerkspeicherprotokoll formatierte Anfrage vorzubereiten, die einen speziellen Speicherschlüssel (MKEY) enthält, der auf den Host-Speicher und nicht auf den DPU-Speicher verweist, um so im Rahmen des RDMA-Protokolls (Remote Direct Memory Access) das einfache Kopieren der Daten von einem Puffer in einen anderen im Host zu erleichtern, ohne dass die auf dem Fabric-Target-Service befindliche Funktionalität von dem einfachen Kopieren Kenntnis erhält.
  • Ausführungsform 25. Das Verfahren gemäß einer der hierin beschriebenen Ausführungsformen, wobei die Funktionalität, die sich auf dem Fabric-Target-Service befindet, dazu dient:
    1. a. die für das Netzwerkspeicherprotokoll formatierte Anfrage von der auf dem Speicheremulator befindlichen Funktionalität abzurufen;
    2. b. eine DMA-Übertragung von RDMA-Daten an einen Staging-Puffer im Host-Speicher vorzunehmen, was tatsächlich zu einem einfachen Kopieren der Daten von einem Puffer in einen anderen im Host führt, ohne dass die auf dem Fabric-Target-Service befindliche Funktionalität von dem einfachen Kopieren Kenntnis erhält;
    3. c. eine für ein lokales Speicherprotokoll formatierte Anfrage zu erzeugen; und
    4. d. die für ein lokales Speicherprotokoll formatierte Anforderung, die vom Fabric-Target-Service erzeugt wurde, an ein lokal angeschlossenes Hardware-Laufwerk zu senden, das für das lokale Speicherprotokoll formatiert ist, wodurch das lokal angeschlossene Speichergerät veranlasst wird, DMAs von Daten zwischen Host-Puffern und internem Flash-Speicher zu initiieren.
  • Ausführungsform 26. Das Verfahren gemäß einer der hierin beschriebenen Ausführungsformen, bei dem das rechnergestützte Gerät eine DPU mit einem Emulator für ein Speichergerät umfasst.
  • Ausführungsform 27. Das Verfahren gemäß einer der hierin beschriebenen Ausführungsformen, wobei das Hardwarespeichergerät ein NVMe umfasst und der Speichergeräteemulator des rechnergestützten Geräts einen NVMe-Laufwerksemulator umfasst, der ein NVMe-Laufwerk auf einem PCIe-Bus emuliert.
  • Ausführungsform 28. Das Verfahren gemäß einer der hierin beschriebenen Ausführungsformen, wobei die DPU mindestens einen Teil der Daten, auf die sich eine von einem Host über das emulierte Speichergerät gestellte Anfrage bezieht, als in mindestens einem Speichergerät /mehreren Speichergeräten, die lokal an den Host, aber nicht an die DPU angeschlossen ist/sind, verfügbar oder auf diese ausgerichtet findet.
  • Ausführungsform 29. Das Verfahren gemäß einer der hierin beschriebenen Ausführungsformen, wobei die DPU einen vom Host angebotenen Fabric-Target-Service verwendet, um auf das einzelne an den Host angeschlossene Speichergerät zuzugreifen, was zu einem Satz von DMAs führt, der mindestens einen und nicht mehr als drei DMAs umfasst.
  • Ausführungsform 30. Das rechnergestützte System gemäß einer der hierin beschriebenen Ausführungsformen, wobei der ursprüngliche Anwendungspuffer des Hosts Teil einer Domäne ist, die im Speicherraum einer Virtuellen Maschine enthalten ist, das emulierte PCI-Speichergerät sich in der Domäne befindet, die im Speicherraum der Virtuellen Maschine enthalten ist, und wobei ein physisches NVMe-Gerät, das sich in der Durchgangs-Host-Domäne befindet und nicht in der Domäne, die im Speicherraum der Virtuellen Maschine enthalten ist, auf den ursprünglichen Anwendungspuffer aufgrund des rechnergestützten Geräts zugreift, die VM-Adressen in Host-Adressen umwandelt, basierend auf einer Zuordnung, die in das rechnergestützte Gerät durch einen Hilfstreiber auf dem Host übergeben wird, der den Gast-zu-Host-Speicherzuordnungen der Virtuellen Maschine ausgesetzt ist.
  • Ausführungsform 31. Das Verfahren gemäß einer der hierin beschriebenen Ausführungsformen, wobei das Hardware-Speichergerät eine der folgenden Gruppen umfasst: NVMe, Virtio-blk, Virtio-scsi, SCSI, SATA, SAS, IDE und der Speichergerätsemulator eine der folgenden Gruppen umfasst: NVMe-, Virtio-blk-, Virtio-scsi-, SCSI-, SATA-, SAS-, IDE-Laufwerksemulator, der ein Speicherlaufwerk auf einem PCIe-Bus emuliert.
  • Jedes Merkmal eines Aspekts oder einer Ausführungsform kann auf andere Aspekte oder Ausführungsformen angewandt werden, und zwar in jeder geeigneten Kombination. Insbesondere kann jedes Merkmal eines Verfahrensaspekts oder einer Ausführungsform auf einen Geräteaspekt oder eine Ausführungsform angewandt werden und umgekehrt.
  • Figurenliste
    • 1 ist eine vereinfachte Blockdiagrammdarstellung einer Rechenzentrumsumgebung, die sich für die Umsetzung von Ausführungsformen der Erfindung eignet.
    • 2 ist eine vereinfachte Blockdiagrammdarstellung eines Datenflusses, der auf eine Datenanforderung reagiert und drei direkte Speicherzugriffsübertragungen umfasst.
    • 3 ist eine vereinfachte Blockdiagrammdarstellung eines Datenflusses gemäß einer beliebigen Ausführungsform der Erfindung, die nur eine einzige direkte Speicherzugriffsübertragung umfasst.
    • 4 ist eine vereinfachte Blockdiagrammdarstellung eines Datenflusses gemäß einer beliebigen Ausführungsform der Erfindung, die zwei statt drei direkte Speicherzugriffsübertragungen umfasst.
    • Die 5a und 5b sind vereinfachte Flussdiagrammdarstellungen von Algorithmen, die von der Funktionalität des rechnergestützten Geräts bzw. von der Funktionalität des Fabric-Target-Service ausgeführt werden können. Diese Methoden zusammen sollen sicherstellen, dass weniger als drei Datenübertragungen stattfinden. Die Methoden beziehen sich auf schriftliche IO, aber das Gleiche gilt mutatis mutandis auch, wenn es sich bei der Anforderung um eine Leseanforderung und nicht um eine Schreibanforderung handelt. Alle oder eine geeignete Teilmenge der dargestellten Vorgänge können in beliebiger Reihenfolge, z.B. in der dargestellten Reihenfolge, durchgeführt werden.
    • 6 ist ein vereinfachtes Blockdiagramm, das den Betrieb eines Fabric-Target-Offloads zeigt.
  • DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
  • Der Einfachheit halber wird in dieser Spezifikation beispielhaft auf NVMe verwiesen. Diese Verweise sollen jedoch nicht einschränkend sein, und generell kann jedes geeignete lokale oder PCI-Speicherprotokoll verwendet werden.
  • Der Einfachheit halber wird in dieser Beschreibung beispielhaft auf NVMf bzw. NVMe-oF verwiesen. Diese Verweise sind jedoch nicht als einschränkend zu verstehen, und es kann generell jedes geeignete Netzwerkspeicherprotokoll verwendet werden.
  • Der Einfachheit halber bezieht sich diese Spezifikation beispielhaft auf SNAP™. Solche Verweise sollen jedoch nicht einschränkend sein, und generell kann jeder Speichergeräteemulator (z. B. ein smartNIC-Dienst) verwendet werden, der ein NVMe-(oder virtio-blk-) Speicher-PCIe-Gerät für den Host emuliert, indem er eine Speicher-PCI-Geräteschnittstelle für einen Host freigibt (oder den Zugriff des Hosts auf das Speicher-PCI-Gerät ermöglicht).
  • Der hier verwendete Begriff „SmartNIC“ kann jede Netzwerkschnittstellenkarte (d.h. PCIe-Karte) umfassen, die in einen Server oder ein Speichergerät eingesteckt wird, um den Anschluss an ein Ethernet-Netzwerk zu ermöglichen. Bei einer DPU-basierten SmartNIC wird neben der Konnektivität auch die Verarbeitung des Netzwerkverkehrs auf der NIC implementiert, die im Falle einer Basis-NIC von der CPU durchgeführt werden müsste. Ein DPU (Data Processing Unit)-basierter SmartNIC kann als ASIC, FPGA oder System-on-a-Chip (SOC) ausgeführt sein.
  • Wenn hier von „emulierten“ Speichergeräten oder der „Emulation“ eines Speichergeräts die Rede ist, ist damit eine PCI-Geräteschnittstelle gemeint, die einem Host zur Verfügung gestellt wird. So kann ein (Hardware-)Gerät, das ursprünglich als Netzwerkgerät konzipiert wurde, auch als Speichergerät verwendet werden, da das Gerät eine Speicherschnittstelle offenlegt oder den Zugriff darauf ermöglicht. Es wird davon ausgegangen, dass ein Gerät, das eine Schnittstelle des Typs X bereitstellt oder den Zugriff darauf ermöglicht, selbst als Gerät des Typs X betrachtet werden kann. Ein SmartNIC-Gerät verfügt beispielsweise normalerweise über eine NIC-Schnittstelle oder sollte über eine solche verfügen (und in ähnlicher Weise sollte ein NVMe-Gerät über eine NVMe-Schnittstelle verfügen usw.), in der Praxis können jedoch aufgrund der Programmierbarkeit des SmartNIC-Geräts, die der Hardware des SmartNIC-Geräts diese Flexibilität oder Emulationsfähigkeit verleiht, auch andere Schnittstellen bereitgestellt werden.
  • In einigen Anwendungsfällen kann SNAP™, das auf einer SmartNIC ausgeführt wird, NVMe-Laufwerke verwenden, die sich auf dem Host befinden. Konventionell besteht in diesem Fall die Lösung darin, dass der Host die NVMe-Laufwerke als Netzwerkspeicher bereitstellt und der SmartNIC dann eine Verbindung zu diesem Netzwerkspeicher herstellt, wie es jeder andere Netzwerk-Client auch tun kann. Wie in 2 gezeigt, hat diese Lösung jedoch den Nachteil, dass die Daten dreimal über die PCI-Schnittstelle übertragen werden:
    1. 1. Host-Original-Anwendungspuffer in SmartNIC-Puffer
    2. 2. SmartNIC-Puffer zum Host-NVMf-Target-Staging-Puffer
    3. 3. Host-NVMF-Target-Staging-Puffer zum lokalen NVMe-Gerät
  • Bestimmte Ausführungsformen hierin versuchen, die gleiche Funktionalität mit nur zwei solchen Übertragungen oder sogar nur einer einzigen PCI-Übertragung zu erreichen, bei der die Daten vom ursprünglichen Anwendungspuffer des Hosts direkt an das lokale NVMe übertragen werden. Beide Möglichkeiten führen zu einer besseren Leistung.
  • Bestimmte Ausführungsformen ermöglichen es einem Host, auf ein emuliertes PCI-Speichergerät zuzugreifen, wobei weniger als drei Direktspeicherzugriffsübertragungen (DMA) verwendet werden, indem ein rechnergestütztes Gerät zur Koordinierung der Ausführung einer Host-Anforderung verwendet wird, die an einer emulierten Schnittstelle ankommt, wobei sich die Host-Anforderung auf Daten bezieht, die auf mindestens einem lokalen Hardwarespeichergerät gespeichert sind oder gespeichert werden sollen, das direkt an den Host angeschlossen ist.
  • Die Begriffe „lokal“, „lokal angeschlossen“ und „direkt angeschlossen“, wie sie hier verwendet werden, sollen Situationen einschließen, in denen ein (typischerweise Hardware-) Speichergerät über einen Peripheriebus, wie z.B. einen PCIe-Bus, für einen Host verfügbar ist, dessen Root-Punkt der Host ist. Steht das Speichergerät dem Host dagegen nur über ein Netzwerk zur Verfügung, so kann das Speichergerät (z.B. auch wenn der Root-Punkt über einen zweiten PCI-Bus mit dem Host verbunden ist) nicht als lokal mit dem Host, nicht als lokal mit dem Host verbunden und nicht als direkt mit dem Host verbunden angesehen werden. Wenn das Speichergerät dem Host nur über einen PCIe-Bus zur Verfügung steht, dessen Root nicht der Host ist, kann das Speichergerät auch nicht als lokal zum Host betrachtet werden (z. B. selbst wenn die Root über einen zweiten PCI-Bus mit dem Host verbunden ist), kann nicht als lokal mit dem Host verbunden betrachtet werden und kann nicht als direkt mit dem Host verbunden betrachtet werden.
  • Die Anzahl der Übertragungen mit direktem Speicherzugriff (DMA) kann z.B. wie folgt ermittelt werden: Wenn zusätzliche PCI-Steckplätze verfügbar sind, kann ein PCI-Analysator an denselben PCI-Bus angeschlossen werden, an den auch die DPU und das NVMe-Laufwerk, die mit den Übertragungen verbunden sind, angeschlossen sind. Nach einer einfachen Lese- oder Schreib-IO-Anforderung an das emulierte Speichergerät wird die Anzahl der DMA-Übertragungen, ob 1, 2 oder 3, deutlich am Ausgang des Analysators angezeigt. Wenn sich die CPU und das NVMe-Laufwerk nicht beide auf demselben PCI-Anschluss befinden, können zwei PCI-Analysatoren verwendet werden, jeweils einer für die DPU und für das NVMe-Gerät. Das NVMe-Gerät kann aus dem Steckplatz herausgezogen und wieder eingesteckt werden, wobei vorhandene Raiser dazwischen verwendet werden, und der Raiser kann auch mit dem Analysator verbunden werden.
  • Der Begriff „lokal“ wird hier verwendet, um sich auf ein Gerät (typischerweise ein Hardware-Speichergerät) zu beziehen, dessen Datenkommunikation mit dem Host nicht über ein Netzwerk erfolgt, sondern typischerweise darauf zurückzuführen ist, dass das Gerät über einen Peripheriebus wie PCle direkt an den Host angeschlossen ist.
  • Typischerweise umfasst die Vorrichtung einen Geräteemulator, der so konfiguriert ist, dass er ein Speichergerät, wie z. B. ein NVMe-Speicher-PCIe-Gerät, an den Host emuliert, ohne darauf beschränkt zu sein. Der Host kann in dieser Ausführungsform ein NVMe-Gerät mit einem Host-NVMe-Treiber umfassen.
  • Ausführungsformen der Erfindung sind in den 1-4 dargestellt. Zunächst illustriert 1 ein Rechenzentrum mit mehreren Knotenpunkten. Ein Rechenzentrum kann jeden physischen Satz von Computersystemen und/oder zugehörigen Telekommunikations- und/oder Speichersystemen umfassen. In der Praxis bieten beispielsweise bestimmte Rechenzentren Amazon-Webdienste an, obwohl diese Dienste vom Standpunkt des Endbenutzers aus gesehen von einer virtuellen Maschine über das Internet bereitgestellt werden, so dass die Rechenzentren, die den Dienst anbieten, für den entfernten Endbenutzer, der den Dienst in Anspruch nimmt, transparent sind.
  • Typischerweise umfasst ein Rechenzentrum Backup-Komponenten und/oder eine Infrastruktur für die Stromversorgung und/oder Datenkommunikationsverbindungen und/oder Umgebungskontrollen, wie z. B. Klimaanlagen und/oder Brandbekämpfung, und/oder Sicherheitseinrichtungen.
  • Die Daten können vom Host eines bestimmten Knotens zu einem lokalen Laufwerk im Knoten des Hosts (auch Fluss 1 genannt) oder zu einem entfernten Netzspeicher (auch Fluss 2 genannt) oder zu einem Laufwerk eines anderen Knotens (Fluss 3) fließen. Die
  • 2-4 zeigen eine Implementierung von Fluss 1, bei der Daten von einem Host zu einem lokalen Laufwerk (oder einem anderen Hardwarespeichergerät) im Knoten des Hosts fließen. Es wird deutlich, dass Fluss 1 besonders für Anwendungsfälle geeignet ist, in denen es wünschenswert ist, dass alle lOs zunächst an das emulierte Gerät gehen, d. h. an das Gerät, das von der DPU-Speicherschnittstelle präsentiert wird. Anschließend entscheidet die Logik der DPU, ob eine bestimmte Anfrage oder Teile davon das/die lokale(n) Host-Laufwerk(e) einbeziehen muss/können oder nicht.
  • In 2 umfasst der herkömmliche Datenfluss als Reaktion auf eine Anforderung drei direkte Speicherzugriffsübertragungen, die mit den DMA-Nummern 1, 2 und 3 gekennzeichnet sind. Der Übersichtlichkeit halber wird in den 2 bis 4 die Datenanforderung als Schreibanforderung dargestellt, alternativ könnte die Anforderung jedoch auch eine Leseanforderung sein. Es ist klar, dass der Target-Service an die Hardware ausgelagert werden kann oder auch nicht.
  • In der Ausführungsform von 3 umfassen die vorgenannten weniger als drei direkten Speicherzugriffsübertragungen nur eine einzige PCI-Übertragung, so dass die Daten direkt zwischen dem ursprünglichen Anwendungspuffer des Hosts und einer Hardwarespeichereinrichtung, die in Bezug auf den Host lokal ist oder direkt an den Host angeschlossen ist, übertragen werden, wobei das Gerät die Übertragung koordiniert, indem es die lokale Speichereinrichtung veranlasst, direkt auf einen Host-Datenpuffer zuzugreifen, der sich im Host befindet, einschließlich der Weiterleitung einer an das rechnergestützte Gerät übergebenen Anforderung an die lokale Speichereinrichtung.
  • Der Host-NVMe-Treiber, der das SNAP™ emulierte NVMe-Gerät betreibt, kann in der Ausführungsform von 3 und 4 derselbe sein wie in 2. Wie jedoch durch die Verwendung des Begriffs „modifiziert“ in 3 und 4 angedeutet, unterscheidet sich der vom SNAP™ und dem Target-Service durchgeführte Fluss, der typischerweise auf eine Datenanforderung reagiert, von den Flüssen, die von ihren jeweiligen Gegenstücken in 2 durchgeführt werden, in allen oder einer beliebigen Teilmenge der folgenden Arten:
    1. 1. SNAP™ NVMF-Initiator sendet eine NVMe-Anfrage (SQE) statt einer NVMe-oF-Anfrage (Befehlskapsel). Typischerweise enthält die NVMe-Anfrage Zeiger auf den lokalen Systemspeicher, die aus den Zeigern erstellt wurden, die ursprünglich vom Host an das SNAP™emulierte NVMe-Gerät gesendet wurden, und/oder die NVMe-Anfrage verwendet einen herstellerspezifischen Opcode anstelle der Standard-Opcodes für Lesen und Schreiben. Falls gewünscht, können auch andere Alternativen (z.B. ein separates vordefiniertes Netzwerksubsystem) implementiert werden.
    2. 2. Die NVMf-Zielsoftware empfängt eine Anforderung, analysiert die herstellerspezifischen Opcodes und schließt daraus, dass es sich um eine NVMe-Anforderung und nicht um eine NVMe-oF-Anforderung handelt, typischerweise auf der Grundlage der herstellerspezifischen Opcodes (oder auf der Grundlage einer anderen Alternative, z.B. eines separaten vordefinierten Netzwerksubsystems oder einer anderen Angabe in der NVMe-Anforderung).
    3. 3. Die NVMf-Zielsoftware muss keine Datenbewegungen im Netzwerk durchführen (da die Daten bereits im Host-Speicher vorhanden sind).
    4. 4. Die NVMf-Zielsoftware ersetzt die Opcodes (die herstellerspezifisch sein können) durch Standard-Lese-/Schreib-Opcodes, wenn dies die Anzeigemethode war, und übermittelt diese an das lokale NVMe-Gerät.
  • Es wird deutlich, dass in den Ausführungsformen der 3 und 4 das physische NVMe-Gerät auf den ursprünglichen Anwendungspuffer zugreift. Dies kann dadurch erreicht werden, dass keine Input-Output-Memory-Management-Einheit (IOMMU) verwendet wird oder eine einfache Durchgangskonfiguration der Input-Output-Memory-Management-Einheit (IOMMU) verwendet wird, so dass sich sowohl das physische NVMe-Gerät als auch das SNAP™emulierte NVMe-Gerät in derselben Durchgangsdomäne befinden. Der ursprüngliche Anwendungspuffer kann dann sowohl für das physische NVMe-Gerät als auch für das von SNAP™ emulierte NVMe-Gerät über dieselbe Adresse beschrieben werden. Im Gegensatz dazu ist in einer virtualisierten Umgebung der ursprüngliche Anwendungspuffer Teil des Speicherbereichs einer virtuellen Maschine (VM). Daher kann eine geeignete Option verwendet werden, um sicherzustellen, dass das physische NVMe-Gerät auf den ursprünglichen Anwendungspuffer zugreifen kann, z.B., aber nicht beschränkt auf eine der folgenden Optionen:
    1. a. Verwendung der PASID-Technologie (Process Address Space ID) auf der physischen NVMe-Festplattenseite;
    2. b. Verwendung einer physischen NVMe-Festplatte, die virtuelle Funktionen (VFs) unterstützt, und Platzierung einer solchen VF in der gleichen Domäne wie die VM;
    3. c. Erstellen einer neuen IOMMU-Domäne (Input-Output Memory Management Unit), die VM-Speicherdomänen enthält, typischerweise alle Speicherdomänen aller VMs, und Einfügen des physischen NVMe-Geräts in diese Domäne. Dann können z. B. in der Software SNAP™ die ursprünglichen Adressen in Adressen übersetzt werden, die dem korrekten VM-Speicher in der neuen Domäne entsprechen, die sie alle enthält.
    4. d. Übertragung der VM-Speicherzuordnungstabelle zu den Rechneradressen in SNAP™. Anschließend kann SNAP™ die Hostadressen entsprechend dieser Zuordnung übersetzen und in der physischen NVMe-Anforderung verwenden.
    5. e. Verwendung von ATS (Address Translation Service), um die Übersetzung der Adressen durch die IOMMU (Input-Output Memory Management Unit) zu erhalten.
  • Um den modifizierten Target-Service von 3 (oder 4) zu erzeugen, wird die hier beschriebene Funktionalität zu einem Target-Service hinzugefügt. Dazu kann ein zielähnliches Subsystem verwendet werden, z.B. unter Verwendung von Literatur des NVM-Express-Konsortiums, um Software zu schreiben, die den NVM-Express-Standards entspricht und auf einem Host-System laufen kann, das in Datenkommunikation mit einer DPU stehen kann. Die DPU kann auf jede geeignete Weise in einen Server eingesteckt und auf jede geeignete Weise mit einem Hostsystem verbunden werden.
  • Der NVM-Express-Standard kann verwendet werden, um die nicht standardisierte NVMe-oF-Anfrage zu standardisieren und zu ermöglichen, dass die Anfrage Zeiger auf den Host-Speicher und nicht auf den Speicher eines entfernten Knotens enthält. In den NVMe- und NVMe-oF-Standards ist eine Anfrage so definiert, dass sie eine von zwei Optionen zur Angabe von Zeigern enthält, und wenn NVMe-oF RDMA verwendet wird, ist das Adressierungsschema der entfernte Speicher (was z.B. im NVMe-Standard als „keyed SGL“ bezeichnet werden kann). Wird diese Anforderung jedoch aufgehoben, kann das NVMe-oF-RDMA-Protokoll standardmäßige lokale Hostadressen weitergeben. Da es sich bei der lokalen Host-Adresse um den Speicher des Speichersystems handelt, kann der Standard durch geeignete Sicherheitsfunktionen und Verhandlungen erweitert werden, die die Verwendung bestimmter Adressen erlauben und die Verwendung bestimmter anderer Adressen verbieten. Wenn die Zielfunktionalität Teil des Hardware-Offloads ist, kann die interne hardwareprogrammierbare CPU so programmiert werden, dass sie die hier beschriebene Target-Service-Funktionalität ausführt.
  • Der Target-Service kann zum Beispiel auf einem x86-Host laufen.
  • Zur Erstellung des modifizierten SNAP™ (oder allgemeiner, des rechnergestützten Geräts) von 3 (oder 4) können Tools und SDKs für die Entwicklung mit BlueField® verwendet werden, um die hierin beschriebenen Funktionen auf dem rechnergestützten Gerät bereitzustellen.
  • Bestimmten Ausführungsformen zufolge können die Host-Zugriffe auf das emulierte PCI-Speichergerät zu mehreren direkten Speicherzugriffsübertragungen führen, und wobei der Zugriff die Befähigung des rechnergestützten Geräts einschließt, den Zugriff auf die Daten zu koordinieren.
  • Es ist klar, dass eine einzelne Anfrage mehrere an den Host angeschlossene Laufwerke umfassen kann. Alternativ oder zusätzlich ist es möglich, dass weniger als alle gestellten Anfragen (z.B. Anfragen, die von einem Host über ein emuliertes Speichergerät gestellt werden) über ein Host-Laufwerk bedient werden, da Teile der Anfrage(n) weiterhin über das Netz bedient werden können.
  • Daher ist gemäß einer Ausführungsform die Funktionalität, die sich auf dem rechnergestützten Gerät befindet, in der Lage, mindestens einen der folgenden Schritte auszuführen:
    1. a. einem Host ein emuliertes Speichergerät zu präsentieren;
    2. b. vom Host Anfragen zu erhalten, die an das emulierte Gerät gesendet werden;
    3. c. die Anfragen zu analysieren;
    4. d. festzustellen, dass ein oder mehrere an den Host angeschlossene Speichergeräte die Quelle oder das Ziel von mindestens einem Teil der Daten sind, auf die sich die Anfrage bezieht, und daraufhin festzustellen, dass das eine oder die mehreren an den Host angeschlossenen Speichergeräte an der Anfrage beteiligt sein sollten; und
    5. e. mindestens eine Anforderung mit einer lokalen Speicheradresse vorzubereuten, die auf den ursprünglichen Puffer im Speicher des Hosts verweist, zum Senden an das/die lokale(n) Hardwarespeichergerät(e), das/die an den Host angeschlossen ist/sind.
  • Es versteht sich von selbst, dass alle oder eine beliebige Teilmenge der oben genannten Vorgänge durchgeführt werden können, wie z.B. alle Vorgänge a - e oder die Vorgänge a - c und e ohne d.
  • Bestimmten Ausführungsformen zufolge ist die Anforderung mit einer lokalen Speicheradresse für ein Netzwerkspeicherprotokoll formatiert, wobei die Funktionalität, die sich auf einem Fabric Target Service in Datenkommunikation mit dem rechnergestützten Gerät befindet, dazu dient:
    1. a. die Nicht-Standard-NVMF-Anfrage zu erkennen, indem sie neue Opcodes oder Angaben innerhalb eines bestehenden Opcodes erkennt;
    2. b. dementsprechend eine konventionelle NVMe-Anforderung (z.B. mit einer Netzwerkadresse) zu erzeugen, die für ein lokales Speicherprotokoll formatiert ist und Zeiger auf ursprüngliche Puffer verwendet, die in der nicht standardmäßigen NVMf-Anforderung empfangen wurden; und
    3. c. die herkömmliche NVMe-Anfrage an ein lokal angeschlossenes Speichergerät zu senden, das dem lokalen Speicherprotokoll unterliegt, wodurch das lokal angeschlossene Speichergerät veranlasst wird, mindestens eine DMA-Übertragung von Daten zwischen Host-Puffern und internem Flash-Speicher einzuleiten.
  • Bestimmten Ausführungsformen zufolge umfasst das Netzwerkspeicherprotokoll ein Blockspeicher-Netzwerkspeicherprotokoll, z.B. ein Netzwerk-Blockspeicherprotokoll mit direktem Fernspeicherzugriff (RDMA) aus der folgenden Gruppe, die jedoch nicht darauf beschränkt ist: NVMe-oF, iSER, SRP. Das lokale Speicherprotokoll kann ein PCI-Speicherprotokoll aus der folgenden Gruppe umfassen, ist aber nicht darauf beschränkt: NVMe, Virtio-blk, Virtio-scsi, SCSI, SATA, SAS, IDE.
  • In der Ausführungsform von 4 umfasst der Zugriff die Möglichkeit, dass der Emulator des Speichergeräts den Zugriff auf die Daten koordiniert, indem er zwei direkte Speicherzugriffsübertragungen der Daten verwendet.
  • Bestimmte Ausführungsformen sehen vor, dass die Funktionalität des Speichergeräte-Emulators dazu dient:
    1. a. dem Host ein emuliertes Speichergerät zu präsentieren;
    2. b. vom Host die auf dem emulierten Gerät gestellten Anforderungen abzurufen;
    3. c. die Anfragen zu analysieren; und
    4. d. eine für ein Netzwerkspeicherprotokoll formatierte Anforderung vorzubereiten, die einen Speicherschlüssel (MKEY) enthält, der auf den Host-Speicher verweist, z.B. anstatt auf den DPU-Speicher, wie es ein herkömmlicher Speicherschlüssel tun würde, um dadurch innerhalb eines RDMA-Protokolls das einfache Kopieren der Daten von einem Puffer in einen anderen im Host zu erleichtern, ohne dass die auf dem Fabric-Target-Service befindliche Funktionalität von dem einfachen Kopieren Kenntnis erhält.
  • Es versteht sich von selbst, dass jede geeignete Methode eingesetzt werden kann, um einen Speicherschlüssel (MKEY) zu erzeugen und zu verwenden, der auf den Host-Speicher verweist. Ein geeigneter Aufruf der DPU-Firmware (BlueField®) erzeugt beispielsweise einen MKEY, der sich auf den Speicher eines anderen Systems anstelle des Speichers des Aufrufers erstreckt (z.B. einer Anwendung, die auf internen Verarbeitungseinheiten in der DPU läuft, die die Logik speichert, die die Methoden der 5a - 5b und/oder andere hier beschriebene Methoden durchführt). Dieser MKEY entspricht den RDMA-spezifischen MKEY-Anforderungen und kann daher genauso verwendet werden wie jeder herkömmliche MKEY.
  • Die Funktionalität, die sich auf dem Fabric-Target-Service befindet, ist normalerweise funktionsfähig um:
    1. a. die für das Netzwerkspeicherprotokoll formatierte Anfrage von der auf dem Speicheremulator befindlichen Funktionalität abzurufen;
    2. b. eine DMA-Übertragung von RDMA-Daten an einen Staging-Puffer im Host-Speicher vorzunehmen, was tatsächlich zu einem einfachen Kopieren der Daten von einem Puffer in einen anderen im Host führt, ohne dass die auf dem Fabric-Target-Service befindliche Funktionalität von dem einfachen Kopieren Kenntnis erhält;
    3. c. eine für ein lokales Speicherprotokoll formatierte Anfrage zu erzeugen; und
    4. d. die für ein lokales Speicherprotokoll formatierte Anforderung, die vom Fabric-Target-Service generiert wurde, an ein lokal angeschlossenes Hardware-Laufwerk zu senden, das für das lokale Speicherprotokoll formatiert ist, wodurch das lokal angeschlossene Speichergerät veranlasst wird, DMAs von Daten zwischen Host-Puffern und internem Flash-Speicher zu initiieren.
  • Typischerweise umfasst das rechnergestützte Gerät eine DPU mit einem Speichergeräteemulator. Die DPU kann eine BlueField® DPU umfassen, und typischerweise umfasst das lokale Speichergerät ein NVME, und der Speichergeräteemulator des rechnergestützten Geräts umfasst einen NVMe-Laufwerksemulator, der ein NVMe-Laufwerk auf einem PCIe-Bus emuliert. Der NVMe-Laufwerksemulator kann beispielsweise das Mellanox NVMe SNAP™Gerät umfassen).
  • Der hier verwendete Begriff „Software-defined Network Accelerated Processing“ (auch bekannt als SNAP™) kann jedes Subsystem oder jede Technologie umfassen, das/die eine hardwarebeschleunigte Virtualisierung von NVMe-Speicher ermöglicht und den Netzwerkspeicher wie eine lokale NVMe-SSD aussehen lässt, z.B. durch Emulation eines NVMe-Laufwerks oder eines anderen Speichergeräts am PCIe-Bus. Das Host-Betriebssystem/der Hypervisor verwendet in der Regel seinen herkömmlichen NVMe-Treiber, ohne zu wissen, dass die Kommunikation nicht von einem physischen Laufwerk, sondern vom NVMe SNAP™ beendet wird. Über das NVMe SNAP™ Framework kann jede beliebige Logik auf die Daten angewendet und über das Netzwerk, entweder über das Ethernet- oder das InfiniBand-Protokoll, an ein Speicherziel übertragen werden.
  • NVMe SNAP™ ermöglicht es den Endnutzern, ihre eigenen Speicherlösungen auf der Grundlage des bereitgestellten Rahmens zu implementieren. NVMe SNAP™ stellt eine Schnittstelle zu Kernen zur Verfügung oder ermöglicht den Zugriff darauf (z.B. den Zugriff der Kerne auf die Schnittstelle), wie z.B. BlueField® SmartNIC ARM® Kerne, zur Implementierung der Steuerung der Speicherlösung. NVMe SNAP™ ist in das beliebte Open-Source-Projekt Storage Performance Development Kit (SPDK) integriert und bietet Kunden die Möglichkeit, in einer vertrauten Umgebung zu programmieren. In der Regel stehen den Endnutzern einer oder beide Datenpfade zur Verfügung - der erste, Full-Offload, nutzt einen Hardware-Offload für NVMe SNAP™, der den Datenverkehr von NVMe PCle übernimmt, ihn in NVMe-oF (z. B. RoCE (RDMA Over Converged Ethernet) oder Infiniband) konvertiert und direkt an das Netzwerk überträgt, typischerweise alles in Hardware. Es ist klar, dass bei dieser Option die Möglichkeit fehlt, dass Software, die auf ARM-Kernen läuft, die Daten „anfassen“ oder das Speicherprotokoll ändern kann. Ein zweiter Datenpfad, der zur Verfügung gestellt werden kann, ermöglicht es einem SPDK, das auf den ARM-Kernen läuft, den von der NVMe-PCIe kommenden Datenverkehr zu beenden und jegliche Kundenlogik auf der NVMe-PCIe zu implementieren und die Daten dann an das Netzwerk zu übertragen. Dieser Pfad, bei dem ARM-Cores im Datenpfad verwendet werden, bietet die Flexibilität, jede Art von Speicherlösung inline zu implementieren. Bei beiden oben genannten Datenpfadoptionen läuft die Steuerebene in der Regel immer in den ARM-Cores, die den Datenverkehr zu seinem Ziel orchestrieren.
  • Endbenutzer können maßgeschneiderte Virtualisierungslösungen auf BlueField® SmartNICs mit dem NVMe SNAP™ Framework entwickeln, das BlueField® SoC ARM-Cores nutzt, um die integrierten Hardwarebeschleunigungs-Engines zu nutzen.
  • NVMe SNAP™ ist durch alle oder eine beliebige Teilmenge der folgenden Merkmale gekennzeichnet:
    • • Implementiert Hardware-interne Speichervirtualisierung
    • • Programmierbares NVMe SNAP™ Framework ermöglicht die Integration in jede Speicherlösung, die auf einem beliebigen Netzwerkprotokoll basieren kann
    • • Ermöglicht die Optimierung von Speicherressourcen für CAPEX- und OPEX-Einsparungen
    • • Freisetzung von CPU-Ressourcen des Rechenknotens durch Auslagerung von Netzwerk- und Speicherdatenpfaden
    • • Zwei-in-Eins-Lösung, die NVMe SNAP™ mit einer intelligenten NIC wie BlueField® SmartNIC kombiniert:
      • - Netzwerkadapterkarte mit zwei Anschlüssen für 25/100 Gb/s
      • - BlueField® SoC: 16 ARM A72 Kerne
      • - Hardware-Offload-Beschleuniger
      • - DDR4-Speicher
      • - PCIe 3.0/4.0-Schnittstelle
      • - FHHL-Formfaktor
      • - Anwendungsfälle, die alle oder eine Teilmenge von:
      • - Bare-Metal-Cloud-Speichervirtualisierung
      • - Rack-Skalierungsdesigns ohne Auswirkungen auf die Software
      • - Einführung von NVMe-oF im Unternehmen ohne Abhängigkeit von Betriebssystemtyp und -version
      • - Rechenzentren erhalten eine bessere Serverauslastung, wodurch mehr virtuelle Maschinen und mehr Mieter auf derselben Hardware möglich sind, während gleichzeitig die Gesamtbetriebskosten, der Stromverbrauch und die Komplexität der Verkabelung reduziert werden.
  • NVMe SNAP™ kann beispielsweise auf der Technologie von Mellanox BlueField® basieren, die hardwarebeschleunigte Speichervirtualisierung mit den fortschrittlichen Netzwerk- und Programmierfähigkeiten des BlueField® SmartNIC kombiniert. Mellanox BlueField® SmartNIC mit NVMe SNAP™ dient als intelligenter Netzwerkadapter für die gleichzeitige Speicher- und Netzwerkvirtualisierung und bietet damit eine In-Hardware-Speichervirtualisierung, um sowohl die Speicher- als auch die Netzwerkinfrastruktur zu verbessern, da NVMe SNAP™ auf Mellanox BlueField® die In-Hardware-Speichervirtualisierung ermöglicht und gleichzeitig die ARM-Programmierbarkeit des intelligenten Adapters nutzt. Kunden können die BlueField®-Infrastruktur auch parallel nutzen, um Netzwerkvirtualisierungs-Offloads zu implementieren, wie z. B. die Ausführung der vSwitch-Steuerung auf ARM-Cores, während der Datenpfad auf die ConnectX®-Technologie im SoC ausgelagert wird, wodurch die Skalierbarkeit und Effizienz der Virtualisierung maximiert wird.
  • Es versteht sich, dass die DPU zumindest einen Teil der Daten, auf die sich eine von einem Host über das emulierte Speichergerät gestellte Anfrage bezieht, in mindestens einem Speichergerät, das lokal mit dem Host, aber nicht mit der DPU verbunden ist, verfügbar oder auf dieses ausgerichtet ist, lokalisieren kann.
  • Es versteht sich von selbst, dass sich die Anfragedaten überhaupt nicht auf Host-Speichergeräte beziehen können. Oder zumindest ein Teil der Anfragedaten (alle Anfragedaten oder nur ein Teil davon) kann sich auf ein oder mehrere Host-Speichergeräte beziehen. Ein einzelnes Host-Gerät oder mehrere Host-Geräte können für einen bestimmten Teil (oder Teile) der Anfragedaten betroffen sein.
  • Bestimmten Ausführungsformen zufolge verwendet die DPU einen vom Host angebotenen Fabric-Target-Service, um auf das einzelne an den Host angeschlossene Speichergerät zuzugreifen, was zu einer Reihe von DMAs einschließlich 1-3 DMAs führt.
  • Es ist klar, dass es sich bei den Anfragen entweder um Lese- oder um Schreibanfragen handeln kann. Im ersten Fall werden die Daten typischerweise auf dem Speichergerät gespeichert, und die Anforderung umfasst eine Leseanforderung, bei der Daten über die Direktspeicherzugriffsübertragungen vom Speichergerät zum Host übertragen werden. Alternativ kann eine gegebene Anforderung jedoch auch eine Schreibanforderung umfassen, wobei die Daten über die Schreibanforderung auf dem Speichergerät gespeichert werden sollen, um die Daten über die direkten Speicherzugriffsübertragungen vom Host zum Speichergerät zu übertragen.
  • Gemäß einer Ausführungsform arbeitet das System in Verbindung mit einem rechnergestützten Gerät und mit einem Fabric Target Service, der in Datenkommunikation mit dem rechnergestützten Gerät steht, und das System umfasst eine Funktionalität, die sich auf dem rechnergestützten Gerät befindet, und eine Funktionalität, die sich auf dem Fabric-Target-Service befindet, die, wenn sie in Kombination arbeiten, das rechnergestützte Gerät in die Lage versetzen, den Zugriff auf Daten zu koordinieren.
  • Beispiel: Das rechnergestützte Gerät umfasst typischerweise einen Speichergeräte-Emulator, der ein Speichergerät an einem PCIe-Bus emuliert, und den Fabric Target Service, und der Speichergeräte-Emulator umfasst einen Laufwerksemulator, der ein Laufwerk an einem PCIe-Bus emuliert. Der Laufwerksemulator kann einen NVMe-Laufwerksemulator umfassen, der ein NVMe-Laufwerk an einem PCIe-Bus emuliert. In der Regel verwendet der NVMe-Laufwerksemulator eine softwaredefinierte netzbeschleunigte Verarbeitung. Der NVMe-Laufwerksemulator kann z.B. ein Mellanox NVMe SNAP™-Gerät sein. Optional wird der Fabric-Target-Service vom Host und einem lokalen Hardwarespeichergerät angeboten und durch eine spezielle Fabric-Target-Hardware-Offload unterstützt.
  • Das Fabric-Target-Offload kann wie in 6 dargestellt funktionieren, wobei typischerweise nur der Kontrollpfad, die Verwaltung und Ausnahmen durch die CPU-Software des Ziels laufen. Der Datenpfad und die NVMe-Befehle werden in der Regel von einem Netzwerkadapter verarbeitet.
  • In der Regel dient ein Target-Service dazu, Netzwerk-Clients ein Speichersystem zu präsentieren, von den Clients eingehende Verbindungen zu verarbeiten, Verwaltungsaufgaben zu erledigen (z.B. einen in den NVMe- und NVMe-oF-Spezifikationen definierten Verwaltungsbefehlssatz) und jede IO-Anforderung unter Verwendung konfigurierter physischer Laufwerke zu verarbeiten/zu bedienen. Bei einer Target-Offload-Funktion, die in Übereinstimmung mit bestimmten Ausführungsformen bereitgestellt wird, wird der Target-Service auf die Hardware ausgelagert, die dann die IO-Anforderungen bearbeitet/behandelt, anstatt dass der Host dies tut. Typischerweise wird auf dem Host weiterhin Software ausgeführt, um Verbindungen und Verwaltungsaufgaben zu bearbeiten und die Target-Offload-Funktion in geeigneter Hardware wie ConnectX® -5 und BlueField® zu konfigurieren. Sobald dies jedoch geschehen ist, wird die Aufgabe der Bearbeitung jeder Anforderung, einschließlich der Bedienung der Anforderung unter Verwendung des konfigurierten physischen Laufwerks, vollständig von der Hardware übernommen, während die Host-Software für Ausnahmeabläufe, Fehler, Trennungen usw. verantwortlich bleibt. Die Konfiguration von NVMe-over-Fabrics (NVMe-oF) Target-Offload ist online beschrieben, z.B. unter community.mellanox.com/s/article/howtoconfigure-nvme-over-fabrics--nvme-of-target-offload.
  • Es wird anerkannt, dass Verweise auf einen Laufwerksemulator hier nur beispielhaft sind, da im Allgemeinen jedes beliebige Speichergerät (nicht unbedingt ein Laufwerk) emuliert werden kann. Auch Verweise auf NVMe sind hier nur beispielhaft, da im Allgemeinen jedes lokale Speicherprotokoll verwendet werden kann. Auch Verweise auf NVMe-oF sind lediglich beispielhaft, da im Allgemeinen jedes beliebige Netzwerkspeicherprotokoll verwendet werden kann.
  • Die Funktionalität, die sich auf dem rechnergestützten Gerät befindet, ob allein oder in Kombination mit anderen hier gezeigten und beschriebenen Komponenten, ist typischerweise in der Lage, ein Verfahren (wie in 5a gezeigt) durchzuführen, das alle oder eine beliebige Teilmenge der folgenden Vorgänge umfasst, z.B. in folgender Reihenfolge:
    1. a. einem Host ein emuliertes Speichergerät zu präsentieren;
    2. b. vom Host die auf dem emulierten Gerät gestellten Anforderungen abzurufen;
    3. c. die Anfragen zu analysieren;
    4. d. festzustellen, dass ein oder mehrere an den Host angeschlossene Speichergeräte die Quelle oder das Ziel von mindestens einem Teil der Daten sind, auf die sich die Anfrage bezieht, und daraufhin festzustellen, dass das eine oder die mehreren an den Host angeschlossenen Speichergeräte an der Anfrage beteiligt sein sollten; und
    5. e. mindestens eine Anforderung mit einer lokalen Speicheradresse vorzubereiten, die auf den ursprünglichen Puffer im Speicher des Hosts verweist, zum Senden an das/die lokale(n) Hardwarespeichergerät(e), das/die an den Host angeschlossen ist/sind.
  • Die Funktionalität, die sich auf einem Fabric-Target-Service befindet, ist typischerweise in der Lage, ein Verfahren (wie in 5b gezeigt) durchzuführen, das alle oder eine beliebige Teilmenge der folgenden Operationen umfasst, z.B. in folgender Reihenfolge:
    1. a. die Anforderung mit einer lokalen Speicheradresse zu erkennen, indem sie neue Opcodes oder Angaben in bestehenden Opcodes erkennt;
    2. b. dementsprechend eine konventionelle, für ein lokales Speicherprotokoll formatierte Anforderung unter Verwendung von Zeigern auf Originalpuffer, die in der Anforderung mit einer lokalen Speicheradresse empfangen wurden, zu erzeugen; und
    3. c. die konventionelle Anforderung (mit einer Netzwerkadresse) an ein lokal angeschlossenes Speichergerät zu senden, das dem lokalen Speicherprotokoll unterliegt, was das lokal angeschlossene Speichergerät veranlasst, mindestens eine DMA-Übertragung von Daten zwischen Host-Puffern und internem Flash-Speicher einzuleiten.
  • Die Funktionalität des rechnergestützten Geräts kann in Software, Hardware, Firmware oder einer beliebigen Kombination davon implementiert sein. Die Funktionalität auf dem Fabric Target Offload kann in Software, Hardware, Firmware oder einer beliebigen Kombination daraus implementiert werden.
  • Es wird deutlich, dass die Methoden von 5a und 5b, typischerweise zusammengenommen, sparsamer sind als die folgende Methode, die zu drei oder mehr direkten Speicherzugriffsübertragungen führt:
    1. i. Die Funktionalität auf dem Computer stellt dem Host mit Hilfe von HW-Funktionen ein emuliertes Speichergerät (in diesem Fall NVMe) zur Verfügung.
    2. ii. die Funktionalität auf dem rechnergestützten Gerät erhält Anfragen vom Host, die auf dem emulierten Gerät mit Hilfe der HW-Fähigkeiten gebucht werden
    3. iii. Die Funktionalität des Computers analysiert die Anfragen
    4. iv. DMA überträgt den Datenpuffer, auf den die Anforderung verweist, mit Hilfe von HW-Funktionen in den internen DPU-Speicher (DMA#1)
    5. v. bereitet eine herkömmliche NVMe-oF-Anfrage vor und sendet sie an den Target-Service
  • In Verbindung mit allen oder einer Teilmenge der folgenden Vorgänge:
    • Vorgang 1011: Die Fabric-Target-Service-Funktionalität erhält die konventionelle NVMe-oF-Anforderung (mit einer Netzwerkadresse), die im obigen Vorgang vorbereitet wurde. v Vorgang 1012: RDMA überträgt Daten von der DPU an einen Bereitstellungspuffer im Host-Speicher (DMA #2)
    • Vorgang 1013: Fabric-Target-Service erzeugt eine konventionelle NVMe-Anfrage Operation 1014: Fabric-Target-Service sendet NVMe-Anfrage an das lokal angeschlossene reale NVMe-Laufwerk, Laufwerk sendet Daten per DMA an internen Flash-Speicher (DMA #3)
  • Wie man sieht, führt diese Methode zu drei DMAs und ist daher weniger einfach als die Methoden in 5a und 5b.
  • Viele Anwendungsfälle für die hierin beschriebenen Ausführungsformen sind möglich, wie z. B. Anwendungsfälle, in denen BlueField® SNAP™ (oder ein anderes rechnergestütztes Gerät) versuchen kann, auf Host-NVMe zuzugreifen, umfassen Cache Tier, Layered Storage und Hyper Converged Anwendungsfälle.
  • Gemäß bestimmten, nicht einschränkenden Ausführungsformen werden bei den hier beschriebenen Verfahren alle oder eine beliebige Teilmenge der folgenden Technologien eingesetzt:
    • NVMe
    • „NVM Express (NVMe) oder Non-Volatile Memory Host Controller Interface Specification (NVMHCIS) ist eine offene Logical-Device-Schnittstellenspezifikation für den Zugriff auf nichtflüchtige Speichermedien, die über den PCI Express (PCIe)-Bus angeschlossen sind. NVM steht für nichtflüchtigen Speicher, bei dem es sich häufig um NAND-Flash-Speicher handelt, der in verschiedenen physischen Formfaktoren erhältlich ist, darunter Solid-State-Laufwerke (SSDs), PCI Express (PCIe)-Add-in-Karten, M.2-Karten und andere Formen.“
  • Software-definiertes Netzwerk - Beschleunigte Verarbeitung
  • NVMe SNAP™ ermöglicht die Hardware-Virtualisierung von NVMe-Speicher. Das Mellanox NVMe SNAP™-Framework ermöglicht es Kunden, vernetzte Speicherlösungen einfach in ihre Cloud- oder Unternehmensserver-Implementierungen zu integrieren. NVMe SNAP™ bringt virtualisierten Speicher in Bare-Metal-Clouds und macht Composable Storage einfach. Es ermöglicht die effiziente Disaggregation von Rechen- und Speicherressourcen, um eine vollständig optimierte Ressourcennutzung zu ermöglichen und so Composable Storage zu erleichtern.
  • NVMe SNAP™ gibt den Kunden die Freiheit, ihre eigenen Speichertechnologien und -lösungen auf der Grundlage des NVMe SNAP™ Frameworks zu implementieren, das auf dem Mellanox BlueField® System-on-Chip-Controller läuft. SNAP™ erreicht sowohl Leistung als auch Software-Transparenz, indem es die eingebetteten Hardware-Speicherbeschleunigungs-Engines von BlueField® zusammen mit integrierten programmierbaren ARM-Cores nutzt. Diese leistungsstarke Kombination ist agil und dennoch völlig transparent für die Host-Software, so dass SNAP™ in eine Vielzahl von Speicherlösungen integriert werden kann.
  • NVIDIA® BlueField® Datenverarbeitungseinheiten
  • Die NVIDIA® BlueField® Datenverarbeitungseinheit (DPU) sorgt für beispiellose Innovationen in modernen Rechenzentren und bietet eine breite Palette an fortschrittlichen Netzwerk-, Speicher- und Sicherheitsdiensten für komplexe Rechen- und Kl-Workloads. Durch die Kombination des branchenführenden Netzwerkadapters ConnectX® mit einer Reihe von ARM-Kernen bietet BlueField® zweckmäßige HardwareBeschleunigungs-Engines mit vollständiger Programmierbarkeit der Rechenzentrumsinfrastruktur auf dem Chip.
  • Die Leistungen umfassen alle oder eine Teilmenge von:
    1. a. Datenspeicherung für die wachsende Arbeitslast; mit NVMe over Fabric (NVMe-oF) Storage Direct, Verschlüsselung, elastischer Speicherung, Datenintegrität, Komprimierung und Deduplizierung bietet die NVIDIA® BlueField®-2 DPU ein hochleistungsfähiges Speichernetzwerk mit Latenzen für Remote-Storage, die mit Direct Attached Storage konkurrieren.
    2. b. Hochleistungsfähiges, effizientes Netzwerk; die BlueField®-2 DPU ist ein leistungsfähiger Beschleuniger für Rechenzentrumsdienste, der bis zu 200 Gigabit pro Sekunde (Gb/s) Ethernet- und InfiniBand-Leitungsgeschwindigkeit für herkömmliche Anwendungen und moderne GPU-beschleunigte Kl-Workloads liefert und gleichzeitig die CPU-Kerne des Hosts entlastet; und
    3. c. Software-definierte Infrastruktur: Das NVIDIA® DOCA Software Development Kit (SDK) ermöglicht es Entwicklern, auf einfache Weise leistungsstarke, softwaredefinierte, Cloud-native, DPU-beschleunigte Dienste zu erstellen und dabei branchenübliche APIs zu nutzen.
  • NVMe über Fabric (auch bekannt als NVMe-oF oder NVMF)
  • Devops.com beschreibt, dass „NVMe ein Protokoll ist, das vorgibt, wie eine CPU Speicher über den PCI-Bus an ein Speichergerät überträgt. NVMe kommuniziert über eine Reihe von Ringen (pro CPU), über die Befehle von jeder CPU an das zugrunde liegende NVMe-Gerät übermittelt werden können. Durch das Design von NVMe werden Zwischenschichten zwischen der CPU und dem Speichergerät eliminiert. NVMe-Geräte bestehen aus einem Controller, Warteschlangen, Namespaces, Namespace-IDs und den eigentlichen Speichermedien mit einer Art von Schnittstelle. Speichermedien können in Abschnitte gruppiert werden, die Namespaces mit einer ID genannt werden. Im Kontext der NVMF bieten Namespaces eine Möglichkeit zur Durchsetzung der Zugriffskontrolle für die Datenträger/Verbraucher. Namespaces entsprechen einer Betriebssystempartition, mit dem Unterschied, dass die Partitionierung in der Hardware durch den Controller und nicht durch das Betriebssystem vorgenommen wird (Betriebssystempartitionen in Namespaces sind dennoch möglich). Einige NVMe-Namensräume können vor dem Benutzer verborgen werden (z. B. zur Sicherheitsisolierung). Ein Controller verbindet sich mit einem Port über Warteschlangen und mit einem Namespace über seine Namespace-ID. Ein Controller darf sich mit mehreren Namespaces verbinden und ein Namespace darf von mehreren Controllern (und damit auch von mehreren Ports) kontrolliert werden. Stellen Sie sich vor, Sie könnten dieses NVMe-Gerät über mehrere Computer verteilen, und Sie kommen zum nächsten wichtigen Konzept, einer Storage Fabric.
  • Wenn Sie ein Netzwerk zwischen den PCI-Bus und das Speichergerät schalten, verwenden Sie NVMe over Fabric (auch bekannt als NVMe-oF oder einfach NVMF). NVMF ermöglicht den schnellen Zugriff zwischen Hosts und Speichersystemen über ein Netzwerk. Im Vergleich zu iSCSI hat NVMF eine viel geringere Zugriffslatenz, die in der Praxis nur einen kleinen Latenzunterschied zwischen lokalem und entferntem Speicher ausmacht. NVMF bietet einen Durchbruch bei Durchsatz und Suchzeit im Vergleich zu herkömmlichem Device Attached Storage“.
  • Cache-Ebene
  • Beim Cache-Tiering werden schnelle und/oder teure Speichergeräte wie Solid-State-Laufwerke, die für den Betrieb als Cache-Tier konfiguriert sind, in Verbindung mit einem „Backing-Pool“ aus löschungscodierten oder langsameren/kostengünstigeren Geräten bereitgestellt, die als wirtschaftlicheres Storage-Tier als das Cache-Tier dienen. Mellanox bietet beispielsweise ein Softwareprodukt zur Speicherbeschleunigung namens VSA an, das eine Softwareplattform ist, die auf der iSER-Technologie aufbaut. VSA wurde entwickelt, um die Verwendung von Flash-Speicher oder SSD als Cache-Tier zu unterstützen.
  • ConnectX®
  • Layered Storage ist eine bekannte Speichertechnologie. Die ConnectX® 40Gb/s-InfiniBand-Adapter von Mellanox liefern beispielsweise eine führende E/A-Leistung für RAIDs X2-IB, eine neue InfiniBand-Layered-Storage-Lösung.
  • Hyperkonvergente Technologie oder Hyperkonvergenz umfasst in der Regel Rechen-, Speicher-, Netzwerk- und Virtualisierungsfunktionen (alle oder eine beliebige Untergruppe davon), die alle in einer typischerweise unsichtbaren Infrastruktur zusammengeführt werden. Die Technologie bewegt sich weg von proprietären und teuren Speicher-Arrays hin zu offenen Standard-Rechen- und Speicherarchitekturen, die auf handelsüblichen Servern aufbauen. Unternehmen können die Commodity-Architektur nutzen, um hyperkonvergente Lösungen zu implementieren, die mit großen, teuren Speicher-Arrays konkurrieren und mit der Leistung typischer Speicherplattformen mithalten können. Die Storage Spaces Direct (S2D) Edition von Microsoft in Windows Server 2019 ist ein Beispiel für eine hyperkonvergente Lösung.
  • Es versteht sich von selbst, dass die Softwarekomponenten der vorliegenden Erfindung, falls gewünscht, in ROM-Form (Festwertspeicher) implementiert werden können. Die Softwarekomponenten können im Allgemeinen in Firmware oder Hardware implementiert werden, falls gewünscht, unter Verwendung herkömmlicher Techniken. Außerdem können die Softwarekomponenten beispielsweise als Computerprogrammprodukt oder auf einem materiellen Medium instanziiert werden. In einigen Fällen kann es möglich sein, die Softwarekomponenten als ein von einem geeigneten Computer interpretierbares Signal zu instanziieren, obwohl eine solche Instanziierung in bestimmten Ausführungsformen der vorliegenden Erfindung ausgeschlossen sein kann.
  • Es versteht sich von selbst, dass verschiedene Merkmale der Erfindung, die aus Gründen der Übersichtlichkeit im Zusammenhang mit einzelnen Ausführungsformen beschrieben werden, auch in Kombination in einer einzigen Ausführungsform vorgesehen werden können. Umgekehrt können verschiedene Merkmale der Erfindung, die der Kürze halber im Zusammenhang mit einer einzigen Ausführungsform beschrieben werden, auch separat oder in jeder geeigneten Unterkombination bereitgestellt werden.
  • Dem Fachmann wird klar sein, dass die vorliegende Erfindung nicht auf das beschränkt ist, was vorstehend gezeigt und beschrieben wurde. Vielmehr wird der Umfang der Erfindung durch die beigefügten Ansprüche und deren Äquivalente definiert.
  • Es versteht sich, dass die oben beschriebenen Aspekte und Ausführungsformen nur beispielhaft sind und dass im Rahmen der Ansprüche Änderungen im Detail vorgenommen werden können.
  • Jedes Gerät, Verfahren und Merkmal, das in der Beschreibung und (gegebenenfalls) in den Ansprüchen und Zeichnungen offenbart wird, kann unabhängig oder in jeder geeigneten Kombination bereitgestellt werden.
  • Die in den Ansprüchen enthaltenen Bezugszahlen dienen nur der Veranschaulichung und haben keine einschränkende Wirkung auf den Umfang der Ansprüche.

Claims (28)

  1. Ein rechnergestütztes System, das in Verbindung mit einem rechnergestützten Gerät und mit einem Gewebe-Ziel-Dienst in Datenkommunikation mit dem rechnergestützten Gerät arbeitet, wobei das System umfasst: Funktionalität, die sich auf dem rechnergestützten Gerät befindet; und Funktionalität, die sich auf dem Fabric Target Service befindet, die, wenn sie in Kombination arbeiten, es dem rechnergestützten Gerät ermöglichen, den Zugang zu den Daten zu koordinieren.
  2. Das rechnergestützte System nach Anspruch 1, wobei das rechnergestützte System einen Host in die Lage versetzt, auf ein emuliertes PCI-Speichergerät zuzugreifen, indem das rechnergestützte Gerät zum Koordinieren der Ausführung einer Host-Anforderung, die an einer emulierten Schnittstelle ankommt, unter Verwendung von weniger als drei Direktspeicherzugriffsübertragungen (DMA) verwendet wird, wobei sich die Host-Anforderung auf Daten bezieht, die in mindestens einem lokal an den Host angeschlossenen Hardwarespeichergerät gespeichert sind oder gespeichert werden sollen, wobei die Daten zwischen dem ursprünglichen Anwendungspuffer des Hosts und dem lokal an den Host angeschlossenen Hardwarespeichergerät übertragen werden.
  3. Das rechnergestützte System nach Anspruch 2, wobei das Hardwarespeichergerät ein physisches NVMe-Gerät umfasst, das sich in der gleichen Durchgangsdomäne wie das emulierte PCI-Speichergerät befindet, und wobei der ursprüngliche Anwendungspuffer des Hosts sowohl für das physische NVMe-Gerät als auch für das emulierte PCI-Speichergerät unter Verwendung derselben Adresse beschrieben wird.
  4. Das rechnergestützte System nach Anspruch 3, wobei das rechnergestützte System ferner eine physische NVMe-Seite umfasst, wobei der ursprüngliche Anwendungspuffer Teil eines Speicherraums oder einer VM-Domäne einer virtuellen Maschine (VM) ist, das emulierte PCI-Speichergerät sich in dieser VM-Domäne befindet und wobei das physische NVMe-Gerät, das sich in der Durchgangs-Host-Domäne und nicht in der VM-Domäne befindet, auf den ursprünglichen Anwendungspuffer zugreift, indem es die PASID-Technologie (Process Address Space ID) auf der physischen NVMe-Seite verwendet.
  5. Das rechnergestützte System nach Anspruch 4, wobei der ursprüngliche Anwendungspuffer des Hosts Teil einer Domäne ist, die im Speicherraum einer Virtuellen Maschine enthalten ist, das emulierte PCI-Speichergerät sich in der Domäne befindet, die im Speicherraum der Virtuellen Maschine enthalten ist, und wobei ein physisches NVMe-Gerät, das sich in der Durchgangs-Host-Domäne befindet, und nicht in der Domäne, die im Speicherraum der Virtuellen Maschine enthalten ist, auf den ursprünglichen Anwendungspuffer aufgrund der rechnergestützten Geräts zugreift, die VM-Adressen in Host-Adressen umwandelt, basierend auf einer Zuordnung, die in das rechnergestützte Gerät durch einen Hilfstreiber auf dem Host übergeben wird, der den Gast-zu-Host-Speicherzuordnungen der Virtuellen Maschine ausgesetzt ist.
  6. Das rechnergestützte System nach Anspruch 3, wobei der ursprüngliche Anwendungspuffer Teil eines Speicherraums oder einer VM-Domäne einer virtuellen Maschine ist, das emulierte PCI-Speichergerät sich in der VM-Domäne befindet und das physische NVMe-Gerät auf den ursprünglichen Anwendungspuffer zugreift, indem es eine IOMMU-Domäne (Input-Output Memory Management Unit) erzeugt, die Speicherdomänen mehrerer virtueller Maschinen enthält, das physische NVMe-Gerät in der IOMMU-Domäne (Input-Output Memory Management Unit) einsetzt und mindestens eine ursprüngliche Adresse in eine Adresse übersetzt, die mit mindestens einem der Speicher der mehreren virtuellen Maschinen übereinstimmt.
  7. Das rechnergestützte System nach Anspruch 3, wobei der ursprüngliche Anwendungspuffer Teil eines Speicherraums einer virtuellen Maschine oder VM-Domäne ist, das emulierte PCI-Speichergerät sich in der VM-Domäne befindet und das physische NVMe-Gerät, das sich eher in einer Durchgangs-Host-Domäne als in der VM-Domäne befindet, auf den ursprünglichen Anwendungspuffer zugreift, indem es ATS (Address Translation Service) verwendet, um eine IOMMU-Übersetzung (Input-Output Memory Management Unit) mindestens einer Adresse bereitzustellen.
  8. Das rechnergestützte System nach einem der Ansprüche 2 bis 7, wobei die auf dem rechnergestützten Gerät befindliche Funktionalität dazu dient, mindestens einen der folgenden Schritte auszuführen: a. einem Host ein emuliertes Speichergerät zu präsentieren; b. vom Host die auf dem emulierten Gerät gestellten Anfragen abzurufen; c. die Anfragen zu analysieren; d. festzustellen, dass ein oder mehrere an den Host angeschlossene Hardware-Speichergerät(e) eine Quelle oder ein Ziel von mindestens einem Teil der Daten ist/sind, auf die sich die Anfrage bezieht, und daraufhin festzustellen, dass das eine oder die mehreren an den Host angeschlossene(n) Speichergerät(e) an der Anfrage beteiligt sein sollten; und e. mindestens einer Anforderung mit einer lokalen Speicheradresse vorzubereiten, die auf den ursprünglichen Puffer im Speicher des Hosts verweist, zum Senden an das/die an den Host angeschlossene/n Hardware-Speichergerät/e.
  9. Das rechnergestützte System nach Anspruch 8, wobei die Anforderung mit einer lokalen Speicheradresse für ein Netzwerkspeicherprotokoll formatiert ist, und wobei die Funktionalität, die sich auf dem Fabric Target Service befindet, dazu dient: a. die Anforderung mit einer lokalen Speicheradresse zu erkennen, indem sie neue Opcodes oder Angaben innerhalb eines bestehenden Opcodes erkennt; b. dementsprechend eine konventionelle, für ein lokales Speicherprotokoll formatierte Anforderung unter Verwendung von Zeigern auf Originalpuffer, die in der Anforderung mit einer lokalen Speicheradresse empfangen wurden, zu erzeugen; und c. die konventionelle Anforderung an ein lokal angeschlossenes Speichergerät zu senden, das dem lokalen Speicherprotokoll unterliegt, was das lokal angeschlossene Speichergerät veranlasst, mindestens eine DMA-Übertragung von Daten zwischen Host-Puffern und internem Flash-Speicher einzuleiten.
  10. Das rechnergestützte System nach Anspruch 9, wobei das lokale Speicherprotokoll ein PCI-Speicherprotokoll aus der folgenden Gruppe umfasst: NVMe, Virtio-blk, Virtio-scsi, SCSI, SATA, SAS, IDE.
  11. Das rechnergestützte System nach Anspruch 9, wobei das Netzwerkspeicherprotokoll ein Blockspeichernetzwerkspeicherprotokoll umfasst.
  12. Das rechnergestützte System nach Anspruch 11, wobei das Blockspeichernetzwerkspeicherprotokoll ein Netzwerk-Blockspeicherprotokoll mit direktem Fernspeicherzugriff (RDMA) aus der folgenden Gruppe umfasst: NVMe-oF, iSER und SRP.
  13. Das rechnergestützte System nach einem der vorhergehenden Ansprüche, wobei das rechnergestützte Gerät umfasst: einen Speichergeräte-Emulator, der ein Speichergerät auf einem PCIe-Bus emuliert; und den Fabric-Target-Service, und wobei der Speichergeräteemulator einen Laufwerksemulator umfasst, der ein Laufwerk auf einem PCIe-Bus emuliert.
  14. Das rechnergestützte System nach Anspruch 13, wobei der Laufwerksemulator einen NVMe-Laufwerksemulator umfasst, der ein NVMe-Laufwerk auf einem PCIe-Bus emuliert.
  15. Das rechnergestützte System nach Anspruch 14, wobei der NVMe-Laufwerksemulator eine softwaredefinierte netzbeschleunigte Verarbeitung verwendet.
  16. Das rechnergestützte System nach einem der vorhergehenden Ansprüche, wobei der Fabric-Target-Service von einem Host angeboten wird, der lokal an ein Hardware-Speichergerät angeschlossen ist und auch eine Fabric-Target-Hardware-Offload umfasst, die zumindest einige Funktionen im Namen des Fabric-Target-Services ausführt.
  17. Ein Verfahren, das es einem Host ermöglicht, auf ein emuliertes PCI-Speichergerät zuzugreifen, wobei das Verfahren den Einsatz eines rechnergestützten Geräts zur Koordinierung der Ausführung einer Host-Anforderung, die an einer emulierten Schnittstelle ankommt, einschließt, während weniger als drei Direktspeicherzugriffsübertragungen (DMA) verwendet werden, wobei sich die Host-Anforderung auf Daten bezieht, die auf mindestens ein lokal an den Host angeschlossenes Hardware-Speichergerät gespeichert sind oder gespeichert werden sollen.
  18. Das Verfahren nach Anspruch 17, wobei der Host auf das emulierte PCI-Speichergerät unter Verwendung mehrerer direkter Speicherzugriffsübertragungen zugreift und wobei der Zugriff die Freigabe des rechnergestützten Geräts zur Koordinierung des Zugriffs auf die Daten umfasst.
  19. Das Verfahren nach Anspruch 17 oder 18, wobei die Daten auf dem Speichergerät gespeichert sind und die Anforderung eine Leseanforderung umfasst, bei der Daten über die Direktspeicherzugriffsübertragungen von dem Speichergerät zum Host übertragen werden.
  20. Das Verfahren nach Anspruch 17 oder 18, wobei die Anforderung eine Schreibanforderung umfasst und die Daten über die Schreibanforderung auf dem Speichergerät gespeichert werden sollen, um die Daten über die Direktspeicherzugriffsübertragungen vom Host zum Speichergerät zu übertragen.
  21. Das Verfahren nach einem der Ansprüche 17 bis 20, wobei der Zugriff umfasst, dass der Speichergeräteemulator in die Lage versetzt wird, den Zugriff auf die Daten zu koordinieren, indem zwei direkte Speicherzugriffsübertragungen der Daten verwendet werden.
  22. Das Verfahren nach Anspruch 21, wobei die Funktionalität, die sich auf dem Speichergeräte-Emulator befindet, dazu dient: a. dem Host ein emuliertes Speichergerät zu präsentieren; b. von dem Host die auf dem emulierten Gerät gestellten Anfragen abzurufen; c. die Anfragen zu analysieren; und d. eine für ein Netzwerkspeicherprotokoll formatierte Anforderung vorzubereiten, die einen speziellen Speicherschlüssel (MKEY) enthält, der auf den Host-Speicher und nicht auf den DPU-Speicher verweist, um dadurch im Rahmen des RDMA-Protokolls (Remote Direct Memory Access) das einfache Kopieren der Daten von einem Puffer zu einem anderen im Host zu erleichtern, ohne dass die auf einem Fabric-Target-Service befindliche Funktionalität von dem einfachen Kopieren Kenntnis erhält.
  23. Das Verfahren nach Anspruch 22, wobei die Funktionalität, die sich auf dem Fabric-Target-Service befindet, dazu dient: a. die für das Netzwerkspeicherprotokoll formatierte Anfrage von der auf dem Speichergeräteemulator befindlichen Funktionalität abzurufen; b. eine DMA-Übertragung von RDMA-Daten zu einem Staging-Puffer im Host-Speicher vorzunehmen, was tatsächlich zu einem einfachen Kopieren der Daten von einem Puffer zu einem anderen im Host führt, ohne dass die auf dem Fabric-Target-Service befindliche Funktionalität von diesem einfachen Kopieren Kenntnis hat; c. eine für ein lokales Speicherprotokoll formatierte Anfrage zu erzeugen; und d. die für ein lokales Speicherprotokoll formatierte Anforderung, die vom Fabric-Target-Service erzeugt wurde, an ein lokal angeschlossenes Hardware-Laufwerk zu senden, das für das lokale Speicherprotokoll formatiert ist, wodurch das lokal angeschlossene Speichergerät veranlasst wird, DMAs von Daten zwischen Host-Puffern und internem Flash-Speicher zu initiieren.
  24. Das Verfahren nach einem der Ansprüche 17 bis 23, wobei das rechnergestützte Gerät eine DPU mit einem Emulator für ein Speichergerät umfasst.
  25. Das Verfahren nach Anspruch 24, wobei das Hardware-Speichergerät eine der folgenden Gruppen umfasst: NVMe, Virtio-blk, Virtio-scsi, SCSI, SATA, SAS, IDE, und der Speichergeräteemulator eine der folgenden Gruppen umfasst: NVMe-, Virtio-blk-, Virtio-scsi-, SCSI-, SATA-, SAS-, IDE-Laufwerksemulator, der ein Speicherlaufwerk auf einem PCIe-Bus emuliert.
  26. Das Verfahren nach Anspruch 24 oder 25, wobei das Hardwarespeichergerät ein NVMe umfasst und der Speichergeräteemulator des rechnergestützten Geräts einen NVMe-Laufwerksemulator umfasst, der ein NVMe-Laufwerk auf einem PCIe-Bus emuliert.
  27. Das Verfahren nach Anspruch 24, 25 oder 26, wobei die DPU mindestens einen Teil der Daten, auf die sich eine von einem Host über das emulierte Speichergerät gestellte Anfrage bezieht, als in mindestens einem Speichergerät /mehreren Speichergeräten, die lokal an den Host, aber nicht an die DPU angeschlossen ist/sind, verfügbar oder auf diese ausgerichtet findet.
  28. Das Verfahren nach Anspruch 27, wobei die DPU einen vom Host angebotenen Fabric-Target-Service verwendet, um auf ein einzelnes, an den Host angeschlossenes Speichergerät zuzugreifen, das lokal an den Host, aber nicht an die DPU angeschlossen ist, wodurch sich ein Satz von DMAs ergibt, der mindestens einen und nicht mehr als drei DMAs umfasst.
DE102022203658.1A 2021-04-19 2022-04-12 Gerät, Verfahren und Computerprogrammprodukt für effiziente, softwaredefinierte, netzbeschleunigte Verarbeitung unter Verwendung von Speichergeräten, die in Bezug auf einem Host lokal sind Pending DE102022203658A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/234,189 2021-04-19
US17/234,189 US11940935B2 (en) 2021-04-19 2021-04-19 Apparatus, method and computer program product for efficient software-defined network accelerated processing using storage devices which are local relative to a host

Publications (1)

Publication Number Publication Date
DE102022203658A1 true DE102022203658A1 (de) 2022-10-20

Family

ID=83446964

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102022203658.1A Pending DE102022203658A1 (de) 2021-04-19 2022-04-12 Gerät, Verfahren und Computerprogrammprodukt für effiziente, softwaredefinierte, netzbeschleunigte Verarbeitung unter Verwendung von Speichergeräten, die in Bezug auf einem Host lokal sind

Country Status (3)

Country Link
US (1) US11940935B2 (de)
CN (1) CN115221089A (de)
DE (1) DE102022203658A1 (de)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11847081B2 (en) * 2022-03-24 2023-12-19 Dell Products L.P. Smart network interface controller (SmartNIC) storage non-disruptive update
US11977504B2 (en) * 2022-04-26 2024-05-07 Dell Products L.P. Smart network interface controller operating system deployment
US12117948B2 (en) 2022-10-31 2024-10-15 Mellanox Technologies, Ltd. Data processing unit with transparent root complex
US12007921B2 (en) 2022-11-02 2024-06-11 Mellanox Technologies, Ltd. Programmable user-defined peripheral-bus device implementation using data-plane accelerator (DPA)
CN116028292B (zh) * 2023-02-28 2023-06-06 珠海星云智联科技有限公司 用于远程直接内存访问仿真验证的仿真验证系统及方法
CN117560408B (zh) * 2023-11-06 2024-10-18 中科驭数（北京）科技有限公司 用于dpu的文件系统远程访问方法及装置

Family Cites Families (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7721068B2 (en) * 2006-06-12 2010-05-18 Oracle America, Inc. Relocation of active DMA pages
US20080140724A1 (en) * 2006-12-06 2008-06-12 David Flynn Apparatus, system, and method for servicing object requests within a storage controller
US8565811B2 (en) * 2009-08-04 2013-10-22 Microsoft Corporation Software-defined radio using multi-core processor
US9081501B2 (en) * 2010-01-08 2015-07-14 International Business Machines Corporation Multi-petascale highly efficient parallel supercomputer
TWI465905B (zh) * 2010-09-22 2014-12-21 Toshiba Kk 記憶體系統、主機控制器、及直接記憶體存取之控制方法
WO2016206012A1 (en) * 2015-06-24 2016-12-29 Intel Corporation Systems and methods for isolating input/output computing resources
US20180213669A1 (en) * 2015-07-10 2018-07-26 Prasad Lalathuputhanpura KOCHUKUNJU Micro data center (mdc) in a box system and method thereof
US10229142B2 (en) * 2015-09-14 2019-03-12 International Business Machines Corporation Method and system for handling binary large objects
US10162793B1 (en) * 2015-09-29 2018-12-25 Amazon Technologies, Inc. Storage adapter device for communicating with network storage
US10769098B2 (en) * 2016-04-04 2020-09-08 Marvell Asia Pte, Ltd. Methods and systems for accessing host memory through non-volatile memory over fabric bridging with direct target access
US10216423B1 (en) * 2016-09-16 2019-02-26 Pavilion Data Systems, Inc. Streams across multiple controllers to improve solid state drive performance
US10572161B2 (en) * 2017-11-15 2020-02-25 Samsung Electronics Co., Ltd. Methods to configure and access scalable object stores using KV-SSDs and hybrid backend storage tiers of KV-SSDs, NVMe-SSDs and other flash devices
CA3021969A1 (en) * 2017-11-30 2019-05-30 Eidetic Communications Inc. System and method for tcp offload for nvme over tcp-ip
JP2019179455A (ja) * 2018-03-30 2019-10-17 東芝メモリ株式会社 記憶装置及びコンピュータシステム
US11016911B2 (en) * 2018-08-24 2021-05-25 Samsung Electronics Co., Ltd. Non-volatile memory express over fabric messages between a host and a target using a burst mode
US10860504B2 (en) * 2018-12-05 2020-12-08 New Century Technologies Ltd. Peripheral device with embedded video codec functionality
US11868284B2 (en) * 2018-12-05 2024-01-09 Rongming Microelectronics (Jinan) Co., Ltd. Peripheral device with embedded video codec functionality
EP3900308A4 (de) * 2019-01-30 2022-02-23 Huawei Technologies Co., Ltd. Eingabe-/ ausgabeverarbeitung in einem verteilten speicherknoten mit rdma
US20200319972A1 (en) * 2019-04-05 2020-10-08 Pure Storage, Inc. Offloading raid reconstruction to a secondary controller of a storage system
US11025544B2 (en) * 2019-06-07 2021-06-01 Intel Corporation Network interface for data transport in heterogeneous computing environments
US11314460B2 (en) * 2019-09-13 2022-04-26 Kioxia Corporation Solid state drive supporting both byte addressable protocol and block addressable protocol
US11093144B1 (en) * 2020-02-18 2021-08-17 EMC IP Holding Company LLC Non-disruptive transformation of a logical storage device from a first access protocol to a second access protocol
US20200319812A1 (en) * 2020-06-03 2020-10-08 Intel Corporation Intermediary for storage command transfers
US20220075747A1 (en) * 2020-09-09 2022-03-10 Mellanox Technologies Tlv Ltd. Support for multiple hot pluggable devices via emulated switch
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
US20220164303A1 (en) * 2020-11-25 2022-05-26 Intel Corporation Optimizations of buffer invalidations to reduce memory management performance overhead
US20220029929A1 (en) * 2020-12-08 2022-01-27 Intel Corporation Technologies that provide policy enforcement for resource access
WO2022139850A1 (en) * 2020-12-26 2022-06-30 Intel Corporation Cryptographic computing including enhanced cryptographic addresses
US12056374B2 (en) * 2021-02-03 2024-08-06 Alibaba Group Holding Limited Dynamic memory coherency biasing techniques
US11693804B2 (en) * 2021-06-03 2023-07-04 Mellanox Technologies, Ltd. Cross bus memory mapping
US20220342841A1 (en) * 2021-12-22 2022-10-27 Swadesh Choudhary Die-to-die adapter
US20220342840A1 (en) * 2021-12-30 2022-10-27 Intel Corporation Die-to-die interconnect
US20220334995A1 (en) * 2021-12-30 2022-10-20 Debendra Das Sharma Parameter exchange for a die-to-die interconnect
US20220334932A1 (en) * 2022-01-27 2022-10-20 Debendra Das Sharma Retimers to extend a die-to-die interconnect

Also Published As

Publication number Publication date
US11940935B2 (en) 2024-03-26
US20220334989A1 (en) 2022-10-20
CN115221089A (zh) 2022-10-21

Similar Documents

Publication Publication Date Title
DE102022203658A1 (de) Gerät, Verfahren und Computerprogrammprodukt für effiziente, softwaredefinierte, netzbeschleunigte Verarbeitung unter Verwendung von Speichergeräten, die in Bezug auf einem Host lokal sind
DE102022205478A1 (de) Busübergreifende speicherabbildung
US9342448B2 (en) Local direct storage class memory access
DE102018004046A1 (de) Nichtflüchtiger Speicher-Express über Fabric (NVMeOF) unter Verwendung eines Volumenverwaltungsgeräts
DE102020127705A1 (de) Techniken für einen effizienten fabric-attached-speicher
DE102014109519A1 (de) Techniken zum Replizieren von Daten zwischen Speicherservern
DE112012003776T5 (de) Migration logischer Partitionen mit zustandsbehafteten Auslagerungsdatenverbindungen während des laufenden Betriebs unter Verwendung der Kontextherauslösung und -einfügung
DE112011100323T5 (de) Architekturübergreifende Migration virtueller Maschinen
DE112012003808T5 (de) Ermittlung der Migration des Netzwerkadapter-Hardwarezustands in einer zustandsbehafteten Umgebung
DE112011100392T5 (de) Ressourcenaffinität durch dynamisches hinzufügen oder entfernen von warteschlangenpaaren für netzadapter mit software zur empfangsseitigen skalierung (rss)
DE102014109518A1 (de) Techniken zur Initialisierung von einem Speichergerät, auf das von der Ferne zugegriffen werden kann
DE102016119298B4 (de) Zeitpunktkopieren mit klonen von ketten
DE112012005209T5 (de) Brückenfunktion zwischen Virtual Machine Monitor und Bare-Metal-Bootvorgang
DE112013000752T5 (de) Verwalten von Verarbeitungselementen in einem Streaming-Datensystem
DE112008001168T5 (de) System und Verfahren zum gemeinschaftlichen Verwenden eines Druckers
DE112012002404B4 (de) Konfiguration und Management virtueller Netzwerke
DE112010004194T5 (de) Erleichterung der Datenverdichtung während des Kopierens
DE112015000203T5 (de) "Compare and Delay"-Befehle
DE102010044531A1 (de) Autonome Speicherarchitektur
DE112021001408T5 (de) Verwendung kohärent verbundener schnittstellen in einem netzwerkstapelrahmen
DE102022202780A1 (de) Speicherprotokoll-emulation in einem peripheriegerät
DE112021005881T5 (de) Inline datenpakettransformationen
DE102010044529A1 (de) Autonome Subsystem-Architektur
DE112019005392T5 (de) Steigern von datenleistung durch transferieren von daten zwischen speicherebenen unter verwendung von arbeitslastmerkmalen
DE102018213428A1 (de) Techniken zum Reduzieren von Beschleuniger-Speicherzugriffskosten in Plattformen mit mehreren Speicherkanälen

Legal Events

Date Code Title Description
R012 Request for examination validly filed