Single Point of Failure

Ein Single Point of Failure (SPOF) ist eine gefürchtete Schwachstelle in Form einer einzelnen Komponente. Versagt die Komponente, kommt es zum Ausfall des gesamten Systems. Wir zeigen, welche Arten von SPOF es gibt und wie sich das Risiko für das Auftreten eines SPOF minimieren lässt.

Als „Single Point of Failure“ (SPOF) wird eine Art von Schwachstelle innerhalb eines Systems bezeichnet. Ein SPOF liegt dann vor, wenn der Ausfall einer einzelnen Komponente den Totalausfall des Gesamtsystems bewirkt. Dabei existieren mehrere „failure modes“, also Fehlermöglichkeiten. Die am häufigsten anzutreffenden lassen sich in drei grobe Kategorien einordnen:

1. Achillesferse bzw. „schwächstes Glied der Kette“: Der Wegfall einer Komponente führt zum schlagartigen Verlust der Funktion des Gesamtsystems.
2. Kettenreaktion bzw. „Domino-Effekt“: Das Versagen einer Komponente bewirkt das sukzessive Versagen weiterer Komponenten, bis zum Versagen des Gesamtsystems.
3. Engpass bzw. „Flaschenhals“: Eine Komponente wirkt als limitierender Faktor des Gesamtsystems. Bei Beeinträchtigung der limitierenden Komponente wird die Leistungsfähigkeit des Systems auf die Kapazität der Komponente reduziert.

Am häufigsten anzutreffen sind SPOFs in komplexen Systemen, die miteinander verknüpfte Komponenten in mehreren Schichten enthalten. Je nach Aufbau des Systems bewirkt das Versagen einer kritischen Komponente den Ausfall des gesamten Systems. Dann liegt ein Single Point of Failure in Form der kritischen Komponente vor.

Die Komplexität eines mehrschichtigen Systems macht es ggf. schwierig, SPOFs zu erkennen. Es fehlt schlichtweg der Überblick, um die Wechselwirkungen der einzelnen Komponenten wahrzunehmen. Dann ist es unmöglich, Gefahren zu identifizieren und Gegenmaßnahmen zu ergreifen. Prinzipiell sollte jegliche für den Betrieb kritische, nicht redundant ausgelegte Komponente als Single Point of Failure betrachtet werden.

Denken wir beispielshalber an den menschlichen Körper. Die kritischen Organe Herz und Gehirn sind pro Körper nur einfach vorhanden und damit nicht redundant ausgelegt. Ein Ausfall eines dieser Organe führt zum Versagen des Körpers. Ergo handelt es sich bei Herz und Gehirn um SPOFs. Demgegenüber sind Augen, Ohren, Lungenflügel und Nieren doppelt ausgelegt. Der Körper kompensiert bei Bedarf den Ausfall einer Seite und operiert mit verminderter Leistungsfähigkeit weiter.

Mit Bezug zum Rechenzentrum zeigen sich einige Parallelen. Alle für den Betrieb kritischen Komponenten stellen potenzielle SPOFs dar. Daher sind Server für gewöhnlich mit redundanten Anbindungen an Stromnetz und Netzwerk versehen. Auch Massenspeicher werden über RAIDs oder ähnliche Technologien redundant bereitgestellt. Ziel ist, beim Versagen einer einzelnen, kritischen Komponente den Weiterbetrieb des Gesamtsystems sicherzustellen.

Es finden sich vielfältige Beispiele für Single Points of Failure (SPOFs) aus den unterschiedlichsten Bereichen. Denn SPOFs betreffen keinesfalls nur Informationssysteme. Schauen wir uns eine Handvoll eindrucksvoller Beispiele an.

In den beliebten „Star Wars“-Filmen führt ein Single Point of Failure zur Zerstörung des gefürchteten „Todessterns“. Ein einzelner vom Protagonisten abgefeuerter Protonentorpedo schlägt an einer kritischen Stelle des Reaktors ein. Die Explosion ruft eine katastrophale Kettenreaktion hervor, die den gesamten Todesstern vernichtet.

Im Jahr 2021 kam es zur beispiellosen Blockade des Suezkanals durch das Containerschiff „Ever Given“. Das Schiff war an einem kritischen Abschnitt des Kanals, der nur eine Wasserstraße umfasst, auf Grund gelaufen und stecken geblieben. Der Flaschenhals war verstopft, der Schiffsverkehr durch den gesamten Kanal lahmgelegt. Der Single Point of Failure war die nicht redundante Wasserstraße.

In den Jahren 2018 und 2019 kam es zu zwei Abstürzen des Flugzeugtyps „Boeing 737 MAX“ mit dem Verlust hunderter Menschenleben. Als Absturzursache wurde ein einzelner Sensor identifiziert, der fehlerhafte Daten lieferte. Auf Grundlage der Sensordaten reagierte das automatische Flugkontrollsystem katastrophal falsch und brachte das Flugzeug zum Absturz. Mehrere Fehler spielten zusammen; der Single Point of Failure war der nicht redundant ausgelegte Sensor.

Auch an sich für Hochverfügbarkeit konzipierte Systeme sind nicht vollständig gegen SPOFs geschützt. So kam es in den vergangenen Jahren immer wieder zu schweren Ausfällen großer Cloud-Dienste. Der Single Point of Failure war in den meisten Fällen der Mensch. Ein versehentlicher Push der falschen Konfigurationsdaten auf ein Produktionssystem legt dieses lahm, auch wenn dessen Komponenten redundant ausgelegt sind.

Vielleicht kennen Sie das Problem: das WiFi-Netzwerk am Laptop ist verbunden, doch Webbrowser und Mailprogramm verweigern den Dienst. Dazu häufen sich weitere, seltsame Fehler: Von der automatischen Zeiteinstellung bis zum Verbinden mit dem GitHub-Account über SSH – überall hakt es. Es ist zum Haareausraufen, dabei ist die Antwort ganz einfach:

Unter IT-versierten gilt das geflügelte Wort „It’s always DNS“ als humorvolle, jedoch ernstgemeinte Beschreibung für das Fehlerpotenzial des Domain Name Systems (DNS). Denn wenn DNS-Server nicht antworten, versagen Websites und Dienste auf vielfältige Weise. Der Effekt ist ähnlich, als wäre die Anbindung ans Internet gekappt. Forscht man nach, sieht man jedoch, dass der Paketverkehr zwischen IP-Adressen noch funktioniert.

Meistens treten DNS-Fehler auf Nutzerseite auf, wenn die im System hinterlegten DNS-Server nicht ansprechbar sind. Es gilt daher als Best Practice, immer zwei Nameserver-Adressen zu hinterlegen. Ist der erste Server nicht erreichbar, wird der zweite genutzt. Man schafft damit Redundanz und löst den Single Point of Failure auf.

Oft gehören beide DNS-Server zur selben Organisation. Fällt einer der beiden aus, ist die Wahrscheinlichkeit hoch, dass auch der andere betroffen ist. Um auf Nummer sicher zu gehen, hinterlegt man die Adressen zweier Nameserver von unterschiedlichen Organisationen. Eine beliebte Kombination ist 1.1.1.1 und 9.9.9.9 von Cloudflare und Quad9 als primärer und sekundärer DNS-Server.

Bis zum Ende des Jahres 2021 klaffte in einer Vielzahl Java-basierter Webservices die Sicherheitslücke Log4Shell. Der Single Point of Failure war eine Java-Logging-Bibliothek namens Log4J. Wurde ein verwundbares System angegriffen, kam es im schlimmsten Fall zu einer kompletten Übernahme des Systems.

Generell gilt: Vorbeugen ist die beste Strategie, um SPOFs zu vermeiden. Denn ein Single Point of Failure führt der Definition nach zum Funktionsverlust des gesamten Systems. Tritt dieser Fall ein, ist es in vielen Fällen zu spät: Meist lässt sich höchstens noch Schadensbegrenzung betreiben.

Grundlage für vorbeugende Maßnahmen ist die Planung für den Ernstfall. Man spielt glaubhafte Fehlerszenarien durch und analysiert die ausgehenden Risiken sowie mögliche Schutzmaßnahmen. Verschiedenen Arten des Single Point of Failure lässt sich durch spezifische Eigenschaften des umgebenden Systems vorbeugen:

Gut vorbereitet unterzieht man kritische Systeme kontinuierlicher Beobachtung, um auftretende Fehler möglichst frühzeitig zu erkennen und ggf. zu korrigieren.

In der Literatur findet sich am häufigsten die Empfehlung, SPOFs durch den Aufbau von Redundanzen entgegenzuwirken. Es werden mehrere Instanzen einer kritischen Komponente (z. B. Stromversorgung, Netzwerkanbindung, DNS-Server) parallel betrieben. Im Idealfall ist beim Versagen einer Instanz ein Weiterbetrieb des Systems ohne Leistungseinbuße möglich.

Auch softwareseitig beugt Redundanz vielen SPOFs vor. Ein Beispiel sind die beliebten Microservices im Gegensatz zum Software-Monolithen. Ein System aus Microservices gilt als stärker entkoppelt und weniger komplex und ist damit robuster gegenüber dem Auftreten von SPOFs. Da Microservices für gewöhnlich als Container gestartet werden, ist es einfacher, Redundanzen aufzubauen.

Doch wie genau schützt Redundanz ein System? Zum besseren Verständnis des Wirkprinzips bedienen wir uns der als „Lussersches Gesetz“ bekannten Abschätzung der Verlässlichkeit eines Systems. Exerzieren wir das an einem Gedankenbeispiel durch:

Nehmen wir an, ein System verfüge über zwei voneinander unabhängige, parallel geschaltete Anbindungen an die Stromversorgung. Nehmen wir ferner an, die Wahrscheinlichkeit für das Versagen der Anbindung innerhalb eines bestimmten Zeitraums betrage 1 Prozent. Dann lässt sich die Wahrscheinlichkeit für das komplette Versagen der Stromanbindung als Produkt der Wahrscheinlichkeiten berechnen:

1. Wahrscheinlichkeit des Versagens einer Instanz:

1% = 1 / 100 = 1 / 10 ^ 2 = 0.01

1. Wahrscheinlichkeit, dass hintereinander zwei Instanzen versagen:

1% * 1% = (1 / 10 ^ 2) ^ 2 = 1 / 10 ^ 4 = 0.0001

Wie Sie sehen, halbiert sich die Wahrscheinlichkeit für einen SPOF beim Betreiben von zwei Instanzen nicht etwa, sondern verringert sich um zwei Größenordnungen. Eine beachtliche Verbesserung. Bereits bei drei parallel betriebenen Instanzen dürfte ein Versagen des Gesamtsystems nahezu ausgeschlossen sein.

Leider ist Redundanz kein Allheilmittel. Vielmehr schützen Redundanzen ein System gegenüber SPOFs innerhalb bestimmter Annahmen. Zunächst muss gegeben sein, dass die Wahrscheinlichkeit für das Versagen einer Instanz unabhängig ist von der Wahrscheinlichkeit für das Versagen der redundanten Instanz(en). Nicht gegeben ist dies bereits, wenn das Versagen durch ein äußeres Ereignis hervorgerufen wird. Brennt das Datencenter, fallen redundante Komponenten zusammen aus.

Neben der Redundanz eingesetzter Komponenten ist eine Verteilung gewisser Komponenten kritisch, um SPOFs zu mindern. Geografische Verteilung von Datenspeichern und Recheninfrastruktur schützt vor Umweltkatastrophen. Ferner zahlt es sich aus, eine gewisse Heterogenität bzw. Diversität kritischer Systemkomponenten anzustreben. Diversität senkt die Wahrscheinlichkeit für das Versagen redundanter Instanzen.

Veranschaulichen wir uns den Vorteil von Diversität am Beispiel der Cybersicherheit. Stellen wir uns ein Datencenter mit redundanten Load-Balancern exakt gleicher Machart vor. Besteht bei einem der Load-Balancer eine Sicherheitslücke, liegt diese auch bei den redundanten Instanzen vor. Ein Angriff legt im schlimmsten Fall alle Instanzen lahm. Bei Einsatz verschiedener Modelle besteht eine bessere Chance für das Gesamtsystem, mit verminderter Leistungsfähigkeit weiter zu operieren.

Wie wir gesehen haben, ist Redundanz nicht immer ausreichend, um SPOFs vorzubeugen. Ferner gibt es Komponenten, die sich nicht redundant auslegen lassen. Wenn das Schaffen von Redundanz keine verfügbare Option darstellt, kommen andere Strategien zum Einsatz.

Aus der Cybersicherheit bekannt ist der „Defence in Depth“-Ansatz. Dabei werden mehrere, voneinander unabhängige Schutzringe um ein System gezogen. Diese müssen nacheinander durchbrochen werden, um ein katastrophales Resultat herbeizuführen. So wird ein Totalausfall aufgrund des Versagens einer einzelnen Komponente weniger wahrscheinlich.

In Bezug auf digitale Systeme existieren spezielle Programmiersprachen mit eingebauter Fehlertoleranz. Als bekanntestes Beispiel gilt die Ende der 1980er Jahre entwickelte Sprache „Erlang“. Gemeinsam mit der dazugehörigen Laufzeitumgebung eignet sich die Sprache zum Erstellen hochverfügbarer, fehlertoleranter Systeme.

Der globale Siegeszug des World Wide Web und die damit einhergehende Verbreitung der Webentwicklung brachte eine neue Herausforderung mit sich. Programmierer und Programmiererinnen sahen sich gezwungen, Websites zu entwickeln, die auf verschiedenen Endgeräten funktionieren. Der grundlegende dabei zum Einsatz kommende Ansatz ist als „Graceful Degradation“ bekannt. Unterstützt ein Browser oder Gerät eine bestimmte Technologie auf einer Seite nicht, wird diese so gut wie möglich dargestellt. Es handelt sich um einen „fail-soft“-Ansatz:

Um Single Points of Failure innerhalb der eigenen IT zu identifizieren, sollte man keinesfalls warten, bis der Fehlerfall eintritt. Stattdessen ist angeraten, im Rahmen einer Risikomanagement-Strategie proaktiv vorzugehen. Dabei kommen Analysen aus der Zuverlässigkeitstechnik wie Fehlerbaum- oder Ereignisbaumanalyse zum Einsatz. Die Failure Mode and Effects Analysis (FMEA, „Fehlermöglichkeits- und -einflussanalyse“) wird genutzt, um die kritischsten Fehlerquellen zu identifizieren.

Das generelle Vorgehen zur Identifikation von Single Points of Failure (SPOF) in der Unternehmens-IT besteht darin, eine Risikobewertung der drei hauptsächlichen Dimensionen durchzuführen:

• Hardware
• Software/Dienste/Anbieter
• Personal

Zunächst erstellt man eine SPOF-Analyse-Checkliste, welche die generellen Bereiche für die weiteren Analysen aufzeigt. Im Anschluss wird eine detaillierte SPOF-Analyse der einzelnen Bereiche durchgeführt. Man sucht nach:

• Nicht überwachten Geräten im Netzwerk
• Nicht redundanten Software- oder Hardware-Systemen
• Personal und Anbietern, die sich im Notfall nicht ersetzen lassen
• Jeglichen Daten, die nicht in Backups aufgenommen werden

Für jede Systemkomponente wird analysiert, welche negativen Effekt ein Versagen hätte. Ferner wird die ungefähre Wahrscheinlichkeit für das Auftreten eines katastrophalen Fehlers abgeschätzt. Die gewonnen Erkenntnisse fließen in einen übergeordneten „Disaster Recovery“-Plan (Notfallwiederherstellungsplan) ein, um die Sicherheit im Rechenzentrum zu gewährleisten.

Als grundlegende Maßnahme zur Vermeidung von SPOFs sollte Redundanz von Datenspeichern und Rechenkraft auf drei Ebenen sichergestellt werden:

• Auf der Server-Ebene durch redundante Hardware-Komponenten
• Auf System-Ebene durch Clustering, d. h. den Einsatz mehrerer Server-Instanzen
• Auf Rechenzentrum-Ebene durch Einsatz geografisch verteilter Betriebsstätten