Server migriert – OMFG!

Nachdem die Trockenübungen abgeschlossen waren, bin ich mit meinem Server nun auf das neue System umgestiegen. Und musste unerfreuliche „Risiken und Nebenwirkungen“ feststellen. Die HHVM ist im Einsatz nicht unbedingt so stabil, wie auf der Testmaschine. Die letzten 12 Stunden? Ein Höllenritt! Aber ein sehr lehrreicher…

Den Server umziehen ist eigentlich eine einfache Sache. Alles von Maschine A einpacken, auf Maschine B entpacken, DNS umstellen, fertig.
Den Server migrieren hingegen bereitet mitunter Kopfschmerzen. Beim Migrieren ist das System auf der Maschine B anders als auf A. Kein Copy / Paste im herkömmlichen Sinn. Und bei dieser Migration hat sich, verglichen mit der alten Maschine, so ziemlich alles geändert, was sich ändern lässt.

Nun ist es nicht so, dass ich das nicht ausgiebig auf diversen Test-Rechnern vorher ausprobiert hätte. Leider lässt sich „die freie Wildbahn“ halt nur sehr unzureichend simulieren. Und synthetische Last-Tests haben wohl so gar nichts mit ‚echter‘ Last zu tun, die sich der Server dann später einfängt.

In ein paar Stunden waren die Internet-Seiten migriert. Configs neu angelegt, Datenbank erstellt, Daten übertragen, System hochgefahren, läuft. Testen – läuft. Bett gehen.

Die böse Überraschung folgte dann, als der nächste Morgen graute…

Einen „Bad Gateway“ hab isch!

Fahre meinen Rechner hoch, freue mich noch, dass die Migration doch recht vernünftig hingehauen hat, bis ich dann eine der Seiten aufgemacht habe. Aufmachen wollte, besser gesagt, denn ich wurde nicht von der Seite, sondern von einem „502 – Bad Gateway“ Error begrüßt.

Herzstillstand. Bohrende Kopfschmerzen. Magenkrämpfe. Fühlt sich an wie echte Liebe…

© Warner Bros.

Also, VeraCrypt hochfahren, Image mounten, SSH starten, Serververbindung herstellen, einloggen.

Error-Logs ansehen. Nicht viel erhellendes.

Die Prozesse ansehen… Aha, die HHVM ist weg. Cool. Nicht cool! WTF?!
Also einen service hhvm start gemacht. HHVM kommt hoch. Läuft.

Reload im Browser – Webseite da. Na immerhin…
Erleichterung macht sich breit!

Aber warum ist die HHVM weggebrochen? Keine Ahnung. Log schreibt zwar was, aber da wird keiner schlau draus. Also gegoogelt. Nicht viel erfreuliches. Aber einige Anleitungen mit diversen WorkArounds für dieses Problem. Jetzt weiß ich auch, warum es DIE HHVM heißt und nicht DER.

HHVM – die Zicke!

Der „Rest“ der Maschine läuft noch. Wir müssen also „nur“ die HHVM dazu bewegen, ihre Zickerei sein zu lassen. (sigh!)

Dazu gibt es im Netz zwei Ansätze, die ineinander greifen:

  • Einen Watcher installieren, der die HHVM tritt, wenn sie zickt.
  • Einen Notfall-PHP-Interpreter installieren, der PHP so lange ausliefert, bis der Watcher die HHVM aufmöbelt.

Wäre wiederum der Wahnsinn, wenn es für den Notfall-PHP-Interpreter EINE Lösung gäbe. Nein, es gibt ZWEI. Und wie bei 50/50 Sachen üblich, verhau ich einiges an Zeit mit dem falschen Ansatz. Denn es ist Tor Nummer Zwei, nicht Tor Nummer Eins, das funktioniert.

Glücklicherweise hat mir ein guter Freund just am Vortag vom Weihnachtsmarkt eine Zuckerstange mitgebracht. Die habe ich im Laufe der Server-Operation dann mit zittriger Hand verbraucht, sonst wäre ich wohl ins Koma gefallen.

Mist, elender.

Aber hey, die HHVM war dann immer noch nicht fertig mit mir: Während der Installation diverser Sachen ist mir doch glatt der Repo-Cache auf die Füße gefallen. Den kann man ausschalten. Aber das hat eine geschlagene Stunde gedauert, bis ich gefunden habe, wie und womit.

An dieser Stelle wäre ich für eine vernünftige Dokumentation dankbar, liebes HHVM-Team.

In Retrospekt wäre der Ansatz rein über die „php5-fpm“ wohl nervenschonender gewesen. Wieder was gelernt.
Aber wer Sportwagen fahren will… Der muss halt mit dessen Zickereien leben.

Egal! Mit der Lösung „Notfall-PHP + Watcher“ haben wir beides: Einen Rennwagen, so lange die HHVM läuft. Und ein Sicherheitsnetz, wenn die HHVM in der „Werkstatt“ steht. Der Betrieb geht nahtlos weiter. Die Besucher merken nichts davon, wenn die Seite von dem Notfall-PHP-Interpreter ausgeliefert wird. Bis jetzt klappt diese Lösung einwandfrei.

Aber wo ist der Pferdefuß?!

Ja, fast vergessen. Natürlich gibt es hier nichts geschenkt. Diese Lösung bezahlen wir durch eine kompliziertere Konfiguration. Für jeden vHOST müssen wir nun eine zusätzliche Config-Datei für den Upstream anlegen.

Ende vom Lied:

Ich habe jetzt noch eine ganze Menge Dinge, die ich schreiben muss:

  • Piwik
  • WordPress
  • fail2ban
  • HHVM mit „Failsafe“

Ab Neujahr trete ich mit meiner primären Arbeit etwas kürzer.

Nachdem ich eine beachtliche ToDo abgearbeitet haben werde, die sich im Laufe der Zeit angesammelt hat, nehme ich mir die Zeit, diese Artikel vernünftig fertig zu schreiben. Das sollte dann so weit alles komplettieren und unser Server ist dann einsatzbereit. So die Theorie :)

Ich freue mich schon und brenne darauf, diese Kapitel abzuschließen.
Bis dahin wünsche ich euch schöne Weihnachten und einen „guten Rutsch“!

Haftungsausschluss!

Bitte lies Dir den Disclaimer durch, bevor Du eine Anleitung umsetzt...

Anzeige *

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.