Remote Direct Memory Access

Direkte Datenübertragung mit geringerer CPU-Auslastung

RDMA kann Kopieren, Kontextwechsel und Datenpfadlatenz zwischen Systemen reduzieren. Der Vorteil ist real – aber nur, wenn Anwendungen, Adapter, Switches, Firmware und Betriebsprozesse als eine qualifizierte Einheit konzipiert sind

Architektur besprechenRDMA-Transporte vergleichen
Anwendungspuffer Registrierter Speicher
→
RDMA-Adapter Warteschlange und Schutzstatus
RoCEv2- oder Infiniband-Fabric
RDMA-ADAPTER Direkte Platzierung
→
Remote-Puffer Anwendungs- oder Speicherdienst
Schneller Pfad: Weniger Kernel-Übergänge · Weniger Datenkopieren · Geringere CPU-Auslastung
RoCEv2Routingfähiger RDMA über Ethernet
InfiniBandSpeziell entwickelte RDMA-Fabric
Soft-RoCESoftwareimplementierung zur Validierung
Storage-ProtokolleNVMe/RDMA und NFS über RDMA
Was ändert RDMA?

Das Betriebssystem kontrolliert weiterhin die Ressourcen; der schnelle Pfad überträgt Daten direkter

RDMA bedeutet keinen uneingeschränkten Zugriff auf den Speicher eines anderen Computers. Anwendungen oder Protokollimplementierungen erstellen geschützte Ressourcen und registrieren spezifische Puffer, bevor die Datenübertragung beginnt
01
Registrierter Speicher Der RDMA-Stack legt definierte Speicherbereiche fest und schützt sie. Schlüssel und Zugriffsrechte legen fest, welche Fernoperationen zulässig sind
02
Warteschlangen und Abschlüsse Arbeitsanforderungen werden an Warteschlangenpaare gesendet. Abschlusswarteschlangen melden abgeschlossene Operationen, ohne dass für jede Übertragung der normale Socket-Datenpfad benötigt wird
03
Direkte Platzierung Ein RDMA-fähiger Adapter kann Nutzdaten im vorgesehenen Puffer platzieren und so Zwischenkopien und die CPU-Auslastung bei Übertragungen mit hoher Rate reduzieren
RDMA ist kein automatischer Anwendungsbeschleuniger Die Anwendung oder das Speicherprotokoll muss eine RDMA-fähige Schnittstelle verwenden, und die Workload muss durch Datenbewegungen oder CPU-Overhead begrenzt sein, bevor der schnellere Pfad einen wesentlichen Mehrwert bietet
Transportauswahl

RoCE, RoCEv2, InfiniBand und Soft-RoCE sind keine austauschbaren Bezeichnungen

Sie stellen verwandte RDMA-Semantik bereit, unterscheiden sich jedoch in Routing, Hardware, Netzwerkbetrieb und Qualifizierungsaufwand
Transport Netzwerkmodell Routbarkeit Betriebsprofil Optimale Anpassung
RoCE v1 RDMA über Ethernet auf Layer 2 Gleiche Broadcast-Domäne Ethernet-QoS und Dämpfungsdesign müssen konsistent sein Eingeschlossene Legacy- oder Spezial-Fabrics
RoCEv2 RDMA über UDP/IP Layer-3-Routing möglich ECN, PFC (falls erforderlich), QoS, Puffer und Endpunkte werden gemeinsam validiert Konvergentes Enterprise Ethernet
InfiniBand Native InfiniBand-Verbindung und -Transport Fabric-Routing unter InfiniBand-Management Dedizierte Switches, HCAs und Subnet Manager HPC, KI und spezialisierte Umgebungen mit niedriger Latenz
Soft-RoCE In Software implementierte RoCE-Semantik über eine Ethernet-Schnittstelle Folgt dem zugrunde liegenden IP/Ethernet-Design Verbraucht Host-CPU; Verhalten abhängig von der Betriebssystemimplementierung Funktionstests, Labore und ausgewählte CPU-tolerante Workloads
End-to-End-Stoffdesign

RDMA ist eine Architektur – keine NIC-Checkbox

Der Transport kann den Datenpfad des Hosts entlasten, macht aber gleichzeitig die Konsistenz zwischen Endpunkten und dem Netzwerk wichtiger. Eine einzige nicht übereinstimmende Kombination aus MTU, Warteschlangenrichtlinie, Treiber oder Firmware kann den erwarteten Vorteil zunichtemachen oder zu intermittierenden Fehlern führen
Adapter und FirmwarePassen Sie HCA/NIC, Firmware und Treiber an die Host-Plattform und die Speicherversion an
NUMA-PlatzierungHalten Sie Anwendungsthreads, Speicher und Adapter nahe beieinander, wenn Latenz kritisch ist
Unabhängige PfadeVerwenden Sie separate Adapter, Switches und Zielports für echte Pfadausfallsicherheit
BetriebstelemetrieÜberwachung von ECN-Markierungen, PFC-Pausenaktivität, Paketverlusten, Überlastungsmeldungen und Wiederholungsübertragungsverhalten
AnwendungNVMe-oF, NFS oder ein anderes RDMA-fähiges Protokoll definiert die Datennutzung
HostSpeicherregistrierung, Warteschlangen, CPU/NUMA-Platzierung, Treiber- und Adapter-Firmware
NetzwerkMTU, VLAN oder Routing, QoS-Klassifizierung, ECN und – falls vom qualifizierten Design gefordert – PFC
ZielKompatibles Transport-, Portal-, Warteschlangenverhalten, Multipathing- und Verfügbarkeitsmodell
Moderne Plattformen unterstützen sowohl verlustfreie Designs mit PFC und ECN als auch validierte ECN-basierte Designs ohne PFC. Orientieren Sie sich an der vom Endgeräte- und Switch-Hersteller unterstützten Architektur, anstatt eine universelle Konfiguration zu kopieren
Anwendungsnutzen

Workloads bieten nur dann Vorteile, wenn der Datenpfad die eigentliche Einschränkung darstellt

Blockspeicher
NVMe über RDMA Behält das parallele NVMe-Befehlsmodell über RoCEv2 oder InfiniBand hinweg bei und kann den Protokoll-Overhead für latenzempfindlichen gemeinsam genutzten Speicher reduzieren
Dateispeicher
NFS über RDMA Verschiebt NFS-Nutzdaten über einen RDMA-Transport. Es ist nützlich für Linux-basierte Workloads mit gemeinsam genutzten Dateien, bei denen die Unterstützung für Client, Server und Netzwerk validiert wurde
Virtualisierung
VMware-Datenspeicher ESXi kann NVMe/RDMA-Speicher über unterstützte RoCEv2-Adapter nutzen. Das genaue Verhalten von Netzwerkkarte, Treiber, Firmware, PFC und Zielsystem muss noch geprüft werden
Virtualisierungsplattform
eEVOS Der integrierte Initiator NVMe-oF kann kompatiblen Remote-Speicher NVMe/RDMA nutzen; eEVOS selbst bleibt eine vollständige Alternative für Virtualisierung, Datensicherung und Speicherung
Transaktionale E/A
Datenbanken Geringere Transportlatenz und CPU-Auslastung können die E/A-Leistung bei hoher Parallelität verbessern, vorausgesetzt, Konsistenz, Warteschlangenlänge und Failover wurden mit der tatsächlichen Datenbank getestet
Paralleles Rechnen
HPC, KI und Analytik Hohe Nachrichtenraten und direkte Datenplatzierung können den Kommunikationsaufwand reduzieren, wenn Rechen-, Speicher- und Speicherpipelines ausgeglichen sind
Zuerst das Zugriffsmodell auswählen

NVMe/RDMA und NFS über RDMA lösen unterschiedliche Speicherprobleme

RDMA ist der Transportmechanismus. Er ändert nichts daran, ob der Host Rohdatenblöcke oder ein gemeinsam genutztes Dateisystem empfängt

NVMe über RDMA

Block
Der Client erhält einen NVMe-Namensraum und ist Eigentümer des darauf abgelegten Dateisystems oder der Anwendungsdatenstruktur
  • VMFS und Virtualisierungsdatenspeicher
  • Datenbankvolumes
  • Clusteranwendungen mit blockbasierter Koordination
  • Multipath-NVMe-Hostkonnektivität

NFS über RDMA

Datei
Der Server verwaltet das Dateisystem und stellt mehreren Clients gemeinsam genutzte Verzeichnisse, Dateinamen, Berechtigungen und Sperrsemantik zur Verfügung
  • Gemeinsam genutzte Linux-Dateien
  • HPC- und technische Datensätze
  • Anwendungsinhalte und Projektverzeichnisse
  • Zentrale Dateiberechtigungen und Namensraum
NFS über normales TCP und NVMe/TCP sind weiterhin gute Optionen, wenn einfache Bedienung, Kompatibilität oder Routing wichtiger sind als ein möglichst geringer CPU-Overhead
Verfügbarkeit und Validierung

Geringe Latenz ist nur dann wertvoll, wenn der Wiederherstellungspfad bekannt ist

Ein zweites Kabel stellt keine vollständige Verfügbarkeitsarchitektur dar. Testen Sie die gesamte Kette unter repräsentativen Anwendungs-E/A-Bedingungen
Host und InitiatorSeparate RDMA-fähige Ports, korrekte NUMA-Platzierung und unterstütztes Multipath-Verhalten
→
Duale FabricsUnabhängige Switches, konsistente QoS und MTU sowie kein gemeinsamer versteckter Fehlerpunkt
→
Storage-DienstZielportale, Controller, geschützte Daten und definiertes Failover- oder Scale-Out-Verhalten
Fehlertests gehören zu den Abnahmetests Validierung von Kabelausfall, Switch-Ausfall, Überlastung, Zielneustart, Controller- oder Knoten-Failover, Pfadwiederherstellung und Anwendungsreaktion. Benchmarking der stationären Leistung erst nach Nachweis des Wiederherstellungsverhaltens
Implementierungsbeispiele für euroNAS

Derselbe RDMA-Transport dient verschiedenen Bereitstellungsmodellen

Wählen Sie das Verfügbarkeits- und Skalierungsmodell, bevor Sie ein Produkt auswählen. euroNAS wird hier als praktisches Beispiel verwendet, da es sich um die uns bekannte und direkt dokumentierbare Implementierung handelt
Plattform NVMe/RDMA-Rolle Relevante Transporte Multipathing Bereitstellungsmodell
euroNAS Premium Ziel und Initiator RoCE/RoCEv2 und InfiniBand, sofern qualifiziert Unterstützt Eigenständiger Speicherserver oder virtuelle Speicher-Appliance
euroNAS HA Cluster Ziel und Initiator RoCE/RoCEv2 und InfiniBand, sofern qualifiziert Unterstützt Zwei-Knoten-Speicherkontinuität mit automatischem Failover
eEKAS Ziel und Initiator RDMA-fähige Gateway-Pfade, sofern qualifiziert Unterstützt Ceph-gestützte Scale-Out-Speicher und Gateways
eEVOS Eingebauter Initiator; Integrierter NVMe-Initiator Verbindet sich mit kompatiblem NVMe/RDMA-Speicher Unterstützt Virtualisierungshost oder Cluster, der gemeinsam genutzten Speicher verwendet
Soft-RoCE und Hardwareauswahl: Die euroNAS RDMA Implementierung kann, sofern qualifiziert, auch Soft-RoCE verwenden. Für hardwareausgelagerte Produktionsdesigns umfassen typische Enterprise-Bausteine ​​NVIDIA/Mellanox ConnectX oder andere unterstützte RDMA-Adapter in Serverplattformen von HPE, Supermicro und vergleichbaren Herstellern. Die genaue Kombination aus Adapter, Firmware, Treiber und Switch ist wichtiger als das Logo
Einzelner Speicherserver

euroNAS Premium

Kompatibler NVMe/RDMA-Speicher von Standard-Enterprise-Serverhardware Premium-Details →
Kontinuität auf zwei Knoten

HA Cluster

Koordinierung von geschützten Daten, Portaladressierung und Zieldienst-Failover über zwei Knoten HA Cluster-Details →
Verteilter Speicher

eEKAS

Kombination von verteiltem Ceph-Datenschutz mit qualifizierter Hochleistungs-Gateway-Konnektivität eEKAS Details →
Virtualisierungsnutzer

eEVOS

Verwenden Sie den integrierten Initiator, um kompatiblen gemeinsam genutzten NVMe/RDMA-Speicher zu nutzen eEVOS-Details →
Primäre technische Referenzen

Standards und Plattformleitfaden

Architekturübersicht RDMA Red Hat erläutert Speicherplatzierung, Kernel-Bypass und die unterstützten RDMA-Netzwerkmodelle Red Hat-Dokumentation öffnen →
Spezifikationskontext von RoCEv2 Die Handelsassoziation InfiniBand beschreibt die durch RoCEv2 hinzugefügte Layer-3-Routing-Funktionalität IBTA-Referenz öffnen →
Netzwerkdesign für RoCE NVIDIA dokumentiert verlustfreie und ECN-gesteuerte RoCE-Modi, Verkehrsklassen, PFC und Staubehandlung NVIDIA-Dokumentation öffnen →
Soft-RoCE-Implementierung Das Linux-Projekt RDMA dokumentiert die RXE-Softwareimplementierung und deren Konfiguration Open Linux RDMA-Referenz →
NFS über RDMA Red Hat dokumentiert Server- und Client-Anforderungen für NFSoRDMA auf aktuellen Enterprise-Linux-Systemen Open Red Hat NFSoRDMA-Leitfaden →
VMware NVMe/RDMA Broadcom-Dokumente beschreiben die Verbindung von ESXi mit NVMe/RDMA-Speicher über RoCEv2-Adapter Broadcom-Anleitung öffnen →

Den gesamten Pfad prüfen, bevor RDMA ausgewählt wird

Teilen Sie uns mit, welche Hosts, Protokolle, Adapter, Switches, Workloads und Verfügbarkeitsanforderungen zusammenarbeiten müssen. Wir können prüfen, ob RoCEv2, InfiniBand, Soft-RoCE oder eine TCP-basierte Alternative die geeignete Lösung darstellt
Architekturbeschreibung
RoCE, InfiniBand, NVMe, VMware und zugehörige Marken gehören ihren jeweiligen Eigentümern. VMware und Hardwarehersteller werden als Beispiele für technische Interoperabilität genannt; diese Seite impliziert keine Partnerschaft oder Zertifizierung. Unterstützte Konfigurationen hängen von der aktuellen euroNAS-Version, der Lizenz, qualifizierter Hardware, Treibern, Firmware, Switching-Plattform und validierter Client-Software ab
Nach oben scrollen