# 13.6 Failover, Quorum und Split-Brain

**Einordnung**

Diese Seite gehört zum Kapitel:

**Server, Virtualisierung und Hochverfügbarkeit**

Auf der vorherigen Seite ging es allgemein um Cluster und Hochverfügbarkeit.

Jetzt geht es genauer um drei besonders wichtige Cluster-Begriffe:

| Begriff | Bedeutung |
|---|---|
| Failover | Übernahme bei Ausfall |
| Quorum | Entscheidungsmechanismus im Cluster |
| Split-Brain | Gefährlicher Zustand durch getrennte Cluster-Teile |

Diese Begriffe sind wichtig, weil sie erklären, wie ein Cluster bei Fehlern entscheidet und warum falsche Entscheidungen zu Datenverlust führen können.

---

**Grundidee**

Ein Cluster besteht aus mehreren Servern.

Diese Server müssen ständig wissen:

| Frage | Warum wichtig? |
|---|---|
| Welche Nodes sind erreichbar? | Damit Ausfälle erkannt werden |
| Welche Ressourcen laufen wo? | Damit Dienste nicht doppelt starten |
| Wer darf aktiv sein? | Damit keine Daten beschädigt werden |
| Gibt es eine Mehrheit? | Damit der Cluster eindeutig entscheiden kann |

Wenn ein Node ausfällt, soll der Cluster reagieren.

Wenn aber nur die Netzwerkverbindung gestört ist, darf der Cluster nicht einfach falsch übernehmen.

Genau dafür sind Quorum und Split-Brain-Schutz wichtig.

---

**Was ist Failover?**

Failover bedeutet, dass ein Dienst oder eine Ressource bei Ausfall eines Systems auf ein anderes System wechselt oder dort neu gestartet wird.

Beispiel:

Eine virtuelle Maschine läuft auf Host 1.

Host 1 fällt aus.

Der Cluster startet die VM auf Host 2 neu.

| Schritt | Ereignis |
|---|---|
| 1 | VM läuft auf HV01 |
| 2 | HV01 fällt aus |
| 3 | Cluster erkennt den Ausfall |
| 4 | VM wird auf HV02 gestartet |
| 5 | Dienst ist wieder erreichbar |

---

**Merksatz**

**Failover bedeutet Übernahme bei Ausfall.**

---

**Warum Failover wichtig ist**

Ohne Failover müsste ein Administrator einen Dienst manuell auf einem anderen System starten.

Das dauert länger und erhöht die Ausfallzeit.

Mit Failover kann ein Cluster schneller reagieren.

Vorteile:

| Vorteil | Erklärung |
|---|---|
| Kürzere Ausfallzeit | Dienst wird schneller wieder verfügbar |
| Automatische Reaktion | Kein sofortiges manuelles Eingreifen nötig |
| Bessere Verfügbarkeit | Kritische Dienste fallen weniger lange aus |
| Geplanter Betrieb | Ressourcen können gezielt verteilt werden |

---

**Failover bei virtuellen Maschinen**

In einem Virtualisierungscluster kann eine VM bei Host-Ausfall auf einem anderen Host neu gestartet werden.

Beispiel:

| VM | Vor Ausfall | Nach Failover |
|---|---|---|
| DC01 | HV01 | HV02 |
| FILE01 | HV01 | HV03 |
| WEB01 | HV02 | HV02 |
| DB01 | HV03 | HV03 |

Wenn HV01 ausfällt, werden die betroffenen VMs auf anderen Hosts neu gestartet.

Wichtig:

Es gibt meistens eine kurze Unterbrechung, weil die VM neu starten muss.

---

**Failover ist nicht immer unterbrechungsfrei**

Failover bedeutet nicht automatisch, dass Benutzer gar nichts merken.

Beispiel:

| Situation | Auswirkung |
|---|---|
| Host fällt aus | VM läuft nicht mehr |
| Cluster erkennt Ausfall | Fehler wird verarbeitet |
| VM wird auf anderem Host gestartet | Bootvorgang dauert |
| Dienst startet | Benutzer können wieder zugreifen |

Je nach Dienst kann die Unterbrechung Sekunden bis Minuten dauern.

---

**Failover vs. Fault Tolerance**

| Begriff | Bedeutung |
|---|---|
| Failover | Dienst wird nach Ausfall auf anderem System gestartet |
| Fault Tolerance | Dienst läuft trotz Ausfall möglichst ohne Unterbrechung weiter |

Failover ist in vielen IT-Umgebungen üblich.

Fault Tolerance ist technisch aufwendiger.

---

**Automatisches Failover**

Beim automatischen Failover erkennt der Cluster einen Fehler selbst und startet die betroffene Ressource auf einem anderen Node.

Beispiel:

| Ereignis | Reaktion |
|---|---|
| Node fällt aus | Cluster startet Ressource auf anderem Node |
| VM reagiert nicht | Cluster versucht Neustart |
| Dienst ist nicht erreichbar | Cluster löst Failover aus |

Vorteil:

Schnelle Reaktion.

Nachteil:

Wenn die Fehlererkennung falsch ist, kann ein unnötiges Failover ausgelöst werden.

---

**Manuelles Failover**

Beim manuellen Failover verschiebt ein Administrator eine Ressource bewusst auf einen anderen Node.

Typische Gründe:

| Grund | Beispiel |
|---|---|
| Wartung | Ein Host soll aktualisiert werden |
| Test | Failover-Funktion prüfen |
| Lastverteilung | Ressource soll auf anderen Node |
| Fehleranalyse | Dienst soll kontrolliert verschoben werden |

Manuelles Failover ist kontrollierter als automatisches Failover.

---

**Geplantes Failover**

Ein geplantes Failover findet bewusst statt.

Beispiel:

Ein Administrator möchte HV01 warten.

Vorher werden die VMs kontrolliert auf HV02 und HV03 verschoben.

| Schritt | Erklärung |
|---|---|
| 1 | Wartung ankündigen |
| 2 | Backups prüfen |
| 3 | VMs verschieben |
| 4 | Host warten |
| 5 | Funktion prüfen |
| 6 | Host wieder aktivieren |

Geplantes Failover verursacht meist weniger Risiko als ungeplantes Failover.

---

**Ungeplantes Failover**

Ein ungeplantes Failover passiert durch einen Fehler.

Beispiele:

| Ursache | Beispiel |
|---|---|
| Hardwaredefekt | Host fällt plötzlich aus |
| Stromausfall | Node geht aus |
| Netzwerkfehler | Node ist nicht erreichbar |
| Hypervisor-Absturz | Host reagiert nicht |
| Storageproblem | VM-Daten nicht erreichbar |

Ungeplantes Failover ist riskanter, weil der Ausfall plötzlich passiert.

---

**Failback**

Failback bedeutet, dass eine Ressource nach der Reparatur wieder auf das ursprüngliche System zurückwechselt.

Beispiel:

| Schritt | Ereignis |
|---|---|
| 1 | VM läuft auf HV01 |
| 2 | HV01 fällt aus |
| 3 | VM wird auf HV02 gestartet |
| 4 | HV01 wird repariert |
| 5 | VM wird wieder zurück auf HV01 verschoben |

Failback kann automatisch oder manuell erfolgen.

---

**Automatisches Failback**

Beim automatischen Failback wird eine Ressource automatisch auf den ursprünglichen Node zurückverschoben, sobald dieser wieder verfügbar ist.

Vorteil:

Der gewünschte Normalzustand wird automatisch wiederhergestellt.

Nachteil:

Es kann zusätzliche Bewegung und Last erzeugen.

Beispiel:

Ein Host kommt nach Reparatur zurück und viele VMs wandern automatisch zurück.  
Das kann unnötige Last verursachen.

---

**Manuelles Failback**

Beim manuellen Failback entscheidet ein Administrator bewusst, wann eine Ressource zurückverschoben wird.

Vorteil:

Kontrollierter Ablauf.

Nachteil:

Mehr manueller Aufwand.

In produktiven Umgebungen ist manuelles Failback oft sinnvoller, weil man vorher prüfen kann, ob der reparierte Node wirklich stabil läuft.

---

**Failover-Voraussetzungen**

Damit Failover funktionieren kann, müssen bestimmte Bedingungen erfüllt sein.

| Voraussetzung | Erklärung |
|---|---|
| Mehrere Nodes | Es muss ein Zielsystem geben |
| Clusterverwaltung | Nodes müssen gemeinsam verwaltet werden |
| Ressource muss clusterfähig sein | Dienst oder VM muss verschiebbar sein |
| Zugriff auf Daten | Zielnode muss an die Daten kommen |
| Netzwerkverbindung | Nodes müssen kommunizieren |
| Quorum | Cluster muss entscheiden können |
| Ressourcenreserve | Zielnode muss genug CPU/RAM haben |
| Monitoring | Fehler müssen erkannt werden |

---

**Failover bei VMs mit Shared Storage**

Bei Shared Storage greifen mehrere Hosts auf denselben Speicher zu.

Beispiel:

| Host | Zugriff auf VM-Daten |
|---|---|
| HV01 | Ja |
| HV02 | Ja |
| HV03 | Ja |

Wenn HV01 ausfällt, kann HV02 die VM starten, weil HV02 ebenfalls Zugriff auf die VM-Daten hat.

Vorteil:

Failover ist einfacher, weil die VM-Daten nicht erst kopiert werden müssen.

---

**Failover bei VMs mit lokalem Storage**

Wenn eine VM nur auf lokalem Storage eines Hosts liegt, ist Failover schwieriger.

Beispiel:

| VM | Speicherort |
|---|---|
| WEB01 | Lokale Disk von HV01 |

Wenn HV01 ausfällt, kommt HV02 nicht automatisch an die VM-Daten.

Mögliche Lösungen:

| Lösung | Erklärung |
|---|---|
| Replikation | VM-Daten werden auf anderen Host kopiert |
| Verteilter Storage | Daten liegen verteilt auf mehreren Nodes |
| Backup-Restore | VM aus Backup wiederherstellen |
| Shared Storage | Gemeinsamen Speicher nutzen |

---

**Failover und Ressourcenreserve**

Ein Failover funktioniert nur sinnvoll, wenn der Zielnode genug freie Ressourcen hat.

Beispiel:

| Node | Auslastung |
|---|---|
| HV01 | 90 % |
| HV02 | 95 % |
| HV03 | 92 % |

Wenn HV01 ausfällt, können HV02 und HV03 die zusätzlichen VMs kaum übernehmen.

Besser:

| Node | Auslastung |
|---|---|
| HV01 | 60 % |
| HV02 | 60 % |
| HV03 | 60 % |

Dann gibt es Reserven für einen Ausfall.

---

**N+1 beim Failover**

N+1 bedeutet, dass eine zusätzliche Reserve vorhanden ist.

Beispiel:

Für die normale Last werden zwei Hosts benötigt.

Es sind drei Hosts vorhanden.

| Benötigt | Vorhanden |
|---|---|
| 2 Hosts | 3 Hosts |

Wenn ein Host ausfällt, können die anderen Hosts die Last übernehmen.

---

**Was ist Quorum?**

Quorum ist ein Entscheidungsmechanismus in einem Cluster.

Es legt fest, ob der Cluster oder ein Teil des Clusters weiterarbeiten darf.

Ziel:

Der Cluster soll auch bei Störungen eindeutig entscheiden können.

Quorum verhindert, dass mehrere getrennte Cluster-Teile gleichzeitig aktiv werden.

---

**Merksatz**

**Quorum sorgt dafür, dass im Cluster nur der Teil weiterarbeitet, der eine gültige Mehrheit besitzt.**

---

**Warum braucht ein Cluster Quorum?**

Ein Cluster muss erkennen können, ob ein Node wirklich ausgefallen ist oder nur die Verbindung gestört ist.

Beispiel:

| Situation | Problem |
|---|---|
| Node antwortet nicht | Ist der Node aus oder nur nicht erreichbar? |
| Netzwerk getrennt | Beide Seiten könnten weiterarbeiten wollen |
| Storage erreichbar | Mehrere Nodes könnten auf dieselben Daten schreiben |
| Dienst wird doppelt gestartet | Daten können beschädigt werden |

Quorum verhindert falsche Mehrfachaktivität.

---

**Quorum und Mehrheit**

Viele Cluster arbeiten mit einem Mehrheitsprinzip.

Beispiel mit drei Nodes:

| Komponente | Stimme |
|---|---|
| Node 1 | 1 |
| Node 2 | 1 |
| Node 3 | 1 |

Insgesamt gibt es 3 Stimmen.

Mehrheit bedeutet mindestens 2 Stimmen.

| Erreichbare Stimmen | Entscheidung |
|---|---|
| 3 von 3 | Cluster darf arbeiten |
| 2 von 3 | Cluster darf arbeiten |
| 1 von 3 | Keine Mehrheit, Cluster sollte stoppen |

---

**Quorum-Beispiel mit drei Nodes**

Ausgangslage:

| Node | Zustand |
|---|---|
| HV01 | Online |
| HV02 | Online |
| HV03 | Online |

Alle Nodes haben Verbindung.

Der Cluster hat Quorum.

Jetzt fällt HV03 aus.

| Node | Zustand |
|---|---|
| HV01 | Online |
| HV02 | Online |
| HV03 | Offline |

HV01 und HV02 haben zusammen noch die Mehrheit.

Der Cluster darf weiterarbeiten.

---

**Quorum-Beispiel mit zwei getrennten Cluster-Teilen**

Ein Drei-Node-Cluster wird getrennt.

| Cluster-Teil | Nodes | Stimmen |
|---|---|---|
| Teil A | HV01, HV02 | 2 |
| Teil B | HV03 | 1 |

Teil A hat die Mehrheit und darf weiterarbeiten.

Teil B hat keine Mehrheit und darf nicht weiterarbeiten.

Dadurch wird verhindert, dass beide Seiten gleichzeitig aktiv sind.

---

**Quorum bei zwei Nodes**

Ein Zwei-Node-Cluster ist besonders kritisch.

Beispiel:

| Komponente | Stimme |
|---|---|
| Node 1 | 1 |
| Node 2 | 1 |

Wenn die Verbindung zwischen beiden Nodes ausfällt, hat jede Seite nur eine Stimme.

Ohne zusätzliche Entscheidungshilfe ist unklar, wer weiterarbeiten darf.

Deshalb braucht ein Zwei-Node-Cluster häufig einen Witness.

---

**Witness**

Ein Witness ist eine zusätzliche Entscheidungsinstanz für das Quorum.

Er hilft, eine Mehrheit zu bilden.

Beispiele:

| Witness-Art | Erklärung |
|---|---|
| File Share Witness | Netzwerkfreigabe als Zeuge |
| Disk Witness | Gemeinsamer Datenträger als Zeuge |
| Cloud Witness | Cloud-Dienst als Zeuge |

---

**Merksatz**

**Ein Witness hilft dem Cluster, bei gerader Node-Anzahl eine eindeutige Mehrheit zu bilden.**

---

**Zwei Nodes mit Witness**

Beispiel:

| Komponente | Stimme |
|---|---|
| Node 1 | 1 |
| Node 2 | 1 |
| Witness | 1 |

Insgesamt gibt es 3 Stimmen.

Mehrheit bedeutet mindestens 2 Stimmen.

| Erreichbar | Stimmen | Ergebnis |
|---|---|---|
| Node 1 + Node 2 + Witness | 3 | Cluster arbeitet |
| Node 1 + Witness | 2 | Node 1 darf arbeiten |
| Node 2 + Witness | 2 | Node 2 darf arbeiten |
| Nur Node 1 | 1 | Keine Mehrheit |
| Nur Node 2 | 1 | Keine Mehrheit |

---

**File Share Witness**

Ein File Share Witness ist eine Netzwerkfreigabe, die als Zeuge für das Quorum verwendet wird.

Beispiel:

| Komponente | Beispiel |
|---|---|
| Witness-Server | FS01 |
| Freigabe | \\FS01\ClusterWitness |
| Aufgabe | Zusätzliche Stimme für Quorum |

Vorteil:

Einfach einzurichten.

Nachteil:

Die Freigabe muss zuverlässig erreichbar sein.

---

**Disk Witness**

Ein Disk Witness ist ein gemeinsamer Datenträger, der als Zeuge genutzt wird.

Er wird oft in klassischen Shared-Storage-Clustern verwendet.

| Vorteil | Nachteil |
|---|---|
| Gute Integration in Storage-Cluster | Abhängigkeit vom gemeinsamen Storage |

---

**Cloud Witness**

Ein Cloud Witness nutzt einen Cloud-Dienst als Zeuge.

Beispiel:

Ein Windows-Failover-Cluster kann einen Cloud Witness verwenden.

Vorteil:

Nützlich bei verteilten Standorten.

Nachteil:

Abhängigkeit von Internet und Cloudzugang.

---

**Dynamisches Quorum**

Manche moderne Cluster können Stimmen dynamisch anpassen.

Ziel:

Der Cluster soll bei Node-Ausfällen möglichst lange entscheidungsfähig bleiben.

Beispiel:

Wenn ein Node geplant heruntergefahren wird, kann der Cluster die Stimmenverteilung anpassen.

Für die IHK reicht meist:

**Quorum bedeutet Mehrheitsentscheidung im Cluster.**

---

**Was ist Split-Brain?**

Split-Brain ist ein gefährlicher Zustand in einem Cluster.

Dabei verlieren Cluster-Teile die Verbindung zueinander und glauben gleichzeitig, aktiv sein zu dürfen.

Beispiel:

| Cluster-Teil | Glaubt |
|---|---|
| Teil A | Ich bin der aktive Cluster |
| Teil B | Ich bin der aktive Cluster |

Wenn beide Teile gleichzeitig auf dieselben Daten schreiben, können Daten beschädigt werden.

---

**Merksatz**

**Split-Brain bedeutet, dass getrennte Cluster-Teile gleichzeitig aktiv werden und dadurch Daten beschädigen können.**

---

**Wie entsteht Split-Brain?**

Split-Brain entsteht häufig durch Kommunikationsprobleme.

Beispiele:

| Ursache | Erklärung |
|---|---|
| Netzwerkunterbrechung | Nodes erreichen sich nicht mehr |
| Heartbeat-Verlust | Cluster erkennt andere Nodes nicht |
| Falsches Quorum | Keine klare Mehrheitsentscheidung |
| Fehlender Witness | Besonders kritisch bei zwei Nodes |
| Storage weiterhin erreichbar | Beide Seiten können auf Daten schreiben |
| Fehlkonfiguration | Clusterregeln sind falsch gesetzt |

---

**Split-Brain-Beispiel**

Ein Cluster besteht aus zwei Nodes.

Beide greifen auf denselben Storage zu.

| Komponente | Zustand |
|---|---|
| Node 1 | Online |
| Node 2 | Online |
| Verbindung zwischen Nodes | Unterbrochen |
| Shared Storage | Für beide erreichbar |

Problem:

Node 1 glaubt, Node 2 sei ausgefallen.  
Node 2 glaubt, Node 1 sei ausgefallen.

Wenn beide den Dienst aktiv starten und auf dieselben Daten schreiben, entsteht Datenkorruption.

---

**Warum Split-Brain gefährlich ist**

| Gefahr | Erklärung |
|---|---|
| Datenkorruption | Zwei Systeme schreiben gleichzeitig |
| Inkonsistente Daten | Unterschiedliche Datenstände entstehen |
| Dienstfehler | Anwendungen arbeiten mit falschem Zustand |
| Datenverlust | Änderungen können überschrieben werden |
| Schwierige Wiederherstellung | Manuelle Reparatur nötig |
| Lange Ausfallzeit | Analyse und Korrektur dauern |

---

**Wie verhindert man Split-Brain?**

Wichtige Maßnahmen:

| Maßnahme | Wirkung |
|---|---|
| Quorum korrekt planen | Nur Mehrheit darf arbeiten |
| Witness einsetzen | Hilft bei gerader Node-Anzahl |
| Redundantes Cluster-Netzwerk | Heartbeat-Ausfall vermeiden |
| Storage-Zugriff absichern | Nicht mehrere Seiten gleichzeitig schreiben lassen |
| Fencing / STONITH | Defekten oder isolierten Node ausschalten |
| Monitoring | Fehler früh erkennen |
| Tests | Failover-Szenarien prüfen |

---

**Fencing**

Fencing bedeutet, einen fehlerhaften oder isolierten Node vom Clusterbetrieb auszuschließen.

Ziel:

Ein Node, der nicht mehr sicher koordiniert ist, darf nicht weiter auf gemeinsame Ressourcen zugreifen.

Beispiel:

| Situation | Fencing-Reaktion |
|---|---|
| Node reagiert nicht korrekt | Node wird ausgeschaltet oder isoliert |
| Node hat Clusterkontakt verloren | Zugriff auf Ressourcen wird verhindert |
| Gefahr von Split-Brain | Unsicherer Node wird blockiert |

---

**STONITH**

STONITH steht für:

**Shoot The Other Node In The Head**

Das klingt hart, bedeutet technisch:

Ein unsicherer Node wird ausgeschaltet oder vom Zugriff ausgeschlossen.

Ziel:

Datenkonsistenz schützen.

Beispiel:

Ein Cluster kann über IPMI, iLO, iDRAC oder PDU einen Node ausschalten, wenn dieser nicht mehr sicher arbeitet.

---

**Warum Fencing wichtig ist**

Ohne Fencing könnte ein isolierter Node weiterarbeiten.

Problem:

Auch wenn ein Node keine Clusterverbindung mehr hat, kann er eventuell noch auf Storage schreiben.

Fencing stellt sicher:

| Ziel | Erklärung |
|---|---|
| Nur ein aktiver Zugriff | Daten werden geschützt |
| Unsicherer Node wird isoliert | Split-Brain wird verhindert |
| Clusterzustand bleibt eindeutig | Andere Nodes können übernehmen |

---

**Heartbeat**

Heartbeat ist ein regelmäßiges Signal zwischen Cluster-Nodes.

Damit prüfen Nodes gegenseitig, ob sie erreichbar sind.

Beispiel:

| Node | Heartbeat |
|---|---|
| HV01 | sendet Signal |
| HV02 | sendet Signal |
| HV03 | sendet Signal |

Wenn ein Node keinen Heartbeat mehr sendet, kann der Cluster einen Ausfall vermuten.

---

**Heartbeat-Verlust**

Ein Heartbeat-Verlust bedeutet nicht automatisch, dass der Server wirklich ausgefallen ist.

Mögliche Ursachen:

| Ursache | Erklärung |
|---|---|
| Server aus | Echter Ausfall |
| Netzwerkproblem | Node läuft noch, ist aber nicht erreichbar |
| Switchproblem | Verbindung unterbrochen |
| Firewallproblem | Heartbeat blockiert |
| Überlastung | Node antwortet zu spät |

Deshalb darf der Cluster nicht nur nach Gefühl entscheiden.

Quorum und Fencing sind wichtig.

---

**Cluster-Kommunikation**

Cluster-Nodes kommunizieren ständig miteinander.

Übertragen werden zum Beispiel:

| Information | Bedeutung |
|---|---|
| Node-Status | Online oder offline |
| Ressourcenstatus | Welche VM läuft wo? |
| Heartbeat | Erreichbarkeit |
| Quorum-Information | Mehrheit vorhanden? |
| Failover-Ereignisse | Umschaltungen |
| Konfiguration | Clusterregeln und Zustände |

---

**Cluster-Netzwerk redundant auslegen**

Das Cluster-Netzwerk sollte nicht nur über eine einzige Verbindung laufen.

Besser:

| Maßnahme | Vorteil |
|---|---|
| Zwei Netzwerkkarten | Schutz bei NIC-Ausfall |
| Zwei Switches | Schutz bei Switch-Ausfall |
| Getrennte VLANs | Logische Trennung |
| Separates Heartbeat-Netz | Weniger Störungen |
| Monitoring | Fehler schnell erkennen |

---

**Failover-Reihenfolge**

In manchen Clustern kann man festlegen, auf welchen Node eine Ressource bevorzugt wechseln soll.

Beispiel:

| Ressource | Bevorzugter Node | Ersatznode |
|---|---|---|
| VM DC01 | HV01 | HV02 |
| VM FILE01 | HV02 | HV03 |
| VM WEB01 | HV03 | HV01 |

Das hilft bei geordneter Lastverteilung.

---

**Failover-Priorität**

Nicht alle VMs sind gleich wichtig.

Beispiel:

| VM | Priorität |
|---|---|
| DC01 | Hoch |
| DNS01 | Hoch |
| DB01 | Hoch |
| FILE01 | Mittel |
| TEST01 | Niedrig |

Bei Ressourcenknappheit sollten wichtige VMs zuerst gestartet werden.

Testsysteme können später oder gar nicht automatisch starten.

---

**Abhängigkeiten beim Failover**

Manche Dienste hängen von anderen Diensten ab.

Beispiel:

| Dienst | Benötigt |
|---|---|
| APP01 | DB01 |
| WEB01 | APP01 |
| FILE01 | DC01 und DNS |
| BACKUP01 | Storage und Netzwerk |

Bei Failover oder Neustart muss die Reihenfolge beachtet werden.

---

**Startreihenfolge nach Failover**

Eine sinnvolle Startreihenfolge kann sein:

| Reihenfolge | System | Grund |
|---|---|---|
| 1 | Netzwerk / Storage | Grundlage |
| 2 | Domain Controller / DNS | Anmeldung und Namensauflösung |
| 3 | Datenbank | Anwendung benötigt Daten |
| 4 | Applikationsserver | Anwendung startet |
| 5 | Webserver | Zugriff für Benutzer |
| 6 | Monitoring / Backup | Kontrolle und Sicherung |

---

**Failover-Test**

Ein Failover sollte getestet werden.

Warum?

| Grund | Erklärung |
|---|---|
| Funktion prüfen | Failover muss im Ernstfall funktionieren |
| Ausfallzeit messen | RTO prüfen |
| Abhängigkeiten erkennen | Startreihenfolge testen |
| Dokumentation verbessern | Ablauf festhalten |
| Fehler vor Ernstfall finden | Risiko senken |

---

**Geplanter Failover-Test**

Typischer Ablauf:

| Schritt | Erklärung |
|---|---|
| Test ankündigen | Benutzer und Verantwortliche informieren |
| Backup prüfen | Rückfallmöglichkeit sicherstellen |
| Clusterzustand prüfen | Alle Nodes gesund? |
| Failover auslösen | Ressource verschieben |
| Dienst prüfen | Funktioniert der Dienst? |
| Rückschwenk testen | Failback prüfen |
| Ergebnis dokumentieren | Erkenntnisse festhalten |

---

**Risiken beim Failover-Test**

| Risiko | Erklärung |
|---|---|
| Dienstunterbrechung | Benutzer können betroffen sein |
| Datenbankprobleme | Transaktionen können unterbrochen werden |
| Abhängigkeiten | Folgefehler bei anderen Diensten |
| Performance | Zielnode kann überlastet werden |
| Rückfallplan fehlt | Problem dauert länger |

Deshalb sollten Failover-Tests geplant und dokumentiert werden.

---

**RTO beim Failover**

RTO steht für Recovery Time Objective.

Es beschreibt, wie lange ein Dienst maximal ausfallen darf.

Beispiel:

| Dienst | RTO |
|---|---|
| DNS | 15 Minuten |
| Fileserver | 2 Stunden |
| Testsystem | 24 Stunden |

Failover hilft, das RTO zu verkürzen.

---

**RPO beim Failover**

RPO steht für Recovery Point Objective.

Es beschreibt, wie viele Daten maximal verloren gehen dürfen.

Bei Failover hängt RPO stark von Storage und Replikation ab.

Beispiel:

| Technik | Möglicher Datenverlust |
|---|---|
| Shared Storage | Meist geringer, wenn Storage intakt |
| Synchrone Replikation | Sehr gering |
| Asynchrone Replikation | Letzte Änderungen können fehlen |
| Backup-Restore | Abhängig vom letzten Backup |

---

**Failover ersetzt kein Backup**

Failover schützt vor Ausfallzeiten, aber nicht vor Datenverlust durch falsche oder beschädigte Daten.

Beispiele:

| Problem | Failover hilft? | Backup hilft? |
|---|---|---|
| Host fällt aus | Ja | Nicht primär |
| Datei gelöscht | Nein | Ja |
| Ransomware verschlüsselt Daten | Nein | Ja, wenn Backup geschützt |
| Datenbank beschädigt | Nicht zuverlässig | Ja, wenn konsistentes Backup |
| Fehlkonfiguration | Nicht zuverlässig | Ja, wenn alter Stand vorhanden |

Merksatz:

**Failover erhöht Verfügbarkeit, Backup schützt vor Datenverlust.**

---

**Typische Fehler bei Failover, Quorum und Split-Brain**

| Fehler | Auswirkung |
|---|---|
| Kein Witness bei zwei Nodes | Unklare Entscheidung bei Ausfall |
| Quorum falsch geplant | Cluster kann stoppen oder falsch arbeiten |
| Kein Fencing | Split-Brain-Gefahr |
| Cluster-Netzwerk nicht redundant | Heartbeat-Probleme |
| Shared Storage nicht redundant | Storage bleibt Single Point of Failure |
| Keine Ressourcenreserve | Failover kann nicht starten |
| Keine Failover-Tests | Funktion im Ernstfall unsicher |
| Abhängigkeiten nicht dokumentiert | Dienste starten falsch |
| Failback automatisch ohne Kontrolle | Unnötige Last oder neue Störungen |
| Kein Backup | Datenverlust trotz Cluster möglich |

---

**Gute Praxis**

| Empfehlung | Grund |
|---|---|
| Quorum-Konzept planen | Klare Entscheidungen ermöglichen |
| Witness bei gerader Node-Anzahl nutzen | Mehrheit herstellen |
| Fencing einrichten | Split-Brain verhindern |
| Heartbeat-Netz redundant auslegen | Fehlalarme vermeiden |
| Ressourcenreserve einplanen | Failover ermöglichen |
| Failover regelmäßig testen | Ernstfall vorbereiten |
| Failback kontrolliert durchführen | Stabilität prüfen |
| Abhängigkeiten dokumentieren | Richtige Startreihenfolge |
| Monitoring einrichten | Probleme früh erkennen |
| Backups getrennt halten | Datenverlust vermeiden |

---

**Prüfungsnahes Beispiel 1**

Aufgabe:

Ein Zwei-Node-Cluster verliert die Netzwerkverbindung zwischen den beiden Nodes. Beide Nodes können weiterhin auf den gemeinsamen Storage zugreifen.

Frage:

Welches Risiko entsteht?

Mögliche Antwort:

Es besteht die Gefahr eines Split-Brain-Zustands. Beide Nodes könnten glauben, dass der jeweils andere ausgefallen ist und gleichzeitig aktiv werden. Wenn beide auf denselben Storage schreiben, kann es zu Datenkorruption kommen. Ein korrektes Quorum mit Witness und Fencing soll das verhindern.

---

**Prüfungsnahes Beispiel 2**

Aufgabe:

Ein Cluster besteht aus drei Nodes. Ein Node fällt aus.

Frage:

Darf der Cluster weiterarbeiten?

Mögliche Antwort:

Ja, wenn die verbleibenden zwei Nodes noch miteinander kommunizieren können. Bei drei Stimmen besitzen zwei erreichbare Nodes weiterhin die Mehrheit. Das Quorum ist vorhanden.

---

**Prüfungsnahes Beispiel 3**

Aufgabe:

Ein Cluster besteht aus zwei Nodes ohne Witness. Die Verbindung zwischen den Nodes wird unterbrochen.

Frage:

Warum ist das problematisch?

Mögliche Antwort:

Ohne Witness gibt es keine eindeutige Mehrheit. Jeder Node hat nur seine eigene Stimme. Dadurch kann der Cluster nicht sicher entscheiden, welcher Node weiterarbeiten darf. Es besteht Risiko für Dienstunterbrechung oder Split-Brain, je nach Konfiguration.

---

**Prüfungsnahes Beispiel 4**

Aufgabe:

Ein Administrator möchte einen Host warten und verschiebt vorher die VMs auf einen anderen Host.

Frage:

Ist das Failover oder Live Migration?

Mögliche Antwort:

Das ist eine geplante Verschiebung und wird als Live Migration bezeichnet, wenn die VMs dabei weiterlaufen. Failover beschreibt eher die Übernahme bei einem Fehler oder Ausfall.

---

**Prüfungsnahes Beispiel 5**

Aufgabe:

Ein Unternehmen hat einen Cluster, aber keine Backups. Ein Benutzer löscht versehentlich wichtige Daten.

Frage:

Warum hilft der Cluster nicht?

Mögliche Antwort:

Der Cluster sorgt für Verfügbarkeit, aber er stellt keine alten Datenstände wieder her. Wenn Daten gelöscht werden, ist der gelöschte Zustand auch im aktiven Dienst vorhanden. Für die Wiederherstellung wird ein Backup benötigt.

---

**Typische Prüfungsfrage: Was ist Failover?**

Mögliche Antwort:

Failover bedeutet, dass ein Dienst oder eine Ressource bei Ausfall eines Systems auf ein anderes System wechselt oder dort neu gestartet wird. Dadurch wird die Ausfallzeit reduziert.

---

**Typische Prüfungsfrage: Was ist Failback?**

Mögliche Antwort:

Failback bedeutet, dass eine Ressource nach der Reparatur des ursprünglichen Systems wieder zurück auf dieses System verschoben wird.

---

**Typische Prüfungsfrage: Was ist Quorum?**

Mögliche Antwort:

Quorum ist ein Entscheidungsmechanismus in einem Cluster. Es stellt sicher, dass nur der Cluster-Teil mit gültiger Mehrheit weiterarbeiten darf. Dadurch werden gefährliche Mehrfachaktivitäten verhindert.

---

**Typische Prüfungsfrage: Warum braucht ein Zwei-Node-Cluster oft einen Witness?**

Mögliche Antwort:

Bei zwei Nodes gibt es ohne Witness keine klare Mehrheit, wenn die Verbindung zwischen den Nodes unterbrochen wird. Ein Witness liefert eine zusätzliche Stimme und hilft dem Cluster, eindeutig zu entscheiden, welcher Teil weiterarbeiten darf.

---

**Typische Prüfungsfrage: Was ist Split-Brain?**

Mögliche Antwort:

Split-Brain ist ein gefährlicher Cluster-Zustand, bei dem getrennte Cluster-Teile gleichzeitig aktiv werden. Wenn beide Seiten auf dieselben Daten schreiben, kann es zu Datenkorruption oder Datenverlust kommen.

---

**Typische Prüfungsfrage: Wie verhindert man Split-Brain?**

Mögliche Antwort:

Split-Brain wird durch ein korrekt geplantes Quorum, einen Witness bei Bedarf, redundante Cluster-Kommunikation und Fencing verhindert. Dadurch darf nur der berechtigte Cluster-Teil weiterarbeiten.

---

**Typische Prüfungsfrage: Was ist Fencing?**

Mögliche Antwort:

Fencing bedeutet, einen unsicheren oder isolierten Node vom Zugriff auf gemeinsame Ressourcen auszuschließen. Dadurch wird verhindert, dass dieser Node weiterarbeitet und Daten beschädigt.

---

**Typische Prüfungsfrage: Was bedeutet STONITH?**

Mögliche Antwort:

STONITH steht für „Shoot The Other Node In The Head“. Gemeint ist, dass ein unsicherer Node ausgeschaltet oder isoliert wird, damit er keine gemeinsamen Daten beschädigen kann.

---

**Typische Prüfungsfrage: Unterschied Failover und Live Migration**

| Failover | Live Migration |
|---|---|
| Reaktion auf Fehler oder Ausfall | Geplante Verschiebung |
| Häufig kurze Unterbrechung | Möglichst ohne Unterbrechung |
| Beispiel: Host fällt aus | Beispiel: Host wird gewartet |
| Cluster startet Ressource woanders | Laufende VM wird verschoben |

---

**Typische Prüfungsfrage: Warum braucht Failover Ressourcenreserven?**

Mögliche Antwort:

Wenn ein Node ausfällt, müssen die verbleibenden Nodes dessen Dienste oder VMs übernehmen. Sind die verbleibenden Nodes bereits vollständig ausgelastet, kann das Failover nicht zuverlässig funktionieren. Deshalb braucht ein Cluster freie CPU-, RAM-, Storage- und Netzwerkressourcen.

---

**Typische Prüfungsfrage: Warum ersetzt Failover kein Backup?**

Mögliche Antwort:

Failover reduziert Ausfallzeiten bei Systemfehlern, stellt aber keine alten Datenstände wieder her. Bei gelöschten, verschlüsselten oder beschädigten Daten wird weiterhin ein Backup benötigt.

---

**Wichtige Begriffe**

| Begriff | Kurz erklärt |
|---|---|
| Failover | Übernahme bei Ausfall |
| Failback | Rückkehr auf ursprüngliches System |
| Automatisches Failover | Cluster reagiert selbst auf Fehler |
| Manuelles Failover | Administrator löst Umschaltung aus |
| Geplantes Failover | Bewusste Umschaltung für Wartung oder Test |
| Ungeplantes Failover | Umschaltung durch plötzlichen Fehler |
| Quorum | Entscheidungsmechanismus im Cluster |
| Mehrheit | Genug Stimmen für Weiterbetrieb |
| Witness | Zusätzliche Entscheidungsinstanz |
| File Share Witness | Netzwerkfreigabe als Zeuge |
| Disk Witness | Gemeinsamer Datenträger als Zeuge |
| Cloud Witness | Cloud-Dienst als Zeuge |
| Split-Brain | Getrennte Cluster-Teile werden gleichzeitig aktiv |
| Heartbeat | Regelmäßiges Signal zwischen Nodes |
| Fencing | Unsicheren Node ausschließen |
| STONITH | Unsicheren Node ausschalten oder isolieren |
| RTO | Maximal erlaubte Ausfallzeit |
| RPO | Maximal erlaubter Datenverlust |
| Live Migration | Laufende VM geplant verschieben |
| Ressourcenreserve | Freie Kapazität für Failover |

---

**Wichtige Merksätze**

**Failover bedeutet Übernahme bei Ausfall.**

**Failback bedeutet Rückkehr auf das ursprüngliche System.**

**Quorum sorgt für eine eindeutige Entscheidung im Cluster.**

**Ein Witness hilft besonders bei Clustern mit gerader Node-Anzahl.**

**Split-Brain ist ein gefährlicher Zustand, bei dem getrennte Cluster-Teile gleichzeitig aktiv werden.**

**Fencing verhindert, dass ein unsicherer Node weiter auf gemeinsame Ressourcen zugreift.**

**Heartbeat zeigt Erreichbarkeit, beweist aber nicht allein den echten Zustand eines Servers.**

**Failover braucht Ressourcenreserven.**

**Failover reduziert Ausfallzeiten, ersetzt aber kein Backup.**

**Live Migration ist geplant, Failover ist meist eine Reaktion auf einen Fehler.**

---

**Kurzzusammenfassung**

Failover, Quorum und Split-Brain gehören zu den wichtigsten Grundlagen beim Verständnis von Clustern.

| Thema | Kerngedanke |
|---|---|
| Failover | Ein Dienst oder eine VM wird bei Ausfall auf einem anderen Node gestartet |
| Failback | Nach Reparatur wird auf das ursprüngliche System zurückgeschwenkt |
| Quorum | Der Cluster entscheidet über eine Mehrheit |
| Witness | Zusätzliche Stimme zur Mehrheitsbildung |
| Split-Brain | Gefährliche Mehrfachaktivität getrennter Cluster-Teile |
| Heartbeat | Regelmäßige Erreichbarkeitsprüfung |
| Fencing | Unsichere Nodes werden ausgeschlossen |
| STONITH | Unsichere Nodes werden ausgeschaltet oder isoliert |

Für die IHK ist besonders wichtig:

| Prüfungsrelevanter Punkt | Bedeutung |
|---|---|
| Failover erklären | Übernahme bei Ausfall |
| Quorum erklären | Mehrheitsentscheidung im Cluster |
| Witness kennen | Zusätzliche Stimme bei gerader Node-Anzahl |
| Split-Brain verstehen | Gefahr für Datenkonsistenz |
| Fencing verstehen | Schutz vor unsicheren Nodes |
| Failover vs. Live Migration unterscheiden | Fehlerfall vs. geplante Verschiebung |
| Cluster vs. Backup unterscheiden | Verfügbarkeit ist keine Datensicherung |

Der nächste logische Schritt ist:

**Load Balancing und Skalierung**