Übernahme bei Ausfall

Was ist ein Hochverfügbarkeits-Cluster?

High Availability Cluster, kurz HA-Cluster

Ein Hochverfügbarkeits-Cluster ist ein Verbund mehrerer Server, die denselben Dienst bereitstellen können: Fällt ein Knoten aus, übernimmt ein anderer automatisch, sodass die Unterbrechung Sekunden bis Minuten dauert statt Stunden.

Wenn nachts ein Server stirbt, entscheidet nicht die Hardware darüber, ob morgens jemand arbeiten kann, sondern ob die Übernahme vorher schon einmal geprobt wurde.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Schützt vor: Ausfall eines Knotens, nicht vor Fehlern
Braucht: Quorum und Fencing
Zuerst klären: Zulässige Ausfallzeit und Datenverlust
Verwechselt mit: Backup

Quorum und Fencing verhindern den Split-Brain-Fall

Die gefährlichste Situation ist nicht der Ausfall eines Knotens, sondern der Abriss der Verbindung zwischen zwei Knoten, die beide weiterlaufen. Beide halten sich für den Überlebenden, beide starten den Dienst, beide schreiben auf denselben Speicher. Das Ergebnis ist ein zerstörter Datenbestand, im Englischen als Split Brain bekannt.

Dagegen helfen zwei Mechanismen. Das Quorum verlangt eine Mehrheit, bevor ein Knoten Dienste übernehmen darf, weshalb drei Knoten oder zwei Knoten plus ein Schiedsrichter üblich sind. Fencing schaltet den verdächtigen Knoten hart ab, meist über die Fernwartungskarte oder die Stromleiste, bevor der andere übernimmt. Wer Fencing für optional hält, baut sich eine Zeitbombe ein.

Aktiv-passiv oder aktiv-aktiv

Im aktiv-passiven Aufbau läuft der Dienst auf einem Knoten, der zweite wartet und übernimmt bei Bedarf. Das ist einfach zu verstehen, gut zu testen und für die meisten Anwendungen ausreichend. Der Preis ist Hardware, die im Normalbetrieb nichts tut.

Im aktiv-aktiven Aufbau arbeiten mehrere Knoten gleichzeitig am selben Dienst und teilen sich die Last. Das setzt allerdings voraus, dass die Anwendung dafür gebaut ist, insbesondere beim gleichzeitigen Schreiben. Viele Datenbanken bieten das an, aber mit Einschränkungen bei Sperren und Konsistenz, die man vor der Entscheidung kennen sollte.

Erst die Zielwerte, dann die Technik

Zwei Kennzahlen bestimmen den ganzen Entwurf. Die zulässige Ausfalldauer, üblicherweise RTO genannt, sagt, wie lange ein Dienst stillstehen darf. Der zulässige Datenverlust, RPO, sagt, wie viele Minuten Arbeit im Ernstfall verloren gehen dürfen. Beides muss aus dem Fachbereich kommen, nicht aus der IT.

Erst danach lässt sich beurteilen, ob synchrone Spiegelung nötig ist oder asynchrone reicht, ob ein zweiter Standort dazugehört und wie viel das Ganze kosten darf. Ein Cluster, dessen Umschaltung nie unter Last getestet wurde, hat übrigens keinen belegbaren RTO-Wert, sondern nur eine Hoffnung.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Nicht verwechseln

Hochverfügbarkeits-Cluster und was oft damit gleichgesetzt wird

Hochverfügbarkeits-Cluster gegen Backup

Ein Cluster schützt vor Hardware- und Softwareausfall, nicht vor Löschen, Verschlüsselung oder fehlerhaften Änderungen. Solche Fehler treffen alle Knoten gleichermaßen, weil diese entweder denselben Speicher benutzen oder die Änderung sofort weitergereicht bekommen. Ohne getrennte Sicherung sind die Daten deshalb trotz Cluster ungeschützt.

Hochverfügbarkeits-Cluster gegen Lastverteilung

Ein Load Balancer verteilt Anfragen auf mehrere Instanzen, um Durchsatz zu gewinnen. Hochverfügbarkeit ist ein Nebeneffekt, aber ohne Zustandsverwaltung und Failover-Logik keine Garantie.

Hochverfügbarkeits-Cluster gegen Georedundanz

Ein HA-Cluster steht meist in einem Rechenzentrum und überlebt keinen Brand oder Stromausfall des Standorts. Für diesen Fall braucht es einen zweiten Standort mit eigenen Regeln für Latenz und Umschaltung.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

In der Praxis

Ein Cluster fällt selten aus, er kippt

Der teuerste Zustand ist nicht der Ausfall, sondern das sogenannte Split-Brain: Die Knoten verlieren die Verbindung untereinander, halten sich beide für aktiv und schreiben beide auf denselben Datenbestand. Dagegen helfen zwei Dinge zusammen. Eine ungerade Zahl an Stimmen oder ein zusätzlicher Zeuge sorgt dafür, dass immer nur eine Seite die Mehrheit hat, und das erzwungene Abschalten des anderen Knotens stellt sicher, dass er wirklich stumm ist. Steht der Zeuge im selben Rack und am selben Strang, ist er keiner.

Alles, was der Verbund gut macht, macht er auch mit einem Fehler mit. Eine versehentlich geleerte Tabelle und verschlüsselte Dateien liegen Sekunden später auf dem zweiten Knoten. Ein Verbund ersetzt deshalb keine Sicherung, sondern verkürzt nur die Unterbrechung beim Hardwareausfall.

Bei der ersten echten Übernahme scheitert es fast nie an der Verbundsoftware, sondern an dem, was drumherum hängt: eine Lizenz, die an eine Netzwerkkennung gebunden ist, ein Dienst, der beim Start eine Freigabe erwartet, ein leerer Zwischenspeicher, der die Anwendung eine Stunde lang zäh macht. Deshalb gehört ein bewusst ausgelöster Schwenk in jedes Wartungsfenster, nicht nur in die Abnahme.

Hochverfügbarkeits-Cluster lernen

Wie sich Quorum, Fencing und Ressourcenagenten sauber konfigurieren lassen, üben die Kurse zu SUSE Linux Enterprise an einem echten Verbund.

Weil viele Cluster auf virtueller Hardware laufen, lohnt sich der Blick in die Kurse zur Virtualisierung im Rechenzentrum gleich mit.

Wissen prüfen

Sitzt Hochverfügbarkeits-Cluster schon?

Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.

Wissenstest LPIC-2 QuizTeste dein Wissen für die LPIC-2 Prüfungen 201 und 202: Kernel, Storage, DNS, Webserver, Samba und Sicherheit. Quiz starten Wissenstest LPIC-1 QuizTeste dein Wissen für die LPIC-1 Prüfungen 101 und 102: Shell, Prozesse, Dateisysteme, Netzwerk und Sicherheit. Quiz starten

Kurse, die Hochverfügbarkeits-Cluster behandeln

Häufige Fragen

Warum reichen zwei Knoten oft nicht?

Weil bei zwei Knoten keine Mehrheit zustande kommt, wenn die Verbindung abreißt. Üblich sind deshalb drei Knoten oder zwei Knoten und ein zusätzlicher Schiedsrichter, der nur eine Stimme beisteuert und selbst keine Dienste trägt.

Wie oft sollte der Failover getestet werden?

Mindestens einmal im Jahr und nach jeder größeren Änderung an Betriebssystem, Speicher oder Anwendung. Ein Test unter Last bringt dabei mehr als ein Test im Leerlauf, weil sich Zeitüberschreitungen und Sperren erst dann zeigen.

Schützt ein Cluster vor Ransomware?

Nein. Verschlüsselte Dateien werden auf die anderen Knoten repliziert, oft in Sekunden. Schutz bieten nur Sicherungen, die vom Cluster aus nicht veränderbar sind, etwa unveränderliche Ablagen oder physisch getrennte Kopien.

Persönlich für dich da