Kühlungsausfall erzwang Wikipedias Failover – und der Failover selbst brach das DNS weltweit

Am 24. März 2010 fiel die Kühlung im europäischen Rechenzentrum von Wikimedia aus, und viele Server schalteten sich selbst ab, um ihre Hardware zu schützen. Da dieser Standort den europäischen Traffic für Wikipedia und die anderen Projekte bediente, führte das Betriebsteam seinen standardmäßigen schnellen Failover durch: DNS-Einträge ändern, damit der gesamte Nutzerverkehr zum Cluster in Florida wechselte. Minuten später stellte das Team fest, dass der Failover-Mechanismus selbst defekt war, und die DNS-Auflösung für jede Wikimedia-Seite funktionierte nicht mehr – nicht nur in Europa, sondern weltweit.

Die Wiederherstellung traf dann auf einen zweiten, stilleren Fehlermodus. Das Team erwartete, dass Resolver die fehlerhaften Antworten innerhalb einer Stunde verwerfen würden – der negativen Cache-TTL, die die Zone angekündigt hatte –, doch die Resolver vieler ISPs ignorierten diesen Hinweis und speicherten die fehlgeschlagenen Abfragen länger. Die Umgehung war grob: den betroffenen DNS-Eintrag umbenennen, damit Resolver einem frischen Namen nachgehen mussten. In der Zwischenzeit brach das SSL-Gateway secure.wikimedia.org, das während des Notfalls deaktiviert worden war, unter dem zurückkehrenden Traffic zusammen und blieb bis 21:32 UTC außer Betrieb.

Mehrere Stunden lang war die Referenzenzyklopädie der Welt schlicht nicht auflösbar, ohne einen Ausfall-Stream zum Mitverfolgen – Mashable merkte an, Twitter sei der einzige Ort, um ihn zu verfolgen. Der Wikimedia Signpost verzeichnete die Seite als „weltweit mehrere Stunden offline“, und das Team veröffentlichte noch am selben Tag eine Erklärung im Tech-Blog, unterzeichnet vom Infrastruktur-Ingenieur Mark Bergsma.

Jede Wikimedia-Seite war weltweit mehrere Stunden lang nicht auflösbar, wobei der Ausfall von CNN, dem Telegraph und Mashable aufgegriffen wurde, als Leser den Zugang verloren.

Das Failover-Verfahren war als „standardmäßig schnell“ bezeichnet, doch sein DNS-Schritt war defekt, als er tatsächlich ausgeführt wurde – der Wiederherstellungspfad war offensichtlich nie gegen einen echten Wechsel erprobt worden.

Die Wiederherstellungsschätzungen gingen davon aus, dass ISP-Resolver den beworbenen einstündigen negativen Cache-TTL einhalten würden; viele taten es nicht, wodurch ein begrenzter Vorfall zu einem unbegrenzten wurde.

Das SSL-Gateway hatte keinen Spielraum: Als der Traffic zurückströmte, überlastete secure.wikimedia.org und fiel aus, was den Ausfall verschlimmerte.

Die europäische Bedienung war in einer einzigen Einrichtung konzentriert, sodass ein einziger Kühlungsausfall überhaupt einen globalen Traffic-Wechsel erforderte.

Ein Failover-Pfad, der nie erprobt wird, ist eine Hoffnung, kein Mechanismus. Üben Sie Wiederherstellungsverfahren als Live-Übungen ein und gehen Sie nie davon aus, dass nachgelagerte Caches planmäßig ablaufen.

Der Zugang kehrte zurück, nachdem der DNS-Eintrag umbenannt worden war und frische Abfragen sich verbreitet hatten; das SSL-Gateway war noch am selben Tag um 21:32 UTC wieder da. Die noch am selben Tag veröffentlichte öffentliche Postmortem im Wikimedia-Tech-Blog gab den Ton für die spätere Gewohnheit der Foundation vor, Incident-Retrospektiven zu veröffentlichen. Die Redundanzfalle selbst blieb bestehen: Im August 2012 durchtrennte ein einziger Glasfaserschnitt beide „redundanten“ Verbindungen zwischen den Rechenzentren Ashburn und Tampa und legte Wikipedia für weitere 63 Minuten lahm, und erst danach konsolidierte die Foundation ihr Serving-Backend in Ashburn.