Und ich lächelte und war froh, und es kam schlimmer!

Eigentlich wollte ich einen vorbereiteten Beitrag fertig stellen, in dem es um die – sagen wir – leicht verunfallte Zustellung eines wichtigen Pakets durch DHL ging. Diesen Beitrag veröffentliche ich nun doch (noch) nicht. Stattdessen ein schreibe ich eine Zusammenfassung über die Verkettung von Ereignissen, die mich – in diesem Fall als Administrator – (beinahe) zur Verzweiflung gebracht haben.

Alles der Reihe nach:

Sonntag, 28. Februar

Nachdem ich feststellen musste, dass in einem meiner Daten-Server – ich nenne ihn hier NAS1 – der RAID-Controller durch Hardware-Defekt ausgefallen war, bestellte ich noch am gleichen Abend einen neuen. Aus Mangel an angebotenen, schnelleren Zahlungsmethoden, entschied ich mich für Vorkasse und überwies sogleich. Da es sich um einen Sonntag handelte, hoffte ich auf Gutschrift beim Versender am Montag, ganz sicher aber am Dienstag und dass dieser den Controller dann umgehend auf den Weg bringen würde.

Bis hier kein Grund zur Besorgnis. Schließlich ist das System durch einen zweiten Daten-Server (NAS2) , der die Daten mit NAS1 bis zu seiner Abschaltung in Echtzeit gespiegelt hat, abgesichert. Die Daten waren „up to date“, als NAS2 übernahm. Um ein Maximum an Sicherheit zu erhalten, liegen die Daten auf beiden Servern in einem RAID6 aus 5 Platten mit zusätzlich je einer Hot-Spare. Und um ganz sicher zu gehen, findet jede Nacht ein Backup aller Nutzer-Daten, SQL-Dumps aller Datenbanken und System-Einstellungen der virtualisierten Server auf File-Basis, auf einem ebenfalls auf beiden Servern dafür eingerichteten, gespiegelten RAID1 statt.

Dienstag, 01. März

Bis zum Abend habe ich keine Versandmitteilung oder eine Bestätigung meiner Zahlung erhalten. Bis dahin war ich noch recht gelassen und nahm mir vor, am nächsten Tag anzurufen. Schließlich ist es doch beruhigender, wenn ein Ersatzsystem zur Verfügung steht.

Ich habe für alle Systeme automatische Überwachung eingerichtet. Diese informieren mich, sobald etwas aus der Norm läuft – dachte ich. Trotzdem habe ich mich auf dem NAS2 eingeloggt um einfach mal zu kontrollieren, ob alles rund läuft. Und das tat es nicht!

JETZT wurde ich leicht nervös!

Mittwoch, 02. März

Ich rief die Firma an, bei der ich den Controller (ebenfalls als Firma) bestellt habe. Der freundliche Herr am anderen Ende, dem ich erklärt habe, dass ich den Controller dringend benötige, warf einen Blick in deren System und teilte mir mit, dass die Zahlung verbucht ist und der Controller noch am selben Tag auf den Weg gebracht würde. Kennt Ihr das, wenn man hören kann, dass sich jemand ertappt fühlt? Ich habe ungefähr das gehört:

Oh verdammt! Wir haben den total vergessen! Jetzt aber schnell fertig machen!

Ich tat so, als ob ich das so verstand, wie er es sprach. Ich sagte noch, dass wenn es heute noch zu DHL geht, es ja wahrscheinlich schon morgen (Donnerstag) oder spätestens Freitag da sein würde. Er antwortete so etwas wie

Naja, DHL ist ja auch manchmal eine Sache für sich.

Mir war zu diesem Zeitpunkt noch nicht klar, wie harmlos sich das im Vergleich zu dem anhörte, was mit meiner Lieferung tatsächlich bei DHL passieren sollte. Über den genauen Verlauf gibt es noch den o. g. Beitrag. Zusammenfassend sei hier nur der 9. März als Lieferdatum genannt und ein Bild präsentiert, das den Zustand des Pakets erahnen lässt:

In der Zwischenzeit hatte ich noch einen kompletten Satz Platten bestellt, die – wie sonst von DHL gewohnt – ohne sichtbare Beschädigung des Pakets und von heute auf morgen geliefert wurden.

Mittwoch, 09. März

NAS1 hatte ich bereits aus dem Rechenzentrum abgeholt und hier, zuhause für den Umbau vorbereitet. Die acht Festplatten waren bereits getauscht und steckten in ihren Laden. Nachdem ich den Zustand der Lieferung penibel und hochauflösend dokumentiert habe, war ich zumindest etwas entspannter, als ich sehen konnte, dass die Kartons von Controller und BBU im inneren des Pakets offenbar keiner mechanischen Gewalt ausgesetzt waren. Da ich mich durch die Meldungen auf NAS2 leicht gehetzt fühlte, konnte ich keine weitere Verzögerung durch einen „Umtausch auf Verdacht“ riskieren. Ich baute Controller und BBU ein, verkabelte und startete den Server. Der Controller meldete sich und ich war erleichtert. Anschließend habe ich die RAIDs konfiguriert und den Server für die Initialisierung in Ruhe gelassen.

Donnerstag, 10. März

Installation der Treiber und Software, Partitionierung der Volumes und um ganz, ganz sicher zu gehen auch noch einen ordentlichen Stresstest gestartet um Platten, Controller und nebenbei auch den Server auf Herz und Nieren zu prüfen, bevor ich ihn zurück ins Rechenzentrum bringe. Kurz bevor ich mich auf den Weg machen wollte und noch einmal alles kontrollierte, fiel mir auf, dass ich mich bei der Erstellung der RAIDs offensichtlich vertippt habe. Ein RAID war zu klein, das hätte mit der Spiegelung nicht gepasst. Also nochmal von vorn und über Nacht neu initialisieren lassen.

Freitag, 11. März

Am Mittag war das RAID fertig. Kurz danach die Partitionierung und noch ein kurzer Stresstest. Am Nachmittag ging es nach Düsseldorf, wo das Monster wieder seinen Platz im Rack eingenommen hat. Ich habe den Server gewogen. Er wiegt knapp 20 Kilo und ist damit etwas leichter, als meine kleine Tochter. Meine Tochter fühlt sich aber irgendwie leichter an, wenn ich sie auf dem Arm habe. Ich schweife ab…

Als der Server fertig verkabelt war und eingeschaltet wurde, setzte ich mich an den Arbeits-PC, der für solche Arbeiten im Rechenzentrum zur Verfügung steht und wollte mich einloggen. Ich bekam keinen Login aber Blutdruck! Also nutzte ich die IPMI-Konsole und sah, dass der Controller die angeschlossenen Platten aufgelistet hatte und dort offensichtlich hängen geblieben ist. Also zurück zum Rack, den Server abgeschaltet und jede einzelne Platte einmal raus und wieder rein, den Server wieder eingeschaltet und schnell zur offenen IPMI-Konsole gelaufen. Diesmal verlief der Boot-Vorgang völlig normal.

Die Wiederherstellung des Datenspiegels sollte die nächste Herausforderung sein. Sie kam nämlich nicht in Gang! Solange, bis ich endlich mal in das System-Log des Servers sah. Dort konnte ich sehen, dass die Spiegelung verweigert wurde, weil die Partition des Zielservers (NAS1) zu klein war. Wieviel kleiner stand da nicht und laut parted sollten die Partitionen auf beiden Servern exakt gleich groß sein. Da ich die Partitionen immer etwas kleiner mache, als eine Platte (oder in diesem Fall, das logische Laufwerk des RAID6) zur Verfügung stellt, weil eben genau so etwas passieren kann, habe ich also neu partitioniert und großzügig ein Gigabyte draufgelegt. Damit konnte ich die Spiegelung dann auch starten.

Wieder Zuhause habe ich den Status kontrolliert. Es sollte noch etwa 9 Stunden dauern, also Zeit sich auszuschlafen.

Samstag, 12. März

Meine Tochter weckte mich um 7:00 Uhr und – im Gegensatz zu anderen Samstagen und Sonntagen – habe ich mich auch wecken lassen. Tochter bekam einen Kakao, ich einen Kaffee, Tochter KiKa und ich Konsole. Status: noch etwa eine halbe Stunde!

Endlich! Irgendwann zwischen 8:30 und 9:00 Uhr war der Spiegel auf beiden Seiten wieder „up to date“. Jetzt war der richtige Zeitpunkt NAS2 von seinen Aufgaben zu befreien und ich initiierte – wie ich es schon etliche Male zuvor getan habe – ein Failover auf NAS1. Das Logfile bestätigte auf NAS1 die Anforderung der Ressourcen…

BANG!

… NAS2 antwortete nicht mehr! NAS2 muss genau mit der (durch die) Anforderung komplett abgestürzt sein. So etwas ist vorher noch nie passiert! Und so hatte ich auch erstmals mit Problemen zu kämpfen, die ebenfalls vorher nie aufgetreten sind.

Ich hatte schon am Freitag die Dienste heruntergefahren, die nicht zwingend für den Betrieb – oder besser für die Kunden – erforderlich sind, um das RAID auf NAS2 so wenig wie möglich zu belasten. Die Dienste, die zum Zeitpunkt des Servercrash von NAS2 liefen, liefen auch weiter, als NAS1 übernommen hatte. Fast alle!

Drei virtuelle Server waren verschwunden. Zwei ließen sich (zunächst) wieder problemlos starten, ein weiterer meldete Dateisystem-Fehler und verweigerte den Start. Dieser Server war ausgerechnet einer der Kunden-Web-Server.

Alles in mir schreit und will irgendwas zertrümmern! Meine Tochter liest mir etwas vor, ich bleibe cool…

Ich schrieb über mich, dass ich ADSler bin. Ich lasse gerne mal am Wochenende meine Medikamente weg. An diesem Samstag habe ich sie direkt nach dem Aufstehen genommen. Und das war auch gut so, denn sonst wäre ich wirklich total ausgerastet. Und nicht nur bei dieser Gelegenheit; es sollte weitere Gelegenheiten geben, die Fassung zu verlieren!

Das erste was ich tat, war meinen Partner zu informieren, damit er Kundenanrufe entsprechend beantworten konnte. Und dann fing ich an, den Web-Server wieder online zu bringen.

Ich kürze jetzt ab, da ich über die Verfahren der hier folgenden Schritte – schon deshalb um mich selbst daran zu erinnern – ausführliche Anleitungen schreiben werde.

1. Ich habe das Ploop-Image kopiert, damit ich im Falle eines Misserfolgs von vorn anfangen kann.
2. Nachdem das Image kopiert wurde, habe ich es gemountet und einen e2fsck gestartet
3. Als der Prozess beendet war (mit endlos vielen Meldungen), konnte der Server gestartet werden

Zu unserer großen Verwunderung hat in dieser Zeit nur ein einziger Kunde angerufen! Dass die Katastrophe an einem Samstag-Morgen passiert ist, ist wohl der einzig positive Teil der Geschichte.

Nun wollte ich natürlich wissen, ob der Server auch wirklich korrekt arbeitete. Dazu wollte ich in den Admin-Bereich des Hosting-Panels gehen um mir ein paar Domänen zu suchen, die über diesen Server ausgeliefert wurden. Das Panel (der Master-Server) war einer der beiden anderen, die zunächst nicht da waren, sich aber starten ließen.

Ich kam nicht zum Login. Es gab einen Timeout! Also habe ich auf der Konsole versucht den Dienst auf dem Server zu starten. Er ließ sich allerdings nicht starten. Im Log konnte ich sehen, dass es keine Datenbank-Verbindung gab. Ich habe daraufhin auf allen virtuellen Servern, die vom Master abhängig sind, die Dienste gestoppt, damit sich – sollte die Konfigurations-Datenbank fehlerhaft sein – keine Fehler auf die anderen Server replizieren. Dann habe ich das „neue Problem“ geistig zur Seite geschoben und per Konsole auf dem Web-Server nachgesehen, welche Domänen dort eingerichtet sind.

Und es war fast zu erwarten, dass keine Domain abrufbar war. Es kostete mich einige Zeit, bis ich den Apache wieder starten konnte. Mit dem Apache kamen dann auch die Kunden-Webs zurück.

Jetzt musste ich mich um das Konfigurations-Panel kümmern. Auch hier die Zusammenfassung:

1. Feststellen, was genau den MySQL-Server vom Start abhält. In diesem Fall eine (oder mehrere) InnoDB-Datenbanken.
2. Das MySQL-Datenverzeichnis sichern
3. Die InnoDB-Datenbanken reparieren (auch hier folgt eine ausführliche Anleitung)
4. MySQL-Server starten
5. Auf Funktion prüfen.

Zwischenzeitlich was ganz anderes. Ich fing an zu frieren und hatte meine Frau in Verdacht, die Heizung heruntergedreht zu haben. Tatsächlich waren alle Heizungen so eingestellt, wie man es erwarten sollte. Also ein Blick auf die Therme: Rotes Licht! Echt jetzt? Das kann doch nicht wahr sein!

Nach gefühlt 15 Versuchen die Heizung zu starten (An/Aus, Reset) gab ich auf und informierte unseren Heizungs-Meister, stapfte in den Keller und brachte unseren Wohnbereich durch die Vernichtung von 2 x 1500 Steckdosen-Watt auf erträgliche Temperaturen.

Der Konfigurations-Server war wieder online und schien zu funktionieren. Ich habe daraufhin die Konfiguratoins-Logs mit den Einstellungen verglichen und konnte feststellen, dass offensichtlich keine Daten verloren gegangen sind. So startete ich die Clients wieder und probierte ein paar Einstellungen. Alles wurde umgesetzt, wie es sollte.

Bevor ich nun NAS2 – der nach seinem Absturz selbst wieder hochgefahren war – endgültig abschalten wollte, sollte noch eine komplette Datensicherung angestoßen werden. Diese Sicherung würde bis in den Sonntag laufen – wäre der Backup-Server nicht ausgefallen. Das passierte allerdings erst in der Nacht und sollte mich jetzt noch nicht belasten.

Ich stellte fest, dass auf dem reparierten Web-Server ein Verzeichnis regelrecht „geschreddert“ wurde. Da zu diesem Zeitpunkt der Backup-Server noch lief, konnte ich dieses Problem recht einfach durch ein Restore lösen.

Es war inzwischen Abend und ich war fertig. Ich wollte mich gerade noch ein wenig auf die Couch legen, als mein Monitoring mir meldete, dass X-Tausend Mails in einem unserer Mail-Gateways hingen. Das bedeutet, dass mit allerhöchster Wahrscheinlichkeit ein Kundenaccount gehackt wurde und darüber nun fleißig SPAM-Mails versendet werden. Und so war es auch!

Und weil ich nett bin – zumindest glaube ich das – habe ich zuerst versucht den Kunden telefonisch zu erreichen. Erfolglos. Dann habe ich seine Domains auf ein leeres Verzeichnis umgeleitet, damit der eingeschleuste Mailer nicht weiter verwendet werden kann. Schließlich habe ich dem Kunden eine Mail über den Hack und meine Maßnahme geschickt. Ich habe ihm außerdem geschrieben, was für Sicherheits-Probleme ich in seinem Account – oder besser: in seiner WordPress-Installation – festgestellt habe und wie er vorgehen sollte, um seine Seite abgesichert wieder online zu bringen.

Dann ging ich ins Bett. Vorher habe ich aber noch einmal auf den Power-Knopf unserer Therme gedrückt und ich konnte schon anhand der Geräusche hören, dass sie diesmal starten wollte – und sie tat es! Seit dem läuft die Heizung wieder ohne Probleme. Ich denke nicht darüber nach…

Sonntag, 13. März

Ich ließ mich wieder um 07:00 Uhr von der kleinen Prinzessin wecken und wir wiederholten die Prozedur vom Vortag.

Dann kontrollierte ich den Status vom Backup-Server und stellte fest, dass kein Backup aktiv war. Dafür waren einige Backups als fehlerhaft beendet markiert. Alle zur gleichen Zeit! Ich fühlte es in mir brodeln!

Beim Versuch einen Backup-Job manuell zu starten, wurde der Befehl positiv quittiert. Tatsächlich aber fand kein Backup statt. Einfacher Fix: Reboot des Backup-Servers. Ergebnis: Dateisystem-Fehler! Der Server startet nicht mehr!

Ich habe kurzerhand entschieden, ein e2fsck über das Image laufen zu lassen. Sofort! Ohne dies vorher zu kopieren – das hätte den ganzen Tag gedauert. Hätte ein e2fsck nicht geholfen, hätte ich einen neuen Backup-Server aufgesetzt und stumpf ein Komplett-Backup angestoßen. Der Filesystem-Check mit Reparatur dauerte fast drei Stunden und der Backup-Server fuhr danach auch wieder hoch. Backup-Jobs ließen sich auch wieder starten. In den Logs kann ich allerdings sehen, dass vereinzelt Fehler im Dateisystem gemeldet werden. Ich habe dies zur Kenntnis genommen und werde – wenn die Nacharbeiten abgeschlossen sind und NAS2 mit neuen Platten mit NAS1 synchronisiert hat – einen neuen Backup-Server aufsetzen.

Wer müde ist macht Fehler!

Diese Erfahrung habe ich schon machen müssen und auf eine Wiederholung kann ich gut verzichten. Ich war müde – total erschöpft! Darum habe ich mir mindestens eine Woche Erholung (Regelarbeit) verordnet und sogleich damit begonnen! Prinzessin wollte einen Film mit mir schauen und wir hatten „Nachts im Museum“ aufgenommen. Also haben wir uns zusammen auf die Couch gekuschelt und den Film gesehen. Es muss so 11 Uhr gewesen sein, als ich einschlief. Geweckt wurde ich um kurz vor 19 Uhr, um Töchterchen ins Bett zu bringen. Anschließend habe ich mit Gattin noch eine wirklich mittelmäßige Serie geguckt und schlief beinahe wieder ein. Ich ging dann früh ins Bett und verschlief heute beinahe. Aber – den Schlaf schien ich gebraucht zu haben, denn heute war ich wieder richtig fit!

Was ich daraus lerne?

Das gleiche wie in all den Jahren zuvor, die ich in diesem Geschäft tätig bin: nämlich, dass es nichts gibt, was es nicht gibt! Egal, wie gut man auf alles vorbereitet zu sein glaubt, es kommt immer wieder etwas neues. Wichtig ist nur eines: Nerven behalten!

Was ich daraus mache?

Es folgt eine Anleitung,

• wie man beschädigte Ploop-Images (openvz) repariert
• wie beschädigte InnoDB-Datenbanken gerettet werden
• wie man einen DRBD-Partner komplett neu aufsetzt

Bis bald,

Oskar