Hochverfügbarkeit realistisch planen: Wann Redundanz sich lohnt und wann sie nur Komplexität erzeugt

Hochverfügbarkeit wird oft als Produktmerkmal diskutiert, nicht als Entscheidung. Jemand fragt nach "HA", jemand antwortet mit einem zweiten Server, und am Ende steht ein Aufbau, der doppelt so teuer und doppelt so kompliziert ist, aber im Ernstfall trotzdem nicht umschaltet. Dieser Beitrag beschreibt, wie Sie die Frage von hinten aufrollen: Was kostet ein Ausfall, welche Komponenten können ihn auslösen, und welche Ausbaustufe passt dazu.

Was Hochverfügbarkeit tatsächlich bedeutet

Hochverfügbarkeit heißt nicht, dass nichts ausfällt. Sie heißt, dass der Ausfall einer einzelnen Komponente den Dienst nicht beendet. Das ist ein deutlich bescheideneres Versprechen, als die meisten Anforderungslisten unterstellen.

Entscheidend sind zwei Kennzahlen, die aus der Backup-Planung bekannt sind: Wie lange darf der Dienst stillstehen, und wie viele Daten dürfen verloren gehen. Hochverfügbarkeit adressiert vor allem die erste Frage. Sie ersetzt kein Backup und keine Wiederherstellungsstrategie, denn gegen gelöschte oder verschlüsselte Daten hilft eine synchron gespiegelte Kopie nicht - sie spiegelt den Schaden mit.

Die Frage vor der Technik: Was kostet Stillstand

Bevor Sie über Cluster nachdenken, brauchen Sie eine Vorstellung davon, was eine Stunde Ausfall bedeutet. Nicht als exakte Zahl, sondern als Größenordnung und vor allem differenziert nach Zeitpunkt.

Ein Shop, der am Montagvormittag zehn Minuten nicht erreichbar ist, verliert Umsatz. Ein internes Dokumentationswiki, das sonntags nachts offline geht, verliert nichts. Beide laufen vielleicht auf derselben Infrastruktur, verdienen aber unterschiedliche Schutzniveaus.

Nützlich ist eine einfache Einordnung aller Dienste in drei Klassen: geschäftskritisch mit Minuten-Toleranz, wichtig mit Stunden-Toleranz, unkritisch mit Tages-Toleranz. Redundanz lohnt sich nur dort, wo die Kosten eines Ausfalls die Kosten der zusätzlichen Komplexität übersteigen - und Komplexität ist ein laufender Posten, kein einmaliger.

Single Points of Failure sichtbar machen

Viele Aufbauten haben einen verdoppelten Applikationsserver und darunter eine einzelne Datenbank, einen einzelnen Loadbalancer und einen einzelnen Uplink. Die Verdopplung an der sichtbarsten Stelle beruhigt, verschiebt das Problem aber nur.

Gehen Sie den Pfad einer Anfrage einmal vollständig durch und notieren Sie jede Station, deren Ausfall den Dienst beendet:

• Namensauflösung und autoritative Nameserver
• Eingangspunkt: Loadbalancer oder Reverse Proxy
• Applikationsschicht
• Datenbank und Cache
• gemeinsam genutzter Speicher für Uploads und Dateien
• Netzanbindung, Stromversorgung, Rechenzentrumsbrandabschnitt
• externe Abhängigkeiten wie Zahlungsdienstleister, Mailversand oder Identity Provider

Die letzte Zeile wird regelmäßig übersehen. Wenn der Login über einen externen Dienst läuft und dieser nicht erreichbar ist, nützt ein perfekt redundanter Cluster wenig. Für solche Abhängigkeiten brauchen Sie entweder einen Fallback oder zumindest eine bewusste Entscheidung, den Ausfall hinzunehmen.

Ausbaustufen statt Alles-oder-nichts

Zwischen einem Einzelserver und einem verteilten Cluster liegen mehrere Stufen. Die mittleren werden zu selten gewählt, obwohl sie für die meisten Anforderungen genügen.

Stufe 1: schneller, geprobter Wiederanlauf

Ein Server, aber eine vollständig automatisierte Bereitstellung, aktuelle Images und getestete Backups. Fällt die Maschine aus, steht innerhalb einer definierten Frist ein Ersatz. Das reicht für alles mit Stunden-Toleranz und ist die mit Abstand günstigste Variante. Voraussetzung ist, dass der Wiederanlauf dokumentiert und mindestens einmal real durchgespielt wurde.

Stufe 2: aktiv-passiv

Ein zweites System läuft mit, übernimmt aber nur im Fehlerfall. Die Datenbank repliziert, der Umschaltvorgang erfolgt über eine bewegliche IP-Adresse oder einen vorgelagerten Proxy. Der Vorteil: Die Zustandsfrage bleibt überschaubar, weil nur ein Knoten schreibt. Der Nachteil: Der Passivknoten wird selten benutzt und deshalb gern vergessen. Konfigurationsdrift zwischen beiden Systemen ist der häufigste Grund, warum ein Failover im Ernstfall scheitert.

Stufe 3: aktiv-aktiv

Mehrere Knoten tragen gleichzeitig Last hinter einem Loadbalancer. Das bringt zusätzlich Skalierung und deckt den Ausfall eines Knotens ohne Umschaltzeit ab. Es setzt aber voraus, dass die Anwendung zustandslos ist oder ihren Zustand auslagert. Sessions im lokalen Dateisystem, Uploads auf der lokalen Platte und Cronjobs, die auf jedem Knoten gleichzeitig laufen, sind die typischen Stolpersteine.

Der Zustand ist das eigentliche Problem

Zustandslose Komponenten zu verdoppeln ist einfach. Die Schwierigkeit liegt bei Daten. Eine Datenbank lässt sich nicht beliebig oft parallel beschreiben, ohne dass Konsistenzfragen entstehen.

Praktikabel sind meist eine Primär-Replikat-Konstellation mit kontrolliertem Wechsel oder eine Cluster-Lösung mit Quorum. Beide Varianten verlangen eine Entscheidung: synchrone Replikation schützt vor Datenverlust, kostet aber Schreiblatenz und macht den Dienst von der Erreichbarkeit des zweiten Knotens abhängig. Asynchrone Replikation ist schneller, akzeptiert aber ein kleines Zeitfenster, in dem Schreibvorgänge verloren gehen können.

Für Dateien gilt dasselbe. Entweder ein gemeinsamer Speicher, der dann selbst redundant sein muss, oder ein Objektspeicher, auf den alle Knoten zugreifen. Eine rsync-Synchronisation zwischen Webservern ist keine Hochverfügbarkeit, sondern eine Verzögerung mit Konfliktpotenzial.

Split Brain und das Quorum

Zwei Knoten können nicht zuverlässig entscheiden, wer ausgefallen ist. Verliert die Verbindung zwischen ihnen, hält sich jeder für den Überlebenden und übernimmt die Schreibrolle. Das Ergebnis sind zwei divergierende Datenbestände, die sich nachträglich kaum sauber zusammenführen lassen.

Deshalb arbeiten ernstzunehmende Cluster mit einer ungeraden Zahl an Stimmen oder einem dritten, schlanken Zeugen. Wer zwei Knoten aufstellt und auf automatisches Umschalten setzt, baut ein Risiko ein, das schwerer wiegt als der ursprüngliche Ausfall. In solchen Fällen ist ein manueller, bewusst ausgelöster Wechsel oft die bessere Wahl.

Was Redundanz nicht abdeckt

Ein erheblicher Teil der Störungen im Serverbetrieb hat nichts mit Hardwaredefekten zu tun. Abgelaufene Zertifikate, fehlerhafte Deployments, volle Datenträger, falsch gesetzte DNS-Einträge und Fehlkonfigurationen wirken auf allen Knoten gleichzeitig.

Gegen diese Klasse hilft keine Verdopplung, sondern Automatisierung, Monitoring mit sinnvollen Schwellwerten, ein geregeltes Änderungsverfahren und die Möglichkeit, ein Deployment schnell zurückzunehmen. Wer mit begrenztem Budget die Verfügbarkeit verbessern will, erreicht hier in der Regel mehr als mit einem zweiten Server.

Failover muss geübt werden

Ein Umschaltmechanismus, der nie ausgelöst wurde, ist eine Annahme. Planen Sie regelmäßige Failover-Tests in einem Wartungsfenster: Primärknoten gezielt abschalten, Umschaltzeit messen, Anwendung prüfen, zurückschalten, Protokoll schreiben.

Dabei zeigen sich die üblichen Lücken. Der Passivknoten hat eine ältere Paketversion. Ein Dienst war nicht für den Autostart aktiviert. Die Anwendung cached die IP-Adresse der Datenbank und merkt den Wechsel nicht. Ein Cronjob läuft nach dem Schwenk doppelt. All das findet man nur im Test, nicht im Konzept.

Eine praktikable Reihenfolge

Beginnen Sie mit der Klassifizierung der Dienste und der Frage nach der tolerierbaren Ausfalldauer. Bringen Sie dann Backup, Wiederanlauf und Monitoring auf ein belastbares Niveau. Entfernen Sie anschließend die billigsten Single Points of Failure, etwa einen zweiten Nameserver oder einen redundanten Uplink.

Erst danach lohnt die Diskussion über Cluster. Und auch dann gilt: Jede zusätzliche Komponente, die ausfallen kann, muss überwacht, aktualisiert und getestet werden. Verfügbarkeit entsteht im Betrieb, nicht im Architekturdiagramm.