Zwei Server, die nur mitzählen sollten
Bei einer Bestandsaufnahme vor Kurzem zählten wir die Proxmox-Hosts durch. Mehrere große Hosts trugen die Last, gut ausgestattet, kaum ausgelastet. Daneben standen zwei weitere. Was läuft darauf?
Nichts. Die beiden waren nur fürs Quorum vorgesehen. Sie sollten im Cluster mitzählen, damit bei einem Ausfall eine Mehrheit übrig bleibt. Trotzdem hatte jeder von ihnen über 100 GB Arbeitsspeicher, dazu Strom, Wartung und Subscriptions wie jeder andere Host.
Wofür ein Quorum da ist
Ein Proxmox-Cluster entscheidet per Mehrheit, welche Knoten weiterarbeiten dürfen. Verlieren sich zwei Hälften aus den Augen, darf nur die Seite mit der Mehrheit der Stimmen weitermachen. Sonst würden beide Seiten dieselben VMs starten, und das will niemand.
Bei einer geraden Zahl von Knoten kann es unentschieden ausgehen. Zwei Räume mit gleich vielen Hosts, die Leitung dazwischen bricht: Keine Seite hat die Mehrheit. Dafür braucht man eine zusätzliche Stimme. Das ist der Gedanke hinter den beiden Quorum-Hosts.
Dabei steckt im Aufbau schon ein Haken: Steht von zwei Quorum-Hosts je einer in jedem Raum, hat jede Seite wieder gleich viele Stimmen. Genau den Fall, für den sie gedacht sind, entscheiden sie dann nicht.
Die Stimme muss kein Server sein
Proxmox hat dafür ein eigenes Werkzeug: das QDevice
. Auf jedem Knoten läuft ein kleiner Dienst, und auf einem externen System läuft corosync-qnetd. Dieses externe System gibt seine Stimme immer nur einer Seite. Als Anforderung nennt Proxmox nur Netzwerkzugang zum Cluster und das Paket corosync-qnetd. Eine kleine VM oder ein kleiner Rechner reicht.
Es muss nicht einmal im selben Netz stehen. Das QDevice spricht TCP/IP und hat nicht die strengen Latenzanforderungen von Corosync selbst. Am besten steht es deshalb außerhalb der beiden Räume, an einem dritten Ort. Dann kann es bei einer Trennung zwischen den Räumen tatsächlich entscheiden.
Eine Einschränkung nennt Proxmox ausdrücklich: Unterstützt wird das QDevice für Cluster mit einer geraden Zahl von Knoten. Bei ungerader Zahl rät Proxmox derzeit davon ab, weil das QDevice dann fast zum Single Point of Failure wird. Bei gerader Zahl gibt es laut Doku keine Nachteile: Fällt das QDevice aus, ist man so weit wie ohne.
Warum es hier passt
Die Hosts mit Last waren eine gerade Zahl, je Raum gleich viele. Ceph war nicht im Einsatz, die VMs lagen auf einem SAN. Mit Ceph wäre die Rechnung eine andere, denn dann halten die Hosts selbst die Daten und Ceph braucht eigene Mehrheiten. Ohne Ceph braucht der Cluster für die Entscheidung nur eine Stimme von außen, keine zusätzliche Hardware mit viel Speicher.
Und dann kam die eigentliche Pointe: Einen Cluster gab es gar nicht. Corosync war angefangen, nie fertig. Jeder Host lief für sich. Die beiden Quorum-Hosts zählten also bei nichts mit.
Was wir vorgeschlagen haben
- Zuerst entscheiden, ob es einen Cluster geben soll. Ohne diese Entscheidung ist jede Quorum-Frage theoretisch.
- Wenn ja: QDevice statt zwei Hosts. Eine kleine VM oder ein kleiner Rechner an einem dritten Standort, mit
corosync-qnetd. Die Knotenzahl gerade halten. - Die beiden Hosts freiziehen. Sie sind gute Hardware. Als Ziel für die Datensicherung oder als eigene Firewall-Hardware sind sie besser aufgehoben als beim Mitzählen.
- Subscriptions und Wartung anpassen. Was nicht mehr als Proxmox-Host läuft, braucht keine Proxmox-Subscription.
Zwei Server mit über 100 GB RAM, um eine Stimme abzugeben, die ein kleines System genauso gut abgibt. Die Frage, die vorher niemand gestellt hatte, war einfach: Was soll diese Stimme eigentlich entscheiden, und von wo aus?