Wie fragil ist corosync3 auf pve5?

[puldi]

Hallo,

ich habe mal eine Frage zu der "Fragilität" von corosync v3 auf PVE 5. In der Anleitung wird explizit darauf hingewiesen, dass die corosync 3 Pakete nur für den Upgrade Prozess vorgesehen sind:

Running a cluster of Proxmox VE 6.x with earlier versions is not possible. The cluster protocol (corosync) between Proxmox VE 6.x and earlier versions changed fundamentally. The corosync 3 packages for Proxmox VE 5.4 are only intended for the upgrade procedure to Proxmox VE 6.0.

Vor dem Hintergrund, dass wir ein laufendes Cluster mit 5 Knoten mit PVE 5 laufen haben, das teilweise hardwareseitig erneuert und auch um mindestens einen sechsten Knoten erweitert werden soll, stellt sich mir die Frage, was passieren könnte, wenn das Cluster in einem Mischbetrieb aus PVE5 und PVE6 läuft.
Dies wäre mein Plan:

1. Corosync wird auf allen Knoten auf V3 angehoben
2. Ein Knoten wird leergeräumt und auf Buster und PVE6 aktualisiert
3. ein zusätzlicher Knoten, der bereits Buster/PVE6 laufen hat, wird in das Cluster eingefügt (dann haben wir 4x PVE5 und 2x PVE6)
4. VMs werden auf die PVE6 Knoten verschoben und ein weiterer Knoten frei gemacht.
5. Der freie Knoten wird auf Buster/PVE6 aktualisiert
6. Schritte 4+5 werden wiederholt bis das Cluster komplett auf Buster/PVE6 läuft.

ABER: zwischen den Schritten kann durchaus Zeit vergehen. Es wäre sicher prima, alle Knoten in einem Rutsch an einem Tag auf PVE6 zu bringen aber das halte ich bei uns für utopisch. Zudem rechne ich fest damit, dass einzelne Knoten rumzicken werden, ggf neu installiert werden müssen etc. Kurzum, das ganze Prozedere wird realisitisch eher eine Woche als einen Tag dauern. Ein Hardwareupgrade wird sinnvollerweise wohl erst nach dem PVE Upgrade vorgenommen werden.
Was kann in der Zeit alles passieren, wenn PVE 5 Knoten zusammen mit PVE 6 Knoten in einem Cluster mit corosync 3 laufen? Sind Störungen zu erwarten? Ausfälle? Datenverlust?

 

[Ingo S]

Wir haben unseren Cluster aus 6 Nodes in einem Rutsch migriert. Das dauerte von morgens etwa 8 bis Abends etwa 7, inkl. Ceph Nautilus. Machbar ist das. Ich weiß aber natürlich nicht, wie komplex die Infrastruktur bei euch ist etc..
Wenn man den ersten Node migriert hat, hat man die Anleitung eigentlich ziemlich im Kopf, so das es danach flotter von der Hand geht.

In der Zeit wo es einen Mischbetrieb gab, haben wir keine Probleme mit dem Cluster festgestellt, die Migration lief ziemlich reibungslos. Ich wüsste auch nicht, wie man euren Cluster sonst migrieren könnte, ausser, einen zweiten neuen Cluster aufmachen, und die Maschinen dann via Backup and Restore da rüber ziehen.

 

[aaron]

Der Plan klingt soweit ganz gut.

Das ein größerer Cluster mitunter nicht an einem Tag hochgezogen werden kann ist auch verständlich. Vor allem wenn es kein shared storage gibt.

Es sollte für die Dauer der Migration kein Problem sein PVE5 und PVE6 ein paar Tage parallel zu betreiben wenn man daran denkt, dass Live Migrationen von neuer auf alte Version nicht supported sind und womöglich fehlschlagen.

 

[t.lamprecht]

Also corosync 3 aus unserem extra Stretch Upgrade repository funktioniert gleich gut wie dann das "echte" wenn man auf Buster ist. Man fragt sich dann vielleicht: wieso steht dann dieser Satz so deutlich?

Naja, der Hauptgrund:
Das Cluster Tooling von PVE5 kann nur recht limitiert mit Corosync 3 und seinen doch leicht anderem Konfigurationsformat umgehen, d.h., neue Nodes hinzufügen oder alte Löschen sind während dieser Zeit nicht wirklich möglich, zumindest nicht durch unser Tooling (manuell geht eh immer alles, wenn man weiß wie )

Also Datenverluste o.ä. sind nicht wirklich zu erwarten, aber man darf halt nicht davon ausgehen dass der Cluster komplett gleich bedienbar ist wie ein PVE 5 mit corosync 2 oder ein PVE6 mit corosync 3. Das ändern von Cluster Einstellung o.ä. Aspekten ist halt sehr stark beschränkt.

 

[puldi]

Danke für die Klarstellung. Könntest du mir aber bestätigen, dass mein genannter Schritt 3 trotzdem funktioniert? Zu diesem Zeitpunkt hätte ich 1 aktualisierten Knoten, der bereits im Cluster drin ist. Über diesen Knoten würde ich den neuen einfügen. Das wäre ja PVE6<=>PVE6.

Etwas irritiert bin ich wegen dieses Problems, das ich versucht habe zu verstehen, aber dessen Auswirkungen ich nicht annähernd abschätzen kann:
https://forum.proxmox.com/threads/pve-5-4-11-corosync-3-x-major-issues.56124/
Es scheint mittlerweile patches zu geben, bzw gepatchte Test-Versionen. Soweit ich das nachvollziehen kann, geht es um ausgelastete Netzwerkverbindungen, die corosync zum Absturz bringen und dadurch das ganze Cluster runterreissen.
Wir haben hier ein dediziertes 1GE Netzwerk über das die PVE Kommunikation läuft. Leider auch teilweise noch der Datentraffic der VMs. Alle VM liegen auf NFS Freigaben. Wir haben zwar ein zusätzliches 10GE Netzwerk, aber leider wurde das erst im laufenden Cluster hinzugefügt. Eine Separierung der Netzwerke war also nicht mehr so leicht umzusetzen, zumal ein Knoten noch keine 10GE Karte bekommen konnte.

Je länger ich darüber nachdenke, desto verlockender ist die Variante, gleich ein neues Cluster aufzusetzen. Das erfordert allerdings perfekte Planung, denn bei den VM dürfen wir uns nicht besonders viel Auszeit gönnen.

 

[puldi]

Kurzes Update: Wir migrieren jetzt im laufenden Betrieb auf ein neues Cluster. Das gibt uns auch die Gelegenheit die Hardware zu erneuern und die Hosts komplett mit SSD Speicher auszurüsten. Das logische Netzwerk bleibt identisch, dadurch läuft die Kommunikation weiter, auch Clusterübergreifend. Bislang funktioniert das prima.