Anfrage zur Migration des Proxmox Corosync/Heartbeat-Netzwerks ohne Betriebsunterbrechung

Sep 18, 2024
5
1
3
Germany
Sehr geehrtes Proxmox Support-Team,

wir betreiben aktuell einen Proxmox VE 8 Cluster mit zwei Nodes und einer gemeinsamen SAN-Infrastruktur.

Die aktuelle Umgebung:
  • Proxmox VE Version: 8.x
  • Cluster: 2 Nodes
  • Storage: gemeinsames SAN
  • Corosync/Heartbeat läuft aktuell über ein separates Netzwerkinterface
  • Keine zusätzlichen Netzwerkkarten verfügbar
  • Umgebung ist produktiv im Einsatz (kritische Infrastruktur Feuerwehr)
Wir müssen das bestehende Cluster-/Heartbeat-Netzwerk aufgrund einer Netzwerkanpassung ändern. Eine Betriebsunterbrechung ist möglichst zu vermeiden.

Unsere Fragen:
  1. Gibt es eine empfohlene Vorgehensweise, um die Corosync ring0_addr bei einem produktiven 2-Node-Cluster mit nur einer bestehenden Heartbeat-Verbindung ohne Cluster-Ausfall zu ändern?
  2. Kann die Umstellung im laufenden Betrieb erfolgen, wenn die physische NIC bzw. das Netzwerkinterface bestehen bleibt und nur die IP-/VLAN-Konfiguration geändert wird?
  3. Gibt es Besonderheiten bei einem 2-Node-Cluster ohne QDevice, die wir berücksichtigen müssen?
  4. Empfehlen Sie eine bestimmte Reihenfolge der Änderungen (Netzwerk, Corosync, Neustart der Dienste)?
Zusätzliche Informationen:
  • Die Cluster-Verbindung läuft aktuell über ein dediziertes Interface.
  • Es bestehen separate Netzwerke für Produktivbetrieb und Cluster-Kommunikation.
  • Ein Wartungsfenster mit VM-Ausfällen ist nur sehr eingeschränkt möglich.
Wir möchten die Änderung möglichst risikoarm durchführen und bitten um eine Empfehlung aus Ihrer Erfahrung.

Vielen Dank für Ihre Unterstützung.
 
Sehr geehrtes Proxmox Support-Team,
Wir möchten die Änderung möglichst risikoarm durchführen und bitten um eine Empfehlung aus Ihrer Erfahrung.

FYI: Dies hier ist das Community-Forum.
Für eine direkte Anfrage an den Support mit garantierter Antwort, entsprechende Subskription(en): [1] vorausgesetzt, muss hier: [2] ein Ticket eröffnet werden.


Gibt es Besonderheiten bei einem 2-Node-Cluster ohne QDevice, die wir berücksichtigen müssen?

Insbesondere bei einem Cluster mit nur zwei Nodes ist ein QDevice: [3] als Pflicht anzusehen. [4]
Erst recht, wenn es sich um:
Umgebung ist produktiv im Einsatz (kritische Infrastruktur Feuerwehr)
handelt.


Edit:
Es bestehen separate Netzwerke für Produktivbetrieb und Cluster-Kommunikation.

Siehe: [5]
/E


BTW: Ist das hier der internationale/englische Teil des Forums...


[1] https://proxmox.com/de/produkte/proxmox-virtual-environment/preise
[2] https://my.proxmox.com
[3] https://pve.proxmox.com/pve-docs/chapter-pvecm.html#_corosync_external_vote_support
[4] https://pve.proxmox.com/pve-docs/chapter-pvecm.html#_quorum
[5] https://pve.proxmox.com/pve-docs/chapter-pvecm.html#pvecm_redundancy
 
Last edited:
Hallo,

das Proxmox-Support-Team erreichst du über das Customerportal: https://www.proxmox.com/en/services/support-services/support
Hier ist das Community-Forum, wo zwar auch Leute aus den Team mitlesen und schreiben, aber es gibt keine Garantie dafür, die meisten Antworten kommen von Leuten, die Spaß daran haben Sachen besser zu wissen (also Leute wie mich).

Was mir aus der Beschreibung noch unklar ist: Wofür genau wird der Cluster verwendet? "Nur" zum migrieren, oder auch im HA-Modus? So oder so ist es (erst Recht bei kritischer Infrastruktur!) grob fahrlässig ihn ohne dritten Knoten/Qdevice zu betreiben und keine Redundanz für das Clusternetzwerk zu haben. Damit der Cluster funktioniert, muss beim Ausfall eines Knotens immer noch ein Quorum bestimmt werden können. Bei zwei Knoten kann der Ausfall z.B. des Netzwerk dann zu einen "split-brain"-Szenario führen, weil dann nicht eindeutig bestimmt werden kann, wer nun übernimmt und wohin (bei aktivierter Hochverfügbarkeit) die VMs und Container hin migriert werden sollen. Für einen Cluster (erst Recht mit aktivierter HA) braucht es ZWINGEND einen dritten Knoten und sei es als kombiniertes qdevice/Proxmox Backupserver (siehe: https://forum.proxmox.com/threads/2-node-ha-cluster.102781/#post-442601 für ein mögliches Setup). Benötigt man dagegen keine Hochverfügbarkeit, dann stellt sich die Frage, wofür man dann überhaupt einen Cluster benötigt? Denn eine Migration ist mit dem ProxmoxDatacenterManager in einer VM dann genauso möglich und das geht dann auch zwischen zwei single-nodes.

Daraus ergibt sich die nächste Frage: Wie sieht das Netzwerksetup und was wird überhaupt als Hardware für die Server verwendet? Wird das Corosync-Netzwerk auch für Migrationen genutzt oder nicht? Wird wenigstens der sonstige Traffic über eine eigene Karte ausgeführt? Wenn alles über eine Netzwerkkarte läuft, würde ich generell vom Clustern die Finger lassen.
Wie macht ihr überhaupt eurer Backup? Der ProxmoxBackupServer erlaubt auch ein sogenanntes Live-Restore, damit startet die VM und kann (mit reduzierter Performance) genutzt werden, während die restlichen Daten wiederhergestellt werden. Ist das kombiniert mit stündlichen Backups o.ä. eine Option für euch, falls ihr die Clusteranforderungen nicht erfüllen könnt? Bei kritischer Infrastruktur gehe ich mal davon aus, dass 24/7 jemand kurzfristig bei Problemen eingreifen kann, also z.b. eine Migration oder Live-Restore anstoßen.


Grundsätzlich können zusätzliche Corosync-netzwerke auch nachträglich hinzugefügt werden, dafür (da das ja eh nur als Ausfalloption gedacht ist, NICHT als Hauptclusternetz) kann man auch das "normale" Netz nehmen, was man sonst für den Traffic nimmt, der NICHT corosync ist. Siehe dazu auch die bereits von neobin verlinkten Dokumentation: https://pve.proxmox.com/pve-docs/chapter-pvecm.html#pvecm_redundancy
Prinzipiell sehe ich folgende Möglichkeiten:
  • Temporär oder (noch besser!) dauerhaft zusätzliche Netzwerkkarten einbauen, die (bei dauerhafter Installation) dann auch als eigenes Migrationsnetzwerk fungieren. Die müssen nicht viel können (1Gbit reicht für corosync, für Migration würde ich min. 10Gb nehmen). Als temporäre Karte könnte man notfalls sogar so USB-Ethernet-Adapter nehmen, das dann aber bitte nicht im Dauerbetrieb.
  • Falls das nicht möglich ist, zumindestens das reguläre (nicht corosync) Netzwerk dauerhaft als redundanten Link für corosync hinzufügen. Problem dabei: Gibt es auch da Probleme, habt ihr trotzdem einen Clusterausfall, aber es ist zumindestens auch nicht schlimmer als das aktuelle Risiko.
  • Cluster auflösen und neu aufsetzen mit der dann richtigen Konfiguration (siehe: https://pve.proxmox.com/pve-docs/chapter-pvecm.html#pvecm_remove_node ):
    • Backups von VMs und lxcs sowie der gesamten Konfiguration machen, soweit möglich restore testen.
    • Alle VMs und lxcs auf einen der beiden Knoten migrieren
    • Leeren Knoten vom Cluster entfernen und neu installieren, NICHT den Cluster hinzufügen
    • VMs und lxcs mit ProxmoxDatacenterManager (kann ja in einer VM laufen) auf den neuen leeren Knoten migrieren, danach auch zweiten ( nun leeren ) Knoten neu installieren
    • Danach dann den leeren Knoten und vollen Knoten zu einen neuen (dann bitte mit redundanten Corosync-netzwerken und einen qdevice oder dritten Knoten) zusammenpacken
    • VMS und lxcs nach Belieben zwischen den Knoten aufteilen
  • Cluster wie beschrieben auflösen und durch Setup mit zwei Knoten + DatacenterManager für Migrationen ersetzen
Wie breits gesagt Wenn ihr euch nicht in der Lage seht euren Cluster nach Vorgaben (Also mit drei Knoten oder 2+qdevice und redundanten corosync-netzwerk (notfalls über das normale für den Standard-Traffic) zu betreiben, dann lasst das bitte, gerade in kritische Infrastruktur.

Falls eure Budget-Entscheider das einen hergelaufenen Foristen nicht glauben, versucht eurer Glück beim Proxmox-Support, envtl. haben die einen (mir nicht bekannten Trick), ansonsten habt ihr es dann wenigstens aus offizieller Quelle ;)

Nichts für ungut und schöne Grüße, Johannes.
 
Last edited:
  • Like
Reactions: UdoB