Wenn keine Redundanz zuverlässiger ist – Der Mythos der Redundanz

Risiko ist ein schwieriges Konzept und es erfordert viel Schulung, Überlegung und Analyse, um gegebene Szenarien angemessen einzuschätzen. Da Risikobewertungen oft so schwierig sind, ersetzen wir die Risikoanalyse häufig dadurch, dass wir einfach grundlegende Redundanz hinzufügen und annehmen, wir hätten das Risiko angemessen gemindert. Aber sehr oft ist dies nicht der Fall. Die Einführung von Komplexität oder zusätzlichen Fehlermodi geht oft mit dem Hinzufügen von Redundanz einher, und diese neuen Fehlerformen haben das Potenzial, mehr Risiko hinzuzufügen, als die hinzugefügte Redundanz beseitigt. Speichersysteme sind besonders anfällig für diese Entscheidungsprozesse, was bedauerlich ist, da nur wenige Systeme – wenn überhaupt – so anfällig für Ausfälle und so wichtig zu schützen sind.

RAID ist ein hervorragendes Beispiel dafür, wo ein Mangel an ganzheitlichem Risikodenken zu einigen seltsamen Entscheidungen führen kann. Wenn wir uns ein nicht ungewöhnliches Szenario ansehen, werden wir erkennen, wo das Ziel, sich gegen Laufwerksausfälle zu schützen, tatsächlich zu einer Erhöhung des Risikos führen kann, selbst wenn zusätzliche Redundanz angewendet wird. In diesem Szenario vergleichen wir ein Array aus zwölf Laufwerken, bestehend aus zwölf SATA-Festplatten mit je drei Terabyte in einem einzigen Array. Es ist nicht ungewöhnlich zu hören, dass Menschen für dieses Szenario RAID 5 wählen, um “maximale Kapazität und Leistung” zu erzielen und dabei “ausreichenden Schutz gegen Ausfälle” zu haben.

Die Idee dabei ist, dass RAID 5 gegen den Verlust eines einzelnen Laufwerks schützt, das ersetzt werden kann, und das Array sich selbst wiederaufbaut, bevor ein zweites Laufwerk ausfällt. Das ist in der Theorie großartig, aber die wirklichen Risiken eines Arrays dieser Größe, sechsunddreißig Terabyte Laufwerkskapazität, kommen nicht von mehreren Laufwerksausfällen, wie die Leute im Allgemeinen vermuten, sondern von der Unfähigkeit, das Array nach einem einzelnen Laufwerksausfall zuverlässig wiederaufzubauen, oder von einem Ausfall des Arrays selbst, ohne dass einzelne Laufwerke ausfallen. Das Risiko, dass ein zweites Laufwerk ausfällt, ist gering, nicht nicht existent, aber recht gering. Laufwerke sind heute hochzuverlässig. Sobald ein Laufwerk ausfällt, erhöht das tatsächlich die Wahrscheinlichkeit, dass ein zweites Laufwerk ausfällt, was gut dokumentiert ist, aber ich möchte nicht, dass uns dieses Risiko davon ablenkt, die wahren Risiken zu betrachten – das Risiko eines fehlgeschlagenen Resilver-Vorgangs.

Was uns während eines RAID-5-Resilver-Vorgangs beunruhigt, ist, dass ein nicht behebbarer Lesefehler (Unrecoverable Read Error, URE) auftreten kann. Wenn das geschieht, hält der Resilver-Vorgang an und das Array verbleibt in einem nutzlosen Zustand – alle Daten auf dem Array sind verloren. Bei gängigen SATA-Laufwerken liegt die URE-Rate bei 10^14, also einmal pro zwölf Terabyte an Lesevorgängen. Das bedeutet, dass ein Array mit sechs Terabyte, das resilvert wird, eine ungefähr fünfzigprozentige Wahrscheinlichkeit hat, auf einen URE zu treffen und auszufallen. Eine fünfzigprozentige Ausfallwahrscheinlichkeit ist wahnsinnig hoch. Stellen Sie sich vor, Ihr Auto hätte jedes Mal, wenn Sie es fahren, eine fünfzigprozentige Wahrscheinlichkeit, dass die Räder abfallen. Bei einem kleinen (nach heutigen Maßstäben) RAID-5-Array mit sechs Terabyte, das SATA-Laufwerke mit einer URE-Rate von 10^14 verwendet, hätten wir also, wenn wir ein einzelnes Laufwerk verlören, nur eine fünfzigprozentige Wahrscheinlichkeit, dass sich das Array erholt, vorausgesetzt, das Laufwerk wird sofort ersetzt. Das schließt das Risiko eines zweiten Laufwerksausfalls nicht ein, nur das Risiko eines URE-Fehlers. Es setzt außerdem voraus, dass das Laufwerk außer dem Resilver-Vorgang völlig untätig ist. Wenn die Laufwerke gleichzeitig fleißig für andere Aufgaben genutzt werden, beginnen die Chancen, dass etwas Schlimmes passiert – sei es ein URE oder ein zweiter Laufwerksausfall –, dramatisch zu steigen.

Bei einem Array mit zwölf Terabyte nähern sich die Chancen eines vollständigen Datenverlusts während eines Resilver-Vorgangs hundert Prozent an – was bedeutet, dass RAID 5 in diesem Fall keinerlei Funktion hat. Es gibt immer eine Überlebenschance, aber sie ist sehr gering. Bei sechs Terabyte kann man einen Resilver-Vorgang mit einer Partie Russisch Roulette mit einer Kugel und sechs Kammern vergleichen, bei der man dreimal abdrücken muss. Bei zwölf Terabyte muss man sechsmal abdrücken! Das sind keine guten Chancen.

Aber wir sprechen nicht von einem Array mit zwölf Terabyte. Wir sprechen von einem Array mit sechsunddreißig Terabyte – was groß klingt, aber dies ist eine Größe, die jemand heute leicht zu Hause haben könnte, ganz zu schweigen von einem Unternehmen. Jeder große Serverhersteller sowie nahezu alle Anbieter günstiger Speicherlösungen stellen heute Speichersysteme in diesem Kapazitätsbereich für unter 10.000 US-Dollar her. Das Resilvern eines RAID-5-Arrays mit einem einzelnen Laufwerksausfall bei einem Array mit sechsunddreißig Terabyte ist wie Russisch Roulette mit einer Kugel, sechs Kammern und achtzehnmaligem Abdrücken! Ihre Daten haben da nicht viele Chancen. Hinzu kommt die unglaubliche Zeitspanne, die für das Resilvern eines Arrays dieser Größe benötigt wird, und das Risiko, dass eine zweite Festplatte während dieses Resilver-Zeitfensters ausfällt, beginnt zu einer recht erheblichen Bedrohung zu werden. Ich habe Schätzungen von Resilver-Zeiten gesehen, die bei manchen Systemen auf Wochen oder Monate ansteigen. Das ist eine lange Zeit, um zu laufen, ohne ein weiteres Laufwerk verlieren zu dürfen. Wenn wir von Stunden oder Tagen sprechen, sind die Risiken recht gering, aber dennoch vorhanden. Wenn wir von Wochen oder Monaten kontinuierlicher Belastung sprechen – da Resilver-Vorgänge die Laufwerke extrem beanspruchen –, steigen die Ausfallraten dramatisch an.

Bei einem Array dieser Größe können wir effektiv annehmen, dass der Verlust eines einzelnen Laufwerks den Verlust des gesamten Arrays bedeutet, sodass wir überhaupt keinen Schutz gegen Laufwerksausfälle haben. Wenn wir nun ein Laufwerk gleicher oder besserer Leistung mit gleicher oder besserer Kapazität unter RAID 0 betrachten, das ebenfalls keinen Schutz gegen Laufwerksverlust bietet, benötigen wir nur elf derselben Laufwerke, von denen wir für unser RAID-5-Array zwölf benötigten. Das bedeutet, dass wir statt zwölf Festplatten, von denen jede eine ungefähr dreiprozentige Wahrscheinlichkeit eines jährlichen Ausfalls hat, nur elf haben. Das allein macht unser RAID-0-Array zuverlässiger, da weniger Laufwerke ausfallen können. Wir haben nicht nur weniger Laufwerke, sondern es besteht auch keine Notwendigkeit, den Paritätsblock zu schreiben oder beim Zurücklesen Paritätsblöcke zu überspringen, was den mechanischen Verschleiß des RAID-0-Arrays bei gleicher Auslastung ganz geringfügig senkt und ihm einen sehr leichten zusätzlichen Zuverlässigkeitsvorteil verschafft. Das RAID-0-Array aus elf Laufwerken wird in der Kapazität identisch mit dem RAID-5-Array aus zwölf Laufwerken sein, aber einen etwas besseren Durchsatz und eine etwas bessere Latenz haben. Ein Gewinn auf ganzer Linie. Hinzu kommt die Kostenersparnis, kein zusätzliches Laufwerk zu benötigen.

Was wir hier also sehen, ist, dass RAID 0 bei großen Arrays (groß in der Kapazität, nicht in der Spindelanzahl) in bestimmten Szenarien RAID 5 tatsächlich übertrifft. Bei der Verwendung gängiger SATA-Laufwerke geschieht dies bei Kapazitäten, die sogar von anspruchsvollen Heimanwendern und von vielen kleinen Unternehmen erreicht werden. Wenn wir zu Enterprise-SATA-Laufwerken oder SAS-Laufwerken übergehen, wird die Kapazitätszahl, bei der dies eintritt, sehr hoch und ist heute kein Problem, wird es aber in nur wenigen Jahren sein, wenn die Laufwerkskapazitäten noch größer werden. Dies verdeutlicht jedoch, wie gefährlich RAID 5 in den Größen ist, die wir heute sehen. Jeder versteht die unglaublichen Risiken von RAID 0, aber es kann schwierig sein, ins rechte Verhältnis zu setzen, dass die Probleme von RAID 5 so extrem sind, dass es tatsächlich weniger zuverlässig sein könnte als RAID 0.

Dass RAID 5 bei einem Array dieser Größe allein aufgrund der Resilver-Vorgänge weniger zuverlässig sein könnte als RAID 0, ist erst der Anfang. Bei einem derart riesigen Array kann die Resilver-Zeit so lange dauern und die Laufwerke so stark beanspruchen, dass auch ein zweiter Laufwerksausfall zu einem messbaren Risiko wird. Und dann gibt es zusätzliche Risiken, die durch Fehler des Array-Controllers verursacht werden, der Resilver-Algorithmen nutzen kann, um ein ganzes Array zu zerstören, selbst wenn kein Laufwerksausfall aufgetreten ist. Da RAID 0 (oder RAID 1 oder RAID 10) keine Resilver-Algorithmen haben, sind sie diesem zusätzlichen Risiko nicht ausgesetzt. Diese Risiken sind schwer zu quantifizieren, aber wichtig ist, dass es sich um zusätzliche Risiken handelt, die sich anhäufen, wenn man ein komplexeres System verwendet, während ein einfacheres System ohne die Redundanz von Anfang an zuverlässiger war.

Nachdem wir nun festgestellt haben, dass RAID 5 weniger zuverlässig sein kann als RAID 0, werde ich auf die offensichtlichen Gefahren von RAID 0 hinweisen. RAID wird allgemein verwendet, um das Risiko des Ausfalls einer einzelnen, einsamen Festplatte zu mindern. Wir alle fürchten, dass eine einzelne Festplatte einfach ausfällt und alle Daten verloren gehen. RAID 0, das ein großer Stripe von Laufwerken ohne jegliche Form von Redundanz ist, nimmt das Risiko des Datenverlusts beim Ausfall eines einzelnen Laufwerks und multipliziert es über eine Reihe von Laufwerken, bei der der Ausfall eines beliebigen Laufwerks den vollständigen Verlust der Daten auf allen Laufwerken verursacht. In unserem Beispiel mit elf Festplatten oben gilt also: Wenn eine der elf Festplatten ausfällt, ist alles verloren. Es ist klar zu erkennen, wo dies dramatisch gefährlicher ist als die Verwendung eines einzelnen Laufwerks, ganz allein.

Worauf ich hier hinweisen möchte, ist, dass Redundanz nicht Zuverlässigkeit bedeutet. Nur weil etwas redundant ist, wie RAID 5, bietet das keine Garantie dafür, dass es immer zuverlässiger sein wird als etwas, das nicht redundant ist.

Meine Lieblingsanalogie hierfür ist, Häuser in einem Tornado zu betrachten. In einem Szenario bauen wir ein Haus aus Ziegel und Mörtel. Im zweiten Szenario bauen wir zwei redundante Häuser, jedes aus Stroh (unsere Bauarbeiter sind offenbar Schweine). Wenn der Tornado (oder der böse Wolf) kommt, bei welchem Szenario ist es wahrscheinlicher, dass uns ein stehendes Haus bleibt? Natürlich hat ein Haus aus Ziegel und Mörtel einige erhebliche Zuverlässigkeitsvorteile gegenüber redundanten Strohhäusern. Redundanz spielte keine Rolle, am Ende zählte die Zuverlässigkeit.

Redundanz ist oft irreführend, weil sie leicht zu quantifizieren, aber schwer zu qualifizieren ist. Redundanz ist eine Schwarz-Weiß-Frage: Ist es redundant? Ja oder nein. Einfach. Zuverlässigkeit ist nicht so einfach. Bei Zuverlässigkeit geht es um Ausfallraten und Wahrscheinlichkeiten. Es geht um Statistik und Analyse. Da es schwer ist, Zuverlässigkeit auf sinnvolle Weise zu quantifizieren, besonders wenn man ein Projekt den Geschäftsleuten verkauft, wird Redundanz oft zu einem einfachen Ersatz für dieses komplexe Konzept.

Das Konzept, Redundanz zu verwenden, um von Fragen der Zuverlässigkeit abzulenken, findet am Ende auch auf sehr verworrene Weise Anwendung auf Teilsysteme. Anstatt ein “System” redundant zu machen, ist es üblich geworden, ein hochzuverlässiges und kostengünstiges Teilsystem redundant zu machen und die Redundanz des Teilsystems so zu behandeln, als gälte sie für das gesamte System. Das häufigste Beispiel hierfür sind RAID-Controller in SAN-Produkten. Anstatt ein redundantes SAN zu haben (was zwei SANs bedeutet), machen Hersteller oft jene eine Komponente, die in normalen Servern nicht oft redundant ist, redundant und nennen das SAN dann redundant – was ein SAN bedeutet, das Redundanz enthält, was keineswegs dasselbe ist.

Eine gute Analogie hierfür wäre, den Besitz redundanter Autos – also zwei vollständiger, fahrtüchtiger Autos – mit dem Besitz eines einzelnen Autos mit einer Ersatzwasserpumpe im Kofferraum für den Fall, dass die Hauptpumpe ausfällt, zu vergleichen. Eine Ersatzwasserpumpe ist eindeutig keine schlechte Sache. Aber sie ist auch ein trivialer Schutz gegen einen Autoausfall im Vergleich dazu, ein zweites fahrbereites Auto zu haben. Im einen Fall ist das gesamte System redundant, einschließlich der Karosserie. Im anderen Fall machen wir nur eine einzige, hochzuverlässige Komponente innerhalb der Karosserie redundant. Es ist nicht einmal gleichwertig mit einem Ersatzreifen, der zumindest eine Autokomponente mit einer höheren Ausfallwahrscheinlichkeit ist.

Genau wie der Mythos der RAID-5-Zuverlässigkeit und der System-/Teilsystem-Zuverlässigkeit werden auch Technologien für geteilten Speicher wie SANs und NAS oft auf dieselbe Weise behandelt, besonders im Hinblick auf Virtualisierung. Es gibt ein häufiges Szenario, in dem ein Virtualisierungsprojekt in Angriff genommen wird und die Leute instinktiv in Panik geraten, weil ein einzelner Virtualisierungshost einen Single Point of Failure darstellt, bei dem, wenn er ausfällt, viele Systeme auf einmal ausfallen.

Die Verwendung des Begriffs “Single Point of Failure” löst ein Gefühl der Panik aus und ist ein hervorragendes Mittel, um ein Gespräch zu lenken. Aber ein SPOF, wie wir ihn gerne nennen, ist zwar etwas, das wir nach Möglichkeit beseitigen wollen, muss aber nicht der Weltuntergang sein. Denken Sie an unser Ziegelhaus. Es ist ein SPOF. Unsere zwei Strohhäuser sind es nicht. Doch ein einziger Windstoß reißt unsere redundanten Lösungen schneller nieder als unseren zuverlässigen SPOF. Die Suche nach SPOFs ist eine hervorragende Methode, um Schwachstellen in einem System zu finden, aber denken Sie nicht, dass jeder SPOF in jedem Szenario redundant gemacht werden muss. Die meisten Unternehmen werden ihren besten Wert darin finden, viele SPOFs vorzuhalten. Unser eigentliches Ziel ist Zuverlässigkeit zu angemessenen Kosten; Redundanz ist, wie wir gesehen haben, kein Ersatz für Zuverlässigkeit, sondern lediglich ein Werkzeug, das wir nutzen können, um Zuverlässigkeit zu erreichen.

Die Theorie, der viele Menschen beim Virtualisieren folgen, ist, dass sie ihren Virtualisierungshost nehmen und sagen: “Dieser Host ist ein SPOF, also brauche ich zwei davon und nutze High-Availability-Funktionen, um ein transparentes Failover zu ermöglichen!” Dies wird dadurch befeuert, dass der führende Virtualisierungsanbieter sein Geld erstens damit verdient, teure HA-Zusatzprodukte zu verkaufen, und zweitens dadurch, dass er einem großen Speicheranbieter gehört – sodass der Verkauf von unnötigem oder sogar gefährlichem zusätzlichem geteiltem Speicher für ihn ein großer finanzieller Gewinn ist und leicht der Grund dafür sein könnte, dass er den Virtualisierungsbereich von Anfang an vorangetrieben hat. Redundante Virtualisierungshosts mit geteiltem Speicher klingen großartig, können aber aus mehreren Gründen äußerst fehlgeleitet sein.

Der erste Grund ist, dass der ursprüngliche SPOF, der Virtualisierungshost, beim Beseitigen durch einen neuen SPOF, den geteilten Speicher, ersetzt wird. Das erreicht nichts. Unter der Annahme, dass wir Server und geteilten Speicher vergleichbarer Qualität verwenden, haben wir lediglich verschoben, wo das Risiko liegt, nicht aber verändert, wie groß es ist. Die Wahrscheinlichkeit, dass das Speichersystem ausfällt, ist ungefähr gleich der Wahrscheinlichkeit, dass der ursprüngliche Server ausfällt. Aber zusätzlich dazu, den SPOF wie bei einem Hütchenspiel hin und her zu schieben, haben wir auch etwas weitaus, weitaus Schlimmeres getan – wir haben verkettete oder kaskadierende Ausfallabhängigkeiten eingeführt.

In unserem ursprünglichen Szenario hatten wir einen einzigen Server. Wenn der Server weiter funktionierte, war alles gut, wenn er ausfiel, war es das nicht. Einfach. Jetzt haben wir zwei Virtualisierungshosts, einen einzigen Speicherserver (SAN, NAS, was auch immer) und ein Netzwerk, das sie miteinander verbindet. Wir haben bereits festgestellt, dass das Risiko eines Ausfalls des geteilten Speichers ungefähr gleich unserem Gesamtsystemrisiko im ursprünglichen Szenario ist. Aber jetzt haben wir die zusätzlichen Abhängigkeiten des Netzwerks und der beiden vorgelagerten Virtualisierungsknoten. Jede dieser Komponenten ist zuverlässiger als der fragile geteilte Speicher (alles mit mechanischen Laufwerken wird fragil sein), aber dass sie ein geringeres Risiko aufweisen, ist nicht das Problem; das Problem ist, dass sich die Risiken kombinatorisch verhalten.

Wenn eine dieser drei Komponenten (Speicher, Netzwerk oder die vorgelagerten Knoten) ausfällt, dann fällt alles aus. Die Lösung dafür ist, den geteilten Speicher für sich genommen redundant zu machen und das Netzwerk für sich genommen redundant zu machen. Mit genügend Aufwand können wir die Fragilität und das Risiko überwinden, die wir durch das Hinzufügen von geteiltem Speicher eingeführt haben, aber der geteilte Speicher an sich ist keine Form der Risikominderung, sondern selbst ein Risiko, das gemindert werden muss. Die Spirale der Komplexität beginnt, und die Kosten, die damit verbunden sind, dieses neue System auf das Zuverlässigkeitsniveau des ursprünglichen Einzelserver-Systems zu bringen, können astronomisch sein.

Nachdem wir nun all diese Redundanz haben, müssen wir uns um ein weiteres Risiko sorgen. Die Verwaltung all dieser Redundanz, all dieser beweglichen Teile, erfordert weitaus mehr Wissen, Können und Vorbereitung als die Verwaltung eines einfachen, einzelnen Servers. Wir sind von einer einfachen Lösung zu einer sehr komplexen übergegangen. In meiner eigenen anekdotischen Erfahrung kommen die wahren Gefahren von Lösungen wie dieser nicht vom Ausfall der Hardware, sondern von menschlichem Versagen. Es wurde nicht nur wenig getan, um zu vermeiden, dass menschliches Versagen dieses neue System zum Ausfall bringt, sondern wir haben unzählige Punkte hinzugefügt, an denen ein Mensch versehentlich das gesamte System, samt aller Redundanz, lahmlegen könnte. Ich habe es aus erster Hand gesehen; ich habe die Horrorgeschichten gehört. Je komplexer das System, desto wahrscheinlicher ist es, dass ein Mensch versehentlich alles kaputt macht.

Es ist von entscheidender Bedeutung, dass wir als IT-Fachleute einen Schritt zurücktreten und vollständige Systeme betrachten und Zuverlässigkeit und Risiko bedenken und Redundanz lediglich als ein Werkzeug betrachten, das im Streben nach Zuverlässigkeit eingesetzt wird. Redundanz an sich ist kein Allheilmittel. Einfachheit ebenso wenig. Zuverlässigkeit ist ein komplexes Problem, das es zu bewältigen gilt. Simplistische Ersatzlösungen zu vermeiden, ist ein wichtiger erster Schritt, um von der Verschleierung von Zuverlässigkeitsproblemen dazu überzugehen, sie anzugehen und zu lösen.