GlusterFS oder DRBD: Replikation, Konsistenz und Hochverfügbarkeit im Vergleich

EdwardMoon

GlusterFS und DRBD replizieren beide Daten über das Netzwerk, sind aber keine direkten Ersatzprodukte füreinander. GlusterFS ist ein verteiltes Dateisystem mit einem Dateinamensraum über mehreren Bricks. DRBD repliziert dagegen Blockgeräte unterhalb des Dateisystems. Vor der Produktauswahl muss deshalb feststehen, welche Zugriffssemantik die Anwendung benötigt.

Dieser Vergleich geht über die Faustregel „GlusterFS für Dateiserver, DRBD für Datenbanken“ hinaus. Er behandelt Schreibbestätigung, gleichzeitige Mounts, Netzpartitionen, Quorum, Fencing, Heal und die Zuständigkeit für Failover. Dazu kommen Befehle zur Zustandsprüfung und eine Auswahlcheckliste.

GlusterFS und DRBD: verteilte Dateireplikation und synchrone Blockgerätereplikation — Links ist die verteilte Dateireplikation dargestellt, rechts die Blockgerätereplikation mit Quorum-Zeugen.

Architekturunterschiede

Merkmal	GlusterFS Replica	DRBD 9
Replikationsebene	Dateien, Verzeichnisse und Metadaten	Geänderte Blöcke eines Blockgeräts
I/O-Pfad	Client beziehungsweise FUSE kommuniziert mit mehreren Bricks	Kernelmodul überträgt lokale Block-I/O an Peers
Darüberliegendes Dateisystem	GlusterFS stellt selbst einen gemeinsamen Namensraum bereit	ext4, XFS oder unter bestimmten Voraussetzungen ein Clusterdateisystem erforderlich
Übliches Zugriffsmodell	Mehrere Clients mounten gleichzeitig	Typischerweise Single-Primary im Active-Passive-Betrieb
Skalierung	Verteilte Replikatsätze erweitern Kapazität und Clientzugriff	DRBD 9 unterstützt mehrere Replikations-Peers, ist aber kein verteiltes Dateisystem
Wiederherstellungsebene	Dateiweises Heal und Bestimmung der gültigen Kopie bei Split Brain	Blocksynchronisierung anhand einer Dirty-Bitmap

Grundlegende Unterscheidung

Müssen mehrere Server denselben Dateibaum gleichzeitig lesen und schreiben, die gemeinsame Dateisemantik von GlusterFS prüfen.
Soll ein Dienst mit seinem lokalen Blockgerät auf einen anderen Knoten wechseln und dort weiterlaufen, DRBD Single-Primary prüfen.
In beiden Fällen ersetzt Replikation keine Sicherung: Auch Löschungen, Ransomware und logische Fehler können repliziert werden.

Schreibbestätigung und Latenz

Bei einem GlusterFS-Replica-Volume übermittelt der Client Dateioperationen über die AFR-Schicht an die Bricks des Replikatsatzes. Nach Ausfällen kann Heal erforderlich sein. Wird dieselbe Datei in getrennten Clusterteilen verändert, kann Split Brain entstehen: Die maßgebliche Kopie lässt sich dann nicht automatisch bestimmen. Mehr Replikate allein ergeben noch keine vollständige Quorum-Strategie.

DRBD Protocol C repliziert synchron und bestätigt den Abschluss gegenüber der oberen Schicht erst nach Bestätigung der lokalen und entfernten Datenträgerschreibvorgänge. Das kann das RPO beim Verlust eines Knotens reduzieren, überträgt aber Netzwerklaufzeit und Schreiblatenzen beider Speicher auf die Anwendung. Protocol A und B haben andere Bestätigungskriterien; DRBD ist daher nicht grundsätzlich immer synchron.

Identische Blöcke gewährleisten weder intakte Datenbanktransaktionen noch ein fehlerfreies Dateisystem. Cache-Persistenz bei Stromausfall, Dateisystem-Journal, fsync-Verhalten der Anwendung und Wiederherstellung nach erzwungenem Abbruch müssen gesondert geprüft werden.

Was gleichzeitiger Zugriff bedeutet

GlusterFS ist für mehrere gleichzeitig mountende Clients ausgelegt. Direkte Anwendungszugriffe auf die zugrunde liegenden Brick-Verzeichnisse sind jedoch kein unterstützter gemeinsamer Zugriffspfad. Nur über das Gluster-Clientprotokoll bleiben die AFR-Konsistenz- und Heal-Metadaten gewahrt.

Bei DRBD Single-Primary wird ein gewöhnliches Dateisystem wie ext4 oder XFS üblicherweise nur auf einem Primary gemountet. DRBD unterstützt auch Dual-Primary; gleichzeitige Mounts benötigen dann jedoch ein Clusterdateisystem mit verteilten Sperren wie GFS2 oder OCFS2 sowie Fencing. Ein gewöhnliches XFS gleichzeitig auf zwei Knoten zu mounten, kann das Dateisystem beschädigen.

Quorum und Split Brain

Replica 2 kann bei einer Netzpartition Konsistenz und Verfügbarkeit nicht gleichzeitig maximieren. Die offizielle Gluster-Dokumentation beschreibt Replica 3 beziehungsweise Arbiter-Volumes mit Client-Quorum zur Verringerung des Split-Brain-Risikos. Ein Arbiter ist keine dritte vollständige Datenkopie, sondern nutzt Metadaten als Stimme zur Bestimmung der maßgeblichen Seite.

GlusterFS-Zustand ohne Änderungen prüfen

sudo gluster peer status
sudo gluster volume list
sudo gluster volume info <VOLNAME>
sudo gluster volume status <VOLNAME> detail

Heal- und Split-Brain-Listen prüfen

sudo gluster volume heal <VOLNAME> info summary
sudo gluster volume heal <VOLNAME> info
sudo gluster volume heal <VOLNAME> info split-brain

Wer bei Split Brain den Quell-Brick allein nach Dateigröße oder Änderungszeit auswählt, kann gültige Daten überschreiben. Die maßgebliche Kopie gemeinsam mit den Anwendungsverantwortlichen bestimmen, sichern und erst danach das dateiweise Wiederherstellungsverfahren anwenden.

Aktuelle Quorum-Optionen prüfen

sudo gluster volume get <VOLNAME> cluster.quorum-type
sudo gluster volume get <VOLNAME> cluster.quorum-count
sudo gluster volume get <VOLNAME> cluster.server-quorum-type
sudo gluster volume get <VOLNAME> all | grep -Ei 'quorum|arbiter'

DRBD 9: Rollen, Protokolle und Quorum

DRBD-Ressourcen haben die Rolle Primary oder Secondary. Single-Primary ist ein übliches HA-Muster, doch DRBD 9 ist nicht auf zwei Knoten beschränkt und kann eine Ressource auf mehrere Hosts replizieren. Mit mehr Knoten werden Verbindungen, Metadaten, Resynchronisierung und Quorum-Planung komplexer. Technische Unterstützung und Eignung für den eigenen Betrieb müssen deshalb getrennt bewertet werden.

DRBD-Zustand und Replikationsfortschritt prüfen

sudo drbdadm status
sudo drbdsetup status --statistics
cat /proc/drbd
journalctl -k -b | grep -i drbd

Dry-Run vor Konfigurationsänderungen

sudo drbdadm -d adjust <RESOURCE>
sudo drbdadm dump <RESOURCE>

DRBD übernimmt nicht selbstständig die vollständige Umschaltung eines verbliebenen Secondary samt Anwendungsstart. Pacemaker, DRBD Reactor oder ein striktes manuelles Verfahren müssen Dienststopp, Aushängen des Dateisystems, Rollenwechsel, Mount sowie Start von VIP und Dienst geordnet steuern.

Quorum und Rollenstatus prüfen

sudo drbdsetup status --verbose --statistics
sudo drbdadm status <RESOURCE>

# Bei gemeinsamem Einsatz mit Pacemaker
sudo crm_mon -1Arf

Bei nur zwei Knoten lässt sich nach einer Verbindungsunterbrechung allein über das Netz nicht entscheiden, welche Seite die weiterhin gültige Kopie hält. Diskless Tiebreaker und Quorum von DRBD 9, Fencing beziehungsweise STONITH in Pacemaker sowie unabhängige Strom- und Netzwerkwege gemeinsam planen.

Warum sich die Failover-Abläufe unterscheiden

Schritt	GlusterFS	DRBD
Ausfallerkennung	Client erkennt fehlgeschlagene Brick-Verbindungen	Änderungen an Peer-Verbindung und Datenträgerzustand werden erkannt
Entscheidung über Schreibfreigabe	AFR-Client-Quorum und Volume-Zustand	Rolle, Datenträgerzustand und DRBD-Quorum
Wechsel des Datenpfads	Client kommuniziert mit weiterhin verfügbaren Bricks	Cluster-Manager führt Promotion, Mount und Dienststart aus
Wiederherstellung	Dateiweises Heal und Klärung von Split Brain	Blockweise Resynchronisierung und Wiedereingliederung der Rollen
Erforderliche externe Komponenten	Mehrere funktionierende Volfile-Server und Monitoring	Meist Cluster-Manager und Fencing

Die Pfadausweichung von GlusterFS und das Dienst-Failover von DRBD sind unterschiedliche Formen der Umschaltung. Bei GlusterFS wechselt der verteilte Dateisystemclient seinen I/O-Pfad. Bei DRBD muss ein Clusterablauf auch Dateisystem und Anwendung über dem Blockgerät geordnet auf den anderen Knoten verlagern.

Auswahl nach Arbeitslast

Die folgende Tabelle vergleicht technische Zugriffsmodelle. Vor einer Einführung gesondert den Sicherheits-Support durch GlusterFS-Community oder Distributionsanbieter sowie die Kompatibilität von DRBD-Kernelmodul und -Werkzeugen mit dem Hostkernel prüfen. Ohne wartbaren Paketbezugsweg scheidet eine Lösung für den Betrieb aus, selbst wenn ihre Funktionen passen.

Anforderung	Zuerst prüfen	Begründung und Einschränkungen
Mehrere Webknoten teilen dieselben Upload-Dateien	GlusterFS	Für gleichzeitigen Dateizugriff geeignet; Leistung mit kleinen Dateien und Heal prüfen
Active-Passive für eine einzelne Datenbank mit lokalem Dateisystem	DRBD	Protocol C und Cluster-Manager prüfen und mit der datenbankeigenen Replikation vergleichen
Horizontal skalierender Objektspeicher	Beide Ansätze erneut bewerten	S3-kompatibler Objektspeicher kann besser zur Zugriffssemantik passen
Live-Migration virtueller Maschinen	DRBD unter Voraussetzungen	Dual-Primary, Clusterdateisystem und Fencing oder eine spezielle Virtualisierungsintegration erforderlich
Große, nur lesend bereitgestellte Artefakte	GlusterFS oder Objektspeicher	Auch Cache, CDN und Verteilungspipeline vergleichen
Sicherung und Langzeitaufbewahrung	Keine der beiden Lösungen allein ausreichend	Separate Sicherung mit Versionierung, Unveränderlichkeit und standortübergreifender Wiederherstellung nötig

Fragen vor der Auswahl

Müssen mehrere Knoten gleichzeitig dasselbe Dateisystem beschreiben, oder genügt ein einzelner aktiver Knoten?
Welche RPO- und RTO-Werte sind zulässig, und ist die Latenz synchroner Replikation tragbar?
Hat bei einer Netzpartition Verfügbarkeit oder Konsistenz Vorrang?
Gibt es einen unabhängigen dritten Abstimmungspfad für Quorum und eine geeignete Fencing-Anbindung?
Wurde die Leistung im Normalbetrieb, bei eingeschränkter Replikation und während der Resynchronisierung getrennt gemessen?
Bestehen unabhängige Sicherungen und tatsächlich durchgeführte Wiederherstellungstests gegen Löschung, Beschädigung und Ransomware?

Checkliste für den Betrieb

Replikationsverbindungen vom Dienstverkehr trennen und Latenz, Paketverlust sowie Bandbreite überwachen.
Dienstverhalten auch bei Knotenausfall, Linkunterbrechung, Neustart und Resynchronisierung testen.
Bei GlusterFS Alarme für Heal-Rückstand und Split Brain einrichten; bei DRBD für Rollen-, Datenträger-, Verbindungs- und Quorum-Zustände.
Verfahren, die eigenmächtig beide Seiten schreibbar erzwingen, aus der regulären Betriebsanweisung entfernen.
Zusätzlich zur Replikation unveränderliche Sicherungen an einem anderen Standort mit Aufbewahrungsfristen betreiben und Wiederherstellungen regelmäßig prüfen.

Offizielle Dokumentation und weiterführende Anleitungen

Zusammenfassung

Die Auswahl zwischen GlusterFS und DRBD hängt davon ab, ob gemeinsamer Dateizugriff oder Blockgeräte-Failover benötigt wird. GlusterFS bietet einen verteilten Dateinamensraum und Heal, DRBD Blockreplikation und ausdrückliche Rollenwechsel. Für Hochverfügbarkeit muss jede Lösung in ein vollständiges Ausfallmodell mit Quorum, Fencing, Überwachung und unabhängiger Sicherung eingebettet sein.