Editorial: Der zentrale Fehler

Am Montag waren gleich alle Dienste des Face­book-Konzerns auf einmal ausge­fallen, und das welt­weit: Face­book, WhatsApp, Insta­gram, Face­book Messenger und so weiter. Nichts davon lief mehr für ca. sechs Stunden. Ursache war nicht ein Daten­bank-Ausfall oder ein Compu­ter­fehler, sondern Netz­werk-Soft­ware: Diese läuft auf den hoch­leis­tungs­fähigen Internet-Routern, die Daten­pakete jeweils in die rich­tige Rich­tung schi­cken. Die schnellsten kommer­ziellen Router können auf allen Schnitt­stellen gemeinsam hunderte Terabit pro Sekunde über­tragen, und dazu Milli­arden Internet-Pakete pro Sekunde weiter­leiten.

Nun ändert sich die Konfi­gura­tion des Inter­nets ständig: Provider schließen neue Kunden an, sie nehmen neue Back­bone-Leitungen in Betrieb oder schalten alte ab. Inter­con­nect-Verträge zwischen Provi­dern werden geschlossen, im Preis geän­dert oder wieder aufge­löst. In der Folge kann der Weg von Ihrem Computer zum teltarif-Server, der heute noch richtig ist, morgen schon in einer Sack­gasse enden. Um trotz all dieser Dynamik das Internet am Laufen zu halten, gibt es ein koope­ratives Proto­koll aller Provider, genannt BGP, mit dem die nötigen Infor­mationen ausge­tauscht werden, welche Netze auf welchem Weg erreichbar sind.

Für die interne Kommu­nika­tion inner­halb der Struktur eines Provi­ders oder Diens­tean­bie­ters ist BGP aber nur bedingt geeignet. Beispiels­weise benö­tigt ein Frontend-Server für Face­books Web-Dienst die in den BGP-Daten­banken enthal­tenen Infor­mationen, welche welt­weiten Netz­werke wie erreichbar sind, über­haupt nicht. Es reicht, wenn der Web-Dienst weiß, wie er einen Router (und ggfls. noch einen Backup-Router) errei­chen kann, der dann die welt­weite Weiter­lei­tung über­nimmt.

Schlimmer noch, die BGP-Infor­mationen sind regional unter­schied­lich. Für ein Face­book-Daten­zen­trum in Dublin gelten andere Infor­mationen, wie man Pakete am besten Rich­tung der Deut­schen Telekom routet, als für ein Face­book-Daten­zen­trum in Rich­mond. Zugleich müssen die Face­book-Server aber in der Lage sein, über effi­ziente Leitungen direkt mitein­ander zu kommu­nizieren. Zwar hält der Face­book-Konzern die meisten Daten regional möglichst nah am jewei­ligen User. Aber wenn ein User eben von Europa nach Amerika reist, dann loggt er sich anschlie­ßend natür­lich bei einem der US-Daten­zen­tren ein, während seine Daten sich noch in Europa befinden. Und dann muss der US-Frontend-Server auf das euro­päi­sche Daten-Backend zugreifen, über die internen Face­book-Leitungen, für die eben andere Wege gelten als für "normale" Internet-Pakete.

Routing-Proto­kolle für "intern" und "extern"

Für jeden Messaging-Dienst, sollte man einen Plan B bereit halten.
Foto: Picture Alliance / dpa Die Folge: Große inter­natio­nale Inter­net­kon­zerne wie Google, Face­book oder Amazon verwenden spezi­elle interne Routing-Proto­kolle sowohl inner­halb als auch zwischen ihren Daten­zen­tren, und BGP für die Kommu­nika­tion mit dem Rest der Welt. Für die interne Kommu­nika­tion gibt es eben­falls Stan­dard-Proto­kolle, beispiels­weise das recht einfache OSPF, die aber nicht immer alle Anfor­derungen erfüllen. Um die internen Routen optimal zu verwalten, hatte Face­book daher eine eigene Lösung entwi­ckelt.

Und hier passierte dann der Fehler: Bei einem Routine-Update für das interne Routing wurde ein Konfi­gura­tions­fehler gemacht. Bedingt durch Schwä­chen des selbst entwi­ckelten internen Routing-Proto­kolls bewirkte das dann nicht nur, dass die fehl­kon­figu­rierten Server uner­reichbar wurden, sondern, dass das komplette interne Routing zusam­men­brach. Und weil die Edge-Router, das sind die Router zwischen "drinnen" und "draußen", in der Folge eben­falls keine Face­book-Dienste mehr errei­chen konnten, löschten sie dann konse­quent alle bis dahin über BGP veröf­fent­lichten Routen. Schließ­lich wussten sie ja wegen des Zusam­men­bruchs des internen Routings nicht mehr, wie sie Pakete, die für Face­book bestimmt waren, weiter­leiten sollten.

Somit war der interne Konfi­gura­tions­fehler damit maximal eska­liert. Nichts ging mehr. Teil­weise kamen wohl nicht einmal mehr Face­book-Mitar­beiter in ihre Büros, weil, nun ja, die Schlüs­sel­karten nicht mehr einge­lesen werden konnten, weil die zuge­hörige Daten­bank eben­falls im Face­book-Nirwana verschwunden war.

Manage­ment-Netz?

Spätes­tens hier stellt sich nun natür­lich die Frage, warum es kein physisch getrenntes, manuell konfi­guriertes, zwar lang­sames, aber eben nur für Notfälle wie diesen hier ausge­legtes Manage­ment-Netz gibt, über das man den letzten Konfi­gura­tions­stand von vor dem fatalen Update hätte zurück­spielen können. Gut, die Frage werden wohl einige Netz­werk-Manager demnächst detail­lierter an Mark Zucker­berg beant­worten müssen; die Antwort werden wir aber wahr­schein­lich nicht erfahren. "Kosten" könnte einer der Gründe sein, schließ­lich macht es einen Unter­schied, ob man zu jedem Server und jedem Router noch eine Ethernet-Strippe zusätz­lich ziehen muss und dann auch regel­mäßig testen muss, ob diese auch wirk­lich funk­tio­niert. Denn im Regel­betrieb braucht man ja das Manage­ment-Netz nicht.

Alter­native Messenger-App

Die folgende Frage können Sie hingegen für sich selber beant­worten: Wie viele alter­native Messenger-Apps haben Sie betriebs­bereit auf Ihrem Smart­phone? Denn der nächste WhatsApp-Ausfall kostet Sie nur ein Schul­ter­zucken, wenn Sie auch Signal, Threema und Tele­gram auf dem Smart­phone haben. Wenn Nach­richten auf App 1 nicht durch­gehen, dann nehmen Sie halt einfach App 2. Klar kann man App 2 zur Not auch dann instal­lieren, wenn App 1 gerade in die Knie geht. Nur: Weil ja nicht nur bei Ihnen App 1 gerade zickt, laden dann viele User auf einmal App 2 herunter, und dann droht schon wieder Rück­stau auf deren Regis­trie­rungs­server. Besser, Sie haben App 2 schon auf dem Handy, bevor App 1 das nächste Mal zickt.