• Wir führen Instantaneous PowerLoss Storm ein, ein neues Testparadigma innerhalb der Meta-Infrastruktur zur Verwaltung und Abmilderung plötzlicher oder unvorhergesehener Stromausfälle in unseren Rechenzentren.
• Wir teilen: Wie wir mithilfe tiefgreifender Verteidigungsstrategien die Bereitschaft aufgebaut haben, sofortige Ausfälle in unseren bestehenden Systemen zu tolerieren; welche Kompromisse bei der Umsetzung eingegangen wurden und wie wir unsere Bereitschaft bekräftigt haben.

---

Katastrophenvorsorge ist keine Option. Hurrikane, Waldbrände, Strom- und Netzwerkstörungen, und unzählige andere Katastrophenszenarien stellen Risiken für unser Rechenzentrum dar (Gleichstrom) Infrastruktur.

Frühwarnsysteme und bewährte Schadensbegrenzungsstrategien leisten uns bereits gute Dienste in Situationen, in denen die Vorwarnung einige Stunden oder länger dauert. Während diese Strategien im Laufe der Zeit ausgereift sind, da wir unsere DC-Präsenz erweitert haben, Die immer größer werdende Größe und Vielfalt unserer Infrastruktur erfordert ein höheres Maß an Vorbereitung auf unvorhersehbare Katastrophen (solche, die ohne Vorwarnung auftreten), wie zum Beispiel: sofortiger Leistungsverlustmit minimale Auswirkung auf die Gesamtverfügbarkeit der Flotte.

Instantaneous PowerLoss Storm ist ein neues Testparadigma innerhalb der seit langem etablierten Metamethode Katastrophenvorsorge (DR)”Sturm”-Programm, das die letzte Verteidigungslinie und das ultimative Sicherheitsnetz bietet, um sofortige oder unvorhergesehene Stromausfälle aufgrund bekannter Umstände zu bewältigen und zu mildern, aufkommende und unbekannte Risiken.

Wie wir mithilfe von Defense-in-Depth-Strategien die Bereitschaft aufgebaut haben, sofortige Ausfälle in unseren bestehenden Systemen zu tolerieren.

Die Fähigkeit, einen sofortigen Stromausfall zu bewältigen, musste von Grund auf in unseren DC-Stack integriert werden, von Mechanik und Elektrik bis hin zu Server-Racks, vom Speicher bis zur Rechenleistung und dem Kern Kabel Container-Orchestrator. Glücklicherweise, Jede dieser Architekturen wurde bereits mit Stromausfalltoleranz als integraler Bestandteil entwickelt.

Bietet die Möglichkeit, In-Memory-Daten beizubehalten, wenn Racks mithilfe von Batterien und wiederaufladbaren Batterien keinen Strom mehr haben Sirene bei Stromausfall (Bitte) ist eine solche Fähigkeit. Ein weiterer Vorteil besteht darin, dass über einen robusten DC-regionweiten asynchronen Signalisierungsmechanismus für Twine-Dienste in Form von Nichtverfügbarkeitsereignissen verfügt (UE). (Eine DC-Region – im Folgenden als a bezeichnet „Region“ – ist eine Region, in der mehrere DC-Gebäude nebeneinander liegen und sich ein gemeinsames Netzwerk und einen Stromanschluss teilen.)

Während diese Fähigkeiten in einzelnen Fehlerdomänen innerhalb einzelner DCs kampferprobt und gehärtet wurden, Wir haben in Szenarien, die sich über eine ganze Region erstreckten, auffällige Schwachstellen identifiziert. Zusätzlich, beim Testen einer Region, Wir mussten uns nicht nur mit Fragen der Skalierung auseinandersetzen (Eine typische Region ist typischerweise 50- bis 60-mal so groß wie die typischen Fehlerdomänen) und Replikatplatzierung, aber auch Probleme des autonomen Bootstrappings.

Bootstrapping bezieht sich auf den Kickstart einer ausgeschalteten Region und erfordert, dass Millionen von Diensten gleichzeitig gestartet werden und sich gegenseitig automatisch erkennen. Im Folgenden beschreiben wir zwei der Probleme, auf die wir beim Bootstrapping gestoßen sind und die die Einführung von a erforderten Ansatz mit Gürtel und Hosenträgern um alle möglichen Eventualitäten und Eventualitäten abzudecken.

Ein herausragendes Problem, das uns von Anfang an verfolgt hat, sind die Abhängigkeiten und insbesondere die gefürchteten Abhängigkeiten zirkuläre Abhängigkeit, „ouroboros„Risiko! Unser Twine-Orchestrator verfügt über eine Reihe von Steuerungsebenendiensten – PlanerAllokator, Makler, Eifrig (Koordinator) usw. – ohne die wir keine weiteren Dienste in der Region betreiben oder starten können. Während das Risiko zirkulärer Abhängigkeiten im regulären Betrieb gering ist, Das Risiko und die Auswirkungen sind beim Bootstrapping einer gesamten Region weitaus höher. Es ist ein echtes Henne-Ei-Problem.

Wir haben dieses Problem durch Identifizierung gelöst kritische Startabhängigkeiten zu den Kontrollflugzeugdiensten, und wir entdecken diese ständig früh und oft mit Belljar-Tests in unseren CI/CD-Pipelines. Diese haben dazu beigetragen, die meisten aufzudecken und zu beseitigen, wenn nicht alle, Abhängigkeitsrisiken, bevor Sie sie in der Produktion einsetzen. Angesichts der rasanten Entwicklung unserer Infrastruktur und als Gürtel-und-Hosenträger-Lösung, das brauchten wir auch Fähigkeit Zu Brechen Sie alle zirkulären Abhängigkeiten auf Dies kann unerwartet geschehen sein. Ein speziell entwickeltes Twine-Wiederherstellungskit bietet diese „Starthilfe“-Funktion zur Wiederherstellung der Twine-Dienste, die Twine selbst betreiben. Zusammen mit Belljar und Twrko, Es ist uns gelungen, das Gespenst der zirkulären Abhängigkeiten erfolgreich zu beenden.

Wir sind auch auf einem „Boomerang“ Problem in der gleichen Umgebung – Der Generator eines kritischen Signals, das von demselben Signal beeinflusst wird. Die UEs, die zum Orchestrieren des Herunterfahrens und Wiederherstellens von Diensten verwendet wurden, führten letztendlich dazu, dass die Orchestrator-Steuerungsebenendienste selbst heruntergefahren wurden, Dies führte zu verwaisten Diensten, die nicht mehr ausgeführt werden konnten.geerntet” (weil sie nie eine UE erhalten haben.) Dieses Problem hätte zwar mit komplizierten Lösungen gelöst werden können, beispielsweise durch den Ausschluss einer voreingestellten Reihe von Diensten aus der UE-Versandliste, Wir haben uns für einen einfacheren und nachhaltigeren Ansatz entschieden, indem wir den Steuerungsebenendiensten erlauben, Abschaltsignale, die mit energiebezogenen UEs verbunden sind, einfach zu „ignorieren“..

Kompromisse bei der Suche nach der richtigen Balance zwischen Zuverlässigkeit und Wachstumsgeschwindigkeit.

Zwar ist es möglich, eine wasserdichte Toleranz gegenüber unmittelbaren Verlusten aufzubauen, Dies kann mit Opportunitätskosten für die Infrastruktur oder dem Risiko einer Überentwicklung unserer Systeme verbunden sein. Letzteres birgt sogar die Gefahr, dass Fehlalarme den regulären Betrieb beeinträchtigen. daher, Wir mussten bestimmte Kompromisse eingehen, um die richtige Balance zwischen Zuverlässigkeit und Technologie zu finden.

Wir begannen damit, die Grenze zu ziehen, ab der Stöße vermieden werden müssen. Datenverlust aus Speicher- und Datenbanksystemen, dauerhafte Schäden an DC-Einrichtungen (mechanisch/elektrisch), oder nachhaltige Auswirkungen über eine einzelne Region hinaus sind einige, die wir klar als wesentliche Anforderungen benannt haben. Vorübergehende Dienstausfälle, Rackausfälle (innerhalb einer vordefinierten Schwelle), und begrenzte Veralterung in Service-Routing-Tabellen oder bei der Erkennung der Nichtverfügbarkeit von Regionen (Das ist ein Problem). schwieriges Problem für asynchrone Systeme) wurden als tolerierbare Risiken angesehen. Im Allgemeinen, Nur Probleme, die außerhalb der Grenze tolerierbarer Auswirkungen liegen und nicht durch Abhilfemaßnahmen nach dem Vorfall und innerhalb einer angemessenen mittleren Reaktionszeit gemildert werden können (MTTR).

Wie wir unsere Bereitschaft durch die Übung „Instantaneous PowerLoss Storm“ bestätigt haben und wie wir dadurch die Grenzen noch weiter verschieben können.

Die Bestätigung der oben genannten Erwartungen und die Vorbereitung durch die Schließung einer großen Produktionsregion bergen erhebliche Risiken mit mehreren bekannten und unbekannten Unbekannten. Um dieses Henne-Ei-Problem zu lösen, Risiken einzugehen, um Risiken anzugehen, Wir haben einen inkrementellen Ansatz entwickelt, bei dem wir in sich geschlossene Probleme wie Abhängigkeiten validierten, wenn neue Regionen/Vorproduktionsregionen entstanden, und Tests in „Schattenregionen“ durchführten, die Produktionsregionen replizieren. Anschließend konnten wir unser Neustes erfolgreich testen (und daher am kleinsten) Produktionsregionen mit begrenztem Explosionsradius. Endlich, Wir haben große Produktionsregionen geschlossen, in denen sich kritische Lager befinden, KI, und Data-Warehouse-Workloads. An dieser Stelle haben wir diese Angriffsübungen benannt Sofortige Unwetter mit Stromausfällen.

Aus einer Höhe von 10,000 Füße, Der Sturm besteht aus einem injizierten Stromausfall, der nach einer kurzen MTTR zu einer sofortigen Abschaltung der gesamten Region führt, Es werden Abhilfemaßnahmen ergriffen, um die betroffene Region von globalen Kontrolleuren/Planern abzuschotten. Außerdem wollten wir vermeiden, vor dem Test vorbeugende Maßnahmen zu ergreifen, die tatsächlich einen unerwarteten Stromausfall darstellen könnten. Die für den Test ausgewählte MTTR spiegelte die typische MTTR wider, die in realen Vorfallszenarien beobachtet wurde.

Jede dieser Übungen trug dazu bei, unsere Infrastruktur und Ingenieure schrittweise auf das langfristige Ziel hin zu schulen, den Verlust einer Region ebenso nahtlos zu bewältigen wie den Verlust einer subregionalen Verwerfungsdomäne.

Sprungbrett in die Zukunft: Langsam ist sanft. Glatt ist schnell

Trotz aller Vorsichtsmaßnahmen, Dies war keine völlig reibungslose Reise, sondern eine Reise mit zahlreichen Möglichkeiten zum Lernen und zur Verbesserung, was nicht nur unsere Testmöglichkeiten verbesserte, sondern spiegelte sich auch in unserer gesamten Infrastruktur wider und führte zu mehreren architektonischen Verbesserungen unserer bestehenden Systeme.

Unsere im Tandem Infra hat sich schnell weiterentwickelt und deckt unzählige Anwendungsfälle von Kapazität und KI ab. Schnelles Handeln ist nur möglich, wenn wir ein starkes Fundament haben. Zuverlässigkeit Und Geschwindigkeit sind zwei Facetten derselben Medaille. Man kann das eine nicht ohne das andere haben. Die Fähigkeit, eine Region nach einem plötzlichen Ausfall wiederherzustellen, hat eine solide Grundlage geschaffen, die es uns ermöglicht, DC-Designs zu innovieren und zu validieren, Bauen Sie Zuverlässigkeit im Gleichschritt mit schnellen Kapazitätsbereitstellungen auf, und weiterhin die Grenzen des Risikos verschieben, das wir tolerieren können.

Während frühere Stürme vor allem Speicher- und Datenbank-Backends validierten, Wir verfolgen die gleiche inkrementelle Strategie, um Regionen mit Live-Client-Verkehr gegen sofortige Ausfälle zu validieren. (Mehr dazu in einem kommenden Beitrag!) Darüber hinaus überprüfen und überarbeiten wir laufend Kompromisse angesichts neuer Herausforderungen, die sich in dieser Wachstumsphase ergeben.