Hochverfügbarkeit & Redundanzkonzepte#

Hochverfügbarkeit (High Availability, HA) bezeichnet die Eigenschaft eines Systems, auch beim Ausfall einzelner Komponenten weiterhin nutzbar zu bleiben. Statt Ausfälle vollständig zu verhindern — was praktisch unmöglich ist —, wird das System so gebaut, dass ein einzelner Ausfall nicht zum Totalausfall des Dienstes führt.

Verfügbarkeit als Kennzahl#

Verfügbarkeit wird üblicherweise als Prozentsatz der Zeit angegeben, in der ein System innerhalb eines Zeitraums nutzbar ist, z. B. 99,9 % Verfügbarkeit im Monat. Je näher der Wert an 100 % liegt, desto weniger Ausfallzeit ist toleriert und desto höher ist in der Regel der technische und finanzielle Aufwand, um dieses Niveau zu erreichen. Solche Verfügbarkeitsziele werden häufig vertraglich in einem Service Level Agreement (SLA) zwischen Anbieter und Kunde festgelegt.

Als grobe Faustregel gilt: Jede zusätzliche „Neun" hinter dem Komma (99 % → 99,9 % → 99,99 %) reduziert die tolerierte Ausfallzeit drastisch und erhöht den Aufwand für Redundanz, Monitoring und Prozesse überproportional.

Redundanzprinzipien#

Redundanz bedeutet, kritische Komponenten mehrfach vorzuhalten, damit der Ausfall einer einzelnen Komponente nicht zum Ausfall des Gesamtsystems führt. Das Grundprinzip lässt sich unabhängig von der konkreten Komponente anwenden — ob Festplatte, Netzteil oder ganzer Server:

Prinzip	Bedeutung
N	Die minimal benötigte Anzahl an Komponenten für den Normalbetrieb
N+1	Eine zusätzliche Komponente steht bereit, um den Ausfall einer einzelnen N-Komponente aufzufangen
2N	Die komplette Kapazität wird verdoppelt (volle Redundanz, auch räumlich getrennt möglich)

Dieses Prinzip kennst du bereits auf Hardware-Ebene: RAID spiegelt oder verteilt Daten redundant über mehrere Festplatten, eine USV überbrückt den Ausfall der Stromversorgung. Hochverfügbarkeit überträgt dasselbe Prinzip auf die Systemebene — es geht nicht mehr nur um eine einzelne Komponente, sondern um ganze Server oder Standorte.

Clustering#

Ein Cluster ist ein Verbund mehrerer Server (Knoten), die zusammen einen Dienst bereitstellen. Fällt ein Knoten aus, übernehmen die verbleibenden Knoten dessen Aufgaben, ohne dass der Dienst insgesamt ausfällt. Man unterscheidet grob:

Aktiv-Passiv — ein Knoten ist aktiv im Einsatz, ein oder mehrere Knoten stehen als Standby bereit und übernehmen erst bei einem Ausfall
Aktiv-Aktiv — mehrere Knoten sind gleichzeitig aktiv und teilen sich die Last; fällt einer aus, übernehmen die übrigen automatisch dessen Anteil

Failover#

Failover ist der automatische Wechsel von einem ausgefallenen System auf ein Ersatzsystem, ohne dass ein Administrator manuell eingreifen muss. Voraussetzung dafür ist ein funktionierendes Monitoring, das einen Ausfall überhaupt erst erkennt, sowie ein Mechanismus, der den Datenverkehr automatisch auf das Ersatzsystem umleitet.

flowchart LR
    C[Clients] --> LB{Lastverteilung /<br/>Umschaltung}
    LB -->|Normalbetrieb| A[Aktiver Server]
    LB -.->|bei Ausfall von A:<br/>automatisches Failover| P[Passiver Standby-Server]
    A <-->|Datenabgleich /<br/>Zustandsübertragung| P

Im einfachsten Fall überwacht ein Mechanismus laufend die Erreichbarkeit des aktiven Servers (Heartbeat). Bleibt der Heartbeat aus, wird der Ausfall angenommen und der Datenverkehr automatisch auf den passiven Server umgeleitet. Damit dieser nahtlos übernehmen kann, müssen beide Server ihren Datenbestand laufend synchron halten.

Prüfungsbeispiele#

„Was bedeutet das N+1-Redundanzprinzip?"

→ Zusätzlich zu den N für den Normalbetrieb minimal benötigten Komponenten steht eine weitere bereit, die den Ausfall einer einzelnen Komponente auffängt, ohne dass der Betrieb unterbrochen wird.

„Ein Unternehmen betreibt zwei Server: Einer verarbeitet im Normalbetrieb alle Anfragen, der zweite läuft mit, greift aber nicht aktiv ein. Wie nennt man dieses Setup, und was passiert beim Ausfall des ersten Servers?"

→ Ein Aktiv-Passiv-Cluster. Beim Ausfall des aktiven Servers erkennt das Monitoring den Ausfall (z. B. über einen ausbleibenden Heartbeat) und ein automatisches Failover schaltet den Datenverkehr auf den passiven Standby-Server um.

„Warum reicht eine hohe Verfügbarkeitsangabe wie 99,9 % allein nicht aus, um die Qualität eines Dienstes zu beurteilen?"

→ Die Kennzahl sagt nichts darüber aus, wann die Ausfallzeit auftritt oder wie sie verteilt ist — ein kurzer, aber ungünstig getimter Ausfall (z. B. während eines Geschäftsvorgangs) kann trotz hoher Prozentzahl erheblichen Schaden verursachen. Zusätzlich sollten SLAs auch Reaktionszeiten und Wiederherstellungszeiten regeln.

Selbstkontrolle#

❓ Was bedeutet das Redundanzprinzip N+1?

❓ Worin unterscheidet sich ein Aktiv-Aktiv-Cluster von einem Aktiv-Passiv-Cluster?

❓ Was ist Voraussetzung für ein automatisches Failover?

Siehe auch#

raid — Redundanzprinzip auf Ebene einzelner Festplatten
usv-typen — Redundanz bei der Stromversorgung
backup-strategien — Wiederherstellung nach Datenverlust als Ergänzung zur Hochverfügbarkeit
monitoring-logging — Voraussetzung, um einen Ausfall überhaupt zu erkennen
hypervisor — VM-Migration zwischen Hosts als virtualisierte Form von Failover