Cloud & Infrastruktur

Hochverfügbarkeit

High Availability
Auch bekannt als: High Availability, HA, Ausfallsicherheit, Hochverfügbarkeitsbetrieb
Aktualisiert: November 2026
Auf den Punkt gebracht
Fähigkeit eines IT-Systems, auch beim Ausfall einzelner Komponenten weiterzuarbeiten, erreicht durch Redundanz, automatische Umschaltung und Überwachung.

Hochverfügbarkeit fällt im Gespräch mit IT-Abteilung oder Dienstleister meist in einem von zwei Zusammenhängen: bei der Planung eines Systems, das nicht stillstehen darf, und in Verträgen, in denen eine Verfügbarkeit in Prozent zugesagt wird. Technisch beruht sie auf drei Bausteinen. Wichtige Komponenten sind mehrfach vorhanden, etwa Server, Speicher, Netzanbindung und Stromversorgung. Fällt eine davon aus, übernimmt eine andere automatisch, im Fachjargon Failover. Und eine Überwachung erkennt Fehler schnell genug, damit die Umschaltung greift, bevor Nutzer etwas merken. Das Ziel ist, jeden Single Point of Failure zu beseitigen, also jede Stelle, deren Ausfall das ganze System lahmlegt.

Gemessen wird Verfügbarkeit als Anteil der Zeit, in der ein Dienst wie vereinbart nutzbar ist. Die Prozentzahlen klingen ähnlich, liegen in der Wirkung aber weit auseinander. Eine einfache Rechnung über ein Jahr mit 8.760 Stunden zeigt das: 99 Prozent erlauben rund 88 Stunden Ausfall, 99,9 Prozent knapp 9 Stunden, 99,99 Prozent etwa 53 Minuten und 99,999 Prozent gut 5 Minuten. Jede zusätzliche Neun verlangt mehr Redundanz, mehr Automatisierung und mehr Betriebsdisziplin. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat dem Thema mit dem HV-Kompendium ein eigenes Werk mit Definitionen und Grundprinzipien gewidmet.

Warum Hochverfügbarkeit eine Budgetentscheidung ist

Hochverfügbarkeit ist keine Eigenschaft, die ein System einfach hat oder nicht hat, sondern eine Abwägung. Jede Stufe kostet mehr: doppelte oder dreifache Hardware, ein zweiter Standort, Software für Cluster und Replikation, Personal in Rufbereitschaft. Ob sich das lohnt, hängt davon ab, was eine Stunde Stillstand kostet. Für ein Warenwirtschaftssystem im Versand oder die Steuerung einer Produktionslinie fällt die Antwort anders aus als für das Intranet. Die Führung sollte deshalb nicht pauschal Hochverfügbarkeit bestellen, sondern für jeden Geschäftsprozess festlegen, wie lange er höchstens ausfallen darf. Daraus folgt, welche Systeme welche Stufe brauchen.

Hinzu kommt ein Souveränitätsaspekt. In der Cloud ist Verfügbarkeit oft eine Frage der gewählten Konfiguration: Wer einen Dienst nur in einer Zone oder Region betreibt, erhält eine geringere Zusage als bei verteiltem Betrieb. Fällt der Anbieter selbst großflächig aus, hilft auch die beste Konfiguration innerhalb seiner Plattform nicht. Wirklich unabhängig wird nur, wer kritische Dienste notfalls an einem zweiten Standort oder bei einem zweiten Anbieter weiterbetreiben kann. Das ist aufwendig und lohnt sich nur für wenige Kernprozesse, sollte aber bewusst entschieden und nicht dem Zufall überlassen werden.

Wie Hochverfügbarkeit in der Praxis aussieht

Typische Bauformen sind Cluster aus mehreren Servern. Im Aktiv-Passiv-Betrieb arbeitet ein Knoten, ein zweiter wartet und übernimmt bei Ausfall. Im Aktiv-Aktiv-Betrieb teilen sich mehrere Knoten die Last, ein Ausfall verringert nur die Kapazität. Datenbanken werden auf mehrere Knoten repliziert, Speicher auf verteilte Systeme gelegt, Rechenzentren an zwei Standorte gespiegelt. Ebenso wichtig wie die Technik sind geübte Abläufe: Ein Failover, das nie getestet wurde, versagt oft genau dann, wenn es gebraucht wird.

Ein denkbares Szenario: Ein Handelsunternehmen betreibt seinen Onlineshop auf zwei Servern und hält sich damit für hochverfügbar. Bei einem Ausfall zeigt sich, dass beide Server an derselben Datenbank hängen, die nur einmal vorhanden ist. Der Shop steht mehrere Stunden still, obwohl die Webserver einwandfrei laufen. Eine Analyse aller Abhängigkeiten, von der Datenbank über das Speichersystem bis zur Internetanbindung, hätte die Schwachstelle vorher sichtbar gemacht. Die doppelten Server hatten nur einen Teil des Risikos abgedeckt.

Worauf es in Angeboten und Verträgen ankommt

  • Messzeitraum und Messpunkt: Klären, ob die Verfügbarkeit pro Monat oder pro Jahr gilt und wo gemessen wird, beim Anbieter oder aus Sicht der Nutzer. 99,9 Prozent pro Monat erlauben rund 43 Minuten Ausfall, pro Jahr fast 9 Stunden am Stück.
  • Ausnahmen: Geplante Wartungsfenster, höhere Gewalt und Störungen bei Zulieferern sind häufig ausgenommen. Je mehr Ausnahmen, desto weniger sagt die Prozentzahl.
  • Folgen bei Verfehlung: Oft gibt es nur Gutschriften auf die Monatsgebühr. Sie decken den Schaden eines Ausfalls selten ab. Ein Kündigungsrecht bei wiederholter Verfehlung ist meist wertvoller.
  • Nachweis: Regelmäßige Berichte über die tatsächliche Verfügbarkeit, Störungsprotokolle und dokumentierte Failover-Tests vereinbaren.
  • Ganze Kette betrachten: Die Zusage für eine Komponente sagt wenig über den Geschäftsprozess. Hängen mehrere Dienste hintereinander, ist die Gesamtverfügbarkeit niedriger als jede einzelne Zusage.

Abgrenzung zu verwandten Begriffen

Begriff Worum es geht Leitfrage
Hochverfügbarkeit Weiterlaufen trotz Ausfall einzelner Komponenten Merkt der Nutzer den Fehler?
Disaster Recovery Wiederanlauf nach einem großen Schaden, etwa Verlust eines Standorts Wie schnell sind wir wieder arbeitsfähig?
Backup Kopie von Daten zur späteren Wiederherstellung Welcher Datenstand lässt sich zurückholen?
Service Level Agreement Vertragliche Zusage zu Verfügbarkeit und Reaktionszeiten Was passiert, wenn die Zusage verfehlt wird?

Hochverfügbarkeit schützt nicht vor allem: Werden Daten versehentlich gelöscht oder von Schadsoftware verschlüsselt, repliziert ein hochverfügbares System den Schaden in Sekunden auf alle Knoten. Deshalb ersetzt sie weder Backup noch Notfallplanung, sondern ergänzt beide.

Quellen

Vertiefender Leitartikel
Disaster Recovery in der Cloud: RPO, RTO und Business Continuity im B2B-Check
Leitartikel öffnen →
Schwarzbrot Digital · jeden Freitag
Kein Glitzer, kein Hype – nur Substanz.

Der wöchentliche Klartext für Vorstände, CIOs und IT-Entscheider per E-Mail. Kapitel 1 des Buchs „Das CxO-Paradox“ gibt es schon jetzt als Vorabdruck – für alle, die Schwarzbrot Digital abonnieren.

Schwarzbrot Digital kostenlos abonnieren → Jeden Freitag neu · Abmeldung mit einem Klick
Mathias Diwo
Über den Autor

Mathias Diwo

Recherchiert, analysiert und schreibt auf TechNavigator.de über alltagstaugliche Wege zu digitaler Datenhoheit, IT-Architektur und Souveränität für Mittelstand, Geschäftsführung und IT-Leitungen.