# RHEL HA: Multi-Site Cluster und Disaster Recovery

TL;DR / Management Summary Ein lokaler HA-Cluster schützt vor dem Ausfall eines Servers. Aber was passiert, wenn das gesamte Rechenzentrum (RZ) abbrennt? Disaster Recovery (DR) und Multi-Site (Stretch) Cluster dehnen die Hochverfügbarkeit über zwei oder mehr Standorte aus. In der RHEL-Welt nutzen wir dafür den Corosync QNetD für das Quorum und Daten-Replikations-Technologien, um den RPO (Data Loss) und RTO (Downtime) so gering wie möglich zu halten.

# 1. Einführung & Architektur

Das Quorum-Problem über Standorte hinweg.

In einem Stretch-Cluster (Standort A und B) ist die größte Gefahr der Split-Brain. Wenn die Leitung zwischen den RZs reißt, denken beide Standorte, der jeweils andere sei tot, und versuchen die Dienste zu übernehmen.

# Die Architektur-Lösung (Mermaid)

graph TD
    subgraph "Site A (Primary DC)"
        Node1[RHEL Node 1]
        Node2[RHEL Node 2]
    end
    subgraph "Site B (Secondary DC)"
        Node3[RHEL Node 3]
        Node4[RHEL Node 4]
    end
    subgraph "Site C (Witness / Cloud)"
        QNetD[Corosync QNetD]
    end
    Node1 <-->|Data Sync| Node3
    Node1 --- QNetD
    Node3 --- QNetD

• QNetD (Quorum Device): Ein kleiner Dienst an einem dritten Standort (Witness), der entscheidet, welcher Standort überleben darf, wenn die Verbindung zwischen A und B unterbrochen ist.

# 2. Quorum Device Setup

Der Schiedsrichter.

# Schritt 1: QNetD Server (Site C)

sudo dnf install corosync-qnetd
sudo systemctl enable --now corosync-qnetd

# Schritt 2: Cluster-Nodes konfigurieren

sudo dnf install corosync-qdevice
sudo pcs host auth site-c-witness -u hacluster
sudo pcs cluster qdevice add net --peer-host=site-c-witness

# 3. Datenreplikation: DRBD

Die Festplatte über die Leitung spiegeln.

Wenn kein gemeinsames SAN über beide Standorte existiert, nutzen wir DRBD (Distributed Replicated Block Device) – das “Netzwerk-RAID 1”.

# Konfiguration (/etc/drbd.d/data.res)

resource data {
  on node1 { device /dev/drbd0; disk /dev/vg_data/lv_data; address 10.0.1.1:7788; }
  on node3 { device /dev/drbd0; disk /dev/vg_data/lv_data; address 10.0.2.1:7788; }
}

# 4. Day-2 Operations: Failover-Strategien

Manuell oder Automatisch?

# Automatisches Failover (Stretch Cluster)

Innerhalb einer Latenz von < 5ms kann Pacemaker Ressourcen automatisch zwischen Standorten schwenken.

• Vorteil: Minimale Downtime (RTO).
• Nachteil: Gefahr von Flapping bei instabilen Leitungen.

# Manuelles DR (Primary/Secondary)

Bei großen Entfernungen (> 50km) ist die Replikation oft asynchron. Hier triggert der Admin das Failover manuell über Satellite oder Ansible.

# 5. Troubleshooting & “War Stories”

Wenn die Welt untergeht.

# Story 1: “Der falsche Zeuge”

Symptom: Bei einem Leitungsabbruch zwischen Site A und B schalten sich beide Standorte ab, obwohl Site C (QNetD) erreichbar ist. Ursache: Fehlkonfiguration der expected_votes. Der Cluster erkennt den Zeugen nicht als stimmberechtigtes Mitglied. Lösung: Prüfen Sie mit corosync-quorumtool -s, ob das QDevice aktiv ist und ein “Vote” abgibt.

# Story 2: “Replication Lag im Ernstfall”

Symptom: Nach einem Failover zu Site B sind die Daten korrupt oder uralt. Ursache: Asynchrone Replikation. Die Leitung war zu langsam für die Schreiblast, und der Puffer auf Site A wurde nie geleert, bevor der Standort ausfiel. Lösung: Überwachen Sie den Replikations-Status (z.B. drbdadm status). Setzen Sie Schwellwerte für den maximalen Datenrückstand.

# 6. Fazit & Empfehlung

• Drittstandort: Ein Multi-Site Cluster ohne dritten Standort für das Quorum ist extrem riskant. Eine kleine VM in der Cloud oder einem Büro reicht als Witness.
• Netzwerk: Latenz ist wichtiger als Bandbreite. Nutzen Sie dedizierte L2-Verbindungen (Dark Fiber) wenn möglich.
• Test: Simulieren Sie den Totalausfall eines Standorts (“Pull the Plug”) mindestens einmal im Jahr.

# Anhang: Cheatsheet