Single Point of Failure

Ein Single Point of Failure (SPOF) ist eine ge­fürch­te­te Schwach­stel­le in Form einer einzelnen Kom­po­nen­te. Versagt die Kom­po­nen­te, 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 mi­ni­mie­ren lässt.

Als „Single Point of Failure“ (SPOF) wird eine Art von Schwach­stel­le innerhalb eines Systems be­zeich­net. Ein SPOF liegt dann vor, wenn der Ausfall einer einzelnen Kom­po­nen­te den To­tal­aus­fall des Ge­samt­sys­tems bewirkt. Dabei exis­tie­ren mehrere „failure modes“, also Feh­ler­mög­lich­kei­ten. Die am häu­figs­ten an­zu­tref­fen­den lassen sich in drei grobe Ka­te­go­rien einordnen:

1. Achil­les­fer­se bzw. „schwächs­tes Glied der Kette“: Der Wegfall einer Kom­po­nen­te führt zum schlag­ar­ti­gen Verlust der Funktion des Ge­samt­sys­tems.
2. Ket­ten­re­ak­ti­on bzw. „Domino-Effekt“: Das Versagen einer Kom­po­nen­te bewirkt das suk­zes­si­ve Versagen weiterer Kom­po­nen­ten, bis zum Versagen des Ge­samt­sys­tems.
3. Engpass bzw. „Fla­schen­hals“: Eine Kom­po­nen­te wirkt als li­mi­tie­ren­der Faktor des Ge­samt­sys­tems. Bei Be­ein­träch­ti­gung der li­mi­tie­ren­den Kom­po­nen­te wird die Leis­tungs­fä­hig­keit des Systems auf die Kapazität der Kom­po­nen­te reduziert.

Am häu­figs­ten an­zu­tref­fen sind SPOFs in komplexen Systemen, die mit­ein­an­der ver­knüpf­te Kom­po­nen­ten in mehreren Schichten enthalten. Je nach Aufbau des Systems bewirkt das Versagen einer kri­ti­schen Kom­po­nen­te den Ausfall des gesamten Systems. Dann liegt ein Single Point of Failure in Form der kri­ti­schen Kom­po­nen­te vor.

Die Kom­ple­xi­tät eines mehr­schich­ti­gen Systems macht es ggf. schwierig, SPOFs zu erkennen. Es fehlt schlicht­weg der Überblick, um die Wech­sel­wir­kun­gen der einzelnen Kom­po­nen­ten wahr­zu­neh­men. Dann ist es unmöglich, Gefahren zu iden­ti­fi­zie­ren und Ge­gen­maß­nah­men zu ergreifen. Prin­zi­pi­ell sollte jegliche für den Betrieb kritische, nicht redundant aus­ge­leg­te Kom­po­nen­te als Single Point of Failure be­trach­tet werden.

Denken wir bei­spiels­hal­ber an den mensch­li­chen Körper. Die kri­ti­schen 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. Dem­ge­gen­über sind Augen, Ohren, Lun­gen­flü­gel und Nieren doppelt ausgelegt. Der Körper kom­pen­siert bei Bedarf den Ausfall einer Seite und operiert mit ver­min­der­ter Leis­tungs­fä­hig­keit weiter.

Mit Bezug zum Re­chen­zen­trum zeigen sich einige Par­al­le­len. Alle für den Betrieb kri­ti­schen Kom­po­nen­ten stellen po­ten­zi­el­le SPOFs dar. Daher sind Server für ge­wöhn­lich mit red­un­dan­ten An­bin­dun­gen an Stromnetz und Netzwerk versehen. Auch Mas­sen­spei­cher werden über RAIDs oder ähnliche Tech­no­lo­gien redundant be­reit­ge­stellt. Ziel ist, beim Versagen einer einzelnen, kri­ti­schen Kom­po­nen­te den Wei­ter­be­trieb des Ge­samt­sys­tems si­cher­zu­stel­len.

Es finden sich viel­fäl­ti­ge Beispiele für Single Points of Failure (SPOFs) aus den un­ter­schied­lichs­ten Bereichen. Denn SPOFs betreffen kei­nes­falls nur In­for­ma­ti­ons­sys­te­me. Schauen wir uns eine Handvoll ein­drucks­vol­ler Beispiele an.

In den beliebten „Star Wars“-Filmen führt ein Single Point of Failure zur Zer­stö­rung des ge­fürch­te­ten „To­des­sterns“. Ein einzelner vom Prot­ago­nis­ten ab­ge­feu­er­ter Pro­to­nen­tor­pe­do schlägt an einer kri­ti­schen Stelle des Reaktors ein. Die Explosion ruft eine ka­ta­stro­pha­le Ket­ten­re­ak­ti­on hervor, die den gesamten To­des­stern ver­nich­tet.

Im Jahr 2021 kam es zur bei­spiel­lo­sen Blockade des Su­ez­ka­nals durch das Con­tai­ner­schiff „Ever Given“. Das Schiff war an einem kri­ti­schen Abschnitt des Kanals, der nur eine Was­ser­stra­ße umfasst, auf Grund gelaufen und stecken geblieben. Der Fla­schen­hals war verstopft, der Schiffs­ver­kehr durch den gesamten Kanal lahm­ge­legt. Der Single Point of Failure war die nicht red­un­dan­te Was­ser­stra­ße.

In den Jahren 2018 und 2019 kam es zu zwei Abstürzen des Flug­zeug­typs „Boeing 737 MAX“ mit dem Verlust hunderter Men­schen­le­ben. Als Ab­sturz­ur­sa­che wurde ein einzelner Sensor iden­ti­fi­ziert, der feh­ler­haf­te Daten lieferte. Auf Grundlage der Sen­sor­da­ten reagierte das au­to­ma­ti­sche Flug­kon­troll­sys­tem ka­ta­stro­phal falsch und brachte das Flugzeug zum Absturz. Mehrere Fehler spielten zusammen; der Single Point of Failure war der nicht redundant aus­ge­leg­te Sensor.

Auch an sich für Hoch­ver­füg­bar­keit kon­zi­pier­te Systeme sind nicht voll­stän­dig gegen SPOFs geschützt. So kam es in den ver­gan­ge­nen 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 ver­se­hent­li­cher Push der falschen Kon­fi­gu­ra­ti­ons­da­ten auf ein Pro­duk­ti­ons­sys­tem legt dieses lahm, auch wenn dessen Kom­po­nen­ten redundant ausgelegt sind.

Viel­leicht kennen Sie das Problem: das WiFi-Netzwerk am Laptop ist verbunden, doch Web­brow­ser und Mail­pro­gramm ver­wei­gern den Dienst. Dazu häufen sich weitere, seltsame Fehler: Von der au­to­ma­ti­schen Zeit­ein­stel­lung bis zum Verbinden mit dem GitHub-Account über SSH – überall hakt es. Es ist zum Haa­re­aus­rau­fen, dabei ist die Antwort ganz einfach:

Unter IT-ver­sier­ten gilt das ge­flü­gel­te Wort „It’s always DNS“ als hu­mor­vol­le, jedoch ernst­ge­mein­te Be­schrei­bung für das Feh­ler­po­ten­zi­al des Domain Name Systems (DNS). Denn wenn DNS-Server nicht antworten, versagen Websites und Dienste auf viel­fäl­ti­ge Weise. Der Effekt ist ähnlich, als wäre die Anbindung ans Internet gekappt. Forscht man nach, sieht man jedoch, dass der Pa­ket­ver­kehr zwischen IP-Adressen noch funk­tio­niert.

Meistens treten DNS-Fehler auf Nut­zer­sei­te auf, wenn die im System hin­ter­leg­ten DNS-Server nicht an­sprech­bar sind. Es gilt daher als Best Practice, immer zwei Name­ser­ver-Adressen zu hin­ter­le­gen. Ist der erste Server nicht er­reich­bar, 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 Or­ga­ni­sa­ti­on. Fällt einer der beiden aus, ist die Wahr­schein­lich­keit hoch, dass auch der andere betroffen ist. Um auf Nummer sicher zu gehen, hin­ter­legt man die Adressen zweier Name­ser­ver von un­ter­schied­li­chen Or­ga­ni­sa­tio­nen. Eine beliebte Kom­bi­na­ti­on ist 1.1.1.1 und 9.9.9.9 von Cloud­fla­re und Quad9 als primärer und se­kun­dä­rer DNS-Server.

Bis zum Ende des Jahres 2021 klaffte in einer Vielzahl Java-basierter Web­ser­vices die Si­cher­heits­lü­cke Log4Shell. Der Single Point of Failure war eine Java-Logging-Bi­blio­thek namens Log4J. Wurde ein ver­wund­ba­res System an­ge­grif­fen, kam es im schlimms­ten Fall zu einer kom­plet­ten Übernahme des Systems.

Generell gilt: Vorbeugen ist die beste Strategie, um SPOFs zu vermeiden. Denn ein Single Point of Failure führt der De­fi­ni­ti­on nach zum Funk­ti­ons­ver­lust des gesamten Systems. Tritt dieser Fall ein, ist es in vielen Fällen zu spät: Meist lässt sich höchstens noch Scha­dens­be­gren­zung betreiben.

Grundlage für vor­beu­gen­de Maßnahmen ist die Planung für den Ernstfall. Man spielt glaub­haf­te Feh­ler­sze­na­ri­en durch und ana­ly­siert die aus­ge­hen­den Risiken sowie mögliche Schutz­maß­nah­men. Ver­schie­de­nen Arten des Single Point of Failure lässt sich durch spe­zi­fi­sche Ei­gen­schaf­ten des um­ge­ben­den Systems vorbeugen:

Gut vor­be­rei­tet un­ter­zieht man kritische Systeme kon­ti­nu­ier­li­cher Be­ob­ach­tung, um auf­tre­ten­de Fehler möglichst früh­zei­tig zu erkennen und ggf. zu kor­ri­gie­ren.

In der Literatur findet sich am häu­figs­ten die Emp­feh­lung, SPOFs durch den Aufbau von Red­un­dan­zen ent­ge­gen­zu­wir­ken. Es werden mehrere Instanzen einer kri­ti­schen Kom­po­nen­te (z. B. Strom­ver­sor­gung, Netz­werk­an­bin­dung, DNS-Server) parallel betrieben. Im Idealfall ist beim Versagen einer Instanz ein Wei­ter­be­trieb des Systems ohne Leis­tungs­ein­bu­ße möglich.

Auch soft­ware­sei­tig beugt Redundanz vielen SPOFs vor. Ein Beispiel sind die beliebten Mi­cro­ser­vices im Gegensatz zum Software-Mo­no­li­then. Ein System aus Mi­cro­ser­vices gilt als stärker ent­kop­pelt und weniger komplex und ist damit robuster gegenüber dem Auftreten von SPOFs. Da Mi­cro­ser­vices für ge­wöhn­lich als Container gestartet werden, ist es einfacher, Red­un­dan­zen auf­zu­bau­en.

Doch wie genau schützt Redundanz ein System? Zum besseren Ver­ständ­nis des Wirk­prin­zips bedienen wir uns der als „Luss­ersches Gesetz“ bekannten Ab­schät­zung der Ver­läss­lich­keit eines Systems. Ex­er­zie­ren wir das an einem Ge­dan­ken­bei­spiel durch:

Nehmen wir an, ein System verfüge über zwei von­ein­an­der un­ab­hän­gi­ge, parallel ge­schal­te­te An­bin­dun­gen an die Strom­ver­sor­gung. Nehmen wir ferner an, die Wahr­schein­lich­keit für das Versagen der Anbindung innerhalb eines be­stimm­ten Zeitraums betrage 1 Prozent. Dann lässt sich die Wahr­schein­lich­keit für das komplette Versagen der Strom­an­bin­dung als Produkt der Wahr­schein­lich­kei­ten berechnen:

1. Wahr­schein­lich­keit des Versagens einer Instanz:

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

1. Wahr­schein­lich­keit, dass hin­ter­ein­an­der zwei Instanzen versagen:

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

Wie Sie sehen, halbiert sich die Wahr­schein­lich­keit für einen SPOF beim Betreiben von zwei Instanzen nicht etwa, sondern ver­rin­gert sich um zwei Grö­ßen­ord­nun­gen. Eine be­acht­li­che Ver­bes­se­rung. Bereits bei drei parallel be­trie­be­nen Instanzen dürfte ein Versagen des Ge­samt­sys­tems nahezu aus­ge­schlos­sen sein.

Leider ist Redundanz kein All­heil­mit­tel. Vielmehr schützen Red­un­dan­zen ein System gegenüber SPOFs innerhalb be­stimm­ter Annahmen. Zunächst muss gegeben sein, dass die Wahr­schein­lich­keit für das Versagen einer Instanz un­ab­hän­gig ist von der Wahr­schein­lich­keit für das Versagen der red­un­dan­ten Instanz(en). Nicht gegeben ist dies bereits, wenn das Versagen durch ein äußeres Ereignis her­vor­ge­ru­fen wird. Brennt das Da­ten­cen­ter, fallen red­un­dan­te Kom­po­nen­ten zusammen aus.

Neben der Redundanz ein­ge­setz­ter Kom­po­nen­ten ist eine Ver­tei­lung gewisser Kom­po­nen­ten kritisch, um SPOFs zu mindern. Geo­gra­fi­sche Ver­tei­lung von Da­ten­spei­chern und Re­chen­in­fra­struk­tur schützt vor Um­welt­ka­ta­stro­phen. Ferner zahlt es sich aus, eine gewisse He­te­ro­ge­ni­tät bzw. Di­ver­si­tät kri­ti­scher Sys­tem­kom­po­nen­ten an­zu­stre­ben. Di­ver­si­tät senkt die Wahr­schein­lich­keit für das Versagen red­un­dan­ter Instanzen.

Ver­an­schau­li­chen wir uns den Vorteil von Di­ver­si­tät am Beispiel der Cy­ber­si­cher­heit. Stellen wir uns ein Da­ten­cen­ter mit red­un­dan­ten Load-Balancern exakt gleicher Machart vor. Besteht bei einem der Load-Balancer eine Si­cher­heits­lü­cke, liegt diese auch bei den red­un­dan­ten Instanzen vor. Ein Angriff legt im schlimms­ten Fall alle Instanzen lahm. Bei Einsatz ver­schie­de­ner Modelle besteht eine bessere Chance für das Ge­samt­sys­tem, mit ver­min­der­ter Leis­tungs­fä­hig­keit weiter zu operieren.

Wie wir gesehen haben, ist Redundanz nicht immer aus­rei­chend, um SPOFs vor­zu­beu­gen. Ferner gibt es Kom­po­nen­ten, die sich nicht redundant auslegen lassen. Wenn das Schaffen von Redundanz keine ver­füg­ba­re Option darstellt, kommen andere Stra­te­gien zum Einsatz.

Aus der Cy­ber­si­cher­heit bekannt ist der „Defence in Depth“-Ansatz. Dabei werden mehrere, von­ein­an­der un­ab­hän­gi­ge Schutz­rin­ge um ein System gezogen. Diese müssen nach­ein­an­der durch­bro­chen werden, um ein ka­ta­stro­pha­les Resultat her­bei­zu­füh­ren. So wird ein To­tal­aus­fall aufgrund des Versagens einer einzelnen Kom­po­nen­te weniger wahr­schein­lich.

In Bezug auf digitale Systeme exis­tie­ren spezielle Pro­gram­mier­spra­chen mit ein­ge­bau­ter Feh­ler­to­le­ranz. Als be­kann­tes­tes Beispiel gilt die Ende der 1980er Jahre ent­wi­ckel­te Sprache „Erlang“. Gemeinsam mit der da­zu­ge­hö­ri­gen Lauf­zeit­um­ge­bung eignet sich die Sprache zum Erstellen hoch­ver­füg­ba­rer, feh­ler­to­le­ran­ter Systeme.

Der globale Siegeszug des World Wide Web und die damit ein­her­ge­hen­de Ver­brei­tung der Web­ent­wick­lung brachte eine neue Her­aus­for­de­rung mit sich. Pro­gram­mie­rer und Pro­gram­mie­re­rin­nen sahen sich gezwungen, Websites zu ent­wi­ckeln, die auf ver­schie­de­nen End­ge­rä­ten funk­tio­nie­ren. Der grund­le­gen­de dabei zum Einsatz kommende Ansatz ist als „Graceful De­gra­da­ti­on“ bekannt. Un­ter­stützt ein Browser oder Gerät eine bestimmte Tech­no­lo­gie auf einer Seite nicht, wird diese so gut wie möglich dar­ge­stellt. Es handelt sich um einen „fail-soft“-Ansatz:

Um Single Points of Failure innerhalb der eigenen IT zu iden­ti­fi­zie­ren, sollte man kei­nes­falls warten, bis der Feh­ler­fall eintritt. Statt­des­sen ist angeraten, im Rahmen einer Ri­si­ko­ma­nage­ment-Strategie proaktiv vor­zu­ge­hen. Dabei kommen Analysen aus der Zu­ver­läs­sig­keits­tech­nik wie Feh­ler­baum- oder Er­eig­nis­baum­ana­ly­se zum Einsatz. Die Failure Mode and Effects Analysis (FMEA, „Feh­ler­mög­lich­keits- und -ein­fluss­ana­ly­se“) wird genutzt, um die kri­tischs­ten Feh­ler­quel­len zu iden­ti­fi­zie­ren.

Das generelle Vorgehen zur Iden­ti­fi­ka­ti­on von Single Points of Failure (SPOF) in der Un­ter­neh­mens-IT besteht darin, eine Ri­si­ko­be­wer­tung der drei haupt­säch­li­chen Di­men­sio­nen durch­zu­füh­ren:

• Hardware
• Software/Dienste/Anbieter
• Personal

Zunächst erstellt man eine SPOF-Analyse-Check­lis­te, welche die ge­ne­rel­len Bereiche für die weiteren Analysen aufzeigt. Im Anschluss wird eine de­tail­lier­te SPOF-Analyse der einzelnen Bereiche durch­ge­führt. Man sucht nach:

• Nicht über­wach­ten Geräten im Netzwerk
• Nicht red­un­dan­ten Software- oder Hardware-Systemen
• Personal und Anbietern, die sich im Notfall nicht ersetzen lassen
• Jeglichen Daten, die nicht in Backups auf­ge­nom­men werden

Für jede Sys­tem­kom­po­nen­te wird ana­ly­siert, welche negativen Effekt ein Versagen hätte. Ferner wird die ungefähre Wahr­schein­lich­keit für das Auftreten eines ka­ta­stro­pha­len Fehlers ab­ge­schätzt. Die gewonnen Er­kennt­nis­se fließen in einen über­ge­ord­ne­ten „Disaster Recovery“-Plan (Not­fall­wie­der­her­stel­lungs­plan) ein, um die Si­cher­heit im Re­chen­zen­trum zu ge­währ­leis­ten.

Als grund­le­gen­de Maßnahme zur Ver­mei­dung von SPOFs sollte Redundanz von Da­ten­spei­chern und Re­chen­kraft auf drei Ebenen si­cher­ge­stellt werden:

• Auf der Server-Ebene durch red­un­dan­te Hardware-Kom­po­nen­ten
• Auf System-Ebene durch Clus­te­ring, d. h. den Einsatz mehrerer Server-Instanzen
• Auf Re­chen­zen­trum-Ebene durch Einsatz geo­gra­fisch ver­teil­ter Be­triebs­stät­ten