Beginnen Sie mit der Workload – nicht mit dem Produktnamen
Wählen Sie die Speicher- und Virtualisierungsarchitektur anhand von Zugriffssemantik, Ausfallgrenzen, Wiederherstellungszielen und Wachstum. Die Produktauswahl sollte das Ergebnis dieses Prozesses sein, nicht dessen Ausgangspunkt
und E/A-Verhalten
Datei, Block oder Objekt
und Wiederherstellungsziele
und Betriebsmodell
Ermitteln Sie, welche Speicheranforderungen die Anwendung hat
Dieselbe Kapazitätsangabe kann sehr unterschiedliche Systeme beschreiben. Beginnen Sie mit Zugriffsmuster, Parallelität, Konsistenz, Wiederherstellung und Betriebsverantwortung
VMware, Hyper-V oder eEVOS
Priorisierung: Unterstützt gemeinsam genutzten Speicher, Multipathing, konsistentes Failover und Wiederherstellung auf VM-Ebene. eEVOS ist auch eine vollständige Virtualisierungsalternative mit integriertem Backup & Disaster Recovery
Virtualisierungsleitfaden öffnen →Transaktionale und latenzempfindliche E/A
Priorisierung: Dauerhafte Schreibvorgänge, vorhersehbare Latenz, Pfadresilienz und anwendungskonsistente Wiederherstellung. Benchmark des realen Datenbankprofils
Blockzugriffsoptionen vergleichen →Persistente Kubernetes-Daten
Priorisieren: CSI-Integration, Zugriffsmodi, Ausfallbereichsausrichtung, Lebenszyklusverhalten und Schutz außerhalb des Pods
Öffnen Sie den Kubernetes-Leitfaden →Parallele Datenpipelines
Priorisieren: Gesamtdurchsatz, Metadatenverhalten, Netzwerkdesign und Versorgung mehrerer Rechenknoten. GPUDirect Storage ist nicht impliziert
Öffnen Sie den KI- und HPC-Leitfaden →Bearbeitung, Aufnahme und Rendering
Priorisieren: Gleichzeitige, kontinuierliche Datenströme, gemeinsamer Namensraum, Projektschutz und vorhersehbare Zusammenarbeit zwischen Clients
Medienleitfaden öffnen →Kontinuierliche Aufzeichnung und Beweissicherung
Priorisierung: Dauerhafte Schreiblast, Aufbewahrung, Kamera-/VMS-Kompatibilität, Fehlerverhalten und praktische Abrufbarkeit
Überwachungsleitfaden öffnen →Zusammenarbeit von SMB und NFS
Priorisierung: Identität, Berechtigungen, Sperrung, Clientmix, Namensraum und Service-Failover – nicht nur die aggregierte Bandbreite
Dateizugriffseigenschaften prüfen →S3 für Anwendungen oder Dienstanbieter
Priorisieren: API-Kompatibilität, Mandantenfähigkeit, Schutz, Lebenszyklus, Kontingente und Betriebsmodell. MSP-Anforderungen erfordern ein separates Design
Öffnen Sie den Leitfaden für Enterprise S3 →Wählen Sie die Schnittstelle, die die Workload korrekt verwenden kann
Ein Protokoll ist keine Leistungsgarantie. Hosts, Netzwerke, Pfaddesign, Warteschlangenverhalten, Speichermedien und die Anwendung beeinflussen das Ergebnis
| Zugriff | Datenmodell | Guter Ausgangspunkt | Design-Kompromisse zur Validierung | Technischer Leitfaden |
|---|---|---|---|---|
| SMB | Datei | Windows-orientierte Dateidienste, Zusammenarbeit, Medien- und Anwendungsfreigaben | Identität, ACLs, Sperren, Dialekt- und Mehrkanal-/Client-Unterstützung | SMB & NFS |
| NFS | Datei | Linux/Unix-Anwendungen, VMware NFS und gemeinsam genutzte Namensräume | Version, Sperren, Identitätszuordnung, Mount-Verhalten und Failover | SMB & NFS |
| iSCSI | Block over Ethernet | Weitgehend verstandener gemeinsam genutzter Blockspeicher für Virtualisierung und Anwendungen | Multipathing, Netzwerkisolation, Host-Dateisystembesitz und Warteschlangendesign | iSCSI → |
| Fibre Channel | Block über FC-Fabric | Etablierte Enterprise-SAN-Umgebungen mit operativer FC-Expertise | Zoning, Dual Fabrics, HBAs, Multipathing und Lebenszykluskosten | Fibre Channel → |
| NVMe/TCP | NVMe-Block über TCP/IP | Moderner Ethernet-Blockspeicher ohne RDMA-Anforderung | Hostqualifizierung, Multipathing, Verlust/Latenz, CPU und End-to-End-Unterstützung | NVMe-oF → |
| NVMe/RDMA | NVMe-Blockierung über RDMA | Ressourcenschonende, latenzempfindliche Fabrics, bei denen der gesamte Pfad qualifiziert ist | RoCE/InfiniBand Engineering, NICs, Switching, Stau- und Betriebskenntnisse | RDMA → |
| S3 | Objekt | Anwendungen, Archive, Backup-Ziele und Multi-Tenant-Dienste mit einer S3-kompatiblen API | Anwendungskompatibilität, Konsistenzerwartungen, Objektgröße, Lebenszyklus und Mandantenfähigkeit | Enterprise S3 → |
Dateizugriffe sollten nicht ohne Weiteres in Blockzugriffe übersetzt werden Bei Blockspeicherung ist der Host normalerweise für das Dateisystem und die Koordination verantwortlich. Mehrere Hosts benötigen eine Anwendung oder ein Cluster-Dateisystem, das für den gemeinsamen Blockzugriff ausgelegt ist
Wählen Sie die Ausfallgrenze – nicht ein abstraktes „HA“-Label
Legen Sie fest, welche Fehler automatisch toleriert werden müssen, für welche Ereignisse ein Wiederherstellungsverfahren erforderlich ist und wie viel Verlauf unabhängig wiederherstellbar bleiben muss
Ein Speicherserver
Fokussiert und wirtschaftlich, aber ein Serverausfall wird nicht durch einen zweiten Speicherknoten kompensiert. Fügen Sie eine unabhängige Wiederherstellung und einen Betriebsplan hinzu
Automatisches Failover auf zwei Knoten
Schützt die lokale Servicekontinuität durch synchrones Spiegeln oder gemeinsam genutzten Speicher mit zwei Controllern. Latenz, Quorum und Pfade sind wichtig
Separate Wiederherstellungskopie
Bietet einen wiederherstellbaren Punkt auf einem anderen System oder Standort. Die Datenlücke entspricht dem letzten abgeschlossenen Replikationszyklus
Scale-out-Kontinuität
Verteilt Daten auf mehrere Knoten und Ausfalldomänen. Quorum, Schutzrichtlinie, freie Kapazität und Netzwerkdesign bestimmen die Toleranz
Backup und beibehaltene Versionen
Schützt vor Löschung, Beschädigung oder unerwünschten Änderungen. Eine zweite Live-Kopie allein ist kein historisches Backup
Kann der Dienst nach dem Ausfall einer Komponente, eines Pfads oder eines Knotens fortgesetzt werden?
Kann ein Dienst über die lokale Ausfallgrenze hinaus innerhalb seiner RPO und RTO wiederhergestellt werden?
Können bekannte historische Daten unabhängig wiederhergestellt und verifiziert werden?
Vergleichen Sie die euroNAS-Beispiele, nachdem die Anforderungen klar definiert sind
Die folgenden Plattformen lösen unterschiedliche Betriebsprobleme. Keine ist universell „beste“; die richtige Auswahl hängt von der bereits definierten Architektur ab
| Entscheidungspunkt | euroNAS Premium | HA Cluster | eEKAS | eEVOS |
|---|---|---|---|---|
| Primäre Rolle | Storage Betriebssystem für einen physischen Server oder Virtual Storage Appliance | Automatischer Zwei-Knoten-Speicherdienst | Verteilte Ceph Speicherplattform | Virtualisierungsplattform mit integriertem Datenschutz |
| Topologie | Standalone, Scale-up | Zwei Knoten: synchroner Spiegel oder gemeinsam genutzter Speicher mit zwei Controllern | Multi-Node Scale-out ohne festen Zwei-Knoten-Grenze | Kompakte Virtualisierungsdesigns mit zwei Knoten, gemeinsamem Speicher oder Scale-Out |
| Client-Dienste | Datei-, Block- und S3-Dienste | Hochverfügbare Datei-, Block- und S3-Dienste | Ceph-Block-, Datei- und S3-Dienste | Virtuelle Maschinen; der Speicher kann intern, extern gemeinsam genutzt oder Ceph-basiert sein |
| Verfügbarkeit | Abhängig vom Serverdesign; asynchrone Replikation kann eine separate Wiederherstellungskopie bereitstellen | Automatisches lokales Service-Failover innerhalb der unterstützten Zwei-Knoten-Architektur | Verteilter Service- und Datenschutz über Knoten und Ausfalldomänen hinweg | VM-Verfügbarkeit, Live-Migration und Clusterbetrieb gemäß der gewählten Topologie |
| Wachstumsmodell | Skalierung innerhalb eines Servers | Skalierung innerhalb des Zwei-Knoten-Designs | Hinzufügen qualifizierter Knoten und Kapazität; Rebalancing im verteilten Cluster | Hinzufügen von Rechenknoten jederzeit; Sie nutzen den konfigurierten internen, externen oder Ceph-Speicher |
| Wiederherstellungsbereich | Snapshots und asynchrone Replikation für Wiederherstellungsworkflows auf Speicherebene | Automatisches Failover plus Snapshots und separate Optionen für asynchrone Replikation | Verteilter Schutz plus anwendungsgeeignete Backup- oder externe Wiederherstellungsprozesse | Integrierter Backup & Disaster Recovery, einschließlich Instant Backup & Recovery, Netzwerk-Backup und Cloud-Backup |
| S3-Operationen | S3-kompatibler Dienst und integrierter S3 File Manager; Bucket-Anzahl-Kontingente | S3-kompatibler Dienst und integrierter S3 File Manager; Bucket-Anzahl-Kontingente | Ceph S3, S3 File Manager, Bucket-Anzahl- und Kapazitätskontingente; Abrechnungsfunktionen zur Nutzung durch Dienstanbieter | Nicht die universelle Speicherplattform S3 in diesem Vergleich |
| Wichtiger Unterschied | Kein automatisches Zwei-Knoten-Speicher-Failover | Feste lokale Zwei-Knoten-Architektur; kein verteilter Scale-Out-Cluster | Erfordert eine angemessene Knotenanzahl, ein geeignetes Netzwerk, Kapazitätsreserven und eine entsprechende Planung des verteilten Systems | Eine Virtualisierungsplattform und kein Speicherprodukt. Sie bietet selbst keine Speicherdienste, kann aber internen Speicher, externen gemeinsam genutzten Speicher und Ceph-basierten Speicher nutzen |
| Optimale Lösung | Fokussierter Standalone-Speicher mit definiertem Skalierungsbereich | Kompakter automatischer lokaler Speicher mit Hochverfügbarkeit | Größerer Scale-Out-Speicher, Ceph-Dienste und MSP-orientierter S3 | Organisationen, die Virtualisierung, VM-Betrieb und Wiederherstellung auf einer Plattform benötigen |
| Produktdetails | Premium → | HA Cluster → | eEKAS → | eEVOS → |
Die Tabelle ist eine Erste Auswahlhilfe, keine Kompatibilitätsaussage oder Dimensionierungsberechnung. Bestätigen Sie die erforderlichen Protokolle, Hostversionen, Hardware, Netzwerkarchitektur und das Anwendungsverhalten für die vorgeschlagene Konfiguration
Ein Produkt folgt dem Betriebsmodell
Verwenden Sie diese Fragen, um die Architektur einzugrenzen, und validieren Sie anschließend die Workload und das Protokoll im Detail
- Benötigen Sie eine vollständige Virtualisierungsplattform oder Speicher für einen anderen Hypervisor?
- Muss der Speicher nach einem vollständigen Serverausfall automatisch weiterlaufen?
- Ist die Wachstumsgrenze ein Server, zwei Knoten oder ein verteilter Cluster?
- Sind Backup und Wiederherstellung für VMs, Speicherdaten oder beides erforderlich?
- Welches Team betreibt Netzwerk, Hosts, Speicher und Wiederherstellungsverfahren?
Vier Architekturen decken sehr unterschiedliche Bereiche ab
Standalone-Speicher
Hosts
Server oder VSA
Einfache Besitzverhältnisse und ein definierter Skalierungsbereich. Fügen Sie bei Bedarf ein separates Wiederherstellungsziel hinzu
Premium-Beispiel →Zwei-Knoten-Speicher-HA
Knoten A
Knoten B
Automatisches Failover mit synchronem lokalem Schutz oder einem Shared-Storage-Controller-Modell
HA Cluster-Beispiel →Verteilter Speicher
Endpunkte
und Dienste
Block-, Datei- und S3-Dienste, verteilt auf qualifizierte Knoten und explizite Ausfalldomänen
eEKAS-Architektur →Virtualisierungsplattform
Rechenleistung
oder Ceph-Speicher
VM-Lebenszyklus, Verfügbarkeit und integrierte Wiederherstellung mit Speicher, der für die erforderliche Topologie ausgewählt wird
eEVOS-Architektur →Validierung des gesamten Dienstes, nicht nur des Speichersystems
Ein glaubwürdiges Design kombiniert gemessene Workloaddaten mit aktueller Kompatibilität und einem getesteten Betriebsablauf
Unterstützte Protokolle, Versionen, Dateisystemberechtigungen, Konsistenz- und Wiederherstellungsanforderungen
Kapazitätswachstum, Block- und Objektgröße, Lese-/Schreibverhältnis, Parallelität, Latenz und Burst-Verhalten
Geräte-, Knoten-, Switch-, Rack-, Stromversorgungs- und Standortereignisse, die der Dienst tolerieren muss
RPO, RTO, Aufbewahrung, Wiederherstellungsgranularität, Unveränderlichkeit und Verantwortlichkeit während eines Vorfalls
Bandbreite, Redundanz, Multipathing, Zoning/VLANs, RDMA Konfiguration und operative Transparenz
Erweiterungsschritte, Wartungsfenster, Wiederherstellungsreserve, Überwachung, Kompetenzen und Lebenszyklusverantwortung
Anforderungen in eine Auswahlliste umwandeln
Wir können die Workload, die Zugriffsmethode, die Ausfalldomänen, die Wiederherstellungsziele und den Wachstumsplan für ein Unternehmensspeicher- oder Virtualisierungsprojekt überprüfen