Dieser Artikel befindet sich noch in der Erstelllung - wir arbeiten gerade dran:
Der Upgrade von Proxmox 1.9 auf Proxmox 2.0 kann zur Geduldsprobe werden oder zum Gau führen!
Die vorgeschlagenen Methoden der Entwickler sind leider sehr unschön:
Methode 1 - die gefährlichste:
- alle Container sichern (vzdump) und die Sicherheitskopien auf anderem Server/Space lagern
- alle Conatiner stoppen
- Update-Script durchführen und hoffen, daß der Upgrade funktioniert
- Wenn nicht, wie bei uns auf einem Test-Host, Ausfall von ggf. vielen Stunden/Tagen
- ggf. IP-Umleitung
Methode 2 - die sicherste, aber zeitlich aufwendigste:
- neuen Host erstellen
- alle kleinen Container stoppen
- alle kleinen Container mit vzdump sichern
- alle kleinen Conatiner via SCP manuell auf neuen Host kopieren
- alle kleinen Conainter via vzrestore wieder herstellen
- einen großen Container stoppen
- einen großen Container mit vzdump sichern (100 GB in 3-4 Stunden)
- den großen Container mit SCP auf neuen Host kopieren (40 GB in ca. 1,5 Stunden)
- den großen Container mit vzrestore wieder herstellen (100 GB in 3-4 Stunden)
- ggf. IP-Umleitung
Methode 3 - optimiert für Kunden - Ausfallzeit ca. 15 Minuten bei einem 100 GB Container:
Diese Methode erfolgt in mehreren Schritten und nur im letzten Schritt, wird der Server für nur wenige Minuten herunter gefahren!
- proxmsync kopiert alle Container ONLINE - Unterbrechung bei einzelnen CTs nur Sekunden, bis wenige Minuten, ähnlich wie vzdump im Online-Modus
- ein großer Container wird herunter gefahren
- proxmsync mit anderer Einstellung erneut gestartet - dauert bei 100 GB Container ca. 5 Minuten
- auf dem neuen Host wird die alte Konfigurationsdatei einkopiert
- auf dem neuen Host wird ein Kopierbefehl eingesetzt - ca. 3 Sekunden
- mit vzctl start ..... wird der verschobene Container gestartet
- ggf. IP-Umleitung
Vorteile unserer Methode:
- eine nur sehr kurze Offline-Zeit für den jeweiligen zu transferierenden Container
- die Migration erfolgt in Phasen, die steuerbar sind und den Host daher kaum belasten
- Zeiten für unnötiges Zippen/Entzippen entfallen
- Sicherer und korrekter Transfer
- Einhaltung der Daten-Konsistenz für den gesamten Server (alles befindet sich auf gleichem Stand)
- Der alte Container bliebt auf dem alten Host unangetastet für Prüfungen / Notfälle erhalten
- Das Script ist als Shell-Script prüfbar - somit keine Gefahr für den Einsatz
Sollten Sie sich für die schnelle Transfer-Möglichkeit interessieren, verwenden Sie unseren
Online-Support