Ceph, HA und der minimal tragfähige Cluster für KMU

Wenn Sie als kleines oder mittleres Unternehmen mit Hochverfügbarkeit (HA) über Proxmox und Ceph liebäugeln, stellt sich früh die naheliegende Frage: Was ist der kleinste Cluster-Aufbau, der tatsächlich sinnvoll ist? Reichen zwei Nodes und ein übrig gebliebener Raspberry Pi, der ein Quorum-Device mimt, oder ist das nur ein Absturz auf Abruf?

Diese Frage entfachte eine hitzige Diskussion unter Infrastruktur-Enthusiasten, und die Antworten hatten deutlich mehr Nuancen, als man erwarten würde. Mit „Minimum" meinten die meisten dort „das Kleinste, bei dem Sie ruhig schlafen können", und das liegt über dem, was technisch gerade noch funktioniert.

Die HA-Illusion des 2-Node-Clusters

Auf dem Papier lässt sich ein Proxmox-HA-Cluster mit nur zwei Nodes und einem QDevice für das Quorum aufsetzen, und technisch ist das machbar. Viele Nutzer tun das, vor allem in Labs oder sehr kleinen Deployments, und manche betreiben so sogar Produktions-VMs. Trotzdem werden viele in der Community nervös, wenn „2-Node-HA-Cluster" und „Produktion" im selben Satz auftauchen.

Ein Nutzer brachte es unverblümt auf den Punkt: „3 ist das absolute Minimum, aber einen Produktions-Workload würde ich niemals auf nur 3 laufen lassen."

Ein 2-Node-Cluster mit QDevice ist von Natur aus zerbrechlich. Mit der zusätzlichen Stimme wird Split-Brain zwar vermieden, aber Sie fahren trotzdem auf Messers Schneide. Fällt ein Node aus, sind Sie sofort bei voller Kapazität und kämpfen womöglich mit der Last. Das QDevice ist oft etwas Wackliges wie ein NAS, eine VM oder ein Pi. Es leistet selbst keine Schwerstarbeit, aber fällt es aus, haben Sie ein Quorum-Problem.

In der Praxis soll Ihr HA-Setup einen Ausfall ohne Drama überstehen.

Was Ceph zum Atmen braucht

Wenn Sie Ceph als Storage in einem Proxmox-Cluster einsetzen wollen, wird es schnell anspruchsvoller. Ceph ist robust, skalierbar und performt gut unter Druck, mag es aber nicht, eingeengt zu werden.

Der Konsens lautet: Sie brauchen mindestens vier echte Ceph-Nodes, um es sicher zu betreiben, und die meisten empfehlen fünf, damit man sich wirklich sicher fühlt. Die Reserve soll verhindern, dass Replikation, Performance und Haltbarkeit leiden, wenn es mal chaotisch wird.

Ein erfahrener Admin erklärte es so: „Vier echte Ceph-Nodes und eine Proxmox-VM für die Quorum-Stimme, und ein wirklich starkes Netzwerk-Backbone, kein Scherz, sowas wie 40Gbit/100Gbit."

Der letzte Teil ist nicht optional. Ein Ceph-Cluster auf einem 10-Gbit-Netzwerk ist machbar, aber Sie deckeln damit die Performance. Mindestens brauchen Sie eine sauber durchdachte 10G-Infrastruktur oder den cleveren Einsatz von DACs und direkt verbundenen NICs, um Switch-Kosten und Latenz zu senken. Selbst das wird heikel, je mehr Nodes dazukommen.

Warum 3 Nodes der Sweet Spot der Community sind (mit Einschränkungen)

Fragen Sie zehn Leute in einem Proxmox-Forum nach der minimalen Clustergröße, und die häufigste Antwort lautet: „Drei echte Nodes."

Ab drei wird das Quorum stabil, ohne auf externe Hilfsmittel angewiesen zu sein. Außerdem haben Sie eine Reservemaschine für Updates, Tests oder Failover, ohne bei jedem Neustart in Panik zu geraten. Ceph lässt sich damit auf Minimalniveau betreiben, auch wenn Sie bei der Redundanz weiterhin auf der Kippe stehen.

Ein Nutzer berichtete, dass er einen vierten Node ohne Quorum-Stimme ausschließlich zum Kompilieren von Binaries und Testen von Patches nutzt, damit er den Cluster nicht riskiert. So vorsichtig gehen reale Deployments vor, selbst im kleinen Maßstab.

QDevices können in 2-Node-Szenarien helfen. Mehrere Nutzer argumentierten aber, dass die Verwaltung von zwei vollständigen Proxmox-Nodes plus einem QDevice (auf einem Backup-Server, Pi oder eingebetteten Switch-Container) komplexer ist, als einfach einen dritten Node hinzuzufügen.

Ein anderer Beitragender formulierte es so: „Zwei plus QDevice zu administrieren ist schwerer, als einfach drei Nodes zu haben."

Storage-Frage: Ceph oder Alternativen für KMU

Ceph ist nicht die einzige Option, besonders wenn Sie leichtgewichtige VM-Workloads fahren. Manche Admins empfehlen ZFS-Replikation über Nodes hinweg für HA, ganz ohne gemeinsamen Block-Storage. Andere setzen auf iSCSI-SANs oder sogar neuere Technik wie LINSTOR/DRBD oder SeaweedFS, auch wenn die ihre eigenen Macken und Integrations-Kopfschmerzen mitbringen.

Ceph lockt mit der tiefen Integration in Proxmox und guter Skalierbarkeit, dafür zahlen Sie mit Komplexität und Hardware-Anforderungen.

Ein Nutzer beschrieb, wie er auf Ceph komplett verzichtet und stattdessen mit nur zwei Nodes auf ZFS-Replikation setzt: „Wir betreiben bei der Arbeit einen 2-Node-HA-Cluster mit ZFS-Replikation über die two_node-Option von Corosync, und das funktioniert einwandfrei."

Spektakulär ist das nicht, aber für KMU, die keinen hyperresilienten Objektspeicher brauchen und nicht Hunderte VMs am Laufen haben, reicht es.

Ist das Produktion oder nur ein Lab in Verkleidung?

Im Thread tauchte immer wieder die Frage auf, was eigentlich als Produktion zählt.

Ein Nutzer hatte die beste Antwort: „Produktion wird durch die Workloads definiert und wie man mit ihnen umgeht, nicht durch die Größe."

Wenn Sie einen geschäftskritischen Dienst betreiben, ob eine 911-Notrufzentrale oder das zentrale ERP Ihres Unternehmens, und der läuft auf einem 2-Node-Cluster mit wackligem Shared Storage, dann ist das Produktion. Dieses Setup ist womöglich nur einen Ausrutscher von einem langen, schmerzhaften Tag entfernt.

Wenn Sie es Produktion nennen, behandeln Sie es also auch wie Produktion. Dazu gehören Redundanz, Tests, Monitoring, Backups und vielleicht Geld für den dritten oder vierten Node statt cleverer Tricks mit QDevices und Grenzfällen.

Fazit: Klein bauen, aber klug

Wenn Sie als KMU Proxmox HA und Ceph mit begrenztem Budget umsetzen wollen, gibt es zwei Wege.

Sie können schlank, aber solide starten: drei Proxmox-Nodes mit genug Leistung, um VM-Failover zu bewältigen, kombiniert mit ZFS-Replikation und guten Backups. Ceph kommt erst dazu, wenn Sie verteilten Storage brauchen.

Oder Sie nehmen das volle Programm mit vier oder fünf Nodes, einem sauberen Ceph-Setup, schnellem Networking und einem sauberen HA-Setup mit echtem Quorum. Das ist teuer, aber zukunftssicher.

Wer Hochverfügbarkeit in ein 2-Node-Setup zwingt, will oft neben dem Geld auch anfängliche Komplexität sparen. Wenn dieses „einfachere" Setup Ihnen aber das Leben schwerer macht, sobald etwas ausfällt, ist es dann wirklich einfacher?

Der kleinste Cluster, der sich „lohnt", ist der kleinste, bei dem Sie nachts noch schlafen können, und in den meisten realen Fällen beginnt das bei drei.