Github: 43 Sekunden ohne Netzwerk führen zu 24 Stunden Ausfall
Der Technologiechef von Github, Jason Warner, beschreibt im Blog des Unternehmens(öffnet im neuen Fenster) recht ausführlich den Ablauf eines Vorfalls in der vergangenen Woche, der durch die unglückliche Verknüpfung verschiedener Umstände zu einem Teilausfall der Github-Dienste über 24 Stunden geführt hat. Ausgangspunkt war demnach der routinemäßige Wechsel einer 100-GBit-Glasfaserverbindung in einem der Github-Rechenzentren. Der Wechsel führte jedoch für die Dauer von 43 Sekunden zum Abbruch der Netzwerkverbindung, was große Folgen haben sollte.
Denn der kurzzeitige Netzwerkausfall verursachte Inkonsistenzen in den MySQL-Datenbanken des Betreibers. Zur Verwaltung seiner verschiedenen MySQL-Cluster nutzt Github die eigene Software Orchestrator, die beim Ausfall des Netzwerks genau das machte, was zu erwarten war: Die Orchestrator-Software veranlasste einen Failover der Schreibzugriffe von dem nicht mehr erreichbaren Rechenzentrum an der US-Ostküste zu jenem an der US-Westküste.
Sobald die Netzwerkverbindung jedoch wiederhergestellt worden war, registrierte das System Schreibzugriffe im Rechenzentrum an der US-Ostküste, die nicht an der US-Westküste repliziert worden waren und umgekehrt. Diese Inkonsistenz führte unter anderem zu einigen Problemen mit internen Diensten. Darüber hinaus überlastete die Latenz zwischen den Rechenzentren den Cluster an der Westküste, da nun alle Dienste in dem Rechenzentrum der Ostküste ihre Daten in den Westküsten-Cluster geschrieben hatten.
Sicherung der Daten hat Priorität
Um die Integrität der Nutzerdaten nicht zu gefährden, hat sich das Team schließlich entschlossen, einige Dienste von Github so herunterzufahren, dass diese keine weiteren Daten in den Datenbank-Cluster schreiben können. Betroffen davon waren unter anderem die Webhooks und die Möglichkeit Github-Pages zu erstellen.
Github informierte seine Nutzer zwar kurz über Twitter und die hauseigene Statusseite, konnte allerdings erst Stunden später im eigenen Blog auf das Ereignis näher eingehen(öffnet im neuen Fenster) . Der Grund dafür ist, dass Github für seinen Blog intern ebenfalls auf die Pages setzt, deren Veröffentlichung aber eigentlich ausgesetzt worden war. Es bedurfte also einer "größeren Anstrengung" den Blog-Post zu veröffentlichen. In Zukunft will Github Vorkehrungen treffen, um schneller reagieren zu können.
Mühsame Wiederherstellung
Das zuständige Team hat zwar einen Plan erstellt, um die Inkonsistenzen in den Datenbanken zu beheben, die Daten ordnungsgemäß zu replizieren und die ursprüngliche Topologie wieder aufzubauen. Doch während dies umgesetzt wurde, begann der Arbeitstag in Europa und später in den USA, so dass die Cluster dann eine deutlich größere Anzahl an Schreibzugriffen verarbeiten mussten. Das wiederum verlangsamte jedoch den Wiederherstellungsprozess.
Betroffen waren davon laut dem Blogeintrag etwa fünf Millionen Webhook-Ereignisse und rund 80.000 Pages-Builds. Erst etwas mehr als 24 Stunden nach dem Beginn des Ausfalls waren sämtliche ausstehenden Wiederherstellungsarbeiten abgeschlossen und die Github-Dienste konnten wieder normal arbeiten.
Derzeit untersucht das Team noch knapp 1000 Schreibzugriffe, die möglicherweise nicht richtig von Github verarbeitet worden sind und so zu einem Datenverlust geführt haben könnten. Davon betroffene Nutzer haben ihre Aktionen jedoch zwischenzeitlich einfach wiederholt und so sicher durchführen können. Durch eine detaillierte Analyse will das Team außerdem noch herausfinden, welche dieser Zugriffe noch automatisiert wiederhergestellt werden können und für welche das Team betroffene Nutzer explizit kontaktieren muss.
Darüber hinaus will Github künftig systematisch verschiedene Fehlerszenarien testen und in sogenanntes Chaos-Engineering investieren.
- Anzeige Hier geht es zum Handbuch für Softwareentwickler bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.