In der allgemein verstandenen Informatik ist Redundanz allgegenwärtig und oft als Schlüssel zur Erhöhung der Verfügbarkeit und Ausfallsicherheit von Computersystemen betrachtet. Durch redundante Hardware, Daten oder Softwarekomponenten soll sichergestellt werden, dass der Betrieb auch bei einem Teilausfall (oft transparent) weitergeführt werden kann.
Redundanz in Computersystemen: Mehr ist nicht immer besser
Doch mehr Redundanz bedeutet nicht zwangsläufig eine höhere Verfügbarkeit. In vielen Fällen kann übermäßige Redundanz ein System sogar instabiler machen und die Wartung erschweren. Dies kann zu dem Paradox führen, dass mehr Redundanz zu mehr Ausfällen führt. Ich habe schon sehr oft Situationen erlebt, wo mehr Redundanz höhere Komplexität bedeutete und damit auch mehr Ausfallmöglichkeiten. Damit hat sich die Verfügbarkeit der Dienste gerade wegen der Redundanz verschlechtert und ebenso der Wartungsaufwand.
Komplexität durch zu viel Redundanz
Je mehr Redundanz ein System aufweist, desto komplexer wird dessen Verwaltung. Zusätzliche Komponenten müssen synchronisiert, gewartet und getestet werden. Redundante Systeme erfordern Mechanismen zur Erkennung von Ausfällen und zum reibungslosen Wechsel auf Backup-Komponenten. Diese Mechanismen selbst können jedoch fehleranfällig sein. Ein klassisches Beispiel sind Failover-Mechanismen in Clustersystemen: Wenn die Umschaltung zwischen Haupt- und Backup-System nicht fehlerfrei erfolgt oder die Erkennung eines Ausfalls zu lange dauert, kann dies zu längeren Ausfallzeiten führen als ein einfacheres System mit geringerer Redundanz das man womöglich manuell neustarten könnte um in wenigen Sekunden die Dienste wiederherzustellen.
Single Points of Failure trotz Redundanz
Ein weiterer kritischer Punkt ist, dass Redundanz oft nicht vollständig umgesetzt wird. Häufig existieren Single Points of Failure (SPoFs), die das gesamte System gefährden können. Ein Beispiel ist eine hochverfügbare Datenbank mit mehreren replizierten Knoten, die jedoch von einem einzigen Load Balancer abhängig ist. Fällt dieser aus, ist die gesamte Datenbank unzugänglich – trotz der vermeintlichen Redundanz. In manchen Fällen kann ein einfacheres System mit wenigen, aber gut abgesicherten Komponenten widerstandsfähiger sein als ein komplexes, redundantes System mit versteckten Schwachstellen.
Wartungsaufwand und Fehleranfälligkeit
Höhere Redundanz bedeutet oft einen erhöhten Wartungsaufwand. Updates und Tests müssen an mehreren Systemen gleichzeitig durchgeführt werden, was die Wahrscheinlichkeit von Konfigurationsfehlern erhöht. Zudem kann eine redundante Architektur schwerer zu debuggen sein, da Fehler durch Wechselwirkungen zwischen den verschiedenen Komponenten entstehen können. In manchen Fällen führt eine vermeintlich ausfallsichere Architektur zu einer höheren Fehleranfälligkeit, weil die Fehlersuche komplizierter wird und unerwartete Probleme auftreten.
Weniger Redundanz, mehr Verfügbarkeit?
Eine pragmatische Herangehensweise kann darin bestehen, Redundanz gezielt und maßvoll einzusetzen, anstatt blind alles doppelt oder dreifach abzusichern. Statt Redundanz in jeder einzelnen Komponente zu erhöhen, kann ein System durch vereinfachte, aber robuste Designs oft stabiler gemacht werden. Beispielsweise kann eine gut durchdachte, Fehler-resistente Softwarearchitektur mit effizientem Fehlerbehandlung die Notwendigkeit zusätzlicher Redundanz verringern. Auch präventive Wartung und ein solider Notfallplan sind oft entscheidender als redundante Hardware.
Redundanz ist ein wichtiges Konzept für die Zuverlässigkeit von Computersystemen, doch sie ist kein Allheilmittel. Übermäßige Redundanz kann die Komplexität, die Fehleranfälligkeit und den Wartungsaufwand erhöhen, wodurch die angestrebte höhere Verfügbarkeit untergraben wird. Ein sorgfältig geplantes System, das auf Einfachheit, robuste Architektur und gezielte Absicherung setzt, kann oft widerstandsfähiger sein als ein übermäßig redundantes System. Weniger kann in diesem Fall tatsächlich mehr sein.
Beispiele der guten und schlechten Redundanzen
Die Verbindung von Netzwerkkomponenten und Server mit mehreren, gebündelten Leistungen ist eine gute, günstige und einfache Redundanz, die die Verfügbarkeit deutlich steigert. Diese Art sollte immer angestrebt werden, wenn möglich. Wenn man da noch die Router und Switche doppelt auslegen kann, ist es noch besser.
Die L3 IP Anbindung über automatisch redundante Protokolle wie BGP an mindestens zwei verschiedene Router gehört ebenso zu den relativ einfachen, guten Dingen, die aber die Verfügbarkeit und Ausfallsicherheit enorm erhöhen. Sogar die Verwendung von privaten ASNs (RFC 6996) in Verbindung mit nur einem ISP ist bereits eine starke Verbesserung, z.B. während einer Wartung bei dem ISP, oder bei normalen Ausfällen.
Die Storage-Redundanz mit DRBD usw. kann es zwar im ersten Schritt scheinbar verbessern, aber beinhaltet mehrere Probleme, die am Ende zu inkonsistenten Daten führen können. Auch die Komplexität steigt enorm gegenüber normalen Block-Devices. Demnach ist es, meiner Meinung nach, eine schlechte Redundanz.