Storage & Filesystem

Storage-Optionen im Überblick

Diese vier Optionen decken die allermeisten Proxmox-Installationen ab. Für den Anfang gilt: ZFS ist die im Ökosystem am besten integrierte Wahl (Snapshots, Replikation und Backup-Verifizierung greifen direkt ineinander) – LVM-thin und ext4 sind eher Optionen für sehr einfache Setups oder wenn ein vorhandener Hardware-RAID-Verbund weiterverwendet werden muss.

RAID-Level im Vergleich

ZFS im Detail

• Mirror: einfache Spiegelung (entspricht RAID 1), schnell wiederhergestellt, weniger Nutzkapazität
• RAID-Z: parity-basiert (entspricht RAID 5), mehr Nutzkapazität, längerer Resilver bei Plattenausfall; RAID-Z2 verkraftet wie RAID 6 zwei gleichzeitige Ausfälle
• ARC: RAM-Cache für Lesezugriffe – ZFS ist speicherhungrig, das ist gewollt, denn jeder RAM-Cache-Treffer erspart einen langsamen Plattenzugriff
• SLOG: schnelles Log-Device (z. B. NVMe) beschleunigt synchrone Schreibzugriffe (z. B. Datenbanken) – ohne SLOG landet dieses Log auf dem regulären, langsameren Pool
• Special Device: lagert Metadaten und optional kleine Dateien auf schnellem Storage aus, beschleunigt Verzeichnis-Operationen und viele kleine Dateien spürbar

Hohe I/O-Anforderungen (z. B. Datenbanken)

• NVMe statt SATA/SAS-SSD für die VM-Disk einplanen, wenn die Anwendung latenzempfindlich ist – die geringere Zugriffszeit wirkt sich bei vielen kleinen IOPS deutlich stärker aus als bei sequenziellem Durchsatz
• Cache-Modus der VM-Disk auf none stellen (Proxmox-Standard) – vermeidet doppeltes Caching zwischen Host und Gast, das bei Datenbanken eher zu Inkonsistenzrisiken als zu Performance-Gewinn führt
• Als Async-IO-Modus io_uring nutzen (moderner Standard) statt threads – geringerer CPU-Overhead pro I/O-Operation bei hoher Parallelität
• SLOG-Device (siehe ZFS im Detail) lohnt sich hier besonders: es beschleunigt genau die synchronen Schreibzugriffe, auf die Datenbank-Commits warten
• Bei sehr hohen Ansprüchen: eigenen Storage-Pool nur für I/O-intensive VMs reservieren, damit ein „lauter Nachbar" (z. B. ein Backup-Job) nicht die Datenbank-Latenz verschlechtert

Fallstrick: RAID-Controller

• Controller in den HBA- bzw. IT-Modus versetzen (Firmware-Flash nötig, falls der Controller werkseitig nur RAID-Modus anbietet, z. B. bei vielen Dell-PERC- oder HP-Smart-Array-Controllern)
• Hardware-RAID verschleiert den Plattenzustand vor ZFS/Ceph – Checksumming und Selbstheilung greifen dann nicht mehr richtig, weil ZFS die einzelnen physischen Platten gar nicht mehr sieht, sondern nur noch das vom Controller zusammengefasste virtuelle Laufwerk
• Erkennungsmerkmal im Zweifel: lsblk oder smartctl sollten die einzelnen physischen Platten einzeln auflisten – erscheint stattdessen nur ein einziges großes „virtuelles" Laufwerk, steckt wahrscheinlich noch Hardware-RAID dazwischen
• Wer zwingend mit vorhandenem Hardware-RAID-Controller leben muss, sollte auf ZFS/Ceph verzichten und stattdessen ext4 oder LVM-thin auf dem vom Controller bereitgestellten Verbund nutzen

Local vs. Shared Storage

Der praktische Unterschied zeigt sich bei der Live-Migration: Bei lokalem Storage muss die komplette VM-Disk zum Ziel-Node kopiert werden (dauert je nach Größe und Netzwerk spürbar), bei Shared Storage sieht der Ziel-Node dieselben Daten bereits – nur Arbeitsspeicher und CPU-Zustand wandern, die Migration ist entsprechend schneller und unterbrechungsärmer.

Entscheidungsvergleich

Die drei Wege unterscheiden sich vor allem im Verhältnis von Aufwand zu Ausfallsicherheit: lokales ZFS mit Replikation ist am schnellsten aufgesetzt, akzeptiert dafür ein kleines RPO im Failover-Fall (siehe Modul 9); Ceph braucht mehr Planung und mindestens drei Nodes, liefert dafür echtes Shared Storage ohne Datenverlust bei einem Node-Ausfall; ein bestehendes SAN nutzt vorhandene Investitionen, bringt aber einen zusätzlichen Single-Point-of-Failure außerhalb des Proxmox-Clusters mit, sofern das SAN selbst nicht redundant ausgelegt ist.

HCI: vSAN-Ersatz mit Ceph

• Voraussetzungen: mindestens 3 Nodes, dediziertes 10GbE+ (oder schnelleres) Storage-Netz, Platten am HBA/IT-Mode statt Hardware-RAID, SSD/NVMe empfohlen
• Abgrenzung zu ZFS-Replikation: kein echtes Shared Storage, da nur periodisch repliziert wird – dadurch RPO größer 0 statt RPO 0 wie bei Ceph
• Abgrenzung zu Linstor/DRBD: Block-Replikation zwischen Nodes, ein anderer technischer Ansatz als der verteilte Ceph-Storage
• Klarstellung: VMware vSAN selbst läuft nicht unter Proxmox – wohl aber das dahinterliegende HCI-Prinzip (hyperkonvergente, verteilte Storage-Architektur), das Ceph umsetzt

Empfehlung nach Node-Anzahl & Budget

• 1–2 Nodes, kleines Budget: lokales ZFS mit Replikation – pragmatisch, ausreichend für die meisten KMU, RPO im Minutenbereich ist meist akzeptabel
• 3+ Nodes, Wachstum absehbar: Ceph – mehr Aufwand beim Aufbau (eigenes Storage-Netz empfohlen), dafür sauberes Shared Storage und Kapazität, die sich durch weitere Nodes einfach erweitern lässt
• Bereits vorhandenes SAN im Haus: anbinden statt neu investieren, sofern Performance und Redundanz passen – SAN-Anbindung meist per iSCSI oder NFS, abhängig vom Hersteller
• Faustregel für den Einstieg: erst mit lokalem ZFS produktiv gehen und Erfahrung sammeln, Ceph erst einführen, wenn die Node-Anzahl und der Bedarf an echtem Shared Storage tatsächlich da sind – ein vorschneller Ceph-Aufbau mit zu wenig Nodes oder zu langsamem Netz enttäuscht häufiger, als er hilft
• Für das KMU-Referenz-Szenario dieses Lernbereichs (1–2 Nodes, 4–6 VMs, siehe Modul 0) ist damit die Antwort meist eindeutig: lokales ZFS mit Replikation, nicht Ceph – die Datenmenge und Node-Anzahl rechtfertigen den zusätzlichen Aufwand in aller Regel noch nicht

Snapshots & das Wichtigste

• ZFS und Ceph: Snapshots + eingebaute Redundanz/Selbstheilung – ein Snapshot ist in Sekunden erstellt und kostet zunächst keinen zusätzlichen Speicherplatz (nur die seither geänderten Blöcke wachsen)
• RAID-Controller weg – ZFS/Ceph brauchen direkten Plattenzugriff über HBA/IT-Mode, sonst funktionieren Checksumming und Selbstheilung nicht wie vorgesehen
• Bei hohen I/O-Anforderungen (Datenbanken) zusätzlich NVMe, cache=none und ggf. ein SLOG-Device einplanen
• Storage-Wahl richtet sich nach Node-Anzahl, Budget und HA-Anspruch, nicht nach Gewohnheit – was beim bisherigen ESXi/Hyper-V-Setup funktioniert hat, ist nicht automatisch die richtige Wahl für Proxmox
• Snapshot-Fähigkeit hängt am Storage-Typ: qcow2, ZFS und Ceph unterstützen native Snapshots von VM-Disks, LVM-thick ausdrücklich nicht (LVM-thin dagegen schon)
• Anders als bei VMware: Proxmox-Snapshots sind kein einheitliches Hypervisor-Format, sondern hängen vom gewählten Storage-Backend ab (z. B. ZFS-COW-Blocksnapshot oder Ceph-RBD-Snapshot statt VMFS-Delta-Datei)