# GFS2 Masterclass: Simultaner Datenzugriff im Cluster

TL;DR / Management Summary GFS2 (Global File System 2) ist das Shared-Disk-Dateisystem von Red Hat. Im Gegensatz zu NFS (Dateiebene) oder klassischem XFS (Single-Node Blockebene) erlaubt GFS2 mehreren Servern den zeitgleichen Schreib- und Lesezugriff auf das gleiche Block-Device (SAN/iSCSI). Das Herzstück ist der DLM (Distributed Lock Manager), der verhindert, dass Nodes sich gegenseitig die Daten korrumpieren. Ein “High-Complexity” Werkzeug für spezialisierte Hochverfügbarkeits-Szenarien.

# 1. Einführung & Architektur

Wie wird der Zugriff koordiniert?

In einem lokalen Dateisystem verwaltet der Kernel die Locks im RAM. In einem Cluster-Dateisystem müssen die Locks über das Netzwerk zwischen den Nodes synchronisiert werden.

# Die DLM-Schicht (Mermaid)

graph TD
    subgraph "Node 1"
        A[App A] --> B[GFS2 Driver]
        B --> C[DLM: Request Lock]
    end
    subgraph "Node 2"
        D[App B] --> E[GFS2 Driver]
        E --> F[DLM: Request Lock]
    end
    C <--> G[Cluster Network]
    F <--> G
    G --> H[Shared SAN LUN]

• Journals: Jeder Node hat sein eigenes Journal auf der Disk. Das verhindert, dass bei einem Absturz eines Nodes das gesamte Dateisystem gescannt werden muss.

# 2. Erstellung & Erweiterung

Den Speicher vorbereiten.

# GFS2 formatieren

Sie benötigen einen eindeutigen Namen für das Cluster-Dateisystem (ClusterName:FSName).

# -p: protocol (lock_dlm), -t: locktable, -j: number of journals (one per node!)
sudo mkfs.gfs2 -p lock_dlm -t prod_cluster:shared_data -j 4 /dev/mapper/mpatha

# Journals hinzufügen

Wenn Sie einen fünften Node zum Cluster hinzufügen, müssen Sie ein neues Journal anlegen:

sudo gfs2_jadd -j 1 /mnt/shared_data

# 3. Performance Tuning

Die Netzwerklatenz ist der Feind.

GFS2-Performance steht und fällt mit dem Netzwerk. Jedes Mal, wenn ein Node eine Datei schreiben will, muss er das Lock über das Netz beim “Lock Master” anfordern.

# Optimierungen

• noatime: Deaktivieren Sie das Schreiben des Zugriffszeitstempels (spart massiv Locks).
• plock_rate_limit: Begrenzt die Anzahl der POSIX-Locks, um den DLM nicht zu überfluten.
• Stateless Apps: GFS2 ist nicht für Workloads mit tausenden kleinen Dateien geeignet (z.B. PHP-Sessions oder Mail-Directories). Nutzen Sie es für große Files oder Datenbank-Container.

# 4. Day-2 Operations: Wartung & Checks

Im laufenden Betrieb prüfen.

# Dateisystem-Status

# Zeigt Informationen über Journals und Locks
sudo gfs2_edit -p jindex /dev/mapper/mpatha

# Online-Resize

GFS2 kann im gemounteten Zustand vergrößert werden:

sudo gfs2_grow /mnt/shared_data

# 5. Troubleshooting & “War Stories”

Wenn der Cluster hängen bleibt.

# Story 1: “Der Node-Withdraw”

Symptom: Ein Node “verliert” plötzlich den Zugriff auf das Dateisystem, alle Prozesse hängen (D-State). Im Log steht GFS2: fsid=...: fatal: invalid metadata block. Ursache: GFS2 hat eine Korruption oder einen Netzwerk-Timeout bemerkt und sich aus Sicherheitsgründen “zurückgezogen” (Withdraw), um die Datenintegrität auf der Disk zu schützen. Lösung: Den Node rebooten (Fencing findet oft automatisch statt). Prüfen Sie die Hardware und das Cluster-Netzwerk auf Paketverlust.

# Story 2: “DLM Performance-Drop”

Symptom: Die I/O-Performance sinkt massiv, sobald ein zweiter Node das Dateisystem mountet. Ursache: “Ping-Pong” Effekt der Locks. Zwei Nodes greifen abwechselnd auf das gleiche Verzeichnis/die gleiche Datei zu. Lösung: Applikationen so konfigurieren, dass sie bevorzugt auf “ihre” Unterverzeichnisse zugreifen, um Lock-Konflikte zu minimieren.

# 6. Fazit & Empfehlung

• Komplexität: GFS2 ist eines der komplexesten Dateisysteme. Nutzen Sie es nur, wenn Sie keine andere Wahl haben.
• Alternative: In modernen Cloud-Native Umgebungen ist oft ein Object Store (S3) oder ein verteiltes Dateisystem (CephFS) die bessere und skalierbarere Wahl.
• Netzwerk: Nutzen Sie 10G oder 25G Ethernet mit niedriger Latenz für den DLM-Traffic.

# Anhang: Cheatsheet