2 Node HA Cluster ohne QDevice erstellen

Nov 17, 2023
265
32
33
Moin,

ich experimentiere gerade mit dem Gedanken einen 2 Node HA Cluster ohne QDevice zu erstellen.

Warum mache ich das?

Ich möchte eine Ausfallsicherheit meines Produktiv-Node sicherstellen.
Ich nutze einen Produktiv-Node (PN) und einen Backup-Node (BN), auf dem PN laufen meine VMs und erfüllen Ihre Arbeit.
Der BN repliziert die VMs und dient nur als Backup und übernimmt im Falle das der PN ausfällt die Arbeit.
Aber wie soll ich das ohne ein QDevice oder 3. Node machen?

Ganz einfach, ich erhöhe die Quorum Votes des PN auf 2.
Fällt jetzt der PN aus ist das Quorum nicht mehr erfüllt und der BN übernimmt die Arbeit.

Wie konfigurieren ich das?

Ich gehe in die Shell des PN.

Code:
cp /etc/pve/corosync.conf /etc/pve/corosync.new.conf

Dann bearbeite ich die corosync.new.conf

Code:
nano /etc/pve/corosync.new.conf

Jetzt erhöhe ich die quorum votes des PN auf 2

Code:
nodelist {
    node {
        name: pn
        nodeid: 1
        quorum votes: 2
        ring0 addr: 192.168.0.1
    }
    node {
        name: bn
        nodeid: 2
        quorum votes: 1
        ring0 addr: 192.168.0.2
    }
}

Weiter passen wir in der Config folgende Werte an. Wir erhöhen den Config Version auf 3

Code:
totem {
    cluster name: hacluster
    config version: 3
    interface {
        linknumber: 0
    }
    ip version: ipv4-6
    link mode: passive
    secauth: on
    version: 2
}

Und schließlich kopieren Sie die geänderte Datei zurück in das Original:

Code:
mv /etc/pve/corosync.conf /etc/pve/corosync.conf.bak
mv /etc/pve/corosync.new.conf /etc/pve/corosync.conf

So damit hat der PN die notwendigen Stimmen um auch beim Ausfall des BP weiter zu laufen, aber wenn der PN ausfällt übernimmt der BP die arbeit.

So soll es doch sein oder?

Somit brauche ich kein QDevice oder einen 3. Node.
 
Last edited:
Warum mache ich das?
Das frage ich mich auch. ;-)

Merke: nicht alles, was technisch konfigurierbar, ist auch sinnvoll einsetzbar.

Das Thema wurde übrigens mehrfach diskutiert...
 
Nein, ein Node brauch die Mehrheit bei den Votes damit HA funktioniert. In deinem Beispiel hat der Backup Node aber nur 33% der Votes.
Da er keine Gegenstelle (anderen Node oder QDevice) erreicht wir er versuchen sich neu zu starten.
 
Moin,

ich experimentiere gerade mit dem Gedanken einen 2 Node HA Cluster ohne QDevice zu erstellen.

Warum mache ich das?

Ich möchte eine Ausfallsicherheit meines Produktiv-Node sicherstellen.
Ich nutze einen Produktiv-Node (PN) und einen Backup-Node (BN), auf dem PN laufen meine VMs und erfüllen Ihre Arbeit.
Der BN repliziert die VMs und dient nur als Backup und übernimmt im Falle das der PN ausfällt die Arbeit.
Aber wie soll ich das ohne ein QDevice oder 3. Node machen?

Ganz einfach, ich erhöhe die Quorum Votes des PN auf 2.
Fällt jetzt der PN aus ist das Quorum nicht mehr erfüllt und der BN übernimmt die Arbeit.
Genau hier hast du einen Denkfehler. Wenn dein PN down ist, macht dein BN gar nichts mehr mit 33% Vote. Der einzige Vorteil in diesem Setup ist, dass dein PN die VMs nicht aus macht, wenn dein BN mal in Wartung ist.

Falls du wirklich einen Neustart dener VMs auf dem BN möchtest, kommst du um ein Quorum nicht herum.
Denk einfach noch einmal nach, mit 2x 50% wirst du niemals 2x 51%+ erreichen. Das ist mit Absicht bei jedem Cluster so.
 
  • Like
Reactions: Johannes S
Genau hier hast du einen Denkfehler. Wenn dein PN down ist, macht dein BN gar nichts mehr mit 33% Vote. Der einzige Vorteil in diesem Setup ist, dass dein PN die VMs nicht aus macht, wenn dein BN mal in Wartung ist.

Falls du wirklich einen Neustart dener VMs auf dem BN möchtest, kommst du um ein Quorum nicht herum.
Denk einfach noch einmal nach, mit 2x 50% wirst du niemals 2x 51%+ erreichen. Das ist mit Absicht bei jedem Cluster so.
Sorry, ich war ja noch nicht fertig.

Schau dir bitte noch einmal meinen Post an.

Jetzt hat der PN 2 Stimmen und weil die config version auf 3 steht sollte das doch passen oder?
 
Was hat denn die Config-Version mit der Anzahl der Stimmen zu tun?
In der nodelist haben beide node den gleichen Namen. Der Name muss pro Knoten jedoch eindeutig sein.
 
Rein theoretisch kannst du dir einen trigger setzen, dass wenn der Partner Node weg ist, die corosync.conf angepasst wird. Ob er das akzeptiert wenn der Partner weg ist, weiß ich nicht.

Wenn du mal einen Netzwerkaussetzer hast, starten dann beide Nodes, alle VMs und schon hast du den Split Brain, den Corosync verhindern soll.

Wenn du so etwas bauen möchtest, frage bitte nicht um Hilfe wenn dir die Daten auseinander gelaufen sind. Es gibt schon Gründe warum man mit einen Cluster und Quorum arbeitet. Du kannst dich ja mal ins Thema Grid einlesen, da funktioniert es genau so wie du es möchtest, nur das da auch wieder Scripte gebaut werden, mit Entscheiderinstanzen, um ein Datenfail zu vermeiden.
 
  • Like
Reactions: Johannes S
Rein theoretisch kannst du dir einen trigger setzen, dass wenn der Partner Node weg ist, die corosync.conf angepasst wird. Ob er das akzeptiert wenn der Partner weg ist, weiß ich nicht.

Wenn du mal einen Netzwerkaussetzer hast, starten dann beide Nodes, alle VMs und schon hast du den Split Brain, den Corosync verhindern soll.

Wenn du so etwas bauen möchtest, frage bitte nicht um Hilfe wenn dir die Daten auseinander gelaufen sind. Es gibt schon Gründe warum man mit einen Cluster und Quorum arbeitet. Du kannst dich ja mal ins Thema Grid einlesen, da funktioniert es genau so wie du es möchtest, nur das da auch wieder Scripte gebaut werden, mit Entscheiderinstanzen, um ein Datenfail zu vermeiden.
OK, dann rät du mir also davon ab.

Dann werde ich es mit einem QDevice machen. Ist glaube ich wohl die bessere Variante. ;)
 
Da haben vor Jahrzehnten sich schlaue Köpfe ein Clusterdesign ausgedacht, was überall gleich ist, auch bei Microsoft.
Das hat sich seit Jahrzehnten bewährt, also sollte man nicht versuchen mit gefährlichen Halbwissen das Rad neu zu erfinden. Meine Meinung.
 
Da haben vor Jahrzehnten sich schlaue Köpfe ein Clusterdesign ausgedacht, was überall gleich ist, auch bei Microsoft.
Das hat sich seit Jahrzehnten bewährt, also sollte man nicht versuchen mit gefährlichen Halbwissen das Rad neu zu erfinden. Meine Meinung.
Du hast ja recht. ;) So machen wir das jetzt.
Ich habe ja noch eine NAS darauf könnte ich das Qdevice machen.
 
  • Like
Reactions: Falk R.
Ich habe es mir noch mal überlegt und werde dann doch einen 3. Dummy Node nutzen.
Der Vorteil, die bekommt schon sehr günstig als refurbished z.B. lenovo thinkcentre m900 und kann dann darauf einfach PVE Installieren und diesem dem Cluster hinzufügen. Damit hat man dann die volle Kontrolle über das Node und hat einen vollwertigen HA Cluster.
 
  • Like
Reactions: Johannes S and UdoB
Ich habe es mir noch mal überlegt und werde dann doch einen 3. Dummy Node nutzen.
Der Vorteil, die bekommt schon sehr günstig als refurbished z.B. lenovo thinkcentre m900 und kann dann darauf einfach PVE Installieren und diesem dem Cluster hinzufügen. Damit hat man dann die volle Kontrolle über das Node und hat einen vollwertigen HA Cluster.
Ich nutze immer gern einen PBS als qdevice bei 2 Node Clustern.