Auswahl eines Enterprise-Blockspeicherprotokolls
Die Transportprotokolle Fibre Channel, iSCSI, iSER und NVMe-oF ermöglichen die gemeinsame Nutzung von Blockspeichern. Die richtige Entscheidung hängt von der Host-Unterstützung, der bestehenden Infrastruktur, Ausfallbereichen und der Betriebsverantwortung ab
Beginnen Sie mit Anforderungen, die sich bei Einführung eines neuen Transports nicht ändern
Host-Ökosystem
Listen Sie Hypervisor-Versionen, Betriebssysteme, Datenbankanforderungen, Initiatoren, Multipath-Implementierungen und Boot-Abhängigkeiten auf
Ausfallmodell
Definieren Sie, was bei Ausfall von Kabel, Switch, Netzwerk, Zielport, Controller und dem gesamten Speicherknoten geschieht
Vorhandenes Fabric
Entscheiden Sie, ob ein betriebenes FC-SAN, herkömmliches Ethernet oder ein qualifiziertes RDMA-Netzwerk wiederverwendet werden soll
Betriebliche Zuständigkeit
Ermitteln Sie, wer die Zonierung, VLANs, verlustfreie Ethernet-Einstellungen, Firmware, Pfadrichtlinien und Änderungsfenster kontrolliert
Wählen Sie ein Transportprotokoll nicht allein anhand der Bandbreite aus Warteschlangenverhalten, Latenzkonsistenz, CPU-Pfad, Wiederherstellungszeiten und Plattformunterstützung sind oft wichtiger als die nominale Verbindungsrate
Ähnliche Ziele, unterschiedliche Befehlsmodelle und betriebliche Abhängigkeiten
Fibre Channel
Ausgereifter FCP-Blockspeicher mit dedizierten HBAs und geschalteten FC-Fabrics
- Optimale Eignung für bestehende SAN-Infrastrukturen in Unternehmen
- Dedizierte Fabric und spezialisiertes Betriebsmodell
- Zoning, LUN-Maskierung und Multipathing bleiben unerlässlich
NVMe/FC
Native NVMe-Befehle werden über eine Fibre Channel Fabric transportiert
- Kann die operative Trennung von FC aufrechterhalten
- Erfordert durchgängige NVMe/FC-Unterstützung
- Nicht dasselbe Protokoll wie das herkömmliche FCP
iSCSI
Das etablierte SCSI-Befehlsmodell wird über routingfähiges TCP/IP übertragen
- Breite Initiator- und Betriebssystemkompatibilität
- Nutzt vertraute Ethernet- und IP-Kenntnisse
- Benötigt unabhängige Pfade und diszipliniertes Speichernetzwerk
iSER
iSCSI Erweiterungen für RDMA erhalten das iSCSI-Ökosystem bei, während der Datenpfad geändert wird
- Nützlich, wenn die Semantik von iSCSI erhalten bleiben muss
- Erfordert kompatible Unterstützung für RDMA an beiden Enden
- Die Fabric-Qualifizierung ist anspruchsvoller als gewöhnliche TCP
NVMe/TCP
Native NVMe-Warteschlangen und -Befehle, die über Standard-TCP/IP-Netzwerke transportiert werden
- Routingfähig und einsetzbar über Standard-Ethernet
- Vermeidet RDMA-spezifische Fabric-Anforderungen
- Die Unterstützung von Host- und Zielfunktionen muss noch validiert werden
NVMe/RDMA
Natives NVMe über einen qualifizierten RDMA-Transport wie RoCE oder InfiniBand
- Entwickelt für einen Datenpfad mit geringerem Overhead
- Erfordert kompatible Adapter, Treiber und Fabric
- Die Betriebsqualität entscheidet darüber, ob der Vorteil realisiert wird
Vergleichen Sie, was betrieben werden muss – nicht nur, was übertragen wird
Diese Eigenschaften sind architektonische Tendenzen. Die genaue Leistung und Unterstützung hängen von der Implementierung, der Version, der Hardware und der Workload ab
| Protokoll | Befehlsmodell | Fabric | Routing | Host-Datenpfad | Betriebsstärke | Primäre Abhängigkeit |
|---|---|---|---|---|---|---|
| Fibre Channel | SCSI / FCP | Dedizierter FC | Fabric-basiert, kein IP-Routing | HBA-zentriert | Ausgereifte SAN-Verfahren und Isolation | Qualifizierter HBA, Switch, Optik, Zoning und Pfadrichtlinie |
| NVMe/FC | Natives NVMe | FC | Fabric-basiert, kein IP-Routing | HBA-zentriert | Behält das FC-Fabric-Modell bei | End-to-End-Unterstützung für NVMe/FC-Host, Fabric und Ziel |
| iSCSI | SCSI über TCP | Ethernet / IP | Routingfähig | TCP-Software oder Offload-Pfad | Umfassende Kompatibilität und vertraute Diagnosefunktionen | Korrektes VLAN-, Pfad-, MTU-, Sicherheits- und Multipathing-Design |
| iSER | iSCSI mit RDMA-Datenübertragung | RDMA-Netzwerk | Abhängig vom gewählten RDMA-Transport | RDMA-fähiger Pfad | Bewahrt die iSCSI-Semantik | Kompatibler iSER-Initiator, Ziel, Adapter, Treiber und Fabric |
| NVMe/TCP | Natives NVMe über TCP | Ethernet/IP | Routingfähig | TCP-Software oder Offload-Pfad | Modernes NVMe-Modell über Standard-Ethernet | Host-NVMe/TCP-Funktionen, Zielfunktionen und unabhängige Pfade |
| NVMe/RDMA | Natives NVMe | RoCE, InfiniBand oder ein anderes unterstütztes RDMA-Transportprotokoll | Transportspezifisch | RDMA-fähiger Pfad | Fabric-Pfad mit geringerem Overhead bei korrekter Implementierung | Vollständige RDMA-Qualifizierung und operative Fabric-Disziplin |
Die installierte Umgebung zur Eingrenzung der Kandidaten verwenden
Vorhandenes oder bewusst ausgewähltes FC-Fabric
Ethernet- oder RDMA-Fabric
Die Anwendung beeinflusst die Entscheidung, bestimmt sie aber selten allein
Kompatibilität und Wiederherstellungsverhalten
Überprüfen Sie die ESXi-Version, den Initiator, die Pfadrichtlinie, das Datenspeicherdesign und das Zielverhalten. Die Unterstützung für Fused Command ist insbesondere für NVMe-oF relevant und nicht bei allen Speicherimplementierungen identisch
MPIO und Clusterkoordination
Wählen Sie einen unterstützten Blockpfad und aktivieren Sie das erforderliche Multipathing auf jedem Host. Virtuelles Fibre Channel fügt separate NPIV- und Gastsystem-Designanforderungen hinzu
Externer gemeinsam genutzter Speicherkonsument
eEVOS kann kompatiblen gemeinsam genutzten Blockspeicher über integrierte Initiatoren nutzen und gleichzeitig Virtualisierung und integriertes Backup & Disaster Recovery bereitstellen
Latenzkonsistenz und -wiederherstellung
Messen Sie den gesamten E/A-Pfad und überprüfen Sie das Datenbankverhalten bei Pfadübergängen. Ein geringerer Protokoll-Overhead behebt kein unterdimensioniertes oder instabiles Speichersystem
Umfassende Initiatorunterstützung
iSCSI oder etablierte FC können das Integrationsrisiko reduzieren, wenn mehrere Host-Generationen dieselbe Speicherplattform nutzen müssen
Parallelität und Fabric-Effizienz
NVMe-oF eignet sich möglicherweise gut für hochparallele Workloads, aber Fabric, CPU, Beschleuniger-Datenpfad und Speichermedien müssen gemeinsam bewertet werden
Das Protokoll allein gewährleistet keine Hochverfügbarkeit
Ein robustes Design muss Ausfälle entlang des gesamten Datenpfads überstehen und die Speicherverwaltung korrekt gewährleisten
Hostpfad
Separate Initiator-Ports, Treiber und Multipathing-Logik müssen einen ausgefallenen Pfad erkennen und die Wiederherstellung ermöglichen
Netzwerkstruktur
Zwei an einen Switch oder eine Upstream-Komponente angeschlossene Kabel bilden keine unabhängigen Ausfalldomänen
Zieldienst
Zielports, -adressen oder -controller müssen ohne Konflikte bei der Speicherverwaltung ausfallen
Datenschicht
Replikation, gemeinsam genutzter Datenpool oder Scale-Out-Platzierung bestimmen, ob die zugrunde liegenden Daten verfügbar bleiben
Jede Option verlagert die Komplexität an eine andere Stelle
TCP-basierter Speicher
Spezialisierte Fabrics
Jede Plattform ihrer tatsächlichen Speicherrolle zuordnen
euroNAS dient als praktisches Implementierungsbeispiel. Das Protokoll muss weiterhin mit der aktuellen Version, Lizenz, Hardware und validierten Client-Plattform übereinstimmen
| Plattform | Zielprotokolle in diesem Vergleich | Initiator-/Konsumentrolle | Verfügbarkeitsmodell | Beste Architekturfrage |
|---|---|---|---|---|
| euroNAS Premium | FC-, iSCSI/iSER- und NVMe-oF-Transporte auf qualifizierter Hardware | Integrierte Initiatoren, sofern unterstützt | Eigenständiger Speicherserver, einschließlich Bereitstellungen virtueller Speichergeräte | Ist ein einzelner Speicherserver für das erforderliche Servicelevel ausreichend? |
| euroNAS HA Cluster | Hochverfügbare FC-, iSCSI/iSER- und NVMe-oF-Ziele auf qualifizierter Hardware | Integrierte Initiatoren, sofern unterstützt | Automatisches Service-Failover auf zwei Knoten mittels synchronem Mirroring oder Shared-Storage-Modell; asynchrone Replikation ist eine separate DR-Option | Welches Datenmodell und welches Failover-Verhalten sollen die beiden Knoten bereitstellen? |
| eEKAS |
iSCSI/iSER- und NVMe-oF-Ziele
Kein FC-Ziel |
Kann kompatible externe FC-Ziele über seinen FC-Initiator nutzen | Ceph Scale-Out-Speicher ohne feste Zwei-Knoten-Grenze | Benötigt das Projekt verteilte Kapazität und Gateway-Skalierung anstelle eines Zwei-Controller-Systems? |
| eEVOS | Keine Rolle des Speicherziels in diesem Vergleich | Nutzt kompatiblen externen gemeinsam genutzten Blockspeicher über integrierte Initiatoren | Virtualisierungsplattform mit integriertem Backup & Disaster Recovery | Soll die Plattform Rechenleistung, Virtualisierung, Backup und Speichernutzung kombinieren? |
euroNAS Premium
Verwenden Sie diese Option, wenn ein eigenständiges Speichersystem mehrere Datei- und Blockdienste bereitstellen soll
Premium-Details →HA Cluster
Verwenden Sie diese Option, wenn Zieldienste und deren geschützte Daten zwischen zwei Speicherknoten ausfallen müssen
HA Cluster Details →eEKAS
Verwendung für skalierbaren Speicher auf Basis von Ceph; externer FC-Speicher wird nur über einen Initiator genutzt
eEKAS Details →eEVOS
Verwendung als Alternative zu VMware, die Virtualisierung, Speichernutzung und Backup & Disaster Recovery kombiniert
eEVOS Details →VMware Zusammengeführte Befehle: Für NVMe-oF-Projekte muss sichergestellt werden, dass die vollständige Zielimplementierung das vom ausgewählten VMware-Release geforderte Befehlsverhalten unterstützt. Protokollkonnektivität allein ist nicht ausreichend, und die Unterstützung variiert je nach Speicherhersteller. Die hier beschriebenen Zielplattformen euroNAS und NVMe-oF unterstützen Fused Commands und Multipathing
Standards und Plattformrichtlinien
IETF RFC 7143 definiert das SCSI-over-TCP-Protokoll, Sitzungen, Namensgebung und Sicherheitsaspekte
Open RFC 7143 →IETF RFC 7145 definiert die iSCSI-Erweiterungen und die Datenübertragung, die mit RDMA verwendet werden
Open RFC 7145 →NVM Express erklärt, wie native NVMe-Befehle über die Transportprotokolle TCP, RDMA und Fibre Channel funktionieren
Open NVM Express-Leitfaden →NVM Express dokumentiert die Zuordnung von NVMe-Warteschlangen und die Datenübertragung über TCP
Open NVM Express-Leitfaden →Die NVM Express RDMA-Transportspezifikation definiert den NVMe-Daten- und Speichertransfer über ein RDMA-Fabric
Open NVM Express-Spezifikation →SNIA erläutert FC-Fabric-Topologie, verlustfreie Blocklieferung in der richtigen Reihenfolge und redundante Fabric-Verfahren
Öffnen Sie die SNIA-Richtlinien →Broadcom dokumentiert ESXi-Pfadauswahlrichtlinien und aktives/optimiertes Verhalten für ALUA
Öffnen Sie die Broadcom-Richtlinien →Microsoft dokumentiert die Anforderungen für MPIO- und Fibre Channel-Speicher in Hyper-V-Umgebungen
Microsoft-Anleitung öffnen →Red Hat erklärt, wie mehrere SAN-Pfade zu einem logischen Blockgerät mit Failover werden
Red Hat-Anleitung öffnen →Die Auswahlliste in eine validierte Architektur umwandeln
Hosts, Anwendungen, vorhandene Switches, Adapter, Verfügbarkeitsziele und betriebliche Einschränkungen teilen. Das Ergebnis sollte ein durchgängig unterstütztes Design sein – nicht nur ein Protokollname
Fibre Channel, NVMe, iSCSI, VMware, Hyper-V und zugehörige Marken gehören ihren jeweiligen Eigentümern. VMware und Microsoft werden als Beispiele für technische Interoperabilität genannt; diese Seite impliziert keine Partnerschaft oder Zertifizierung. Die Aussagen stellen architektonische Richtlinien und keine Leistungsgarantien dar. Unterstützte Konfigurationen hängen von aktuellen Produktversionen, Lizenzen, qualifizierter Hardware, Treibern, Firmware, Switches und validierten Client-Plattformen ab