adding a PVE 6.1 to a 5.4 Cluster

[grefabu]

Moin,

ich möchte unseren bestehenden PVE 5.4 ablösen.
Dazu habe ich 3 neue Maschinen vorbereitet, diese sind mit PVE 6.1 vorbereitet, aber Standalone.

Mein geplantes vorgehen wäre gewesen:

1. Vorbereitung der neuen Maschinen, Standalone - abgeschlossen
2. Upgrade von Corosync auf den PVE 5.4 - abgeschlossen
3. Einbinden der neuen 6.1er Nodes in den bestehenden Cluster
4. Migrieren der VMs aus die neuen Knoten
5. alte Knoten aus dem Cluster nehmen.

Den alten Cluster wollte ich nicht auf 6.1 hochziehen, aber ich habe nach Anleitung den Upgrade von Corosync gemacht. Ein pve5to6 gibt mir auch keine grundsätzlichen Probleme (2 Warnings wegen veralteter Pakete und laufenden VMs)

Kann ich die 6.1er Knoten in den 5.4 cluster aufnehmen? Nach diesem Thread müsste mein Vorgehen ja gehen? Mixed Cluster 5.4 / 6.x during upgrade?

Ich würde ungern den weg über den Upgrade auf 6.1 des alten Clusters gehen, wenn es aber gar nicht anders geht,...

 

[t.lamprecht]

Kann ich die 6.1er Knoten in den 5.4 cluster aufnehmen? Nach diesem Thread müsste mein Vorgehen ja gehen? Mixed Cluster 5.4 / 6.x during upgrade?

Ein gemischter Cluster während des Upgrades ist eine Zeitlang kein Problem. Das einbinden von neuen Nodes mit 6.x zu Nodes mit 5.4 ist aber nicht wirklich getestet. Sollte gehen, notfalls einfach mal in zwei virtuellen PVEs das Szenario durchspielen.

 

[grefabu]

Das es kein Dauerhafter zustand sein soll ist selbstverständlicher. Je schneller es über die Bühne geht, um so besser.
Ich möchte halt nach Möglichkeit keine downtime bei den VMs haben.

 

[grefabu]

Ich erhalte folgende Rückmeldung, wenn ich von dem 6.1er Knoten auf den 5.4er joinen möchte:

Login succeeded.
Request addition of this node
400 Parameter verification failed. link0: property is not defined in schema and the schema does not allow additional properties

Die corosync version auf den 5er ist aber auf 3:
root@ph-pve001:~# corosync -v
Corosync Cluster Engine, version '3.0.2'
Copyright (c) 2006-2018 Red Hat, Inc.

Auf dem 6.1er ist es 3.0.3

Momentan gehe ich davon aus, das ich die 5.4er wie beschrieben auf die 6er hochziehen werde. Das hat in einem Testsetup schon problemlos funktioniert.

 

[t.lamprecht]

corosync version

Das Problem ist die alte API des 5er knoten, die kennt die neuen Parameter die der 6er Knoten verwenden will nicht..

Man könnte den 6er Knoten schon manuell hinzufügen (authkey rüberkopieren, manuell in corosync.conf eintragen und diese rüberkopieren) aber dass ist eher eine leichte Frickelei..

Upgrade von 5.4 auf 6.x wurde gut getestet und ist auch ohne herunterfahren der VMs möglich, würde daher auch eher diesen Weg gehen.

 

[grefabu]

Yep, wie geschrieben auf Testmaschinen auch schon erfolgreich exerziert. allerdings werde ich die VMs herunterfahren. kein gemeinsamer share, nur langsame lokale Platten.

Deswegen auch die neuen Knoten, dort wir ein CEPH laufen.

 

[t.lamprecht]

allerdings werde ich die VMs herunterfahren. kein gemeinsamer share, nur langsame lokale Platten.

Da gäbe es vielleicht schon was
qm migrate <vmid> <targetnode> --online --with-local-disks --targetstorage <target-storage-id>

Ab 6.0 gibt's die "local storage live migration" auch am Webinterface.

 

[grefabu]

Moin,

ja das mit der Live Migration mit lokalen Platten ist eine feine Sache. Eine Testmigration hat auch schon geklappt.

Der Upgrade des alten clusters auf die 6.1ser hat auch reibungslos geklappt. Das einbinden der neuen Knoten ebenfalls.
Was ich aber nicht im Vorfeld bis zum Ende überlegt habe: Die Knoten haben jetzt ja unterschiedliche Hardware.

Die neuen Knoten verfügen über SSDs mit denen ich jetzt ein CEPH storage aufbauen möchte.

Was ich nicht bedacht habe: die alten Knoten haben keine entsprechende Netzwerkkarten, um auf den Storage zugreifen zu können.
Aber bei der Migration müsste ich als target ja auch den CEPH Storage auf den neuen Servern als Ziel definieren können?

Mein weiteres vorgehen wäre jetzt:

1. Aufbau des CEPH Clusters auf den neuen Knoten
2. Verschieben der VMs auf den CEPH Cluster
3. Entfernen der alten knoten aus dem Cluster.