Proxmox-Storage: ZFS vs. Ceph vs. LVM Thin vs. RAID

Bei den meisten Proxmox-Systemen mit einem einzelnen Node würde ich mich für ZFS entscheiden, wenn ich lokale Redundanz und Snapshots möchte, oder für LVM Thin, wenn ich einfachen lokalen Block-Storage möchte. Für einen Multi-Node-Cluster, der verteilten Shared Storage benötigt, ist Ceph die naheliegendere Wahl. Hardware-RAID hat weiterhin seinen Platz, gehört aber unter Storage-Stacks, die für den Einsatz eines RAID-Controllers ausgelegt sind, nicht unter ZFS oder Ceph.

Die wichtige Klarstellung ist: ZFS, Ceph, LVM Thin und RAID sind keine vier austauschbaren Produkte. Sie lösen unterschiedliche Ebenen des Storage-Problems. RAID kombiniert Disks für Redundanz oder Performance. ZFS ist ein Dateisystem und Volume-Manager. LVM Thin ist lokaler, thin-provisionierter Block-Storage. Ceph ist ein verteiltes Storage-System.

Welchen Storage unterstützt Proxmox VE 9?

Proxmox VE 9 unterstützt lokale und Shared-Storage-Backends über eine gemeinsame Storage-Schicht. VM-Disks und Container-Volumes können auf lokalem LVM, LVM Thin, ZFS, Directory-Storage, NFS, iSCSI, Ceph RBD und anderen unterstützten Backends liegen.

Diese Flexibilität ist nützlich, macht aber auch schlechte Kombinationen leicht möglich.

Sie sollten Storage zuerst nach dem Ausfallmodell wählen. Fragen Sie sich, ob ein Host ausfallen kann, ob eine Disk ausfallen kann, ob VMs Live-Migration brauchen, wie viele aktuelle Daten verloren gehen dürfen und wie viel operative Komplexität das Team stemmen kann.

Wenn Sie HA planen, ist Proxmox-HA-Storage: Ceph vs. ZFS-Replikation vs. NAS-Failover im Vergleich eine nützliche Ergänzung zu diesem Guide.

Wann sollten Sie ZFS für Proxmox wählen?

ZFS ist die beste Allzweck-Wahl, wenn ein einzelner Proxmox-Host die Disks besitzt und Sie softwaregesteuerte Redundanz, Checksumming, Snapshots, Kompression und effiziente Clones möchten.

Proxmox integriert ZFS direkt. VM-Disks werden als ZFS-Volumes gespeichert, während Container ZFS-Datasets nutzen können. Proxmox unterstützt außerdem ZFS-Replikation zwischen Nodes.

Ein Zwei-Disk-Mirror ist ein verbreitetes Design für kleine Server, da jede der beiden Disks ausfallen kann, ohne den Pool zu verlieren. Größere Systeme können je nach Kapazitäts- und Performance-Anforderungen RAIDZ-Layouts oder mehrere Mirror-Vdevs nutzen.

ZFS ist besonders attraktiv, wenn der Hypervisor den lokalen Storage verstehen soll, statt alle Disks hinter einem RAID-Controller zu verstecken.

Der Preis dafür sind Arbeitsspeicher und operative Disziplin. ZFS nutzt RAM zum Caching, und Entscheidungen zum Pool-Design sollten Sie nicht einfach nebenbei treffen, nachdem der Server schon voll ist.

Die tiefere Community-Debatte dazu behandelt Ceph ist ein Biest, ZFS funktioniert einfach.

Sollten Sie ZFS auf einem Hardware-RAID-Controller betreiben?

Nein. Proxmox rät ausdrücklich davon ab, ZFS auf einem Hardware-RAID-Controller zu betreiben, der seinen eigenen Cache verwaltet, weil ZFS direkte Kommunikation mit den Disks benötigt.

Verwenden Sie einen HBA oder einen Controller-Modus, der die Disks direkt durchreicht.

Das ist eine der wichtigsten Storage-Regeln bei Proxmox, weil ein RAID-Controller das Laufwerksverhalten verbergen kann, das ZFS zu sehen erwartet. Außerdem stapeln Sie am Ende zwei verschiedene Systeme, die beide glauben, für Redundanz und Caching-Richtlinie zuständig zu sein.

Wenn Sie bereits einen Server mit einem guten, batteriegepufferten Hardware-RAID-Controller haben und ihn nicht ersetzen wollen, kann klassisches LVM oder ein Dateisystem auf dem logischen RAID-Volume das sauberere Design sein.

Wann ist LVM Thin besser als ZFS?

LVM Thin ist die bessere Wahl, wenn Sie unkomplizierten lokalen Block-Storage mit Thin Provisioning, Snapshots und Clones möchten und keine ZFS-Funktionen brauchen.

Proxmox nutzt LVM Thin nach einer Standardinstallation auf ext4- oder XFS-basierten Systemen üblicherweise als local-lvm. Das LVM-Thin-Backend unterstützt Snapshots und Linked Clones, ist aber lokaler statt Shared Storage.

Es ist einfach und schnell zu verstehen.

Das größte operative Risiko ist Overcommitment. Thin Provisioning erlaubt es virtuellen Disks, mehr logische Kapazität auszuweisen, als der Pool physisch belegt hat. Das ist nützlich, bis sich der Thin-Pool 100 Prozent nähert.

Ein voller Thin-Pool kann aus einem Kapazitätsproblem ein Verfügbarkeitsproblem für VMs machen. Überwachen Sie Daten- und Metadaten-Nutzung, und lassen Sie genug freien Platz für Wachstum.

Mr.PlanB hat einen eigenen Guide zu Proxmox-LVM-Thin-Storage-Bloat und Kapazitätsproblemen.

Wann sollten Sie Ceph für Proxmox wählen?

Ceph ergibt Sinn, wenn mehrere Proxmox-Nodes verteilten Shared Storage benötigen und der Storage Host- oder Disk-Ausfälle überstehen soll, ohne von einem einzelnen externen SAN oder NAS abhängig zu sein.

Proxmox integriert das Ceph-Management direkt in den Cluster. In einem hyperkonvergenten Design können dieselben Server Compute und Ceph-Storage bereitstellen.

Das ist mächtig, aber Ceph ist kein kostenloser HA-Knopf.

Proxmox empfiehlt mindestens 10 Gbit/s dedizierte Netzwerkbandbreite für Ceph-Traffic. Schnelle SSD- und NVMe-Cluster können deutlich mehr rechtfertigen. Außerdem brauchen Sie genug Nodes, Laufwerke und Failure Domains, damit Replikation sinnvoll ist.

Ceph erzeugt Hintergrund-Traffic für Replikation, Recovery, Rebalancing und Scrubbing. Ein Drei-Node-Cluster mit einem einzelnen langsamen Storage-Netzwerk kann sich in Ordnung anfühlen — bis eine Disk oder ein Node ausfällt, also genau dann, wenn Ceph mehr zu tun hat.

Ich wähle Ceph, wenn Shared Storage und Node-Unabhängigkeit diese Komplexität rechtfertigen.

Ist Ceph besser als ZFS für einen Drei-Node-Cluster?

Ceph ist besser, wenn der Cluster denselben VM-Storage auch nach einem Host-Ausfall von allen Nodes aus erreichbar halten muss. ZFS ist besser, wenn Einfachheit und lokale Performance wichtiger sind und Sie replikationsbasierte Recovery akzeptieren können.

Bei Ceph ist die VM-Disk bereits verteilt. HA kann die VM auf einem anderen Node neu starten, der denselben RBD-Storage sieht.

Bei lokaler ZFS-Replikation hat ein anderer Node eine replizierte Kopie, die nach einem Zeitplan erstellt wird. Der Recovery Point hängt von der letzten erfolgreichen Replikation ab, und die Kopien sind nicht dieselbe Shared Disk.

Das sind unterschiedliche Garantien.

Wählen Sie Ceph nicht, weil die GUI die Installation einfach aussehen lässt. Wählen Sie es, weil Ihre Recovery-Anforderungen verteilten Shared Storage brauchen.

Wo passt Hardware-RAID noch hin?

Hardware-RAID passt weiterhin zu Servern, bei denen ein dedizierter RAID-Controller Proxmox geschützte logische Volumes präsentiert und die Storage-Schicht darüber genau das erwartet.

Die Proxmox-Installationsanleitung besagt, dass lokaler Storage Hardware-RAID mit batteriegepuffertem Write-Cache nutzen kann, während ZFS und Ceph Disks ohne darunterliegendes Hardware-RAID nutzen sollten.

Das macht Hardware-RAID plus LVM zu einem vernünftigen klassischen Design auf manchen Enterprise-Servern.

Der Kompromiss ist Sichtbarkeit. Der RAID-Controller wird verantwortlich für Laufwerksgesundheit, Write-Cache-Schutz, Rebuild-Verhalten und Redundanz. Stellen Sie sicher, dass Ihr Monitoring den Controller-Status und ausgefallene Laufwerke sehen kann.

RAID ist außerdem kein Backup. Eine gelöschte oder verschlüsselte Datei zu spiegeln, gibt Ihnen einfach nur redundante Kopien desselben Problems.

Was ist der Unterschied zwischen RAID- und ZFS-Redundanz?

RAID schützt vor manchen Laufwerksausfällen. ZFS kann ebenfalls Disk-Redundanz bieten, kombiniert das aber mit Checksumming und Storage-Management.

Ein ZFS-Mirror ähnelt auf der Redundanz-Ebene RAID1, während RAIDZ-Layouts paritätsbasierten Schutz bieten. Implementierung und Datenintegritätsmodell unterscheiden sich.

Bei Proxmox ist die operative Frage, wer die Disks besitzt.

Wenn ZFS die Disks besitzt, überlassen Sie ZFS die Redundanz. Wenn ein Hardware-RAID-Controller die Disks besitzt, präsentieren Sie das resultierende logische Volume einer Storage-Schicht, die genau das erwartet.

Vermeiden Sie es, redundante Schichten aufzubauen, nur weil beide verfügbar sind.

Welcher Storage unterstützt Snapshots und Clones?

ZFS und LVM Thin unterstützen beide Proxmox-Snapshots und -Clones effizient. Auch Ceph RBD unterstützt über Proxmox snapshot-fähigen VM-Storage.

Klassisches LVM ist für diesen Anwendungsfall eingeschränkter als LVM Thin. Hardware-RAID allein liefert keine Proxmox-VM-Snapshots. Das Snapshot-Verhalten kommt vom Storage-Backend über oder neben der RAID-Schicht.

Deshalb beantwortet die Wahl von „RAID" nicht die Frage nach dem VM-Storage.

Sie müssen trotzdem entscheiden, was Proxmox oben auf dieses RAID-Volume legt.

Welcher Storage ist am besten für Live-Migration und HA?

Shared Storage ist das einfachste Modell für Live-Migration und HA, weil alle infrage kommenden Nodes auf dieselben VM-Disks zugreifen können. Ceph, NFS, iSCSI und Fibre Channel können diese Eigenschaft in unterschiedlichen Designs bieten.

Lokales ZFS und LVM Thin werden nicht dadurch zu Shared Storage, dass die Hosts geclustert sind.

Proxmox kann lokale Disks migrieren, indem es die Storage-Daten während der Migration verschiebt, und ZFS-Replikation kann Kopien auf anderen Nodes pflegen. Diese Funktionen sind nützlich, haben aber andere Zeit- und Recovery-Eigenschaften als Shared Storage.

Wenn HA eine harte Anforderung ist, sollte die Storage-Architektur entschieden werden, bevor Sie die VMs ausrollen.

Was würde ich für typische Proxmox-Setups wählen?

Für einen kleinen Server mit zwei SSDs würde ich normalerweise einen ZFS-Mirror wählen.

Für einen Server mit bereits vorhandenem, gutem Hardware-RAID-Controller würde ich RAID plus LVM Thin in Betracht ziehen, wenn der Austausch des Controllers keinen echten Vorteil bringt.

Für ein einfaches Lab, in dem ich schnelles Provisioning und Snapshots möchte und im Fall eines Host-Ausfalls aus dem Backup wiederherstellen kann, ist LVM Thin völlig vernünftig.

Für drei oder mehr Produktions-Nodes, die verteilten Shared Storage benötigen und dediziertes schnelles Networking stemmen können, würde ich Ceph evaluieren.

Ich würde Ceph nicht auf einem einzelnen Node installieren, nur weil es im Menü auftaucht. Ich würde ZFS nicht auf Hardware-RAID betreiben. Ich würde einen Pool nicht thin-provisionieren, ohne Kapazitäts-Alerts einzurichten.

Storage sollte das Ausfallverhalten klarer machen. Wenn das Design ein Diagramm und einen Absatz voller Vorbehalte braucht, nur um zu erklären, wo eine einzige VM-Disk liegt, vereinfachen Sie es, bevor Sie weitere Workloads hinzufügen.