Schwarzstart: Wie eine einzige VM eine hochverfügbare Infrastruktur in die Knie zwang

Haben Sie auch eine dieser Erinnerungen? Eine dieser Geschichten aus dem IT-Alltag, die man bei einem Kaffee (oder einem Bier nach Feierabend) erzählt und die bei Kollegen ein wissendes Nicken auslöst? Eine Geschichte, die einen auch Jahre später nicht loslässt, weil die Lektionen, die man gelernt hat, so fundamental waren?

Ich habe so eine. Sie handelt von einem hochredundanten System, verteilt auf zwei Rechenzentren. Einem System, das entworfen wurde, um dem Ausfall eines kompletten Standorts standzuhalten. Und sie handelt von einem 24-Stunden-Totalausfall, der eigentlich unmöglich sein sollte.

Dies ist die Anatomie dieses Ausfalls. Sie ist eine Mahnung, dass in der IT Murphys Gesetz allgegenwärtig ist: Alles, was schiefgehen kann, wird schiefgehen. Besonders, wenn es um ein „Provisorium“ geht.

Das Setup: Ein Bollwerk der Redundanz (theoretisch)

Vor etwa einem Jahrzehnt war ich Teil eines Teams, das eine damals hochmoderne VMWare-Infrastruktur für einen unserer Kunden betreute. Das Setup war, auf dem Papier, eine Festung der Verfügbarkeit:

Zwei Rechenzentren (RZ): Physisch getrennte Standorte, verbunden durch Dark Fibre.
Rechenleistung: Mehrere voll bestückte IBM BladeCenter in beiden RZs.
Virtualisierung: Ein großes, über beide Standorte gestrecktes VMware-Cluster, auf dem Hunderte von kritischen Linux-VMs liefen.
Storage-Backend: Das Herzstück. Ein leistungsstarkes Fibre-Channel-SAN-System, dessen Controller ebenfalls auf beide RZs verteilt und die Daten synchron gespiegelt waren.

Das erklärte Ziel war glasklar: Absolute Redundanz. Fällt ein Blade-Chassis aus? Kein Problem, vMotion schiebt die VMs woanders hin. Fällt ein komplettes Rechenzentrum durch einen Stromausfall oder eine Naturkatastrophe aus? Kein Problem, das zweite RZ sollte nahtlos übernehmen. Wir fühlten uns sicher. Zu sicher.

Der Auslöser: Der unscheinbare Single Point of Failure

Um zu verstehen, was schiefging, müssen wir über ein Kernkonzept von hochverfügbaren Storage-Clustern sprechen: den Quorum Witness (QW).

Stellen Sie sich einen Storage-Cluster mit zwei Köpfen (Controllern) vor, einen in jedem Rechenzentrum. Wenn die Verbindung zwischen den beiden ausfällt, stehen beide vor einer existenziellen Frage: „Bin ich derjenige, der noch lebt, oder bin ich vom Rest des Netzwerks isoliert?“ Wenn beide Controller zu dem Schluss kämen, sie seien der „Master“, würden sie beide Schreibzugriffe annehmen. Dies würde zu einem katastrophalen Zustand führen, der als „Split-Brain“ bekannt ist – zwei inkonsistente Versionen der Wahrheit, die eine Datenrettung nahezu unmöglich machen.

Hier kommt der Quorum Witness ins Spiel. Er ist ein unabhängiger Schiedsrichter. Bei einem Verbindungsabbruch versucht jeder Controller, den QW zu erreichen. Nur der Controller, der den QW erreichen kann, darf weitermachen. Der andere nimmt an, dass er isoliert ist, und legt den Zugriff auf die Daten (die LUNs) still, um Datenkorruption zu verhindern. Eine simple, aber effektive Logik.

Unsere kritische Schwachstelle? Der Quorum Witness war nicht, wie es Best Practice gewesen wäre, auf einer dedizierten, unabhängigen Hardware (z.B. einem kleinen physischen Server in einem dritten Standort) untergebracht. Er war eine winzige virtuelle Maschine. Provisioniert auf genau dem Storage-Cluster, den er überwachen sollte.

Es war ein Provisorium. Eingerichtet während der initialen Inbetriebnahme mit dem festen Vorsatz: „Das machen wir später richtig.“ Dieser Satz sollte uns noch in den Ohren klingeln.

Die Kettenreaktion: Vom Crash zum Totalausfall

An einem ganz normalen Dienstag passierte das Unvermeidliche.

Schritt 1: Der SAN-Cluster im ersten Rechenzentrum (nennen wir ihn Cluster A) erlitt einen schweren, nicht behebbaren Hardware-Ausfall. Mehrere Controller-Komponenten fielen gleichzeitig aus. Genau das Szenario, für das unser redundantes Setup gebaut war. Eigentlich kein Grund zur Panik.
Schritt 2: Da die VM mit dem Quorum Witness ihre virtuelle Festplatte auf dem Storage von Cluster A hatte, stürzte mit dem Cluster auch der QW ab. Er war von einer Sekunde auf die andere weg.
Schritt 3: Jetzt blickte der zweite, eigentlich völlig intakte SAN-Cluster (Cluster B) im zweiten Rechenzentrum auf die Situation. Seine Status-Checks ergaben zwei Dinge gleichzeitig:
1. Die Verbindung zum Partner-Cluster (Cluster A) ist tot.
2. Die Verbindung zum Schiedsrichter (Quorum Witness) ist ebenfalls tot.
Schritt 4: Nach den eisernen Regeln der Cluster-Logik musste Cluster B nun vom Schlimmsten ausgehen. Aus seiner Sicht war es möglich, dass Cluster A und der Quorum Witness noch liefen und nur er, Cluster B, isoliert war. Um unter allen Umständen ein Split-Brain zu verhindern, tat er das einzig Sichere: Er deklarierte sich selbst als die „Split-Brain-Minderheit“ und deaktivierte den Zugriff auf sämtliche Storage-Volumes.

Das Ergebnis war ein digitaler Herzstillstand. Von einer Sekunde auf die andere verloren rund 200 virtuelle Maschinen ihre Festplatten. Das gesamte System stand still. Totalausfall.

Der "War Room": 24 Stunden aus Technik und Menschlichkeit

Was folgte, war einer der längsten Krisen-Calls meiner Karriere. Der „War Room“ war virtuell, eine WebEx-Konferenz, die über 24 Stunden ununterbrochen laufen sollte. Eine kleine Anekdote am Rande: Damals hatten WebEx-Meetings ein hartes Zeitlimit von 10 Stunden. Mitten in der Nacht, auf dem Höhepunkt der Krise, mussten wir hektisch eine neue Konferenz aufsetzen und alle Teilnehmer dorthin migrieren.

Doch was mir von diesen 24 Stunden am stärksten in Erinnerung geblieben ist, war nicht nur die fieberhafte technische Fehlersuche. Es war der menschliche Zusammenhalt. Das Kernteam aus Storage- und VMware-Spezialisten arbeitete sich durch die Nacht, versuchte, den Cluster manuell und ohne Quorum wiederzubeleben.

Das Besondere war: Viele andere Teammitglieder, deren Fachgebiete (z.B. Applikationen, Datenbanken) in diesem Moment nicht direkt gefragt waren, blieben freiwillig in der Leitung. Stundenlang. Sie waren einfach da, um den aktiven Technikern den Rücken freizuhalten, Fragen von außen abzuschirmen und moralische Unterstützung zu leisten. Es war ein stillschweigendes Versprechen: „Wir sind hier. Ihr seid nicht allein.“

Die Lehren: Was wir aus dem Abgrund mitnahmen

Nach über 24 Stunden lief das System wieder. Der „Schwarzstart“ war gelungen. Doch die Erleichterung war gemischt mit der bitteren Erkenntnis, wie fragil unser „Bollwerk“ in Wahrheit gewesen war. Die Lehren, die wir daraus zogen, haben meine Arbeit als Architekt bis heute geprägt.

Lektion 1: Die Tücke des Provisoriums. Dies ist die wichtigste Lektion. Der Satz „Das machen wir später richtig“ ist einer der gefährlichsten in der IT. Ein Provisorium, das in Produktion geht, ist kein Provisorium mehr. Es ist eine tickende Zeitbombe. Murphys Gesetz garantiert, dass sie genau dann hochgeht, wenn die Bedingungen am ungünstigsten sind.
Lektion 2: Wahre Redundanz verstehen. Redundanz ist kein Feature, das man kauft. Es ist ein Konzept, das man Ende-zu-Ende verstehen und implementieren muss. Wir hatten redundante Server, redundante Storage-Controller und redundante Standorte. Aber wir hatten eine fatale logische Abhängigkeit übersehen, die das gesamte Konzept aushebelte. Man muss die gesamte Kette der Abhängigkeiten analysieren, nicht nur die einzelnen Glieder.
Lektion 3: Der Zugriff auf die Dokumentation. Die Ironie des Ganzen? Unser detaillierter Notfallplan, die Dokumentation zur Wiederherstellung des SAN-Clusters, lag… auf einem Wiki. Dessen VM lag auf dem ausgefallenen Cluster. Wir hatten keinen Zugriff auf unsere eigene Rettungsanleitung, als wir sie am dringendsten brauchten. Seit diesem Tag predige ich: Kritische Notfalldokumentation gehört an einen unabhängigen, externen Ort (Cloud Storage, ein ausgedrucktes Handbuch im Tresor – irgendetwas, das nicht vom Ausfall selbst betroffen ist).
Lektion 4: Der Faktor Mensch. In der tiefsten Krise, wenn die Technik versagt, kommt es auf das Team an. Technisches Können ist die eine Hälfte der Miete. Teamgeist, Vertrauen und gegenseitige Unterstützung sind die andere. Ein Team, das zusammenhält, kann fast jedes technische Problem lösen. Dieser Vorfall hat das eindrucksvoll bewiesen.

Fazit: Mehr als nur eine Erinnerung

Diese Geschichte ist mehr als nur eine Anekdote. Sie ist ein Plädoyer für Sorgfalt, für ein tiefes Verständnis der Systeme, die wir bauen, und für eine gesunde Portion Paranoia. Sie ist eine Erinnerung daran, dass die komplexesten Systeme an den einfachsten Stellen scheitern können.

Ich lade Sie ein: Nehmen Sie sich einen Moment Zeit und denken Sie über Ihre eigenen Systeme nach. Wo verstecken sich Ihre „Provisorien“? Welche Abhängigkeiten haben Sie vielleicht übersehen? Ist Ihr Notfallplan wirklich zugänglich, wenn der Notfall eintritt?

Solche Vorfälle sind schmerzhaft, teuer und nervenaufreibend. Aber die wertvollsten Lektionen über Technik, Design und Teamwork lernt man oft nur im Angesicht einer echten Krise. Sie machen uns zu besseren Ingenieuren, besseren Architekten und besseren Kollegen.

Genau solche Erfahrungen teilen wir in unserem Blog. Wenn Sie mehr darüber erfahren wollen, wie wir Technologien einsetzen, Herausforderungen meistern und gemeinsam Lösungen entwickeln, dann werfen Sie einen Blick in unsere weiteren Beiträge, z.B. zu unserem Ansatz zur Versionierung. Vielleicht finden Sie dort genau die Inspiration, die Sie gerade brauchen.