Warum der Facebook-Ausfall eine Lehre sein sollte

Ein schlecht geschriebener Befehl, ein fehlerhaftes Audit-Tool, ein DNS-System, das die Bemühungen zur Wiederherstellung des Netzwerks behindert hat, und die strengen Sicherheitsvorkehrungen in den Rechenzentren trugen alle zu dem siebenstündigen Dumpster Fire bei Facebook bei. [...]

Facebook gibt an, dass die Ursache für den Ausfall am Montag in einer schief gelaufenen Routinewartung lag, die dazu führte, dass die DNS-Server nicht mehr verfügbar waren.

Erschwerend kam hinzu, dass die Techniker von Facebook aufgrund des DNS-Ausfalls nicht mehr aus der Ferne auf die Geräte zugreifen konnten, die sie benötigten, um das Netzwerk wieder in Gang zu bringen.

Das verlangsamte die Dinge, aber sie wurden noch mehr verlangsamt, weil die Rechenzentren über Sicherheitsvorkehrungen verfügen, die Manipulationen erschweren – für jeden. „Sie sind schwer zu knacken, und wenn man erst einmal drin ist, sind die Hardware und die Router so konzipiert, dass sie nur schwer zu verändern sind, selbst wenn man physischen Zugang zu ihnen hat“, heißt es in einem Facebook-Blog von Santosh Janardhan, dem Vizepräsidenten für Technik und Infrastruktur des Unternehmens.

Es hat einige Zeit gedauert, aber sobald die Systeme wiederhergestellt waren, funktionierte das Netzwerk wieder.

Die Wiederherstellung der kundenorientierten Dienste, die über das Netzwerk laufen, war ein weiterer langwieriger Prozess, da das gleichzeitige Hochfahren dieser Dienste eine weitere Runde von Abstürzen verursachen könnte. „Einzelne Rechenzentren meldeten Einbrüche im Stromverbrauch im Bereich von zehn Megawatt, und eine plötzliche Umkehrung eines solchen Einbruchs im Stromverbrauch könnte alles gefährden, von elektrischen Systemen bis hin zu Caches“, schrieb Janardhan.

Insgesamt war Facebook sieben Stunden und fünf Minuten lang nicht erreichbar.

Fehler bei Routinewartung

Zu Beginn des Ausfalls hatte Facebook nur einen Teil des Backbone–Netzwerks für Wartungsarbeiten offline genommen. „Während einer dieser routinemäßigen Wartungsarbeiten wurde ein Befehl mit der Absicht ausgegeben, die Verfügbarkeit der globalen Backbone-Kapazität zu bewerten, wodurch unbeabsichtigt alle Verbindungen in unserem Backbone-Netzwerk unterbrochen und damit die Datenzentren von Facebook weltweit abgeschaltet wurden“, schrieb Janardhan.

Das war nicht geplant, und Facebook hatte sogar ein Tool zur Verfügung, um Befehle auszusortieren, die einen solchen katastrophalen Ausfall verursachen könnten, aber es hat nicht gegriffen. „Unsere Systeme sind darauf ausgelegt, solche Befehle zu prüfen, um Fehler wie diesen zu vermeiden, aber ein Fehler in diesem Audit-Tool hat verhindert, dass der Befehl ordnungsgemäß unterbunden wurde“, so Janardhan.

Als das passierte, war das DNS dem Untergang geweiht.

Social Networks: Hilfe, mein Chef folgt mir auf Instagram!

DNS war eine einzige Schwachstelle

Laut Angelique Medina, Leiterin des Produktmarketings bei Cisco ThousandEyes, das den Internetverkehr und Ausfälle überwacht, scheint eine automatische Reaktion auf den Zusammenbruch des Backbone das DNS zum Absturz gebracht zu haben.

DNS (Directory Name Services) antwortet auf Anfragen, wie Web-Namen in IP-Adressen zu übersetzen sind, und Facebook hostet seine eigenen DNS-Nameserver. „Sie haben eine Architektur, bei der ihr DNS-Service in Abhängigkeit von der Serververfügbarkeit hoch- oder herunterskaliert wird“, sagt Medina. „Und als die Serververfügbarkeit auf Null sank, weil das Netzwerk ausfiel, wurden alle DNS-Server außer Betrieb genommen.

Diese Stilllegung wurde dadurch erreicht, dass die DNS-Nameserver von Facebook Nachrichten an Internet-Border-Gateway-Protokoll (BGP)-Router sendeten, die das Wissen über die zu verwendenden Routen zum Erreichen bestimmter IP-Adressen speichern. Die Routen werden routinemäßig an die Router weitergegeben, damit diese den Datenverkehr entsprechend weiterleiten können.

Die DNS-Server von Facebook schickten BGP-Nachrichten, die die angekündigten Routen für sich selbst deaktivierten, so dass es unmöglich war, den Datenverkehr zu irgendetwas im Backbone–Netzwerk von Facebook aufzulösen. „Das Endergebnis war, dass unsere DNS-Server unerreichbar wurden, obwohl sie immer noch betriebsbereit waren. Dies machte es für den Rest des Internets unmöglich, unsere Server zu finden“, schrieb Janardhan.

Selbst wenn die DNS-Server noch über das Internet erreichbar gewesen wären, hätten Facebook-Kunden den Dienst nicht mehr nutzen können, da das Netzwerk, das sie zu erreichen versuchten, zusammengebrochen war. Unglücklicherweise hatten die Facebook-Ingenieure auch keinen Zugang mehr zu den DNS-Servern, die für ihre Fernverwaltungsplattformen erforderlich waren, um die ausgefallenen Backbone-Systeme zu erreichen.

„Sie nutzen ihren DNS-Service nicht nur für ihre kundenorientierten Webangebote“, sagt Medina. „Sie nutzen ihn auch für ihre eigenen internen Tools und Systeme. Durch die vollständige Abschaltung wurde verhindert, dass ihre Netzwerkbetreiber oder Techniker Zugang zu den Systemen erhielten, die sie für die Behebung des Problems benötigten.“

Eine robustere Architektur würde über zwei DNS-Dienste verfügen, so dass einer den anderen sichern könnte, sagte sie. Amazon beispielsweise, dessen AWS einen DNS-Dienst anbietet, verwendet laut Medina zwei externe Dienste – Dyn und UltraDNS – für sein DNS.

Lektionen, die man daraus lernen kann

Der Vorfall offenbart, was nach bewährten Netzwerkpraktiken ein Mangel in der Facebook-Architektur sein könnte. „Warum war das DNS in diesem Fall tatsächlich ein Single Point of Failure“, sagt sie. Ein DNS-Ausfall ohne Backup-DNS könnte zu einem längeren Ausfall führen, „daher denke ich, dass ein redundantes DNS eine wichtige Konsequenz ist“.

Eine weitere allgemeine Beobachtung hat Medina bei Ausfällen von anderen Dienstanbietern gemacht. „Oftmals gibt es bei diesen Ausfällen so viele Abhängigkeiten innerhalb des Netzwerks, dass ein kleines Problem in einem Teil der gesamten Service-Architektur zu einem Problem führt, das dann eine Art Kaskadeneffekt hat“, sagt sie.

„Viele Unternehmen nutzen eine Vielzahl interner Dienste, und das kann unvorhergesehene Folgen haben. Das ist vielleicht eher etwas für Techniker, aber ich denke, es ist es wert, darauf hinzuweisen.“

*Tim Greene ist leitender Redakteur von Network World.