Schnelle Migration auf Proxmox 2.0: Damit haben wir nun alle Server, die unter der bisherigen Host-Technik von Proxmox 1.9 auf Proxmox 2.0 liefen, umgestellt.
Proxmox 2.0 sieht von der Bedienung und den Möglichkeiten besser aus, setzt aber auf die bestehenden Techniken von vzOpen auf. Wichtigster Grund für einen Upgrade auf Proxmox 2.0 war, daß das Host-Operationg-System in der alten Version unter Debian Lenny, nicht mehr supportet wird und damit überholt und sicherheitskritisch geworden ist. Die neue Version Proxmox 2.0 (und die 2.1 ist gerade auch erschienen), läuft unter Debian-Squeeze, der derzeitigen Debian-Stable-Version.
Unter Proxmox 2.0 kann man von einer hohen Sicherheit ausgehen. Die mitgelieferten Backup-Funktionen, sind leider nicht besonders schön, denn sie belasten den Host über mehrere Stunden (insbesondere das File-System) und die Nacht reicht nicht aus, für einen normalen Backup-Satz und das bei noch relativ wenig virtuellen Servern.
Ebenfalls hätte der Upgrade via Script – bei uns zumindest – zu einem Totalausfall geführt! Daher können wir nur warnen, via Script den Upgrade von Proxmox 1.9 auf 2.0 durch zu führen. In den Requirements für einen Upgrade wird nicht erwähnt, den Grub (Bootloader) auf den neuesten Stand zu bringen. Mittels Supergrub konnte auch das Problem ebenfalls nicht beseitigt werden, es fand nämlich nicht die LVM – Drives (alle Options, wie LVM, SCSI etc. wurden enabled – mehrfach auf alle Arten und Weisen getestet)! Ferner wurden diverse Fehler während der Installation angezeigt! Also eine einfach unschöne Lösung. Wir haben auf einem Host, von dem bereits alle Container auf den neuen Host verschoben wurde, einen Upgrade via Script probiert. Danach haben wir fast 14 Stunden vergeblich versucht, eine Problemlösung zu finden – es half nichts – wir haben aufgegeben!
Die Methode via vzdump + vzrestore bei Container mit 100 GB und mehr, die Server zu verschieben, würden zeitliche Ausfälle wenigstens einzelner Server über viele Stunden, nämlich jeweils denen, die gerade verschoben werden, verursachen. Für den m6server hätten wir ca. 10 Stunden diesen Server „offline“ schalten müssen. Ca. 4 Stunden für vzdump – ca. 2 Stunden für scp zum anderen Host und weitere 4 Stunden für vzrestore.
Wir haben eine andere Methode gefunden, die Server von einem alten auf einen neuen Host zu migrieren und die Ausfallzeit für Kunden pro Server, auf nur 15 Minuten (dies war die echte Ausfallzeit des m6server´s) zu reduzieren!
Artikel schnelle und sichere Migration von Proxmox 1.9 auf 2.0