Warum drei Nodes für HA bei geteiltem Storage?

[Stefan_Malte_Schumacher]

Hallo werte Proxmox-Gemeinde,

bei meinem vorherigen Arbeitgeber haben wir bereits 2 Proxmox-Cluster mit drei Nodes und via iSCSI geteiltem Storage aufgebaut. Den Satz "Man braucht mindestens drei Nodes für ein zuverlässiges Quorum" und ohne Quorum läuft der HA-Betrieb nicht habe ich quasi als Dogma akzeptiert und nicht weiter hinterfragt. Das sollte man eigentlich nicht tun. Es funktionierte ja, wir haben testweise eine Node via IPMI ausgeschaltet und die HA-VMs starteten zuverlässig auf den anderen Nodes. Unser jetziges Setup soll im Endeffekt genauso aussehen. (Ich habe meinen ISP zu meinem neuen Arbeitgeber "mitgenommen"). Nun helfe ich einem Kollegen die Dokumentation für den Kunden zu erstellen. Als ich ihm das erste Mal erklärt habe, daß man drei Nodes für einen Cluster braucht meinte er das wäre ja auch klar, man muss ja eine Mehrheit haben damit z.B. Datenbank-Nodes in Sync bleiben (wie z.B. beim MariaDB Gallera Cluster). Ich habe das dann auch so in die Dokumentation aufgenommen. Nun hat er mir aber noch eine Frage gestellt, die ich auch nach nochmalige Lektüre der Dokumentation und Tests mit dem HA-Simulator nicht beantworten kann: Wenn die VMs auf einem zentralen Storage liegen, wieso braucht man dann drei Nodes und nicht nur zwei? Ich habe in der älteren Doku sogar einen Zwei-Node-Failover-Cluster-Lösung für ältere Proxmox-Versionen gefunden. Nun zum Beispiel: VM2 liegt auf Node2. Node2 wird abgeschaltet - Strom aus. Nun wird es spekulativ: 1 (Node 1, aktiv) ist mehr als 0 (Node 2, nicht aktiv). Ist damit nicht schon ein Quorum erreicht oder zählen auch die nicht-aktiven Nodes zum Quorum hinzu und geben automatisch die Gegenstimme zu den laufenden Nodes ab, womit 1:1 statt 1:0 erreicht wären? Des Weiteren stellt sich uns die Frage: Es schreibt ja in einem solchen Fall niemand anderes auf die Shared VM. Kann man damit nicht einen temporären Notbetrieb aufrechterhalten bis eventuelle Hardware-Schäden in Node 2 beseitigt sind und das Quorum wiederhergestellt wäre?

Viele Grüße
Stefan

 

[sterzy]

Was ist, aber wenn beide Nodes aktiv sind, sich aber nicht sehen können (Netzwerkprobleme o.ä.)? Wenn dann beide davon ausgehen, dass die andere nicht mehr aktiv ist, kommt es zu einem inkonsistent Cluster-Zustand. Daher werden 50%+1 gebraucht um eine Entscheidung zu treffen. Da 1 halt weniger als 50%+1 von 2 ist, ist ein solches Setup nicht empfohlen. Es ist aber möglich ein QDevice einzurichten um nicht mindestens drei volle Nodes betreiben zu müssen und trotzdem ein stabiles Quorum zu erreichen [1].

[1]: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_corosync_external_vote_support

 

[Falk R.]

Für meinen 2 Node Cluster zuhause habe ich einen Pimox (Raspberry Pi mit PVE) als quorum laufen. Der macht nix anderes als Quorum zu spielen für die beiden aktiven Nodes. Er ist auch Ceph monitor, ebenfalls als Entscheider. Das funktioniert super, aber für produktiv würde ich lieber einen kleinen Server oder wenigstens einen NUC als Quorum nehmen.

 

[itNGO]

Bei sonnen anderen Laden da in Redmond gibt es da seit einigen Versionen den sogenannten Cloud-Zeugen oder die File-Share-Witness. Da kann man dann auch zuverlässig 2 Node-Cluster mit betreiben. Aber auch nur wenn der "Zeuge" überwiegend verfügbar ist.

Das Prinzip verfolgt man bei Proxmox mit einem Pi oder einem sehr schlanken Server/PC der nur die "Stimm-Berechtigung" um eine weitere Stimme ergänzt. Bei allen Majority-Node-Clustern gilt immer, ungerade ist die stabilste Variante.

Bei einem Shared-Storage wäre natürlich auch ein Disk-Quorum denkbar, das unterstützt Proxmox aber dis dato nicht....

 

[Admina]

Hallo zusammen, gerne hänge ich mich mit einer Frage ein:

Ist es möglich auch zwei Quorum Server in einem Ubuntu als LXC laufen zu lassen mit den Diensten (corosync-qnetd und corosync-qdevice).
Der erste ist auf dem Master Host als LXC mit einer Verbindung in das HA Netz, der andere läuft auf dem zweiten Hardware Node auch als LXC.

So besteht das HW Setup aus zwei pysikalischen PVE Nodes mit jeweis einem Quorum Dienst im LXC Container.

Danke

 

[Falk R.]

Hallo zusammen, gerne hänge ich mich mit einer Frage ein:

Ist es möglich auch zwei Quorum Server in einem Ubuntu als LXC laufen zu lassen mit den Diensten (corosync-qnetd und corosync-qdevice).
Der erste ist auf dem Master Host als LXC mit einer Verbindung in das HA Netz, der andere läuft auf dem zweiten Hardware Node auch als LXC.

So besteht das HW Setup aus zwei pysikalischen PVE Nodes mit jeweis einem Quorum Dienst im LXC Container.

Danke

Das macht mal gar keinen Sinn.
Der Sinn ist ganz simpel, du brauchst bei jedem Cluster (auch Windows) ein Quorum/Wittness/Entscheider der sagt welche Knoten noch aktiv bleiben dürfen, wenn die Knoten sich nicht mehr sehen. Man will einen Split Brain mit möglichem Datenschrott verhindern.

Also immer N+1. Als kleinstes Setup 3 und dann 5, 7,etc. Im Fall des 5 Knoten Setup, fallen dir 3 Knoten aus, dann stoppen die letzten beiden Knoten die Arbeit.
Die Arbeit mit dem Container kannst du dir sparen und den betreffenden Host einfach 2 votes geben, natürlich mit den möglichen Gefahren,
Beim 2 Knoten Setup ist das überschaubar, abe schöner ist ein drittes echtes Device.

 

[itNGO]

Hallo zusammen, gerne hänge ich mich mit einer Frage ein:

Ist es möglich auch zwei Quorum Server in einem Ubuntu als LXC laufen zu lassen mit den Diensten (corosync-qnetd und corosync-qdevice).
Der erste ist auf dem Master Host als LXC mit einer Verbindung in das HA Netz, der andere läuft auf dem zweiten Hardware Node auch als LXC.

So besteht das HW Setup aus zwei pysikalischen PVE Nodes mit jeweis einem Quorum Dienst im LXC Container.

Danke

Was rechnerisch 4 Nodes und damit eine gerade Node-Anzahl ergibt. Das ist bitte idealerweise unbedingt zu vermeiden.... es müssen dann 3 Nodes laufen, damit der Cluster sich bildet....

 

[Admina]

Danke für euere Rückmeldung.