Proxmox Fachwissen · Storage
Proxmox Storage passend zu Workload und Ausfallziel auswählen.
Ceph, lokales ZFS, Replikation, NFS, iSCSI und klassische SAN-Systeme können in einer Proxmox-Umgebung sinnvoll sein. Die richtige Wahl entsteht aus I/O-Profil, Latenz, Kapazität, Verfügbarkeit, Wachstum, Wiederherstellbarkeit und dem Betriebswissen des Teams – nicht aus einem pauschalen Produktvergleich.
Workloadprofil
Storage-Entscheidungen beginnen bei den Anwendungen.
Eine Kapazitätsangabe in Terabyte beschreibt noch keine geeignete Storage-Plattform. Datenbanken erzeugen andere I/O-Muster als große Dateiablagen, VDI-Arbeitsplätze oder Archivsysteme. Wichtig sind zufällige und sequenzielle Zugriffe, Blockgröße, Schreibanteil, Latenzempfindlichkeit, Spitzenlast, Wachstum und die Frage, wie sich ein Rebuild unter Last auswirkt.
AOIT erfasst reale Messwerte, berücksichtigt aber auch geplante Veränderungen. Eine neue Warenwirtschaft, zusätzliche Standorte oder konsolidierte File-Services können das Profil deutlich verschieben. Aus den Anforderungen entstehen Zielwerte für nutzbare Kapazität, IOPS, Durchsatz, Latenz, Redundanz, RPO und RTO sowie ein nachvollziehbarer Wachstumspuffer.
Leistung
Latenz, IOPS und Durchsatz passend zu den kritischen Anwendungen.
Verfügbarkeit
Controller, Disks, Netzwerkpfade und Fehlerdomänen gemeinsam betrachten.
Wachstum
Nutzbare Kapazität inklusive Redundanz, Snapshots, Rebuild und Reserve planen.
Betrieb
Monitoring, Austausch, Updates, Rebalancing und Wiederherstellung beherrschen.
Lokaler Storage
ZFS verbindet Datenintegrität, Snapshots und flexible lokale Pools.
ZFS prüft Daten und Metadaten mit Checksummen, unterstützt Snapshots, Kompression und unterschiedliche Redundanzmodelle. Für einzelne Nodes oder klar abgegrenzte Clusterdesigns kann lokales ZFS eine leistungsfähige, transparente Basis sein. ARC-Nutzung, Datenträgertypen, Controller-Modus, Pool-Aufbau, Recordsize und freie Kapazität beeinflussen das Ergebnis wesentlich.
In einem Cluster ist lokales ZFS nicht automatisch gemeinsam verfügbar. Die Proxmox-Replikation überträgt VM-Datenträger zeitversetzt auf einen anderen Node. Damit kann ein definierter RPO erreicht werden, der letzte Stand zwischen zwei Replikationsläufen kann jedoch fehlen. Replikation ist außerdem kein Ersatz für eine unabhängige Sicherung, weil logische Fehler oder Löschvorgänge ebenfalls weitergegeben werden können.
Verteilter Storage
Ceph verteilt Daten und Verantwortung über mehrere Cluster-Nodes.
Ceph RBD stellt Proxmox-VMs verteilten Blockspeicher bereit. Daten werden entsprechend der gewählten Replikations- oder Erasure-Coding-Regeln über mehrere OSDs und Fehlerdomänen verteilt. Dadurch entfällt ein einzelnes zentrales Storage-Array als alleiniger Verfügbarkeitsbereich. Compute und Storage können hyperkonvergent auf denselben Nodes oder bewusst getrennt betrieben werden.
Diese Flexibilität benötigt ausreichend Nodes, geeignete Enterprise-Datenträger, schnelle Netzwerke, Kapazitätsreserven und einen kontrollierten Betrieb. Bei einem Disk- oder Node-Ausfall rekonstruiert Ceph Daten, wodurch zusätzliche Netzwerk- und I/O-Last entsteht. Eine Plattform, die im Normalbetrieb bereits an Kapazitäts- oder Leistungsgrenzen arbeitet, besitzt für Rebalancing und Recovery zu wenig Reserve.
AOIT plant Public-, Cluster- und Storage-Netze, Failure Domains, Replikationsfaktor, OSD-Zuschnitt und Wartungsabläufe gemeinsam. Gesundheitszustand, langsame Operationen, Belegung, Recovery-Fortschritt und Datenträgerwerte werden laufend überwacht. So bleibt Ceph eine beherrschbare Plattform und wird nicht zur undurchsichtigen Blackbox.
Lifecycle & Migration
Storage muss im Fehlerfall, bei Wartung und beim Wachstum funktionieren.
Vor der Produktivsetzung werden Leistung und Verhalten nicht nur im Normalzustand geprüft. Disk-Ausfall, Node-Wartung, Pfadverlust, Rebuild, fast volle Pools und der gleichzeitige Backup-Verkehr gehören zu einer realistischen Abnahme. Alarmgrenzen werden so gesetzt, dass noch Zeit für kontrollierte Maßnahmen bleibt.
Bei Migrationen werden Datenmenge, verfügbare Bandbreite, Änderungsrate und geplante Downtime berücksichtigt. Große Datenträger lassen sich nicht beliebig schnell übertragen. Vorabkopien, gestaffelte Wellen und ein getesteter Rückfallweg reduzieren das Risiko. Nach der Migration werden Gastleistung, Storage-Latenz, Backup und Wiederherstellung erneut kontrolliert.
Häufige Fragen
Antworten zur Planung und zum Betrieb.
Ist Ceph für jeden Proxmox-Cluster die beste Wahl?
Nein. Ceph ist leistungsfähig und verteilt, benötigt aber genügend Nodes, geeignete Hardware, schnelle Netze, Reservekapazität und Betriebswissen. Für kleinere Umgebungen können ZFS-Replikation oder ein vorhandenes redundantes SAN/NAS besser passen.
Kann ZFS-Replikation Shared Storage ersetzen?
Nicht vollständig. Replikation überträgt Daten zeitversetzt und besitzt daher einen definierten RPO. Der Failover unterscheidet sich von gemeinsam erreichbarem Storage. Ob das ausreichend ist, hängt von Anwendung und Wiederanlaufziel ab.
Wie viel freie Kapazität sollte eingeplant werden?
Die Reserve hängt von Technologie, Redundanz und Wachstum ab. Sie muss Snapshots, temporäre Migrationen, Rebuild beziehungsweise Rebalancing und Lastspitzen berücksichtigen. Eine dauerhaft fast volle Plattform ist weder leistungsstabil noch sicher wartbar.
Ersetzen Storage-Snapshots ein Backup?
Nein. Snapshots können schnelle Rücksprünge ermöglichen, liegen aber häufig in derselben administrativen und technischen Fehlerdomäne. Ein Backup benötigt unabhängige Aufbewahrung, Schutz vor Veränderung und geprüfte Wiederherstellung.
Technische Quellen
Die konkrete Architektur wird anhand Ihrer Workloads, Schutzanforderungen und vorhandenen Infrastruktur geplant. Diese Primärquellen dienen als technische Orientierung.
Nächster Schritt
Proxmox-Architektur mit klaren Betriebszielen planen.
Wir ordnen Ausgangslage, Risiken, Zielarchitektur und Migrationsweg ein – nachvollziehbar und passend zu Ihrem Unternehmen.