Server-Transfer – der Tag an dem alles schief ging

Am Samstag hatten wir einen Server-Transfer eingeplant und auch vorbereitet. Aufgrund eines vorrangigen Kunden-Problemfalles, mußten wir den Umzug erst mal viele Stunden verschieben.

Als wir dann verspätet den Tranfer gestartet hatten, verlief  dieser im Anfang gut. Nach dem Transfer: Debian lief gut, FTP gut, MySQL gut, Apache gut, Confixx mit neuer Lizenz gut – aber keiner der Test-Webspaces lief. Ursächlich wurden php-Ini-Dateien für die Kunden-Webspaces nicht geschrieben, obwohl selbst der Debug-Modus des Confixx-Update-Scriptes keine Fehler zeigte! Auch in den Log-Files ließ sich nichts feststellen.

1,5 Stunden nach Beginn des Transfers, wurde dann der Rollback beschlossen und eine 1/4 Stunde später, konnten alle Kunden auf diesem Server wieder normal arbeiten! Der gesamte Unterbrechung für Kunden lag nur bei 1,75 Stunden und hätte bei Erfolg vielleicht noch ne Stunde länger gedauert.

Nun müssen wir erst mal das Problem erforschen, denn bei allen anderen Servern der gleichen Art, hat es dieses Problem nicht gegeben und es ist vollständig unverständlich, was hier schief gelaufen ist!

erneuten Proxmox 2.0/2.1 – Gau gefunden

Der besondere Vorteil von #Proxmox ist ja, daß #Proxmox 2.0 und höher  #HA #High-Avaliable #Clustering emöglicht. Eine tolle Sache, wenn alle Voraussetzngen erfüllt sind und der eine oder andere Proxmox Host-Betreiber wird es ausprobieren wollen und einen Cluster zufügen und eine oder mehrere #Nodes additional zufügen – und dann kommt das böse böse Erwachen, wenn nämlich Multicast-Network an einer Stelle nicht unterstützt wird!

Die Hosts haben sich dann bis zu einem Teil mit einander verbunden, eine Fehlermeldung kommt: #corosync nicht läuft und es gibt keine Chance mehr vor und zu rück – die „Kisten“ sind verfahren!

Auf dem ersten Host läuft noch alles, man kann sogar mit dem Webinterface den anderen Host (Cluster) sehen und auch anklicken – und nichts geht mehr – ein Connecten ist nicht möglich.

Auf dem zweiten Host kann das Webinterface nicht gestartet werden, denn der Apache2 startet auf dem Host nicht. Grund sind Zertifikate, die nicht angelegt wurden, aufgrund nicht vorhandener corosync – Verbindung. Die kann man auch nicht in den Berech von dem anderen Host reinkopieren, denn das /etc/pve – Verzeichnis kann nicht mehr beschrieben werden!
Die Zertifikatsdateien können in anderen Verzeichnissen angelegt werden (mal nur testweise), dann wird aber beim Verbinden vom anderen Host, eine gleiche Key-Datei benötigt, die auf dem Problemhost fehlt und auch dort nicht im /etc/pve angelegt werden kann.

Nun gut, was man normalerweise eingestellt hat, kann man ja zurück stellen – doch weit gefehlt:

Beim Zurückstellen mit dem Befehl: pvecm delnode Hostname
kommt die Fehlermeldung, daß corosync nicht läuft und daher ein
delnode nicht möglich ist! Auch -force und -silent bringen hier nichts.

Dann findet sich plötzlich die Möglichkeit, die Zertifikate neu zu erzeugen, auch mit -force und -silent – nur werden die Zertikate definitiv nicht angelegt!

Nirgendwo im Internet unter stundenlangem Suchen, findet man eine manuelle Möglichkeit, die Nodes von einander manuell zu trennen oder den Fehler zu beheben!

Wer sich darauf verlassen hat, daß hier Proxmox datenkonsistent gearbeitet hätte, der ist nun verlassen. Wir haben dann 2 Test-Container erst mal schnell nach langem Suchen, komplett neu aufgespielt! Was wäre passiert, wenn ein Hoster, dies mit vollen Container gemacht hätte? Mehrere Stunden und Tage Ausfall für Umkopieren etc. wären die Folge gewesen.

 

 

 

Schnelle Migration von Proxmox 1.9 auf Proxmox 2.0

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