Ceph, ZFS-Replikation und ein externes SAN oder NAS können Proxmox-VMs über einen Hostausfall bringen. Sie liefern aber nicht dieselbe Datenaktualität, denselben Wiederanlauf und dieselbe Fehlerdomäne. Wer nur „hochverfügbar“ ankreuzt, übersieht oft die eigentliche Anforderung: Wie viele Minuten Datenverlust sind für die Anwendung tragbar (RPO), und wann muss sie wieder nutzbar sein (RTO)?
Hier vergleichen wir drei Speicherwege für denselben hypothetischen Drei-Host-Cluster. Wie Ceph nach einem Hostausfall Kopien wieder aufbaut, ist separat beschrieben. Die Entscheidung hier beginnt bei den Anwendungen und ihren nachweisbaren Wiederherstellungszielen. Ein getrenntes Backup mit Restore-Test bleibt bei allen drei Wegen zusätzlich erforderlich.
Drei Architekturen, drei verschiedene Ausfallwege
Ceph auf lokalen SSDs stellt den VM-Datenträger als verteilten, im Cluster gemeinsam erreichbaren Blockspeicher bereit. In einem replizierten Pool liegen Kopien auf mehreren Hosts; Quorum, Pool-Regel, Netzwerk und freie Kapazität müssen zu der gewählten Host-Fehlerdomäne passen. Nach dem Ausfall eines VM-Hosts kann Proxmox HA eine VM auf einem anderen Host neu starten, wenn Quorum und Ressourcen vorhanden sind. Ein laufender Schreibvorgang, die Gastanwendung und deren Transaktionen müssen trotzdem im Ausfalltest beurteilt werden. Ceph-Redundanz allein verspricht weder eine unterbrechungsfreie VM noch eine garantierte RPO-Null für jede Anwendung.
Lokales ZFS mit Proxmox-Speicherreplikation überträgt VM-Volumes in Zeitabständen per Snapshot auf einen anderen Host. Der Zielhost hat den Stand der letzten erfolgreich abgeschlossenen Replikation. Proxmox erlaubt HA zusammen mit dieser Replikation, weist aber ausdrücklich auf möglichen Datenverlust seit der letzten Synchronisierung hin. Ein eingestellter Fünf-Minuten-Takt ist daher keine pauschale RPO-Zusage: Verzug, fehlgeschlagene Jobs und Anwendungszustand zählen mit. Ohne synchronen gemeinsamen Datenträger muss die wieder gestartete VM mit genau diesem älteren Stand umgehen können.
Externes Shared Storage wie NFS oder iSCSI macht VM-Datenträger für mehrere Hosts erreichbar und erlaubt typischerweise Live-Migration ohne Kopie des VM-Datenträgers. Für den Hostausfall hängt das Datenrisiko vom tatsächlichen Storage-Design ab. Zwei Controller, getrennte Daten- und Strompfade, Multipathing bei iSCSI beziehungsweise redundante Netzpfade bei NFS, Support und ein getesteter Controller-Failover sind zu prüfen; ein einzelnes NAS bleibt eine zentrale Fehlerdomäne. Die Proxmox-Dokumentation warnt ausdrücklich davor, ein ZFS-over-iSCSI-Gerät zum Single Point of Failure zu machen. „Shared“ in der Konfiguration beweist keine redundante Appliance.
Welcher Workload verträgt welchen RPO und RTO?
RPO misst die maximal akzeptierte Datenlücke, RTO die maximal akzeptierte Zeit bis zur nutzbaren Anwendung. Die folgenden Angaben sind Entscheidungsfragen, keine Produkt-SLAs. Für jeden Dienst müssen Datenbank, VM-Neustart, DNS, Benutzeranmeldung und abhängige Systeme im Test zusammen betrachtet werden.
| Anwendung und Ziel | Plausibler Weg | Entscheidende Prüfung |
|---|---|---|
| Transaktionale ERP-Datenbank; kaum Datenverlust tragbar | Ceph oder belastbar redundantes Shared Storage; ggf. zusätzlich anwendungseigene Replikation | Schreib-Latenz, Transaktionskonsistenz, Quorum und echter Neustart bei Host-/Storagefehler |
| Interne Test-VM oder wiederherstellbarer Webdienst; Minuten Datenlücke akzeptiert | Lokales ZFS mit Replikation kann genügen | Alter des letzten erfolgreichen Snapshots, Alarm bei Verzug, Start mit älterem Datenstand |
| Vorhandenes, supportetes SAN/NAS mit ausreichender Reserve | Weiternutzung als Shared Storage kann wirtschaftlich sein | Controller, Pfade, Strom, Firmware, Wartungsvertrag und Live-Failover gemeinsam testen |
Für eine produktive Datenbank mit sehr engem RPO kann asynchrone ZFS-Replikation ungeeignet sein, selbst wenn ein HA-Neustart funktioniert. Umgekehrt rechtfertigt ein wiederherstellbarer Testdienst nicht automatisch einen Ceph-Verbund. Ein einzelner Storage-Server wird auch durch drei Proxmox-Hosts nicht redundant. Die technische Wahl folgt dem akzeptierten Datenverlust und der gemessenen Unterbrechung, nicht dem Namen des Produkts.
Drei- und Fünfjahresrechnung ohne Scheinpreise
Ein hypothetischer Vergleich setzt drei identische Ein-Sockel-Hosts mit Kaufpreis h je Host und einen getrennten Backup-Server mit Medien zum Preis b voraus. Proxmox VE Standard kostet laut aktueller Herstellerliste 550 € je belegtem CPU-Sockel und Jahr; ein Proxmox Backup Server Standard 2.240 € je Server und Jahr. Der gemeinsame Supportblock beträgt somit 3 × 550 + 2.240 = 3.890 € jährlich. Das Modell setzt 90 € je Arbeitsstunde netto an. Es vergleicht weder ungeprüft gleiche IOPS noch gleiche Nutzkapazität: Diese Größen müssen in echten Angeboten zuerst auf denselben Workload normiert werden.
d steht für zusätzliche Ceph-Daten-SSDs je Host, z für lokale ZFS-SSD-Ausstattung je Host, a für eine redundant ausgelegte externe Appliance, nc, nz und ns für die jeweils nötigen Netz- oder Fabric-Investitionen. ec, ez und es sind jährliche zusätzliche Energie-/Housingkosten; s ist der jährliche Hersteller-Servicevertrag der externen Appliance. Alle Buchstaben sind Netto-Angebotswerte in Euro, keine behaupteten Marktpreise.
| Weg | Aufbau / Betrieb pro Jahr | 3 Jahre | 5 Jahre |
|---|---|---|---|
| Ceph | 80 h / 50 h | 3h + b + 3d + nc + 32.370 + 3ec € | 3h + b + 3d + nc + 49.150 + 5ec € |
| ZFS-Replikation | 50 h / 30 h | 3h + b + 3z + nz + 24.270 + 3ez € | 3h + b + 3z + nz + 37.450 + 5ez € |
| Externes Storage | 60 h / 35 h | 3h + b + a + ns + 26.520 + 3s + 3es € | 3h + b + a + ns + 40.600 + 5s + 5es € |
Die Arbeitsstunden sind reine Modellannahmen, keine DAXS-Pauschale. Beispiel: 1.000 € mehr jährlicher Appliance-Service erhöhen die externe Variante über drei Jahre um 3.000 € und über fünf Jahre um 5.000 €. Eine vorhandene Appliance kann a im Betrachtungszeitraum senken, aber Restlaufzeit, Support, Ersatzteile und Erweiterung gehören dann in s oder ein gesondertes Investitionsfeld. Hardwarepreise, Speicherverbrauch, Leistungsprofil, Netzwerk, Steuer und Betriebsort sind mit Angeboten zu belegen. Der niedrigste Formelwert ist ohne gleiche nutzbare Kapazität, IOPS, RPO und RTO keine Kaufentscheidung.
Abnahme: einen Ausfall pro Fehlerdomäne wirklich durchspielen
DAXS würde für jede infrage kommende Architektur vier Nachweise verlangen: (1) Zeitpunkt des letzten konsistenten Anwendungsstands erfassen, (2) einen Hostausfall und VM-Neustart mit Nutzlast messen, (3) zusätzlich den kritischen Speicher- oder Netzpfad gezielt ausfallen lassen und (4) eine VM und einzelne Anwendungsdaten aus einem getrennten Backup wiederherstellen. Bei ZFS gehört ein ausgefallener oder verspäteter Replikationsjob dazu; bei Ceph der degradierte Pool und dessen Wiederaufbau; beim SAN/NAS der Controller- und Pfadwechsel. Erst die Messwerte entscheiden, ob RPO und RTO erreicht werden.
Ceph-Kopien, Replikations-Snapshots und Array-Spiegelung transportieren auch Löschungen und fehlerhafte Daten weiter. Sie ersetzen keine Versionierung, keine externe Kopie und keinen Restore-Test. Der DAXS-Beitrag Proxmox Backup Server: Verify, Aufbewahrung und Restore vertieft die Backup-Abnahme. Wer eine Anwendungsliste samt RPO-/RTO-Zielen hat, kann mit DAXS über Kontakt die drei Wege an der realen Last und den vorhandenen Verträgen messen lassen.
Quellen: Proxmox VE Administration Guide: Storage, Storage Replication und HA · Proxmox VE: aktuelle Supportpreise · Proxmox Backup Server: aktuelle Supportpreise.