Post Mortem

Am Dienstag hat ein Stromausfall die Freifunk-Netze im Kreis Gütersloh und der Müritz-Region lahmgelegt: wieso, weshalb und was kann man tun?

Vorab: sorry für die Tragweite des Ausfalls, sie ist zum Teil unserem Setup geschuldet. Aber von vorne:

Was war passiert?

Soweit wir das wissen, hat es Probleme mit der Stromversorgung in Teilen des Rechenzentrums gegeben. Sollte nicht passieren, aber auch Technik kann ausfallen. Da unsere Server über zwei unterschiedliche Stromkreise versorgt werden, hatten wohl auch wir Pech, denn offensichtich fielen bei einigen Geräten beide aus. Wie schon berichtet, zwei Server haben »nur« rebootet, drei andere kamen nicht automatisch hoch. Davon konnte einer per Fernwartung reanimiert werden, der zweite stellte sich dort auf den Einschaltbefehl taub und wurde durch die Techniker vor Ort eingeschaltet. Der dritte Server, die älteste Büchse, hat keine Fernwartung und ist nicht mehr erreichbar.

Was waren die Auswirkungen?

Letztlich waren rd. die Hälfte unserer Server mindestens kurzzeitig weg, davon besagte 3 bis mindestens mittags. Einer jener Server war auch als NFS-Server konfiguriert, um flexibler und ausfallsicherer zu werden. Im Grunde war das als HA-Setup ausgelegt (die Daten wurden auf einen zweiten Server gespiegelt, welcher bei Ausfall des ersten hätte übernehmen können); allerdings war dies noch nicht vollständig konfiguriert … die freie Zeit für solche Umbauten im laufenden Betrieb ist dann leider doch begrenzt, und das Risiko ja eigentlich marginal. Tja.

Ohne NFS-Server waren die meisten älteren VMs lahmgelegt. Hinzu kam, daß unser verteiltes Dateisystem LizardFS den zeitgleichen Reboot zweier Server verkraften mußte; einer ist eingeplant, bei zweien gab es bei der gewählten Einstellung »Orginal + 1 Kopie« zwangsläufig ebenfalls Probleme.

Aber das war an der Stelle dann auch egal: Unser Hauptproblem, und der Grund für die leider recht lange Wiederherstellungszeit, lag im ältesten System, einer FSC RX300. Ein System, was gegen 2005 schon Alteisen war, welches aber unsere IPv4-PI-Netze routete. Das System hat keine (noch funktionale) Remote-Management-Lösung, somit müßte nun jemand ins RZ fahren und gucken, was das Schäztchen hat.

Es ist nicht unwahrscheinlich, daß das (Hardware-) RAID-1 oder -5 zuviele Platten (wir reden von zwei bis sechs < =72 GB Ultra-320-SCSI-Platten — ich bitte um Wortmeldung, wem das ohne Wikipedia-Hilfe was sagt ;)) durch den Stromverlust verloren hat, weshalb ein Start mislingt. Oder – bis zum Stromausfall hatte die Kiste ca. 1100 Tage Uptime – ein neuerer Kernel mag mit der Hardware nicht mehr. Oder ein simples Konfigurationsproblem, in über 3 Jahren wurde viel konfiguriert …

Anyway, das Netzwerksetup der Altsysteme war abenteuerlich und jener Server sorgte dafür, daß es dennoch klappte. Ein Cleanup ist seit Jahr und Tag geplant, aber ohne Not geht man das ruhig an und zieht einen Service nach dem anderen um — in der Phase befinden wir uns seit ca. Q4 2016. Wir setzen hier auf sauber neu aufgesetzte Server und OpenNebula als Virtualisierungsplattform. Alle neuen VMs nutzen ein neues, ›sauberes‹, Netzwerksetup, waren aber,, wenn sie mit »Altlasten« sprechen mußten, auf jene RX300 angewiesen. Jene verband beide »Welten« und stellte auch den Tunnel ins andere RZ — und das mußte nun in einer VM nachgebaut werden.
Daß die RX300 ein sog. SPOF, ein »single point of failure«, war, war lange bekannt. Daher fanden die Umbauten auch ziemlich bedacht und »auf der grünen Wiese« statt; leider traf uns der Ausfall in einem Moment, in dem drei, vier Baustellen gleichzeitig bearbeitet wurden, und keine davon schon final abgeschlossen werden konnte.

Nebenkriegsschauplätze waren dann noch fehlende Redundanzen beim DNS, was zur Unerreichbarkeit von allem mit guetersloh.freifunk.net im Namen führte. Auch hier haben wir vorher schon Tickets abgearbeitet und erste Zonen umgestellt — guetersloh.freifunk.net war leider noch nicht darunter.

Ausblick?

Das Zielsetup ist aufgeräumter, übersichtlicher und gekapselter (Grundprinzip: eine VM je Service); das Netzwerk ebenso. Das neu eingesetzte verteilte Dateisystem, LizardFS, kann im Grunde multiple Serverausfälle verkraften, existiert auf der anderen Seite schon seit ca. 10 Jahren — und wird auch kommerziell vermarktet und eingesetzt. Kurzum, wie versuchen, Komplexität zu vermindern, SPOFs aufzuösen und gleichzeitig neu zu vermeiden. Wir bauen unser Server- und Servicemonitoring aus, mit weitgehender Automatisierung — evtl. mit gespiegelten Setup, sodaß einerseits eine »Sicht von außen« möglich wird, andererseits wir z. B. beim Ausfall des Hosts, auf dem die Monitoring-VM läuft, dennoch nicht blind sind. Schlußendlich erlaubt OpenNebula es in Verbindung mit einem Netzwerkdateisystem es, VMs sehr einfach in Gruppen von einem Host auf die anderen Host zu migrieren, sodaß wir auch Kernel-Updates auf den Hosts prinzipiell wieder durchführen können.