Hochverfügbarkeit (High Availability, HA) ist die Fähigkeit eines Systems, für seine Nutzer trotz Ausfällen einzelner Komponenten nutzbar zu bleiben. Sie wird durch Redundanz, automatisches Failover, Health Checks und das Beseitigen von Single Points of Failure erreicht und meist als Verfügbarkeitsziel wie 99,9 % oder 99,99 % für einen festgelegten Zeitraum angegeben.
Was ist Hochverfügbarkeit?
Hochverfügbarkeit beschreibt Systeme, die so gebaut sind, dass der Ausfall eines Servers, einer Festplatte, einer Zone oder eines Prozesses den Dienst für Nutzer nicht unbrauchbar macht. Statt Komponenten zu bauen, die nie ausfallen, gehen HA-Architekturen davon aus, dass Ausfälle passieren, und sorgen dafür, dass eine andere Instanz schnell übernimmt, im Idealfall unbemerkt.
Verfügbarkeit wird als Anteil der Zeit oder der Requests gemessen, in denen der Dienst wie erwartet funktioniert. Sie hängt eng mit Uptime und Verfügbarkeit zusammen. Bei Hochverfügbarkeit geht es jedoch um die Mechanismen hinter der Zahl: Redundanz, Fehlererkennung und Wiederherstellung.
Die Rechnung mit den Neunen
Verfügbarkeitsziele werden oft in „Neunen“ angegeben. Die Tabelle zeigt die maximal zulässige Ausfallzeit je Stufe, berechnet aus dem Prozentwert:
| Verfügbarkeit | Ausfallzeit pro Jahr | Ausfallzeit pro 30 Tage |
|---|---|---|
| 99 % | etwa 3,65 Tage | etwa 7,2 Stunden |
| 99,9 % | etwa 8,76 Stunden | etwa 43 Minuten |
| 99,99 % | etwa 52,6 Minuten | etwa 4,3 Minuten |
| 99,999 % | etwa 5,3 Minuten | etwa 26 Sekunden |
Aus der Wahrscheinlichkeitsrechnung folgen zwei Faustregeln. Komponenten in Reihe multiplizieren sich: Ein Dienst, der zwei Abhängigkeiten mit je 99,9 % benötigt, erreicht höchstens etwa 99,8 %. Komponenten parallel ergeben 1 minus das Produkt ihrer Ausfallwahrscheinlichkeiten: Zwei unabhängige Replikate mit je 99 % kommen auf etwa 99,99 %. Der Haken liegt im Wort unabhängig. Replikate in derselben Zone, mit derselben Konfiguration oder demselben Bug fallen gern gemeinsam aus.
Gängige Muster für Hochverfügbarkeit
- Active-Active: Mehrere Instanzen bedienen gleichzeitig Traffic hinter einem Load Balancer. Eine ausgefallene Instanz wird aus der Rotation genommen, die anderen übernehmen ihre Last.
- Active-Passive: Ein Standby übernimmt, wenn die primäre Instanz ausfällt, typisch für Datenbanken wie PostgreSQL mit Streaming Replication. Entscheidend sind Failover-Dauer und möglicher Datenverlust beim Umschalten.
- N+1- oder N+2-Kapazität: genügend Reserve, um eine oder zwei Instanzen, Zonen oder Nodes ohne Überlast zu verlieren.
- Multi-Zone- und Multi-Region-Betrieb, um den Verlust eines Rechenzentrums oder einer ganzen Region zu überstehen.
- Quorum-basierter Konsens (etwa Raft in etcd), damit ein Cluster arbeitsfähig bleibt, solange eine Mehrheit erreichbar ist, und Split Brain vermieden wird.
- Graceful Degradation über Timeouts, Retries mit Backoff und einen Circuit Breaker, damit eine ausfallende Abhängigkeit nicht den Aufrufer mitreißt.
Fehlererkennung und Failover
Redundanz hilft nur, wenn Ausfälle erkannt und behandelt werden. Load Balancer und Orchestrierer nutzen Health Checks, um fehlerhafte Instanzen zu entfernen. Prüfintervall, Anzahl der nötigen Fehlschläge und die Zeit bis zur Beförderung eines Standbys bestimmen zusammen, wie lange Nutzer betroffen sind. Zu empfindliche Checks führen zu Flapping, Checks, die nur „Prozess läuft“ prüfen, übersehen Instanzen, die laufen, aber defekt sind.
Das zweite große Risiko sind Änderungen. Viele Ausfälle entstehen durch Deployments oder Konfigurationsänderungen, die gleichzeitig auf alle Replikate ausgerollt werden und damit den Nutzen der Redundanz aufheben. Schrittweise Rollouts wie Canary Deployments begrenzen den Schadensradius. Dasselbe gilt für Konfigurationsänderungen, Zertifikatswechsel und Datenbankmigrationen, die ebenfalls zonenweise oder in kleinen Schritten erfolgen sollten.
Beispiel: ein einfacher hochverfügbarer Webdienst
Ein illustratives Setup: drei Anwendungsreplikate in drei Availability Zones hinter einem Load Balancer, eine primäre Datenbank mit synchronem Standby in einer zweiten Zone und eine Readiness Probe, die die Datenbankverbindung prüft. Fällt eine Zone aus, bedienen zwei Replikate weiter. Die Kapazität ist so bemessen, dass zwei Replikate die Spitzenlast tragen. Fällt die primäre Datenbank aus, wird der Standby befördert und die Anwendungen verbinden sich neu. Das Team testet dies regelmäßig in einer Staging-Umgebung, indem es ein Replikat beendet und ein Datenbank-Failover auslöst, und misst die Zeit, bis die Fehlerrate wieder normal ist.
Hochverfügbarkeit überwachen
- Messen Sie Verfügbarkeit aus Nutzersicht über Erfolgsquoten von Requests und synthetisches Monitoring von mehreren Standorten.
- Definieren Sie ein Verfügbarkeits-SLO und verfolgen Sie das Error Budget, statt einer abstrakten Anzahl von Neunen nachzujagen.
- Alarmieren Sie bei verlorener Redundanz, etwa wenn ein Replica Set unter der Sollanzahl läuft, bevor der nächste Ausfall zum Totalausfall wird.
- Erfassen Sie Failover-Ereignisse und ihre Dauer und werten Sie sie in Postmortems aus.
- Überwachen Sie auch den Replikationsrückstand von Standby-Datenbanken, denn ein Standby mit großem Rückstand verlängert das Failover oder verliert Daten.
Wie Obseria hilft
Obseria verbindet synthetische Checks, SLOs mit Burn-Rate-Alerts und Statusseiten. So sehen Sie, ob Redundanz Ihre Nutzer tatsächlich schützt, und können kommunizieren, wenn nicht. TopoGraph zeigt, von welchen Abhängigkeiten ein Dienst lebt, und hilft so, Single Points of Failure zu finden. Vertragliche Zusagen behandelt der Eintrag SLA.
