Migration von 4 HA Clustern mit je 4 Nodes auf 2 neue HA Cluster mit je 4 Nodes

[kleemann_hdm_str]

Hallo liebes Forum,

wir sind hier mitten in der Planung unsere bestehende Infrastruktur mit proxmox kpl. neu aufzubauen.

Ist Situation: 4 HA Cluster kvmpool1 bis 4 zzgl. ein Adminpool als Notfall System bestehend aus je 4 Nodes mit ZFS Ceph und Bacula als Backup System. Wir haben aus bestimmten Gründen keinen proxmox Backup-Server.

Auf den 4 Clustern ca insgesamt 200 VM Linux, Windows poprietäres Zeug


Sollsituation: Konsolidierung zu nir noch 2 Clustern kvmpool1 (für die produktiven Systeme) und kvmpool2 (für Test und sonstige Systeme) ob der Adminpool bestehen bleiben soll ist noch offen.

Aufgabe: die 200 VM mit minimaler Downtime auf das neue Blech verschieben, den möglchst reibungslosen Betrieb besonders des kvmpools 1 gewährleisten , die alten Systeme abschalten.

Die Vzdumps werden mittels Bacula gesichert.

Wie würdet ihr am sinnvollsten vorgehen?

Zuerst die Backups von Proxmox auf die neue Maschine unter /var/lib/... kopieren oder?

Von jeder VM zusätzlich noch einen aktuellen Snapshot anlegen? VM für VM oder gleich den kpl. Node migrieren?

Ich weiss viele Fragen , doch wer nicht fragt bleibt dumm.

Ich freue mich auf eure Ideen und Vorschläge

Gruss

Uli

 

[waltar]

Das hängt mal sehr von eurem umgesetztem VM/LXC Storage Konzept ab. Super easy, wenn nfs wäre ... oder zeitweise nfs dazunehmen ...
Angenommen ihr habt die neuen Nodes schon bißchen gequält, daß sie auch stabil laufen ...
kvmpool1 um neue Nodes erweitern, vm/lxc auf neue Nodes life migrieren und alte Nodes aus Cluster entfernen.
Bei den weiteren 3 Clustern kommt es auch auf eure <vm>id's an, ggf. überschneiden sich die vmid Nummern ?!?
Dann weiter mit remote-migration oder über (temp.) storage nfs migrieren.
Wenn man im Betriebskonzept Storage und Virtualisierung trennt, ist ein Austausch wie auch eine Erweiterung wesentlich leichter und vor allem HW Laufzeit unabhängiger Austausch wesentlich leichter zu bewerkstelligen.

 

[Falk R.]

Warum migrierst du nicht einfach live zwischen den Clustern? Natürlich müssen die CPU Architekturen passen oder die VM-CPUs passend maskiert werden.

Guck mal nach [B]qm remote-migrate[/B]
https://pve.proxmox.com/pve-docs/qm.1.html

 

[kleemann_hdm_str]

Warum migrierst du nicht einfach live zwischen den Clustern? Natürlich müssen die CPU Architekturen passen oder die VM-CPUs passend maskiert werden.

Guck mal nach [B]qm remote-migrate[/B]
https://pve.proxmox.com/pve-docs/qm.1.html

Hallo Falk,

erstmal DANKE. Du meintest dies hier: https://debianforum.de/forum/viewtopic.php?t=186538#p1322964
nehme ich an . Ich gehe mal davon aus dass gleiche Haardware von Krenn beschafft wird - das obliegt nicht mir auch nicht die Planung nur die Ausführung.

Frage: Könntest Du uns ggf dabei helfen?

Gruss

Uli

 

[fabian]

je nachdem wie eure VMs und storages derzeit und am neuen cluster konfiguriert sind und wie die anbindung zwischen den clustern ist, kann die remote migration eine option sein. ist zwar noch im preview stadium, aber hautpsaechlich weil es noch ein paar einschraenkungen gibt

ansonsten mit entsprechend mehr downtime ist backup/restore der sicherste weg. haendischer umzug wenn geteilter zugriff auf denselben storage moeglich ist geht auch, ist aber etwas riskanter - wenn ein storage auf mehreren clustern eingebunden ist, koennen unabsichtlich daten geloescht werden weil PVE nicht weiss dass die vom anderen cluster verwendet werden...

 

[kleemann_hdm_str]

je nachdem wie eure VMs und storages derzeit und am neuen cluster konfiguriert sind und wie die anbindung zwischen den clustern ist, kann die remote migration eine option sein. ist zwar noch im preview stadium, aber hautpsaechlich weil es noch ein paar einschraenkungen gibt

ansonsten mit entsprechend mehr downtime ist backup/restore der sicherste weg. haendischer umzug wenn geteilter zugriff auf denselben storage moeglich ist geht auch, ist aber etwas riskanter - wenn ein storage auf mehreren clustern eingebunden ist, koennen unabsichtlich daten geloescht werden weil PVE nicht weiss dass die vom anderen cluster verwendet werden...

Hallo Fabian,

DANKE für deine Antwort, hilft mir schonmal sehr weiter. Downtime möchten wir nach möglichkeit vermeiden. Welche Einschränkungen gibt es noch , die zu beachten wären?


Viele Grüße aus Stuttgart

Uli

 

[fabian]

nach downtime sortiert:

- remote migration (live quasi keine downtime, aber noch ein bisschen mehr einschraenkungen zusaetzlich zu denen die bei jeder live migration gelten, am besten mit test VMs durchspielen die von der config her den echten entsprechen)
- "nur config migration" (erfordert gleichzeitigen zugriff beider cluster auf denselben shared storage - VM abdrehen, config auf neuen cluster schieben und ggf anpassen, VM wieder starten - sehr vorsichtig mit anderen admin tasks umgehen waehrend der storage auf beiden clustern eingebunden ist und gut vorher durchtesten!)
- backup/restore (groesste downtime, aber am meisten flexibilitaet und stabilitaet)

 

[Falk R.]

Hallo Falk,

erstmal DANKE. Du meintest dies hier: https://debianforum.de/forum/viewtopic.php?t=186538#p1322964
nehme ich an . Ich gehe mal davon aus dass gleiche Haardware von Krenn beschafft wird - das obliegt nicht mir auch nicht die Planung nur die Ausführung.

Frage: Könntest Du uns ggf dabei helfen?

Gruss

Uli

Wenn ich das lese, bin ich fast geneigt nein zu sagen aber klar könnte ich dir helfen.
Was mich hier am meisten stört: "beschafft wird - das obliegt nicht mir auch nicht die Planung"

Das ist immer ganz schlecht wenn irgend jemand beschafft und plant, aber jemand anderes dann mit der Umsetzung kämpfen muss.
Es sollten immer die Personen, welche mit der Umsetzung beauftragt sind, auch ein Mitspracherecht bei der Planung haben. Man kann manchmal mit einer kleinen Konfigurationsänderung (die nicht mehr kosten muss) das Leben wesentlich einfacher machen.