2010-03-10 - Serverausfall Blackpearl

2010-03-10/11 - Serverausfall Blackpearl / Wiki, Forum, WWW etc.

Beschreibung

Am Vormittag des 10.03.2010 kam es gegen 10:30 Uhr auf dem Basissystem, auf dem die Dienste Wiki, Forum, WWW, Mail, Mailinglisten, Blog und Planet liefen, zu Störungen. Erstmaßnahmen blieben aufgrund systemseitiger Probleme erfolglos. Nach einer genaueren Analyse haben wir uns entschlossen, die ohnehin geplanten Migrationen durchzuführen, statt weitere Zeit in die Reparatur eines Systems zu investieren, welches ohnehin in dieser Form nicht mehr weiterbetrieben werden sollte. Beim Stoppen des vServers kam es aufgrund der Probleme, die vermutlich auch den Ausfall verursacht hatten, zu verschiedenen zusätzlichen Störungen, die u.a. dazu führten, dass die Datenbank nicht mehr sauber gestoppt werden konnte und ein Zwangsreboot des kompletten Basisservers notwendig wurde. Dies führte wiederum dazu, dass auf dem neuen Server diverse Streicheleinheiten für die Datenbank nötig waren, um Inkonsistenzen zu vermeiden und alle Änderungen seit dem letzten Backup soweit wie möglich zu retten. Aufgrund der Größe der Datenbank (insbesondere der Wiki-Datenbank, in der sämtliche Revisionen seit Beginn gehalten werden) hat sich das ziemlich in die Länge gezogen. Leider stellte sich dann heraus, dass die Datenbank (also der Inhalt) irreparabel beschädigt war und alle MySQL-Recoverymaßnahmen keine brauchbaren Ergebnisse lieferten bzw. selbst auch abbrachen, so dass wir auf das Backup zurückgreifen mussten. Wir mussten auch feststellen, dass das aktuellste Backup aufgrund der Probleme auf dem System nur einen Bruchteil der regulären Größe aufwies. Das Entschlüsseln, Entpacken und Importieren kostete zusätzliche Zeit. Die Datenbank hat derzeit eine Größe von circa 14 GB. Die Versuche, die Datenbank zu restaurieren und schließlich das Einspielen des Backups nahmen ca. 70% der Gesamtausfallzeit in Anspruch.

Ursachenforschung

Ursache für den Ausfall ist vermutlich ein Zusammenspiel aus der eingesetzten Technik der Datensynchronisierung (DRBD), Netzwerkstörungen beim Provider, die auf die Lese- und Schreibaktionen der doch relativ großen Datenmenge einen negativen Einfluss hatten und die wiederum durch die inzwischen als extrem fehleranfällig identifizierten vServer (mehrere virtuelle Server auf einem "richtigen" Server) nicht nur das Wiki-System, sondern gleich den ganzen Server zusammenbrechen liessen.

Aktueller Status

• Der Mailserver, DNS, Wiki, Webserver, Datenbank und Forum sind jetzt von Vserver auf KVM (andere Virtualisierungslösung für Linux) migriert worden. Es sind jetzt noch einige Nacharbeiten notwendig. Dann werden wir in einer Niedriglastzeit einen Failovertest durchführen. (Für Nichttechniker: Dienst auf einem Server stoppen und auf einem anderen System starten)
• Die Geschwindigkeit des Wikis konnte deutlich verbessert werden.

Weitere Maßnahmen

• Monitoring der Backupgröße (Alarmierung, sobald ein bestimmter Wert unterschritten wird)
• Zusätzliche Replikation des Datenbanksystems auf ein Slavesystem (Parallelsystem neben dem eigentlichen System)
• Beseitigung verbliebener Altlasten auf Betriebssystem-Ebene
• Softwareupdates auf Anwendungsebene z.B. Wiki
• Erstellen eines detaillierten Notfallplans.

Chronologie der Ereignisse (Vorsicht, Technik!)

Ein paar Definitionen zum besseren Verständnis:

• Bounty, Blackpearl, Revenge: Namen unserer Server
• vServer & KVM: Techniken zur Virtualisierung von Computern (wird von uns aus Sicherheitsgründen eingesetzt und um Anwendungen einfacher zwischen den verschiedenen Servern wechseln zu lassen.)  Virtuelle_Maschine
• Rescue-System: Notfallsystem mit nur den notwendigsten Funktionen
• Change: engl. Änderung
• Sync / DRBD: der automatische Datenabgleich zwischen den Servern
• Basisystem: System unter dem die virtuellen Maschinen laufen (Muttersystem)

1. 10.03.2010, 10:30 Uhr Ausfall der Webauftritte (u.a. Wiki), die auf Blackpearl laufen.
2. vServer hat hohe Last
3. Schwierigkeiten beim Stoppen des vServers
   1. vServer lässt sich nicht normal stoppen (leider bekanntes Verhalten)
   2. Der Sync der Systemplatten macht Ärger
   3. Das Basissystem hat jetzt auch Probleme mit Schreib-/Leseaktionen
   4. Sync reagiert nicht mehr
   5. Stoppen der anderen vServer funktionierte teilweise, jedoch nicht bei der Datenbankinstanz.
   6. Versuche das System noch so weit wie möglich auf Platte schreiben zu lassen
   7. Das Basissystem führt den Reboot nicht aus
4. Reboot des Basissystems (11:51 Uhr)
   1. Das Basissystem lässt sich nicht mehr starten.
   2. Benutzung des IKVM-Rescue-Modus schlägt fehl (3 Versuche) (11:54, 12:04, 12:21)
   3. Shell-Rescue-Modus lässt ca. 30min auf sich warten (Reboot um 12:25, erneuter Reboot um 12:51 Uhr, System war um 12:55 Uhr da)
   4. das Rescue-System hat kein DRBD
   5. das Rescue-System hat keine Module
   6. Versuche, das System zur Kooperation zu bewegen.
5. Parallel dazu: Diskussion, die Migration jetzt durchzuführen statt der Reparatur.
   1. Umschwenken der IPs ab 13:32 Uhr (Auf Wartungsseite)
   2. Entschluss zur Durchführung der Migration gegen 14:00 Uhr nachdem die Reparaturbemühungen nicht zum Erfolg führten.
   3. Herunterfahren der bestehenden KVM-Instanzen auf Bounty
   4. Kernel-Upgrade und Sudo-Upgrade auf Bounty
   5. Neustart von Bounty
   6. Migration von vServer auf KVM, erste Instanz ca. 1,5h, die darauffolgenden in ca. 30 Minuten, 6 virtuelle Maschinen zzgl. Anpassungen ca. 6h Migrationszeit, im Rahmen des geplanten Changes wäre das auf 2 Stunden reduzierbar gewesen mit minimalen Ausfallzeiten der einzelnen Dienste, während der Nacht.
   7. Verzögerung von ca. einer Stunde durch Adminfehler auf Filesystemebene.
   8. Gegen Abend: Inbetriebnahme von WWW (ohne DB-Probleme), Wiki und Forum mit schweren DB-Fehlern, Datenbank bricht zusammen. Gegen Mitternacht DB zumindest in einen Zustand gebracht, der das Durchführen von Recoverymaßnahmen erlaubt.
6. ab Mitternacht: Versuch der DB-Rekonstruktion mit weiteren Datenbankcrashs; um 9 Uhr vormittags kam die Entscheidung das Datenbankbackup zu verwenden. Weitere Hürde: man kommt nur über das gecrashte System an das Backup heran.
7. Wiederherstellung des produktiven Betriebs:
   1. Dienste ohne Datenbank: 10.03.2010 gegen 20 Uhr
   2. Dienste mit Datenbank (z.B.Wiki): 11.03.2010 - Lesezugriffe ab ca. 15 Uhr, Schreibzugriffe ab ca. 17:30 Uhr

Mal ein offenes Wort

Der Umstand, dass die IT von anderer Stelle während der Recovery-Maßnahmen bedroht wurde und unterstellt wurde, wir würden andere Server angreifen, hat bei der zügigen Durchführung der Recovery-Maßnahmen nicht geholfen.

Die Diskussionen und Maßnahmen rund um das Forum boten zudem einen zeitintensiven Nebenkriegsschauplatz, der uns in der Zeit vor dem Ausfall von der Planung, Vorbereitung und Durchführung der Migrationen abhielt, weil wir gezwungen waren uns mit dem Forumsthema zu befassen. Die ursprüngliche Planung war innerhalb der letzten zwei Wochen die anstehenden Migrationen sauber und ohne viel Aufsehen und Störungen zu testen und durchzuführen.