Gemeinsam genutzter Speicher, der zum Hypervisor und zur Workload passt
Modernisierung des Speichers von VMware oder Hyper-V ohne Hypervisor-Migration. Die Software euroNAS kann Datei- oder Blockspeicher von einem einzelnen Server, einem hochverfügbaren Serverpaar, einer Scale-Out-Plattform Ceph oder einer validierten Bereitstellung Virtual Storage Appliance bereitstellen
Beibehaltung der Rechenplattform. Verbesserung der Speicherschicht
VMware und Hyper-V verwenden beide gemeinsam genutzten Speicher, aber ihre bevorzugten Protokolle, Pfadverwaltung und Betriebsanforderungen sind nicht identisch. Die Architektur muss für den ausgewählten Hypervisor entworfen werden und darf nicht unverändert aus einer anderen Umgebung kopiert werden
VMware vSphere-Speicher
Gemeinsam genutzte Datenspeicher über ausgereifte SCSI-Protokolle oder den nativen NVMe-Stack bereitstellen. NVMe/TCP-Unterstützung ist ab vSphere 7.0 Update 3 verfügbar; die genaue ESXi-Version, der Adapter, das Zielsystem und das Pfaddesign müssen weiterhin gemeinsam qualifiziert werden
- NFS-Datenspeicher für dateibasierte Einfachheit
- iSCSI und Fibre Channel für etablierte VMFS-Designs
- NVMe/TCP oder NVMe/RDMA für qualifizierte moderne Fabrics
- Unterstützung für Fused Command für korrektes NVMe Compare and Write-Verhalten
Microsoft Hyper-V-Speicher
Erstellen Sie Shared-Storage-Cluster mithilfe der für Windows Server dokumentierten Protokolle und validieren Sie Cluster Shared Volumes, Failover und Pfadwiederherstellung mit der vorgesehenen Hardware
- Block-Speicher iSCSI und Fibre Channel
- SMB 3.0 mit den erforderlichen Verfügbarkeitsfunktionen
- NVMe-oF nur über einen separat qualifizierten Initiator- und Treiberpfad
Unabhängige Technologie-Leitlinie: euroNAS wird auf dieser Seite weder als VMware noch als Microsoft-Partner aufgeführt. Die Eignung von Produkt und Protokoll muss anhand der geltenden Kompatibilitätsprogramme, der Betriebssystemversion und der Supportrichtlinien geprüft werden
Gemeinsam genutzter Speicher ist kein einheitliches Protokoll
Wählen Sie den Datenpfad entsprechend Kompatibilität, Latenz, Betriebskenntnissen, Netzwerkdesign und Wiederherstellungsanforderungen. Auch ein unterstütztes Transportprotokoll erfordert eine End-to-End-Qualifizierung
| Protokoll | VMware | Hyper-V | Architekturhinweise |
|---|---|---|---|
| NFS | Verbindung hergestellt Dateibasierter VMware-Datenspeicher | Nicht der Standardpfad Hier nicht für geclusterten Hyper-V-VM-Speicher dargestellt | Einfachere dateibasierte Darstellung; Verfügbarkeit abhängig vom NAS-Dienst und Netzwerkdesign |
| iSCSI | Eingerichtet VMFS-Blockspeicher | Eingerichtet Windows Server-Blockspeicher und CSV | Verwenden Sie separate Pfade, Zielportale und die entsprechende ESXi- oder Windows-Multipath-Richtlinie |
| Fibre Channel | Eingerichtet VMFS über redundante Fabrics | Eingerichtet SAN und optionale virtuelle Fibre Channel-Anwendungsfälle | Erfordert qualifizierte HBAs, Zonierung, LUN-Präsentation und redundantes Fabric-Design |
| SMB 3.0 | Kein VMware-Datenspeicherpfad | Eingerichtet Einschließlich Multichannel und SMB Direct, sofern unterstützt | Validieren Sie das Verhalten von SMB 3.0 und die für das Design von Hyper-V erforderliche kontinuierliche Verfügbarkeit |
| NVMe/TCP | Unterstützter Pfad vSphere 7.0 Update 3 und höher | Separat qualifizieren Gehen Sie nicht von einem nativen Produktionspfad aus | Verwendet Standard-IP-Netzwerk und den NVMe-Stack; redundante Controller und Netzwerkpfade bleiben erforderlich |
| NVMe/RDMA | Qualifizierte Fabrics Erfordert kompatible ESXi-Hosts, Adapter und ein kompatibles Netzwerk | Separate Qualifizierung | Geringerer Transportaufwand, jedoch müssen die gesamte RDMA-Fabric, Firmware und das Fehlerverhalten validiert werden |
Redundanz vom Host zum Speicher muss vorhanden sein
Ein Dual-Controller-Speichersystem kann ein Design nicht schützen, das weiterhin von einem Adapter, Switch, VLAN oder Hostpfad abhängt. Multipathing ist eine End-to-End-Architektur
VMware- oder Hyper-V-Hosts
Mindestens zwei unabhängige Host-seitige Pfade mit der entsprechenden HPP-, NMP-, MPIO- oder SMB-Multichannel-Richtlinie
Unabhängige Fabrics oder Netzwerke
Separate Adapter und Switches oder Fehlerdomänen. Vermeiden Sie es, beide logischen Pfade auf einer physischen Abhängigkeit zu platzieren
euroNAS-Speicher
Premium, HA Cluster oder eEKAS werden je nach erforderlicher Verfügbarkeit und Skalierungsmodell ausgewählt
Fused Commands sind eine kleine Funktion mit großer Auswirkung
VMFS verwendet atomare Sperrsemantik. Wenn ein NVMe-Gerät die Unterstützung für kombinierte Operationen signalisiert, kann ESXi die Befehle „Vergleichen“ und „Schreiben“ als kombiniertes Befehlspaar ausgeben. Das Zielsystem muss die beiden Befehle zusammen verarbeiten und das erforderliche atomare Verhalten beibehalten
Konnektivität reicht nicht aus
Ein NVMe-Namespace kann zwar auffindbar sein, aber dennoch die Erstellung von Datenspeichern oder Sperrvorgänge fehlschlagen lassen, wenn kombinierte Befehle nicht korrekt verarbeitet werden
Unterstützung für das Zielsystem euroNAS
Die Zielpfade euroNAS Premium, HA Cluster und eEKAS sowie NVMe-oF unterstützen kombinierte Befehle und Multipath-fähige Designs
End-to-End-Validierung
ESXi-Release, nativer NVMe-Treiber, Adapter, Transportprotokoll, Zielversion und Pfadrichtlinie müssen vor dem Produktiveinsatz gemeinsam getestet werden
Eine Softwarefamilie, unterschiedliche Verfügbarkeitsgrenzen
Die Produkte sind nicht austauschbar. Wählen Sie die Plattform entsprechend der Toleranz gegenüber Speicherausfällen, Controller-Ausfällen und Kapazitätswachstum, die das Design tolerieren muss
euroNAS Premium
Ein Speicherbetriebssystem für einen physischen oder virtuellen Server
- Datei- und Blockdienste
- Geeignet für unabhängige oder extern geschützte Workloads
- Kein automatisches Speicher-Controller-Failover
euroNAS HA Cluster
Zwei-Knoten-Speicher mit zwei unterschiedlichen Schutzmodellen: synchrone Spiegelung für nahtloses Failover oder asynchrone Replikation für geplanten Speicherschutz
- Synchrones Spiegeln: Bestätigte Schreibvorgänge bleiben auf beiden Knoten für ein nahtloses Failover ausgerichtet
- Asynchrone Replikation: Der Wiederherstellungspunkt hängt vom zuletzt erfolgreich replizierten Zustand ab
- Storage: Adress- und Zielverhalten müssen für das ausgewählte Modell validiert werden
- Erfordert Fencing und getestete Client-Wiederherstellung
eEKAS
Ceph-basierter Speicher für Kapazität, Ausfallsicherheit und Dienste, die über ein Zwei-Knoten-Spiegeln hinauswachsen müssen
- Scale-out Fehlerdomänen
- Ausfallsicherheit verteilter Daten
- Gateway- und Backend-Netzwerke gemeinsam dimensioniert
Physische Appliance oder Virtual Storage Appliance
Je nach Produkt und Architektur kann euroNAS direkt auf Enterprise-Serverhardware oder als virtuelle Speicher-Appliance ausgeführt werden. Virtuelle Bereitstellungen erfordern gezielte Ressourcenreservierungen, Festplattenpräsentation, Bootsequenzierung und Trennung der Ausfalldomänen, damit der Speicherdienst nicht von derselben Komponente abhängt, die er schützen soll
Schutzumfang: VM-Backup, Instant Backup & Recovery und integriertes Offsite-DR sind Funktionen von eEVOS. euroNAS-Speichersysteme bieten Schutz auf Speicherebene durch Mechanismen wie Snapshots und asynchrone Replikation. Der Wiederherstellungspunkt wird durch den zuletzt erfolgreich replizierten Zustand bestimmt. Storage-Replikation ergänzt, ersetzt aber nicht, die workloadkonsistente Datensicherung
Testverhalten bei Fehlern – nicht nur normale E/A
Ein Speicherdesign ist fertig, wenn der vorgesehene Hypervisor, die Pfade und die Wiederherstellungsverfahren gemeinsam getestet wurden
Einen Pfad entfernen
Überprüfung der fortlaufenden E/A, der Wiederherstellungszeit und der Pfadstatusmeldung bei Ausfall eines Adapters, Kabels oder Switches
Dienst verschieben
Zielverschiebung oder Gateway-Verlust testen und die Unterbrechung bei laufenden virtuellen Maschinen messen
Verbindungen wiederherstellen
Verfügbarkeit von persistenter Erkennung, Zugriffsrichtlinien, Multipath-Controllern und Datenspeicher nach dem Neustart bestätigen
Asynchrone Replikation testen
Validierung asynchroner Snapshot- und Replikations-Workflows, einschließlich Ziel, Aufbewahrung, Replikationsintervall, erwartetem Wiederherstellungspunkt und Wiederherstellung replizierter Daten
Technische Grundlagen
Diese Seite verwendet die aktuelle Produktdokumentation für euroNAS zusammen mit Broadcom-Richtlinien zu NVMe/TCP und dem kombinierten Compare-and-Write-Verhalten sowie Microsoft-Richtlinien zu Hyper-V-Speicherarchitekturen. Die versionsspezifische Kompatibilität muss während der Implementierung erneut geprüft werden
Broadcom: Unterstützung für NVMe/TCP ab vSphere 7.0 Update 3 · Broadcom: VMFS und Fused Compare and Write · Microsoft: Speicherarchitekturen für Hyper-V
Hypervisor, Protokoll und Ausfalldomänen vor der Produktauswahl abbilden
Hostversionen, Adapter- und Switch-Auswahl, Datenspeicheranforderungen, Multipath-Richtlinien, Verfügbarkeitsziele und Wiederherstellungsziele prüfen und in eine praktische Speicherarchitektur umsetzen
VMware und vSAN sind Marken von Broadcom Inc. Hyper-V und Windows Server sind Marken der Microsoft Corporation. Die Nennungen dienen der Beschreibung und implizieren keine Partnerschaft, Zertifizierung oder Empfehlung