Amazon erläutert das Problem in der US East Region

Ein Routingfehler in der Folge eines manuellen Netzwerkupgrades für den Amazon Elastic Block Store (EBS) führte zu dem Ausfall in der US East Region der Amazon Cloud.

Der Amazon Elastic Block Store besteht aus zwei Netzwerken, einem Primären für die Verarbeitung von hohen Lasten und einem Sekundären für niedrigere Lasten. Über diese Netzwerke findet die Kommunikation der jeweiligen Cluster innerhalb einer EBS-Zone statt. Um das Update vorzunehmen musste zunächst der Netzwerkverkehr umgeleitet werden. Anstatt diesen jedoch auf einen anderen Router innerhalb des primären Netzwerkes umzuleiten, wurde der Verkehr der Nodes des Cluster in das sekundäre Netz geleitet, das dadurch völlig überlastet wurde. Die Folge war eine Verkettung von Problemen, die durch die Methoden zur redundanten Datenhaltung (um einen Datenverlust zu verhindern) vervielfacht wurden.

Auf Grund dieses Routingproblems waren einige EBS Nodes nicht mehr in der Lage auf das primäre sowie auf das sekundäre Netzwerk zuzugreifen und waren damit von den restlichen Nodes isoliert. Jeder Node repliziert im Normalfall seine Daten auf die anderen Nodes, wodurch eine hohe Verfügbarkeit der Daten erzielt wird. Durch den Verbindungsabbruch verloren die voneinander isolierten Nodes jedoch ihre Replizierungspartner. Nachdem das Routingproblem behoben war, begonnen die Nodes wieder damit, sich einen Replikationspartner mit ausreichend freiem Speicherplatz zu suchen. Dieser Vorgang dauert in einem funktionsfähigem Cluster gewöhnlich nur ein paar Millisekunden. Durch die Masse an Anfragen war jedoch nicht mehr ausreichend Speicherplatz innerhalb des Cluster vorhanden, was dazu führte, dass die Replikation deutlich länger dauerte. Auf Grund dieser Konstellation waren 13 Prozent der EBS Nodes nicht mehr in der Lage Schreib- bzw. Leseanfragen zu beantworten. Zudem war das EBS Kontrollsystem nicht mehr zu 100% funktionsfähig, wodurch innerhalb des Cluster keine neuen Volumes mehr erstellt werden konnten. Durch zwei weitere Missstände wurde die Situation noch verschäft. Zum einen suchten die nicht mehr funktionsfähigen Nodes weiterhin nach freiem Speicherplatz und zum anderen führte eine Race-Condition innerhalb des EBS Programmcodes dazu, dass weitere EBS Nodes ausfielen.

Da die Amazon EC2 Instanzen die EBS Volumes nutzen, um darauf ihre Daten persistent zu speichern, wurden sie dadurch ebenfalls in Mitleidenschaft gezogen. Der Wechseln eines Replikationspartners muss der zugeordneten EC2 Instanz mitgeteilt werden. Das ist im Normalfall in Ordnung. Während des Problems führte diese Methodik jedoch dazu, dass der Kontrolldienst für diese Replikation ebenfalls überlastet wurde, wodurch sich die gesamte Überlast auf die anderen Availability Zones auswirkte.

Ebenfalls von dem Ausfall betroffen war der Amazons Relational Database Service (RDS), der EBS verwendet, um darauf Datenbanken und Logdateien abzulegen. Hier besteht das Problem darin, dass der Ausfall eines EBS Volumes dazu führt, dass die komplette RDS Instanz stehen bleibt. Normalerweise greift eine RDS Instanz parallel auf mehrere EBS Volumes zu. Daher waren innerhalb der Availability Zone davon um die 45 RDS Instanzen betroffen.

Wie von mir bereits empfohlen, sollte sich ein Unternehmen nicht auf die Nutzung einer einzigen Availability Zone konzentrieren, sondern seine Anwendung über mehrere Zonen hinweg betreiben. Im Idealfall sogar über mehrere Regionen hinweg. Amazon ist sich mittlerweile jedoch bewusst, dass die Nutzung mehrerer Availability Zones die Komplexität der Anwendung erhöht und will daran in Zukunft nachbessern. Darüber hinaus soll das Monitoring von Änderungen innerhalb der Infrastruktur verbessert und die Fehlertoleranz von EBS erhöht werden. Zudem wird die Gesamtkapazität freier Ressourcen erhöht, um damit ähnlichen Problemen entgegenzuwirken, sowie das Fehlerverhalten der EBS Nodes angepasst.