Die technischen Hintergründe von Amazons AWS-Ausfall
Eine automatische Skalierung und das Ausbleiben der gewünschten Reaktion führten zu einem der größten Ausfälle in der Geschichte der Cloud.
(Bild: Pete Linforth, gemeinfrei)
- Susanne Nolte
Am Wochenende hat Amazon zu den Ausfällen in der Cloud-Site US-EAST-1 in der Region Northern Virginia einen ausführlichen Bericht über die technischen Hintergründe geliefert, in dem der Anbieter die internen Ereignisse darlegt. AWS entschuldigt sich darin nicht nur für die teils erheblichen Auswirkungen, die die Ausfälle für die Kunden hatten, sondern auch für die fehlenden Informationen während des Ausfalls, durch die sich viele Kunden im Regen stehen gelassen sahen.
Die Ursache dafür war dieselbe wie die des Ausfalls. Der Ursprung der Fehlerlawine lag im internen Managementnetz, daher zählten die Monitoringsysteme zu den ersten Diensten, die betroffen waren. Zudem verhinderte die aus den Fehlern resultierende Netzwerküberlastung, dass das Service Health Dashboard ordnungsgemäß auf die Standby-Region umschaltete. Während also das Operator-Team händisch und ohne funktionierendes Monitoring-System die Fehlerketten aufdröseln musste, bekamen die Kunden durch das Nichtumschalten zur Backup-Site die Auswirkungen der Dienstausfälle voll zu spüren. Und da sich das Support-Center ebenfalls auf das betroffene interne AWS-Netz stützt, konnten dessen Mitarbeiter an diesem 7. Dezember zwischen 7:33 und 14:25 Uhr Pacific Standard Time (PST) weder Auskunft zu Ursache und Dauer der Ausfälle geben noch Tickets erstellen.
AWS nutzt das interne Managementnetz für seine grundlegenden Netzwerkservices einschließlich Monitoring, internes DNS, Autorisierungsdienste und Teile der EC2-Steuerungsebene, während die Mehrheit der AWS-Services und alle Kundenanwendungen innerhalb des AWS-Hauptnetzes laufen. Aufgrund der hohen Bedeutung der internen Netzwerkdienste hat AWS dieses interne Netz mit mehreren geografisch isolierten Netzwerkgeräten verbunden und skaliert die Kapazität dieses Netzes weitreichend, um dessen Verfügbarkeit möglichst hochzuhalten. Diese Netzwerkgeräte übernehmen neben Routing- auch DNS-Aufgaben, damit AWS-Services mit internen Diensten kommunizieren können.
Kennen Sie schon den kostenlosen iX-Newsletter? Jetzt anmelden und monatlich zum Erscheinungsdatum nichts verpassen: heise.de/s/NY1E In der nächsten Ausgabe geht's ums Titelthema der Januar-iX: Server mit ARM-Prozessoren.
Wenn sich Systeme gegenseitig hochschaukeln
Was war nun geschehen? Um 7:30 Uhr PST löste eine automatisierte Skalierung der Kapazität eines der im AWS-Hauptnetz gehosteten AWS-Services ein unerwartetes Verhalten bei einer großen Anzahl Clients im internen Netz aus. Genauer: Die Clients setzten ihre Anfragen aufgrund eines bisher unentdeckten Fehlers nicht wie sonst üblich zurück. Dies führte zu einem starken Anstieg des Netztraffic, der die Router zwischen dem internen und dem AWS-Hauptnetz überforderte und das Routing verzögerte. Die daraus resultierenden Latenzen und Fehler in der Kommunikation erhöhten ihrerseits die Zahl der wiederholten Anfragen von Systemen, die versuchten, ihre Verbindungen aufzubauen oder wiederherzustellen. Dieses sich Hochschaukeln in der Kommunikation führte zur anhaltenden Überlastung der Router.
Diese Überlastung hatte auch zur Folge, dass dem Operator-Team die Echtzeitmonitoringdaten nicht zur Verfügung standen, die es aber benötigte, um die Überlastungsquelle zu finden und zu beheben. Anhand der Logs identifizierte es zunächst eine erhöhte Fehlerzahl beim internen DNS. Da das aber die Grundlage aller Dienste darstellt und das Nichtbeantworten der DNS-Anfragen zur Überlastung beiträgt, konzentrierte sich das Team darauf, den internen DNS-Datenverkehr von den überlasteten Netzwerkpfaden wegzubewegen. Um 9:28 Uhr PST hatte es die DNS-Auflösungsfehler vollständig behoben.
Diese Änderung verbesserte zwar die Verfügbarkeit mehrerer mitbetroffener Dienste, da sie die Belastung der Router reduzierte, behob aber nicht vollständig die Auswirkungen auf den AWS-Dienst und beseitigte nicht die Überlastung anderer Systeme. Vor allem hatte das Operator-Team noch immer keinen Zugriff auf die Monitoringdaten, was die weitere Fehlererkennung und -behebung erschwerte. Eine Reihe von Abhilfemaßnahmen sollte vor allem die Überlastung des internen Netzes reduzieren. Dazu identifizierte das Team die Hauptverkehrsquellen, leitete sie auf dedizierte Router um, deaktivierte einige Dienste mit hohem Trafficaufkommen und stellte zusätzliche Netzwerkressourcen online. Dadurch verbesserte sich die Überlastung um 13:34 Uhr PST erheblich und bis 14:22 Uhr PST waren alle Router vollständig wiederhergestellt.
Auswirkungen auf den AWS-Service
Aus mehreren Gründen kam das Team aber nur langsam voran. Zum einen fehlten durch die Auswirkungen auf das interne Monitoring die Daten, die nötig waren, um die Vorgänge im Netz zu verstehen. Zum anderen verlangsamte die Tatsache, dass die internen Bereitstellungssysteme im internen Netz betroffen waren, die Wiederherstellungsbemühungen weiter. Da viele Services im AWS-Hauptnetz und Kundenanwendungen immer noch normal funktionierten, wollte das Team bei den Änderungen äußerst überlegt vorgehen, um eine Beeinträchtigung der funktionierenden Workloads zu vermeiden.
Obwohl die Arbeitslasten von AWS-Kunden nicht direkt von der Überlastung interner Dienste betroffen waren, hatten sie Auswirkungen auf eine Reihe von AWS-Services, was sich wiederum auf deren Nutzer auswirkte, während andere Kundenanwendungen, die nicht auf diese Funktionen angewiesen waren, von Einschränkungen verschont blieben.
Betroffen waren vor allem die Steuerungsebenen zum Erstellen und Verwalten von AWS-Ressourcen. Sie verwenden Dienste, die AWS im internen Netz hostet. Während sich beispielsweise aktive EC2-Instanzen (Elastic Compute Cloud) – also virtuelle Computer in der Cloud – weiter ausführen ließen, wurden die EC2-APIs, die Kunden zum Starten neuer Instanzen oder zur Beschreibung ihrer aktuellen Instanzen verwenden, ab 7:33 Uhr PST durch massive Kommunikationsstörungen unbrauchbar. Als sich um 13:15 Uhr PST die Überlastung legte, begannen sich auch EC2-API-Fehlerrate und -Latenz zu verbessern, allerdings ließen sich neue EC2-Instanzen erst ab 14:40 Uhr PST erstellen. Kunden, die AWS-Services wie die Datenbank Amazon RDS (Relational Database Service), die Big-Data-Plattform EMR (Elastic MapReduce) oder den Remote Desktop Service Workspaces nutzten, konnten ebenfalls keine neuen Ressourcen anlegen, da sich keine neuen EC2-Instanzen starten ließen.
