Ausfall der Server: Amazon Web Services schaltete sich selbst ab
Ein ganzer Server-Cluster fiel bei AWS aus. US-Kunden konnten daher Dienste teils nicht mehr nutzen. AWS sieht die Schuld bei sich selbst.

Am 25. November 2020 konnten viele US-Kunden ihre Amazon-Web-Services-Dienste nicht verwenden. Der Grund: Die Zone US East 1 war nicht erreichbar. AWS erklärt nun auch im Detail, wo der ausschlaggebende Fehler gefunden wurde, der für den Ausfall gesorgt hat: beim eigenen Team. Nachdem einige weitere Rechenressourcen für den Datenstreamingdienst Kinesis hinzugefügt wurden, stürzte der gesamte Servercluster ab.
Zunächst vermutete das untersuchende AWS-Team richtig und nahm die hinzugefügten Kapazitäten wieder offline. Allerdings erschienen weitere, damit nicht verbundene Fehler im Log. Schnell wurde klar, dass ein kompletter Neustart des Frontend-Clusters durchgeführt werden müsse, um das Problem komplett zu beheben. Dies erfordert ein etappenweises Vorgehen, da sich die Dienste für Datenabfragen und die Dienste zum Erstellen einer Shard-Map - einem Regelsatz, der Abhängigkeiten von einzelnen Teilservern voneinander definiert - Ressourcen teilen. Das Abschalten vieler Systeme auf einmal würde demnach auch den jeweils anderen Dienst beeinflussen.
Der finale Grund waren tatsächlich neue Kapazitäten, die AWS hinzugefügt hatte. Durch diese wurde die maximal zulässige Anzahl an parallelen Threads überschritten, die vom Betriebssystem unterstützt werden. Daraus konnten Caches nicht mehr erfolgreich konstruiert werden, was wiederum die auf den Servern liegenden Shard-Maps verfälschte. Einzelne Geräte konnten folglich nicht mehr untereinander kommunizieren und das Worst-Case-Szenario war programmiert: ein Totalausfall des gesamten Systems.
Never change a running system
Statt das Threadlimit einfach blind ohne vorherige Tests und Prüfungen innerhalb des Betriebssystems zu erhöhen, hat AWS die neuen Ressourcen erst einmal wieder offline genommen und anschließend einzelne Knoten innerhalb der Flotte in kleineren Gruppen neu gestartet. Daher dauerte es eine Zeit lang, bis das System wieder fehlerfrei und mit funktionierenden Shard-Maps hochgefahren wurde.
Von alledem erfuhren betroffene Kunden teils erst mit einer spürbaren Verzögerung. Das lag laut Amazon daran, dass das Service Health Dashboard für die Kommunikation mit Kunden auf den Dienst Cognito setzt. Dieser wiederum baut auf Kinesis-Datenströme, die vom Ausfall betroffen waren. Ein solcher Kaskadeneffekt zeigt, wie oft doch der in der IT-Branche geläufige Spruch "Never change a running system" auch bei großen Konzernen noch angewendet werden kann.
Die Region US East 1 sollte derweil wieder ordnungsgemäß funktionieren. Zumindest hat AWS laut eigenen Aussagen dazugelernt. "Wir werden alles tun, um aus diesem Event zu lernen und das zu nutzen, um unsere Verfügbarkeit noch weiter zu verbessern".
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
Die hatte ein Thread pro Instance um mit den anderen Instanzen zu reden , d.h. das mit...
Eine perfekte Architektur gibt es nicht. Amazon weiß schon was sie tun und die...
Amazon wird dafür bezahlt in Sekunden riesige Rechenkapazitäten bereitzustellen. Die...