Dirks Logbuch

Das ist ein Talk, den mein ehemaliger Arbeitskollege Ramon und ich vor knapp sechs Jahren auf der deutschen Ubucon gehalten haben. Das Prinzip, das dem zu Grund liegt, hat mir auch am vergangenen Wochenende den Hintern gerettet.

Ich werde mal ein Update des Vortrags machen und die neuen Skripte einbauen (die auch unter CentOS wirken).

Zu den Lehren, die ich aus dem Serverausfall gezogen habe, gehören die folgenden.

Wenn das RAID nicht fertig synchronisiert ist, brauche ich mich nicht mehr darum kümmern, die Daten sind weg. Die gesparte Zeit investiere ich besser in eine gute Planung des Restores, die ich eh machen muss.

Die Filekopie einer laufenden MariaDB-Datenbank-Instanz ist immer noch nicht möglich, auch wenn es anfänglich so aussieht. Die interne mysql-Datenbank und die Konfigurationsdatenbank meines Mailservers waren nicht korrupt, der Rest schon.

Einen Rettungsversuch der InnoDB-Datenbanken und MyISAM-Datenbanken kann ich mittels innodb_force_recovery = 1 bzw. myisam-recover = backup,force in den Konfigurationsdateien vornehmen. Wenn das nicht hilft, sollte ich die Optionen auch wieder entfernen, weil sonst der Import der Datenbanken aus dem "richtigen Backup" nicht klappt. Die Fehlermeldung beim Import ist übrigens "Mysql error “#1030 - Got error -1 from storage engine”, das könnte auch sinnvoller benamt werden.

Es ist sinnlos, die Kommunikation des Mailproviders über die Mailadresse zu führen, die auf dem ausgefallenen Server gehostet wird, vorher umstellen!

Sehr lohnenswert ist es ein Chattool zu nutzen, dass unabhängig von der eigenen Infrastruktur ist, dazu habe ich jetzt Slack eingerichtet, ich empfehle allen, die Dienste bei mir nutzen, sich bei mir per Mail zu melden. Künftig werde ich nicht mehr auf andere Anfragen reagieren.

TL;DR: Mein Server ist ausgefallen. Wenn Ihr uns am Samstag Mails geschickt habt, schickt sie bitte noch einmal. Das Backup war leider einige Stunden alt.

Am vergangenen Samstag Morgen hat sich eine von zwei Festplatten aus dem Spiegel verabschiedet. Diese wurde von Hetzner-Mitarbeitern innerhalb einer viertel Stunde ausgetauscht. Das ist echt klasse. Die Dokumentation im erstklassigen Wiki ist ebenfalls sehr hilfreich, insbesondere Festplattentausch im Software-RAID und Seriennummern von Festplatten und Hinweise zu defekten Festplatten.

Glücklicherweise habe ich noch ein schnelles Komplett-Backup per rsync gemacht - note to myself: das nächste Mal vorher die Datenbank runterfahren - so dass zumindest alle Mails noch da waren.

Am frühen Abend, gegen 17:30 Uhr - die Synchronisation des Datendateisystems im RAIDs ist bei 95% (30 Minutes left) - raucht die primäre Platte auch ab und hinterlässt nur noch Datenmüll.

An der Stelle sei erwähnt, dass es nicht hilfreich ist, wenn mir Leute sagen, dass sie deswegen RAID-6 einsetzen. Das würde ich auch gerne, geht bei diesen gemieteten Servern aber nicht.

BTW: Für zukünftige Probleme habe ich eine Slack-Community, wer darauf zugreifen möchte, schicke mir bitte eine Mail an dirk@deimeke.net.

Natzürlich hatte ich ein Backup, warum die Recovery so lange gedauert hat, schreibe ich in einem anderen Artikel.

Die Migration unseres kleinen Internet-Universums auf die neuen root-Server verlief erfolgreich aber leider nicht genau so, wie Ramon und ich uns das vorgestellt haben. Es ist schon interessant zu sehen, wie viel man vergessen kann, wenn man nicht täglich damit umgeht. Insbesondere die Webkonfiguration hat uns unerwarteterweise vor ein paar mittlerweile gelöste Probleme gestellt.

Alle Software, mit Ausnahme von Jabber, läuft jetzt auf den neuen Trümmern.

Es ist immer gut, vernünftig zu planen und das hiess, die Migration nicht am letzten verfügbaren Tag zu machen, weil ja etwas dazwischen kommen kann. Doof nur, dass ich in der letzten Woche Bereitschaft - hier sagt man Pikett - hatte und ich am Wochenende arbeiten musste. Aber Ramon hat das mit einer Menge Einsatz und meinem sporadischen dazwischen funken hinbekommen. Danke!

Der alte Server läuft nur noch heute ...

Ach ja, das Thema Migration werden wir nebenan bei Adminstories noch näher beleuchten.

... und zweitens als man denkt.

Es gibt Tage, da fühle ich mich wie ein absoluter Anfänger, der angesprochene Umzug wurde begonnen, aber wir sind am Wochenende nicht fertig geworden. Warum? Weil Tätigkeiten, die man nicht regelmässig ausführt, die Gehirnwindungen übermässig beanspruchen. Ziemlich doof so etwas.

Die Webseiten sind migriert und laufen bereits auf dem neuen System, die Mailmigration ist zu drei Vierteln fertig und muss noch abgeschlossen werden. Eine ganze Reihe an Aufräumarbeiten steht auch noch an ...

Na, ja, es gab keine Downzeit und das ist ja schon einmal etwas ...

Apropos: Man kann gar nicht oft genug, die Mail-Tutorials von workaround.org loben. Lob!

Ramon und ich werden am kommenden Wochenende, 19. und 20. Februar, unseren root-Server umziehen auf ein neues Serverdoppel. Ich vermute, dass Ihr davon nichts mitbekommen werdet, falls es aber hakt, wisst Ihr warum.

Details über den Umzug und warum wir uns wie entschieden haben, werdet Ihr drüben bei den Adminstories nachlesen können.

Jetzt habe ich doch tatsächlich einen vServer geschenkt bekommen. Die Frage war, was ich damit mache und ich habe mir überlegt, damit freies Monitoring anzubieten. Zum Einsatz kommen soll die Nagios-Abspaltung namens Icinga (damit ich auch etwas dabei lerne).

Über das Design muss ich mir noch ein paar Gedanken machen.

Um abschätzen zu können, wie viele Leute solch ein Angebot gebrauchen können und benutzen würden, bitte ich um einen kurzen Kommentar. Bitte auch dazu schreiben, welche Dienste überwacht werden sollen.

Anmerkung: Ich kenne den Dienstleister nicht und kann (noch) nichts über die Zuverlässigkeit sagen. Wer eine Monitoring-Lösung für sein Unternehmen sucht, sollte nicht auf den von mir angebotenen freiwilligen Dienst setzen.

Unser root-Server macht leider weiterhin Probleme. Seit letzten Donnerstag verabschiedet er sich sang- und klanglos (ohne irgendeine Meldung im Log). Meiner Meinung nach liegt das an Überhitzung, vermutlich hat sich ein oder haben sich mehrere Lüfter verabschiedet. Ein anderer Hardware-Schaden wäre auch denkbar, aber relativ unwahrscheinlich, weil es dann immer noch Meldungen in die System-Logdateien schaffen.

Vor zwei Monaten hatten wir das gleiche schon einmal, ein achtstündiger Hardwaretest hatte allerdings nichts ergeben. Ich bin gespannt, wie sich der Anbieter jetzt dazu stellt. So kann es in keinem Fall weitergehen.

Wir haben kein Glück mit unserem root-Server. Nach dem Ausfall im Januar haben wir momentan nach einer Aufrüstung auf 4 GB (von 2 GB) Probleme mit dem Speicher. Die Kernel-Meldungen lassen keinen anderen Schluss zu.

Aus diesem Grund wird es heute einen intensiven Speicher-Test geben und der Server wird zwischen 10:15 Uhr und voraussichtlich 12:15 Uhr nicht verfügbar sein.

Update: Speicherfehler wurde gefunden und der Speicher wurde komplett ausgetauscht.

Gestern Abend habe ich das Zertifikat unserer Verwaltungsdomain auf dem root-Server auf ein CAcert-Zertifikat umgestellt. Daher kann es sein, dass Ihr einen "Zertifikat-Alarm" bekommt, wenn Ihr auf das Blog hier zugreift, da das Tool, dass ich zur Zugriffs-Analyse benutze (Piwik) in der Verwaltungsdomain liegt und diese ausschliesslich per https erreichbar ist.

Um diesen Alarm dauerhaft abzustellen, gibt es zwei Möglichkeiten, das Zertifikat einmalig zu akzeptieren oder generell allen von CAcert signierten Zertifikaten zu vertrauen. Für das zweite müsst Ihr die CAcert-Webseite mit den root-Zertifikaten besuchen, dort das Intermediate Certificate (PEM Format) (Level 3) auswählen und akzeptieren, das Level 1 Root Certificate (PEM Format) könnt Ihr zusätzlich auch akzeptieren, das ist aber für diese Webseite hier nicht nötig.

So, nach einem kritischen Dateisystemfehler und einem Ausfall von knapp 29 Stunden sind wir wieder da. Danke an Hampa und Ramon für die Zusammenarbeit. Und ein grosses Dankeschön an Ute, auf deren Server wir temporär 140 GB ablegen durften.

Wir haben einiges für unser Backup und Restore Szenario gelernt, aber glücklicherweise haben wir die Daten alle zurückbekommen. Puh!

Alle Mails, die uns zwischen 03:00 Uhr und 09:00 Uhr am Samstag, dem 30. Januar gesendet wurden, sind leider verloren, solltet eine Nachricht von Euch dabei gewesen sein, sendet sie bitte noch einmal.

Gleiches gilt für die Artikel und Kommentare in einem unserer gehosteten Blogs und Wikis. Alles, aus dem Zeitfenster von 03:00-09:00 Uhr am Samstag, dem 30. Januar, ist leider weg.

Ach ja, wenn Euch auffallen sollte, das etwas nicht so läuft wie es sollte, meldet Euch bitte.

So, ich habe mal ein wenig Datenbanktuning betrieben. Das Blog sollte jetzt deutlich schneller reagieren. Eine wirklich grosse Hilfe ist das MySQL Performance Tuning Primer Script von Sundry einem Mitarbeiter von MySQL.

Die meisten Variablen können Online mittels "set global variablenname=wert" gesetzt werden, wobei Wert auch ein Ausdruck wie "32*1024" sein kann.

Die dauerhaften Änderungen an den Variablen gehören bei Ubuntu und Debian in das Verzeichnis /etc/mysql/conf.d (man muss nur in den seltensten Fällen Original-Konfigurationsdateien verändern). ACHTUNG: Dort funktionieren die Ausdrücke nicht, dort müssen Werte gesetzt werden. (Macht nicht den gleichen Fehler wie ich ...)

So, die Migration des Servers ist fast abgeschlossen, jetzt sind nur noch Kleinarbeiten zu leisten.

Hat irgendwer Unterbrechungen mitbekommen?

Wir befinden uns gerade mitten in der Migration von einem root-Server auf einen leistungsfähigeren (für das gleiche Geld). Warum artet solche Arbeit eigentlich immer in Fleissarbeit aus?

Grmpf!

Beginnen mit gestern Abend hatten wir hier auf dem Server eine DDOS (Distributed Denial of Service) Attacke. Ich werde mich mal in die Logdateien hängen und schauen wie ich das vermeiden kann.