Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[BananaJoe]

Ich habe mir hier extra einen Proxmox-Cluster aus 3 Knoten gebaut.
4 VMs sind dabei auf 2 Knoten verteilt, für alle 4 ist HA eingeschaltet mit Request State: started
Aus Wartungszwecken (Steckdosenleiste umbauen) musste ich gerade 2 herunterfahren,
weshalb ich alles auf den einen verbliebenden verschoben habe.

Sah auch erst gut aus.

Als ich dann bei Hochfahren wieder geschaut habe, hatte er alle 4 hart ausgeschaltet ... Warum?
Und wie sorge ich dafür das der Cluster auch auf einem Bein weiter macht?

[BananaJoe]

So, ich konnte das Problem selber lösen. Scheint jedenfalls so, aber ich habe 2 Knoten heruntergefahren und diesmal bleiben die VMs auf dem 1. Knoten an.

Die Lösung wird nicht universal funktionieren, deshalb hier noch mal meine Ausgangslage:

• Ich habe einen Proxmox Cluster mit 3 Proxmox Knoten
  
• HA ist für 4 VMs aktiviert:
  

proxmox02 und proxmoxesxi sitzen dabei in einem Datenschrank. Wenn diese Ausfallen, z.B. wegen Strom, dann höchstwahrscheinlich zusammen. Der proxmox01 sitzt separat, andere Sicherung, anderer Ort.
Ich hatte vorhin also proxmox02 und proxmoxesxi heruntergefahren (und vorher alle VMs auf den proxmox01 verschoben.
Ein paar Minuten nach dem die beiden Server/Hosts aus waren, hat der proxmox01 dann alle VMs gestoppt weil nicht genügend Quorum da war. Naja, nicht genug Stimmen, und das war mein Ansatz:

Auf einen (!) der Proxmox-Hosts bearbeiten wir die Datei

nano /etc/pve/corosync.conf

Und machen folgende zwei Änderungen:

nodelist {
  node {
    name: proxmox01
    nodeid: 2
    quorum_votes: 5
    ring0_addr: 192.168.0.229
    ring1_addr: 172.31.0.229
  }
  node {
    name: proxmox02
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 192.168.0.230
    ring1_addr: 172.31.0.230
  }
  node {
    name: proxmoxesxi
    nodeid: 3
    quorum_votes: 1
    ring0_addr: 192.168.0.231
    ring1_addr: 172.31.0.231
  }
}

Beim Abschnitt proxmox01 habe ich diesem quorum_votes: 5 und damit 5 Stimmen gegeben. Der kann also alle anderen nun überstimmen.
Nun noch die Versionsnummer anpassen:

totem {
  cluster_name: Cluster01
  config_version: 6
  ...

Sucht die Zeile mit config_version: und erhöht die Nummer um 1
Nach dem Speichern wird so diese neue Version Datei automatisch auf die anderen Hosts kopiert.
In der Web-UI lässt sich das prüfen:

Und schon kann ich alle bis auf den proxmox01 ausschalten ohne das dieser sich ins Unglück stürzt (oder mich)

[ticaki]

@bananajoe

Wenn jetzt aber 01 ausfällt haben die anderen 2 keine Mehrheit mehr. Oder sehe ich das falsch?

[Wildbill]

@ticaki Würde ich auch so sehen. Und widerspricht auch irgendwie dem Sinn eines HA-Clusters. Normalerweise gibt es eine ungerade Anzahl an Host mit je einem Quorum. Diese Anzahl kennt jeder Host. Wenn nun welche ausfallen, erkennt jeder Host, ob er noch die Mehrheit sieht oder nicht. Im ersten Fall macht er normal weiter, im zweien Fall wird alles gestoppt, weil er davon ausgehen muss, dass in dem Netzwerkbereich, den er noch sieht, das Problem sein wird, da er weniger als die Hälfte der Hosts sieht.

Das erklärt auch, warum Promox01 bei @BananaJoe alles beendet hat. Er hat nur noch einen Host von 3 gesehen (sich selbst) und daraufhin gemacht, was vorgesehen ist. Er muss davon ausgehen, dass sein Netzwerksegment abgehängt ist und er DARF also nicht weitermachen.

Wenn man dem nun manuell ein Quorum von 5 gibt, so hat man insgeamt ein Quorum von 7. Steigen proxmox02 und proxmoxesxi aus, macht 1 weiter, weil er ja noch die Mehrheit (5) sieht. Steigt aber proxmox01 aus, müssen die beiden anderen auch anhalten, da sie nur noch ein Quorum von 2 aus 7 sehen.

Gruss, Jürgen

[BananaJoe]

@ticaki sagte in [gelöst] Promox Cluster mit 3 Knoten - alle VMs aus:

@bananajoe

Wenn jetzt aber 01 ausfällt haben die anderen 2 keine Mehrheit mehr. Oder sehe ich das falsch?

Nein, die Anzahl für die Mehrheit habe ich nicht angefasst, nur die Stimmen erhöht.
Ok, das klingt jetzt gerade etwas widersprüchlich ...

Es waren vorher 3 Stimmen und 2 waren die Mehrheit.
2 sind immer noch die Mehrheit, nur hat der proxmox01 nun 5 Stimmen und Entscheidet damit jede Wahl. Der kann ja auch für einen anderen Host stimmen.

Das schaue ich mir gerade noch genauer an.

[BananaJoe]

@wildbill Ja, du hast Recht.

Votequorum information
----------------------
Expected votes:   7
Highest expected: 7
Total votes:      7
Quorum:           4
Flags:            Quorate

Das schaue ich mir gerade noch intensiver an.

Mein Problem war insbesondere das ich ja auch die Netzwerkswitche bzw. den Coreswitch lahmgelegt hatte.

Ich komme aus der VMware-Welt. Da lässt sich das sehr viel vielfältiger konfigurieren.
Ein Punkt ist da die "Host Isolation":

Die ESXi Hosts sprechen über das Netzwerk miteinander, wichtig ist auch wer das Standardgateway erreichen kann (sollte unbedingt pingbar sein). Zusätzlich unterhalten die sich aber auch über die gemeinsamen Datenträger und können erkennen ob der andere Host noch seine Finger auf der VM hat.
Und die Hostisolierung stelle ich im Normalfall immer auf Disabled. Da kann unter umständen ein Fehler im Netzwerk reichen um in Sekunden alles herunterzufahren (ok, bei gut konfigurierten Netzwerk mit redundanter Anbindung nicht).

Ich lerne ja erst noch, mein Proxmox-Profi Kurs (im Linux-Hotel in Essen!) ist zwar gebucht, leider aber erst im Oktober.

[BananaJoe]

Nachtrag: Ja, er lässt sich nicht austricksen, die Anzahl der notwendigen Stimmen wird immer automatisch erhöht.
Es gibt zwar jede Menge Optionen, deren Erfolg müsste ich mal durchtesten:
https://manpages.debian.org/bookworm/corosync/votequorum.5.en.html