Verteilte Dateisysteme im Überblick: GlusterFS, Ceph und NFS im Vergleich

1. Warum verteiltes Storage für HA-Cluster nötig ist

Ein verteiltes Dateisystem löst ein Problem, das reine Anwendungs-Redundanz allein nicht lösen kann: Wenn mehrere Server dieselben Daten sehen oder ein Datenverlust bei Knotenausfall verhindert werden muss, reicht lokales Storage auf einer einzelnen Maschine nicht mehr aus. Ohne verteiltes Dateisystem müsste jeder Applikationsserver seine eigene Kopie der Daten halten, was bei Uploads, Sessions oder generiertem Content sofort zu Inkonsistenzen zwischen den Knoten führt.

In Hochverfügbarkeits-Szenarien mit Pacemaker und Corosync ist ein verteiltes Dateisystem oder zumindest ein geteiltes Blockgerät fast immer Teil der Ressourcen-Gruppe, weil eine Datenbank oder ein Applikationsserver nach einem Failover auf demselben Datenstand weiterarbeiten muss, den der vorherige aktive Knoten hinterlassen hat. Die Wahl des richtigen verteilten Dateisystems hat direkten Einfluss darauf, wie schnell ein Failover abläuft und wie robust das Gesamtsystem gegen Netzwerkprobleme ist.

Die Landschaft verteilter Dateisysteme unter Linux reicht von einfachem NFS über blockbasierte Replikation mit DRBD bis zu vollwertigen Cluster-Dateisystemen wie GlusterFS und objektbasierten Systemen wie Ceph. Jede dieser Lösungen für ein verteiltes Dateisystem trifft andere Kompromisse zwischen Einfachheit, Performance und tatsächlicher Ausfallsicherheit, die in den folgenden Abschnitten im Detail verglichen werden.

2. NFS: Der einfache Einstieg mit Grenzen

Network File System, kurz NFS, ist die älteste und am weitesten verbreitete Methode, ein Verzeichnis von einem zentralen Server über das Netzwerk auf mehreren Clients bereitzustellen. Für viele einfache Fälle geteilten Storages ist NFS die pragmatischste Wahl, weil es in jedem Linux-Kernel bereits eingebaut ist und keine zusätzliche Software auf Client-Seite benötigt.

Der entscheidende Nachteil von NFS in einem HA-Kontext: Der NFS-Server selbst ist ein Single Point of Failure. Fällt er aus, verlieren alle Clients gleichzeitig den Zugriff auf ihre Daten, unabhängig davon, wie viele redundante Applikationsserver dahinterstehen. Für echte Hochverfügbarkeit muss der NFS-Server selbst wiederum redundant gemacht werden, etwa über ein Pacemaker-verwaltetes Blockgerät im Hintergrund, wodurch NFS eher zur Zugriffsebene als zur eigentlichen Redundanzlösung wird.

# NFS server: export a shared directory
sudo apt install -y nfs-kernel-server
echo "/srv/shared 10.0.0.0/24(rw,sync,no_subtree_check)" | sudo tee -a /etc/exports
sudo exportfs -ra
sudo systemctl restart nfs-kernel-server

# NFS client: mount the shared directory
sudo apt install -y nfs-common
sudo mount -t nfs 10.0.0.5:/srv/shared /mnt/shared

# Persistent mount in /etc/fstab
echo "10.0.0.5:/srv/shared /mnt/shared nfs defaults,_netdev 0 0" | sudo tee -a /etc/fstab

3. DRBD: Block-Replikation zwischen zwei Knoten

Distributed Replicated Block Device, kurz DRBD, funktioniert grundlegend anders als NFS: Statt Dateien über das Netzwerk freizugeben, spiegelt DRBD ein komplettes Blockgerät in Echtzeit auf einen zweiten Knoten, vergleichbar mit einem netzwerkbasierten RAID 1. Auf dem replizierten Blockgerät liegt dann ein normales Dateisystem wie ext4 oder XFS, das nur auf dem jeweils aktiven Knoten gemountet ist.

DRBD ist die klassische Storage-Basis für Zwei-Knoten-Pacemaker-Cluster, weil es sich nahtlos als Cluster-Ressource einbinden lässt und bei einem Failover das Dateisystem auf dem übernehmenden Knoten sofort mit vollständig replizierten Daten zur Verfügung steht. Der Nachteil: DRBD skaliert konzeptionell nur auf wenige Knoten, typischerweise zwei bis drei, und eignet sich nicht für Storage, das über viele Server verteilt werden soll.

# /etc/drbd.d/shared.res — minimal DRBD resource definition
resource shared {
    protocol C;
    device /dev/drbd0;
    disk   /dev/sdb1;
    meta-disk internal;

    on node1 {
        address 10.0.1.11:7789;
    }
    on node2 {
        address 10.0.1.12:7789;
    }
}

4. GlusterFS: Verteiltes Dateisystem ohne Metadaten-Server

GlusterFS ist ein echtes verteiltes Dateisystem, das mehrere Storage-Knoten zu einem gemeinsamen Namensraum zusammenfasst, ohne dabei einen zentralen Metadaten-Server zu benötigen. Diese Architektur, elastic hashing genannt, berechnet die Position einer Datei direkt aus ihrem Namen, wodurch es keinen einzelnen Server gibt, dessen Ausfall den Zugriff auf Metadaten blockieren würde. Das macht GlusterFS deutlich robuster gegen Teilausfälle als klassische Client-Server-Architekturen.

Ein Replicated Volume in GlusterFS speichert jede Datei redundant auf mehreren Storage-Knoten gleichzeitig, sodass beim Ausfall eines Knotens die Daten auf den verbleibenden Knoten weiterhin verfügbar sind. Für Magento- und PHP-Umgebungen wird GlusterFS häufig für geteilten Media- und Session-Storage über mehrere Applikationsserver hinweg eingesetzt, wenn eine reine NFS-Lösung wegen des Single Point of Failure nicht ausreicht.

# Install GlusterFS server on both storage nodes
sudo apt install -y glusterfs-server
sudo systemctl enable --now glusterd

# Peer the two storage nodes together (run once, from node1)
sudo gluster peer probe node2

# Create a replicated volume across both nodes
sudo gluster volume create shared_vol replica 2 \
  node1:/data/brick1/shared_vol \
  node2:/data/brick1/shared_vol

sudo gluster volume start shared_vol

# Mount the GlusterFS volume on an application server
sudo apt install -y glusterfs-client
sudo mount -t glusterfs node1:/shared_vol /mnt/shared

5. Ceph: Objektspeicher als universelle Storage-Basis

Ceph verfolgt einen fundamental anderen Ansatz als GlusterFS: Im Kern ist Ceph ein verteilter Objektspeicher, auf dem drei unterschiedliche Zugriffsschichten aufsetzen, ein Objektspeicher-Gateway kompatibel zu S3, ein Blockgerät namens RBD und ein POSIX-kompatibles Dateisystem namens CephFS. Diese Flexibilität macht Ceph zur universellsten Lösung unter den hier vorgestellten Systemen, allerdings auch zur komplexesten in Betrieb und Konfiguration.

Die Grundeinheit von Ceph ist das Object Storage Device, kurz OSD, ein Prozess pro physischer Festplatte, der Daten speichert und repliziert. Der CRUSH-Algorithmus verteilt Daten deterministisch über die OSDs, ohne dass ein zentraler Lookup-Server nötig wäre, ähnlich dem elastic hashing von GlusterFS, aber mit deutlich feingranularerer Kontrolle über Replikationsfaktoren, Failure-Domains und Platzierungsregeln. Für Umgebungen, die sowohl Block-, Objekt- als auch Dateisystemzugriff auf derselben Storage-Basis benötigen, ist Ceph häufig die einzige Lösung, die alle drei Anforderungen gleichzeitig abdeckt.

6. Konsistenzmodelle und Split-Brain-Risiken

Jedes verteilte Dateisystem muss eine Grundsatzentscheidung treffen: Wie wird sichergestellt, dass alle Knoten dieselbe Sicht auf die Daten haben, wenn ein Netzwerkproblem die Kommunikation zwischen ihnen unterbricht? DRBD verwendet im Protokoll C eine synchrone Replikation, bei der ein Schreibvorgang erst als abgeschlossen gilt, wenn beide Knoten ihn bestätigt haben, was Konsistenz garantiert, aber Latenz erhöht. Asynchrone Protokolle wie Protokoll A reduzieren die Latenz, riskieren aber Datenverlust bei einem Ausfall des primären Knotens kurz nach einem noch nicht replizierten Schreibvorgang.

GlusterFS und Ceph nutzen Quorum-Mechanismen, ähnlich wie Pacemaker, um zu entscheiden, welche Knotenmehrheit im Zweifel als autoritativ gilt, wenn das Netzwerk partitioniert wird. Ohne korrekt konfiguriertes Quorum können auch verteilte Dateisysteme in eine Split-Brain-Situation geraten, bei der zwei Netzwerkpartitionen unabhängig voneinander widersprüchliche Änderungen an denselben Dateien vornehmen. Die anschließende Konfliktauflösung, in GlusterFS als Split-Brain-Resolution bezeichnet, erfordert häufig manuelles Eingreifen und sollte durch korrekte Quorum-Konfiguration von vornherein vermieden werden.

7. Performance-Charakteristik im Praxisvergleich

Die Performance-Eigenschaften unterscheiden sich erheblich zwischen den vorgestellten Lösungen. NFS bietet die geringste Latenz für einfache Lese- und Schreiboperationen, solange der Server selbst nicht überlastet ist, leidet aber bei vielen kleinen Dateien unter Metadaten-Overhead durch das Netzwerkprotokoll. DRBD erreicht nahezu native Blockgerät-Performance bei synchroner Replikation, wobei die Netzwerklatenz zwischen den beiden Knoten direkt in die Schreiblatenz der Anwendung eingeht.

GlusterFS zeigt gute Performance bei großen, sequenziellen Dateien wie Video- oder Backup-Daten, hat aber traditionell Schwächen bei sehr vielen kleinen Dateien, was für PHP-Anwendungen mit tausenden Session- oder Cache-Dateien relevant sein kann. Ceph benötigt in der Regel eine größere Mindest-Cluster-Größe, um seine Performance-Vorteile durch Parallelisierung über viele OSDs auszuspielen, und lohnt sich performancetechnisch selten bei nur zwei oder drei Storage-Knoten.

8. Praxisbeispiel: Shared Media-Storage für Magento

In einer horizontal skalierten Magento-Umgebung mit mehreren Applikationsservern hinter einem HAProxy-Loadbalancer müssen alle Server denselben Zugriff auf hochgeladene Produktbilder und generierte Cache-Dateien im pub/media-Verzeichnis haben. Eine verbreitete Lösung ist ein GlusterFS Replicated Volume, das auf jedem Applikationsserver als lokales Verzeichnis eingehängt wird, wodurch Uploads über einen Server sofort auf allen anderen sichtbar sind.

Für kleinere Setups mit nur zwei Applikationsservern ist stattdessen häufig eine einfachere Kombination aus NFS mit einem per Pacemaker verwalteten, DRBD-replizierten Blockgerät im Hintergrund ausreichend und deutlich wartungsärmer als ein vollständiges GlusterFS- oder Ceph-Cluster. Die Entscheidung hängt maßgeblich von der Anzahl der Applikationsserver und der erwarteten zukünftigen Skalierung ab, nicht von einer pauschalen Präferenz für die technisch komplexere Lösung.

9. Die richtige Wahl treffen: Entscheidungstabelle

Die Wahl des passenden verteilten Dateisystems hängt von drei Faktoren ab: der Anzahl der beteiligten Knoten, dem dominierenden Dateityp (viele kleine versus wenige große Dateien) und dem Grad an operativer Komplexität, den ein Team bereit ist zu tragen. Es gibt keine universell beste Lösung, nur die passende für ein konkretes Szenario.

10. Zusammenfassung

Ein verteiltes Dateisystem ist die notwendige Storage-Basis, sobald mehrere Server dieselben Daten sehen müssen oder ein Failover ohne Datenverlust ablaufen soll. NFS ist der einfachste Einstieg, bleibt aber ohne zusätzliche HA-Maßnahmen ein Single Point of Failure. DRBD eignet sich für Zwei-Knoten-Datenbank-Failover mit nahezu nativer Blockgerät-Performance, während GlusterFS als echtes verteiltes Dateisystem ohne Metadaten-Server für geteilten Media-Storage über mehrere Applikationsserver funktioniert.

Ceph deckt mit Block-, Objekt- und Dateizugriff aus einer gemeinsamen Basis die breiteste Funktionalität ab, benötigt dafür aber eine größere Mindest-Cluster-Größe und mehr operatives Wissen. Die Wahl zwischen diesen Optionen hängt von Knotenzahl, dominierendem Dateityp und akzeptierter Komplexität ab, nicht von einer pauschalen Empfehlung für die technisch fortschrittlichste Lösung.

11. FAQ: Verteilte Dateisysteme im Überblick