„ZFS oder Ceph?“ ist eine naheliegende Frage, wenn ein Proxmox-Cluster geplant wird. Mich interessiert zuerst, was der Cluster auffangen soll. Den Ausfall einer VM? Eines kompletten Hosts? Oder auch den Verlust eines Storage-Systems?
Ohne diese Anforderungen lässt sich die Speicherfrage kaum sinnvoll beantworten. Hinzu kommen Datenmenge, Netzwerk, Budget und die Zeit, die für den Betrieb zur Verfügung steht.
Welche Ausfälle müssen abgefangen werden?
Mehrere Hosts allein sagen noch wenig darüber aus, wie lange ein Dienst nach einem Ausfall weg ist. Die VMs brauchen erreichbare Daten, das Netzwerk muss funktionieren und die verbleibenden Systeme müssen die zusätzliche Arbeit übernehmen können.
Für die Planung interessieren mich deshalb vor allem diese Fragen:
- Wie lange darf der jeweilige Dienst ausfallen?
- Welcher Datenverlust wäre noch vertretbar?
- Reichen die verbleibenden Ressourcen, wenn ein Host fehlt?
- Wo liegt das Backup, und wurde die Wiederherstellung getestet?
- Wer kümmert sich um eine Störung, wenn sie außerhalb der üblichen Arbeitszeit auftritt?
Ein System, das kurze Ausfälle verkraftet, lässt sich anders planen als eines, dessen Daten möglichst ohne Unterbrechung verfügbar sein müssen. Das sollte vor der Bestellung der Hardware feststehen.
Lokales ZFS und Replikation
ZFS bringt Prüfsummen und Snapshots mit und eignet sich gut für lokale Speicherpools. Mit der Storage-Replikation von Proxmox lassen sich unterstützte VM-Daten auf einen weiteren Host übertragen. Für kleinere Installationen kann das ein gut überschaubarer Aufbau sein.
Dabei muss klar sein, dass die Replikation zeitversetzt arbeitet. Fällt der ursprüngliche Host aus, kann auf dem Ziel der Stand der letzten erfolgreichen Replikation vorliegen. Was seitdem geschrieben wurde, fehlt dort möglicherweise. Ob das akzeptabel ist, hängt vom Dienst und seinen Daten ab.
Diese Abwägung gehört ins Planungsgespräch. Gerade bei Datenbanken kann ein kurzer Zeitraum bereits viele Änderungen enthalten.
Was beim Betrieb von Ceph dazukommt
Ceph verteilt Daten über mehrere Systeme. Das eröffnet Möglichkeiten für gemeinsamen Storage und den Umgang mit Ausfällen. Es stellt aber auch Anforderungen an Netzwerk, Datenträger, Kapazitätsreserven und Überwachung.
Mich interessiert dabei besonders, wie sich der Cluster während einer Störung verhält. Wenn ein Datenträger ausfällt oder Daten neu verteilt werden, entsteht zusätzliche Last. Die übrigen Systeme müssen dann weiterhin die VMs bedienen können.
Für die Dimensionierung zählen deshalb auch Wartung und Wiederaufbau. Ein knappes Budget verschwindet nicht dadurch, dass die Software kostenlos verfügbar ist.
Wer betreut den Cluster?
Ein kleiner Betrieb mit wenig Zeit für Administration hat andere Voraussetzungen als ein Team, das täglich mit verteilter Infrastruktur arbeitet. Es muss klar sein, wer Fehlermeldungen einordnet, Updates plant und im Zweifel die richtigen Schritte zur Wiederherstellung kennt.
Für manche Umgebungen passt lokales ZFS mit geplanter Replikation gut. Andere brauchen die Eigenschaften eines verteilten Storage-Systems und können den Aufwand für Ceph tragen. Eine pauschale Empfehlung würde ich daraus nicht machen.
Der Restore gehört zur Planung
Replikation hilft nicht, wenn eine versehentlich gelöschte Datei bereits auf dem zweiten System ebenfalls fehlt. Auch Ceph ersetzt keine getrennte Sicherung.
Ein Backup-Konzept, etwa mit Proxmox Backup Server, braucht deshalb einen eigenen Platz in der Planung. Dazu gehören Aufbewahrung und getestete Restores. Ich möchte vor einem Ausfall wissen, wie die Daten zurückkommen und wie lange das ungefähr dauert.
Wie die zeitversetzte Replikation arbeitet, beschreibt die Proxmox-Dokumentation zur Storage-Replikation.