Stromausfall im Rechenzentrum führte zu Ausfällen bei mailbox.org

Die Rekonstruktion eines Ausfalls

Von Peer Heinlein, Geschäftführer von mailbox.org

Ein durch einen Kurzschluss in einer 10 kV-Leitung verursachter Stromausfall im Berliner Stadtgebiet Tiergarten am Dienstagnachmittag beschädigte auch die Notstromanlage eines dort von uns genutzten großen Rechenzentrums, sodass es auch im Rechenzentrum zu einem längeren Stromausfall kam und Zehntausende Server ausfielen. Es kam zu großflächigen Internet-Störungen in Berlin und auch zu einem länger andauernden Ausfall bei mailbox.org.

Eigentlich nutzt mailbox.org gezielt zwei Rechenzentren parallel, um Ausfälle dieser Art kompensieren zu können. Trotzdem kam es zu Betriebsstörungen. Deren Ursache zu erklären ist nicht ganz einfach – weil es nicht „ein großes klassisches Problem“ gab. Vielmehr führte die Verkettung mehrerer kleiner Probleme und unglückliche Umstände zu dem Ausfall in beiden Rechenzentren.

 

Die untechnische Kurzfassung

Daten sind zu keinem Zeitpunkt verloren gegangen.

Ein Stromausfall in Berlin und ein Versagen einer Notstromeinrichtung führte zu einem großflächigen Stromausfall in einem von uns genutztem Rechenzentrum. Internet in Berlin war in den Nachmittags- und Abendstunden großflächig gestört, Zehntausende Server sind stromlos ausgefallen. Aufgrund mittlerweile analysierter und geklärter verschiedener Komplikationen konnte unser zweites Rechenzentrum den Betrieb nicht wie erwartet störungsfrei übernehmen. Nach Wiederherstellung der Stromversorgung benötigte unser Team noch ca. zweieinhalb Stunden, bis alle unsere Dienste wieder verfügbar waren. Gemessen an der Schwere und Umfang des Ausfalls eine ggf. nicht ungewöhnliche Zeit. Warum allerdings unser Ersatzrechenzentrum den Dienst nicht unterbrechungsfrei übernehmen konnte, haben wir technisch analysiert und die Ursachen behoben - die Details sind für interessierte Techniker :-) in diesem Artikel im Folgenden aufbereitet.

 

Die technische detaillierte Langfassung

Im Sinne der Transparenz versuchen wir hier, den Ablauf der Geschehnisse zu rekonstruieren. Es lässt sich nicht vermeiden, dass dies eine technische Schilderung wird, da sich die technischen Zusammenhänge nicht anders erklären lassen. Im Folgenden sind einige Sachverhalte verkürzt und vereinfacht dargestellt und einige technische Details unserer Infrastruktur können wir aus Sicherheitsgründen nicht veröffentlichen.

mailbox.org und Heinlein Hosting betreiben zwei physisch komplett getrennte Serverstandorte in Berlin. Dazu haben wir uns mit eigener Technik und Infrastruktur bei zwei verschiedenen Rechenzentrumsanbietern eingemietet. Gleich einer „Shopping Mall“ betreiben diese Anbieter das Gebäude und die Klima- und Stromtechnik, während wir für die Nutzung unserer anteiligen Fläche und Räumlichkeiten mit Servern, Datentraffic & Co. zuständig sind.

An beiden Standorten betreiben wir physisch und auch weitgehend logisch voneinander unabhängige Virtualisierungssysteme und große Festplattenspeicher, auf denen unsere Dienste laufen. Beide Virtualisierungscluster sind über eine gemeinsame Steuereinheit verbunden. Sollte diese ausfallen, können die Cluster autark weiterlaufen, aber Neustarts oder andere Arbeiten sind dann ggf. nicht möglich.

Beim Ausfall eines Standortes oder Virtualisierungsclusters sollte der zweite Standort idealerweise unterbrechungsfrei weiter funktionieren, mindestens aber nach kleineren Anpassungs- oder Umbauarbeiten in angemessener Zeit den Betrieb übernehmen können.

1. Der Stromausfall in Berlin

Ein Stromausfall im Stromnetz passiert immer wieder einmal. Rechenzentren sind mit Batterie-Puffern und großen Notstromanlagen dagegen gerüstet und haben zudem i.d.R. sogar zwei getrennte Stromkreise zur parallelen internen Versorgung.

Denn was bei einem öffentlichen Stromausfall nicht passieren darf: Dass ein Stromausfall in das Rechenzentrum mit seinen zehntausenden Servern durchschlägt.

Was passiert ist: An einem unserer beiden Standorte versagte die Notstromanlage des Anbieters und zehntausende Server verschiedenster Anbieter und Firmen gingen offline. Auch unsere Hardware. Das „darf“ nicht passieren, „kann“ aber passieren und „ist“ passiert. Auch wir sind auf die Ursachenanalyse und den Bericht des Rechenzentrumsanbieters gespannt. Einer ersten Rückmeldung zufolge hat der Kurzschluss einer 10.000 Volt-Leitung im Berliner Stadtnetz auch so ins Rechenzentrum durchgeschlagen, dass die Batterieanlage der Notstromversorgung ebenso Schäden erlitten hat.

Die Konsequenzen bekamen zahlreiche Internet-Dienste zu spüren: Es kam je nachdem zu großflächigen stundenlangen Störungen bis spät in die Nacht, der Berliner Datenaustauschknoten BCIX war zwischendurch teilweise betroffen, am Ende konnte sogar eine Tageszeitung keine Druckausgabe mehr produzieren.

Dass nicht einzelne Geräte, sondern die komplette IT-Infrastruktur an einem Standort offline geht, ist selten und verursacht aufgrund der schieren Masse viel Aufwand, um alles wiederherzustellen.

Aber um das zu minimieren betreiben wir unsere Server an mehreren Standorten – und unser zweiter Standort war vom Stromausfall und Versagen der Notstromanlagen natürlich nicht betroffen gewesen. Trotzdem kam es zu einer auch für Nutzer wahrnehmbaren Störung. Warum?

2. Störungen auch im nicht betroffenen Rechenzentrum

Nach einem Großalarm und einem „All Hands on Deck“ fand unser Team ein sehr unklares und widersprüchliches Bild mit zahlreichen Störungen auch am zweiten Standort vor: Zahlreiche Systeme liefen, trotzdem kam es zu Beeinträchtigungen und Ausfällen, die sich zunächst nicht erklären ließen.

Es zeigte sich schnell, dass auch im eigentlich nicht betroffenen zweiten Standort der Virtualisierungscluster mit Hunderten unserer System zwar „up und running“ war, sich jedoch nicht mehr richtig steuern und ansprechen ließ und einige Server nicht mehr zuverlässig arbeiteten. Um die Fehlersuche zu beschleunigen zogen wir gegen 16 Uhr externe Experten hinzu, die auf unsere dort eingesetzte Virtualisierungssoftware VMware spezialisiert sind, aber auch mit vereinten Kräften ließen sich die Symptome und Probleme nur schwer erklären.

Ursache war Letztenendes eine noch immer andauernde Störung in unserem Domain Name System, also dem System zur Auflösung von Server-Hostnamen zu IP-Adressen. Dafür betreiben wir mehrere sog. DNS-Resolver, die auf beide Rechenzentren aufgeteilt sind um auch hier einen Totalausfall eines Standorts abzufangen.

Zwei unserer drei DNS-Resolver waren durch den Ausfall in Mitleidenschaft gezogen worden – was für unsere Server jedoch zunächst kein Problem darstellte und sich nicht als Fehler zeigte, da der dritte DNS-Resolver weiterhin problemlos funktionierte und nur ein funktionierendes System benötigt wurde. Hunderte von Systemen funktioniert darum zunächst weiterhin planmäßig.

3. Unerkannte Störung eines DNS-Resolvers und VMware-Besonderheit

Anders als bei anderen (Linux-) Serversystemen können bei einer VMware-Virtualisierung jedoch nur zwei statt der sonst üblichen drei unterschiedlichen DNS-Server zeitgleich verwendet werden. Dabei achten wird darauf, je ein System aus jedem Standort zu verwenden. Trotzdem sind aufgrund unglücklicher Details DNS-Resolver an beiden Standorten gestört gewesen und VMware nutzte zufällig genau und ausschließlich die beiden ausgefallenen Systeme.

In der Folge konnten sich die beteiligten Virtualisierungsserver an allen Standorten nicht mehr richtig „sehen“ und intern nicht mehr richtig kommunizieren, sodass der Kontrollverlust des Virtualisierungsclusters an beiden Standorten gleichzeitig auftrat.

Für uns war dieser eigentlich sehr banale Umstand schwer zu erkennen, da alle anderen Systeme weiterhin problemlos auf Basis des 3. DNS-Resolvers funktionierten. Zudem wirkten auch die beiden ausgefallenen DNS-Resolver äußerlich unversehrt und wir gingen lange davon aus, dass diese normal funktionsfähig waren, sodass diese nicht sofort im Fokus der Analyse standen.

4. Ursachenanalyse am falschen Ort

Unser Team hat darum, zusammen mit den externen Experten, in der ersten Stunde (zu) lange nach einem Problem innerhalb der Virtualisierungslösung gesucht und erst spät erkannt, dass die Symptome durch die fehlenden, äußerlich fehlerfreien DNS-Resolver verursacht wurden.

Nachdem wir einen der beiden doch defekten DNS-Server neu gestartet hatten, lösten sich sämtliche Probleme und Ursachen im Cluster schlagartig, wir gewannen die Kontrolle zurück und konnten gegen 17:30 Uhr beginnen, ausgefallene und gestörte Server neu zu starten, sodass relativ zügig rund um 18 Uhr alle Dienste an beiden Standorten wieder verfügbar waren. Unser Team war anschließend noch bis nach Mitternacht beschäftigt, zahlreiche andere Systeme wiederherzustellen, während mailbox.org bereits wieder lief.

 

Zuammengefasst lässt sich festhalten:

1. Ein Stromausfall im Rechenzentrum darf nicht passieren und wir sind auf den Abschlussbericht unseres Anbieters gespannt. Aber je nach Stärke eines Kurzschlusses sind auch dort Schäden nicht immer zu verhindern. An sich sind wir selbst auf diesen Umstand vorbereitet, sodass wir auch bei einem länger andauernden Ausfall den Betrieb mit dem zweiten Standort hätten fortführen können bzw. eigentlich hätte dieser unterbrechungsfrei den Betrieb fortführen müssen.
2. Dass beide Virtualisierungscluster an beiden Standorten ausgerechnet die zwei ausgefallenen DNS-Resolver nutzten und zwar nicht physisch, aber logisch in Mitleidenschaft gezogen wurden, war großes Pech, darf aber ebenso nicht passieren. Wir werden daher auf technischer Ebene an mehreren Stellen Umbauten vornehmen, damit dieses Problem nicht mehr auftreten und erst recht nicht mehr unerkannt auftreten kann. Zudem wissen wir nun die daraus folgenden (sehr verrückten) Symptome zu deuten.
3. Aber abgesehen davon wäre all das jedoch auch kein Problem gewesen, hätte es nicht zusätzlich auch eine kleine netzwerktechnische Besonderheit aufgrund von Wartungsarbeiten gegeben. Diese ist an sich bekannt, belanglos und harmlos, trug am Ende hier in der Kaskade an sich sehr kleiner und vorhersehbarer und eingeplanter Störungen zum Ausfall des DNS-Resolvers auch am unbeteiligten Standort bei, brachte das Fass sozusagen mit dem letzten Tropfen zum Überlaufen.
4. Die Großstörung war das Gesamtergebnis von rund einem halben Dutzend, für sich gesehen, harmloser Kleinigkeiten. Nur durch das gemeinsame Auftreten aller dieser Probleme zusammen konnte die Gesamtstörung auftreten, jeder Wegfall eines Teil-Problems hätte das Gesamt-Problem nicht eintreten lassen.
5. Die Zusammenarbeit von unserem Incident-Team – rund 20 Team-Mitglieder haben den Ausfall gemeinsam bearbeitet – hat gut und binnen Minuten funktioniert; ebenso funktionierte unsere eigene Absicherung durch externe Spezialisten.
6. Daten und E-Mails sind zu keinem Zeitpunkt verloren gegangen.
7. Nach dem Stromausfall um ca. 15 Uhr waren unsere Dienste rund um 18 Uhr wieder verfügbar.
8. Die Ursachen sind bekannt, analysiert und verstanden und können durch Berücksichtigung und Umbauten zukünftig ausgeschlossen werden.