Aktuelles » Totalausfall

Der Server Karl ist ausgefallen

So fing es an:

Am Dienstag fand ich folgende Nachricht im Posteingang:

Fail event on /dev/md2:karl
This is an automatically generated mail message from mdadm
running on karl

A Fail event had been detected on md device /dev/md2.

It could be related to component device /dev/sda3.

Faithfully yours, etc.

Analyse

Mein Freund Karl, von Beruf Webserver, penetriert mich nicht mit sinnlosen Mails. Grund genug, sich um den Fall zu kümmern. Was war geschehen?

Das Paket mdadm ist ein Werkzeug zum Verwalten von Multi-Disk-Arrays unter Linux, in meinem Falle Debian, und das Multi-Disk-Array besteht in diesem Falle aus 2 Festplatten in RAID Level 1, eine Platte ist also eine exakte Kopie der anderen, und diese Kopie wird laufend aktuell gehalten.

Fällt nun eine Platte aus, wird sie aus dem Verbund ausgehängt, die Maschine läuft weiter als sei nichts geschehen. Dennoch besteht natürlich Handlungsbedarf, denn wenn die zweite Platte ausfällt ist Feierabend.

Ich habe also die nötigen Vorbereitungen zum Austausch der Platte getroffen, innerhalb einer halben Stunde war sie getauscht. Nun legte ich die Partitionen wieder an, hängte die neue Platte in den Verbund und startete die Synchronisation. So weit, so gut. Der Server lief wieder, die ganze Aktion dauerte keine Stunde.

Panik?

Am frühen Nachmittag schrieb Karl mir erneut, die Synchronisation war fehlgeschlagen. Die Suche nach der Ursache ergab ein erschreckendes Ergebnis: Die zweite Platte lief zwar noch, hatte aber einzelne Fehler.

Kein Grund zur Panik, denn ich verfüge über weitere Sicherungen. Allerdings hat das Wiederherstellen aus Sicherungen einige Haken:

Da ich ein (fehlerhaft) funktionierendes und aktuelles System vorliegen hatte, musste ich diesen Weg also nicht zwangsläufig gehen.

Wiederherstellung

Die Situation erlaubt verschiedene Optionen, einige kann ich parallel angehen. Den Ansatz über die regulären Backups verwerfe ich zunächst, weil gute Chancen bestehen, den letzten Stand wieder herzustellen.

Also starte ich das Rescue-System. Dabei handelt es sich um eine vorgefertigte Boot-Instanz, die mir die wesentlichen Werkzeuge zur Verfügung stellt. Ich kann Karls fehlerhafte Platte und die Reserve-Platte einhängen.

Ich kopiere also den Inhalt der fehlerhaften Partition auf die Reserve-Platte und lasse dazu ein Protokoll schreiben. Das Protokoll erlaubt mir, hinterher einzelne Dateien auszumachen, die auf Grund des Fehlers nicht kopiert werden können. Diese Dateien kann ich dann ggfls. aus der regulären Sicherung wieder herstellen.

Bis zum Abend scheint dies Strategie perfekt. Über 2/3 des Systems sind kopiert, der Vorgang läuft. Ab ca. 23:00 wird die Übertragung langsamer, bis sie fast ganz zum Stillstand kommt, ab ca. 1:00 geht es wieder schneller. Es ist abzusehen, dass die Geschichte noch einige Stunden läuft, also lege ich mich zur Ruhe.

Am Mittwoch morgen schaue ich mir den Fortschritt an und bin wenig begeistert. Richtig entgeistert bin ich ein paar Minuten später. Schlagartig sitze ich im Dunkeln, der Rechner ist aus. Muss den wirklich immer alle Unbill auf einmal kommen? Stromausfall. Nein, nicht nur eine Sicherung, der ganze Ort hat keinen Strom. Ich mache aus der Not eine Tugend und frühstücke erst mal. Kaffee dazu liefert die Camping-Ausrüstung. Es geht doch nichts über mehrfache Redundanz, und zur Not stünde auch noch ein Stromaggregat in der Garage. Soweit muss ich dann doch nicht gehen, zum letzten Bissen und der zweiten Tasse Kaffee geht das Licht an.

Also frisch gestärkt die Lage betrachtet: Immerhin ist eine wesentliche VE nahezu vollständig auf der Reserveplatte angekommen. Was fehlt ist nahezu vernachlässigbar und im Backup vorhanden. Ich packe also Marineparts ein und schicke das Paket zu Adenauer, meinem zweiten Host. Karl kopiert inzwischen weiter, und ich gehe zu Adenauer und packe das Paket aus. Um die VE in Betrieb zu nehmen, brauche ich neben der VE selbst natürlich die Grundlage. Die besteht ohnehin, ist also kein Problem. Dann brauche ich nur noch die Konfigurationsdatei und eine freie IP-Adresse auf dem Zielsystem. Die IP-Adresse habe ich in Reserve, und die Konfiguration in der Sicherung.

Nun muss in der Konfiguration die IP-Adresse geändert werden, dann kann ich starten. Das geht auch sofort. Gut so, denn inzwischen habe ich einen Erfolg nötig. Nun muß die Verwaltungssoftware geändert werden. Das Webinterface geht natürlich nicht weil es noch nicht über die geänderte IP-Adresse informiert ist. Also gehei ich über die Datenbank. Außerdem muß ich dafür sorgen, dass mein lokaler Rechner für die benötigten Verbindungen nicht den DNS nach der IP-Adresse fragt, ich trage also diese Adressen in meiner lokalen Datei "hosts" ein.

Inzwischen ist es früher Nachmittag. Ich informiere den Kunden (auch über den hosts-Trick), er schaut sich die Sache an und ist's zufrieden. Also aktualisiere ich die DNS-Server.

Parallel hat das Rescue-System tapfer weiter kopiert, ist aber immer noch nicht ganz durch. Ich schaue mir die Ergebnisse an. Die Kundensysteme sind alle durch, auch meine eigene Seite ist betroffen. Aber der Kopiervorgang ist wieder furchtbar langsam geworden, wir sind in einem Bereich des Betriebssystems.

Wieder überlege ich, wie ich schnellstmöglich zum Ziel komme. Der Kopiervorgang läuft nun schon seit rund 24 Stunden, das Ende kaum absehbar. Die wesentlichen Daten sind auf aktuellstem Stand in Kopie vorhanden, ich konnte alle VE wiederherstellen.

Ich entschließe mich zu einer Neuinstallation aus dem Rescue-System heraus. Die ist erstaunlich schnell durch. Was bleibt ist die Installation des modifizierten Kernels für die virtuellen Maschinen, auch das geht schnell. Die Netzwerkkonfiguration dafür (/etc/sysctl.conf) hole ich mir von Adenauer, kopiere noch die VE und die zugehörigen Konfigurationsdateien von der Reserveplatte und starte sie.

Läuft

Runde 36 Stunden nach der Mail bin ich mit allen Systemen wieder online. Datenverluste: Keine.

Was bleibt zu tun?

 

 

 

Das ist der Trick, mit dem auch Zensursula von der Leyens Kinderpornosperre umgangen werden kann

 

Powered by Etomite CMS.