# RHEL High Availability: Enterprise Clustering mit dem HA Add-On

TL;DR / Management Summary Für geschäftskritische Workloads bietet Red Hat das RHEL High Availability Add-On. Während die Basis (Corosync/Pacemaker) Standard ist, bietet die RHEL-Implementierung mit dem Tool pcs (Pacemaker Configuration System) ein konsistentes Interface für alle Cluster-Aufgaben. Ein Senior Admin nutzt dieses Add-On nicht nur für Failover-IPs, sondern oft in Kombination mit GFS2 (Global File System 2), um gleichzeitig von mehreren Nodes auf den gleichen Speicher zuzugreifen.

# 1. Einführung & Architektur

Der RHEL HA Stack.

RHEL HA bündelt mehrere Technologien zu einer stabilen Plattform.

# Die Komponenten (Mermaid)

graph TD
    A[RHEL Host 1] --- B[Corosync: Messaging]
    A --- C[Pacemaker: Resource Manager]
    B <--> D[RHEL Host 2]
    C <--> D
    C --> E[pcs daemon / CLI]
    subgraph "Storage & Fencing"
        F[Shared SAN Storage] --- A
        F --- D
        G[STONITH: IPMI / Fence Agents] --- A
        G --- D
    end

# 2. Der RHEL Weg: pcs

Zentrale Konfiguration.

In RHEL nutzen wir ausschließlich pcs, um den Cluster zu verwalten. Es synchronisiert die Konfiguration automatisch über alle Nodes.

# Cluster-Setup (RHEL Standard)

# 1. Pakete installieren
sudo dnf install pacemaker pcs fence-agents-all

# 2. Dienst starten
sudo systemctl enable --now pcsd

# 3. Authentifizierung (User: hacluster)
sudo pcs host auth node1 node2 -u hacluster -p mypassword

# 4. Cluster erstellen
sudo pcs cluster setup my_cluster node1 node2
sudo pcs cluster start --all

# 3. Clustered File Systems: GFS2

Simultane Schreibzugriffe.

Ein Alleinstellungsmerkmal von RHEL HA ist der Support für GFS2. Im Gegensatz zu NFS/SMB können hier mehrere Nodes gleichzeitig das gleiche Block-Device (iSCSI/FC) mounten.

# Voraussetzung: DLM (Distributed Lock Manager)

GFS2 benötigt DLM, um sicherzustellen, dass zwei Nodes nicht den gleichen Block gleichzeitig schreiben.

# GFS2 Volume erstellen (nachdem Cluster & DLM konfiguriert sind)
sudo mkfs.gfs2 -p lock_dlm -t my_cluster:data01 -j 2 /dev/vg_ha/lv_gfs2

# 4. Day-2 Operations: Monitoring & Failover-Tests

Die Ruhe vor dem Sturm.

# Den Status im Blick behalten

sudo pcs status

Achten Sie auf “Failed Actions”. Ein Cluster, der Ressourcen nicht sauber stoppen kann, wird den Node im Ernstfall “fencen” (abschalten).

# Geplanter Schwenk (Switchover)

# Verschiebe Ressource 'web_vip' auf node2
sudo pcs resource move web_vip node2

# 5. Troubleshooting & “War Stories”

Wenn der Cluster ‘Shoot The Other Node In The Head’ ernst nimmt.

# Story 1: “Der Fencing-Loop”

Symptom: Node 1 startet neu, wird aber sofort nach dem Hochfahren wieder von Node 2 abgeschaltet. Ursache: Ein Ressourcen-Fehler auf Node 1 wird als kritisch eingestuft. Node 2 denkt, Node 1 sei instabil und schaltet ihn sicherheitshalber aus (Fencing). Lösung: Den Node in den Wartungsmodus setzen (pcs node standby), den Fehler beheben und die Historie löschen: pcs resource cleanup.

# Story 2: “DLM Lock-Hänger”

Symptom: GFS2-Dateisysteme sind extrem langsam oder frieren ein. Ursache: Das Netzwerk für Corosync (Heartbeat) hat eine zu hohe Latenz. DLM kann die Locks nicht schnell genug bestätigen. Lösung: Nutzen Sie immer ein dediziertes, latenzarmes Netzwerk (Back-to-Back oder isolierter Switch) für den Cluster-Traffic. Mischen Sie niemals Applikations-Traffic mit Heartbeat-Traffic.

# 6. Fazit & Empfehlung

• Quorum: Betreiben Sie Cluster nach Möglichkeit immer mit einer ungeraden Anzahl an Nodes oder nutzen Sie einen Quorum-Device (QNetD).
• Fencing: Konfigurieren Sie STONITH ab dem ersten Tag. Ohne Fencing ist Ihr Cluster nicht “Enterprise Ready”.
• GFS2: Nutzen Sie GFS2 nur, wenn die Applikation zwingend simultanen Dateisystemzugriff braucht. Für 90% der Fälle reicht ein Failover-Dateisystem (XFS auf Shared Disk).

# Anhang: Cheatsheet