GlusterFS einrichten: Replica 3, Mounts, Heal und Betriebskontrollen

EdwardMoon

GlusterFS stellt Datenträger mehrerer Server als gemeinsames Dateisystem bereit. Die Paketinstallation und das Verbinden zweier Knoten allein ergeben jedoch noch keine Hochverfügbarkeit. Replikationsfaktor, Quorum, Ausfalldomänen, Sicherungen und die Supportdauer der Pakete müssen gemeinsam geplant werden, um Datenverlust und Split-Brain-Risiken zu verringern.

Dieser Leitfaden beschreibt den Aufbau anhand einer Replica-3-Übungsumgebung, die sämtliche Daten auf drei Server repliziert. Befehle und Konfigurationsbeispiele stehen in eigenen Codeblöcken; jeder Schritt enthält Prüfungen und Abbruchbedingungen. Vor dem Übernehmen in eine Produktionsumgebung Gerätenamen, Netzbereiche und den Supportumfang des Paketlieferanten prüfen.

Version und Support vor dem Aufbau prüfen

Im offiziellen Downloadverzeichnis ist 11.1 die jüngste aufgeführte Community-Version. Die offizielle Release-Richtlinie beschreibt jedoch nur etwa zwölf Monate Pflege pro Hauptversion. Für eine neue Produktionsumgebung im Jahr 2026 lässt sich 11.1 daher nicht uneingeschränkt empfehlen. Prüfen, ob Distribution oder kommerzieller Anbieter Sicherheitsupdates liefern. Fehlt ein unterstützter Betriebspfad, auch Alternativen wie Ceph, hochverfügbares NFS oder Cloud-Dateidienste bewerten. Die folgenden Übungsbefehle setzen ein bereits geprüftes Repository für die EL9-Familie voraus.

Beispieltopologie

• Die drei Server in unterschiedlichen Ausfalldomänen betreiben und Zeitsynchronisierung sowie Vorwärts- und Rückwärtsnamensauflösung prüfen.
• Betriebssystem und Brick-Daten auf getrennten Datenträgern oder logischen Volumes unterbringen.
• Replica 3 speichert drei vollständige Kopien und benötigt ungefähr die dreifache Kapazität des ursprünglichen Datenbestands.
• Replikation überträgt auch Löschungen, Verschlüsselung und Anwendungsfehler. Eine unabhängige Sicherung ist daher erforderlich.

Namensauflösung und Zeitsynchronisierung auf allen Knoten prüfen

getent hosts gluster01 gluster02 gluster03
chronyc tracking
timedatectl status

Beispiel für Host-Zuordnungen

10.20.30.11  gluster01
10.20.30.12  gluster02
10.20.30.13  gluster03

Schritt 1: eigenen Brick-Datenträger vorbereiten

Die folgenden Schritte können vorhandene Daten auf dem Gerät löschen. Zunächst auf jedem Server tatsächlichen Gerätenamen und Mount-Status prüfen sowie Sicherung und Änderungsfreigabe sicherstellen. /dev/sdb ist ein Beispiel und muss an die Umgebung angepasst werden.

lsblk -f
findmnt --real
sudo wipefs --no-act /dev/sdb

sudo mkfs.xfs -f -i size=512 /dev/sdb
sudo mkdir -p /bricks/brick1
sudo blkid /dev/sdb

Mit der durch blkid ermittelten UUID auf jedem Server einen Eintrag nach folgendem Muster in /etc/fstab ergänzen.

UUID=<각-서버의-실제-UUID> /bricks/brick1 xfs defaults,noatime 0 2

sudo mount -a
findmnt /bricks/brick1
df -hT /bricks/brick1
sudo mkdir -p /bricks/brick1/gv0

Schritt 2: Pakete und glusterd prüfen

Bei EL9-Systemen zuerst prüfen, ob das Repository glusterfs-server tatsächlich anbietet. Fehlt das Paket oder sind Herkunft und Signatur unklar, hier abbrechen und keine beliebigen veralteten RPMs herunterladen.

sudo dnf repolist
sudo dnf repoquery --info glusterfs-server
sudo dnf install -y glusterfs-server glusterfs-fuse
rpm -q glusterfs-server glusterfs-fuse
glusterfs --version

sudo systemctl enable --now glusterd
sudo systemctl --no-pager --full status glusterd
sudo journalctl -u glusterd -b --no-pager | tail -n 80

Schritt 3: Firewall auf das Speichernetz beschränken

Seit Gluster 10 werden Brick-Ports zufällig innerhalb des konfigurierten Bereichs von base-port bis max-port gewählt. Management-Ports 24007–24008 und den tatsächlich benötigten Brick-Portbereich nur für das Speichersubnetz freigeben. Der folgende Bereich ist ein Beispiel; Brick-Anzahl und glusterd-Konfiguration darauf abstimmen und im Änderungsfenster anwenden.

sudo grep -E 'base-port|max-port' /etc/glusterfs/glusterd.vol
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --permanent --zone=internal \
  --add-rich-rule='rule family=ipv4 source address=10.20.30.0/24 port port=24007-24008 protocol=tcp accept'
sudo firewall-cmd --permanent --zone=internal \
  --add-rich-rule='rule family=ipv4 source address=10.20.30.0/24 port port=49152-49200 protocol=tcp accept'
sudo firewall-cmd --reload
sudo firewall-cmd --zone=internal --list-all

Auf neuen Übungsservern für dieses Firewall-Beispiel in /etc/glusterfs/glusterd.vol jedes Knotens den vorhandenen Block volume management um option base-port 49152 und option max-port 49200 konfigurieren, danach glusterd neu starten. Dieselben Optionen nicht doppelt eintragen. Bei produktiven Volumes zunächst tatsächliche Ports und Anzahl vorhandener Bricks ermitteln und den bisherigen Bereich zulassen. Den Portbereich nicht ohne Wartungsverfahren verkleinern.

sudoedit /etc/glusterfs/glusterd.vol
sudo systemctl restart glusterd
sudo systemctl status glusterd --no-pager
sudo grep -E "base-port|max-port" /etc/glusterfs/glusterd.vol

Schritt 4: Trusted Storage Pool aufbauen

Von gluster01 die beiden anderen Server per probe aufnehmen. Anschließend auch von gluster02 einmal gluster01 ansprechen, damit die Hostnamen einheitlich erfasst werden. Erst ein Volume erstellen, wenn alle Peers Connected melden.

# Auf gluster01 ausführen
sudo gluster peer probe gluster02
sudo gluster peer probe gluster03
sudo gluster peer status
sudo gluster pool list

# Auf gluster02 ausführen
sudo gluster peer probe gluster01
sudo gluster peer status

Schritt 5: Replica-3-Volume erstellen und prüfen

Replica 3 repliziert jede Datei auf drei Bricks. Ein rein verteiltes Volume vergrößert zwar die Kapazität, besitzt aber keine Replikate; der Ausfall eines Bricks kann die dort gespeicherten Dateien unzugänglich machen oder verlieren lassen. Ist Hochverfügbarkeit vorgesehen, Type und Brick-Anordnung in der Ausgabe von volume create sorgfältig prüfen.

sudo gluster volume create gv0 replica 3 transport tcp \
  gluster01:/bricks/brick1/gv0 \
  gluster02:/bricks/brick1/gv0 \
  gluster03:/bricks/brick1/gv0

sudo gluster volume info gv0
sudo gluster volume start gv0
sudo gluster volume status gv0 detail

Nach dem Volume-Start müssen alle drei Bricks Online melden. force kann auch Warnungen zu falschen Pfaden oder einer ungeeigneten Topologie übergehen. Die Option daher nicht verwenden, solange die Ursache einer Warnung unklar ist.

6. Client-Mount und Neustart prüfen

Auf dem Client glusterfs-fuse installieren. Die beiden weiteren Server als backup-volfile-servers angeben, falls der erste Volfile-Server nicht antwortet. Diese Option ersetzt jedoch nicht die Datenreplikation.

sudo dnf install -y glusterfs-fuse
sudo mkdir -p /mnt/gv0
sudo mount -t glusterfs gluster01:/gv0 /mnt/gv0 \
  -o backup-volfile-servers=gluster02:gluster03
findmnt /mnt/gv0
df -hT /mnt/gv0

Für einen automatischen Mount nach dem Neustart folgenden Eintrag in /etc/fstab des Clients ergänzen.

gluster01:/gv0 /mnt/gv0 glusterfs defaults,_netdev,backup-volfile-servers=gluster02:gluster03 0 0

sudo umount /mnt/gv0
sudo mount -a
findmnt /mnt/gv0
sudo touch /mnt/gv0/.mount-test
stat /mnt/gv0/.mount-test

7. Schreiben, Replikation und Wiederherstellung testen

Vor der Aufnahme produktiver Daten grundlegende Schreibzugriffe und Replikation mit einer separaten Testdatei prüfen. Anwendungen dürfen Brick-Pfade nicht direkt lesen oder beschreiben, da sie damit die Gluster-Metadaten umgehen. Clients müssen den Gluster-Einhängepunkt verwenden.

date -Is | sudo tee /mnt/gv0/healthcheck.txt
sha256sum /mnt/gv0/healthcheck.txt
sudo gluster volume status gv0
sudo gluster volume heal gv0 info summary

Geplante Ausfalltests in einem Wartungsfenster mit geprüfter Sicherung und Wiederherstellungsplanung durchführen. Während ein Knoten isoliert ist, Testdateien hinzufügen. Nach seiner Rückkehr prüfen, ob die ausstehenden Heal-Einträge gegen null gehen. Bei verlorener Mehrheit weder Schreibzugriffe erzwingen noch gleichzeitig in mehrere getrennte Clusterteile schreiben.

sudo gluster peer status
sudo gluster volume status gv0 detail
sudo gluster volume heal gv0 info summary
sudo gluster volume heal gv0 info
sudo gluster volume heal gv0 info split-brain

8. Heal und Split Brain sicher behandeln

Ausstehende Heal-Einträge sind für die automatische Wiederherstellung vorgesehen. Bei Split Brain kann Gluster dagegen nicht entscheiden, welche Kopie maßgeblich ist. Eine pauschale Auswahl nach jüngster Änderungszeit oder größter Datei kann korrekte Daten überschreiben. Zuerst Anwendungszugriffe stoppen und sichern, danach Dateiinhalte und Prüfsummen vergleichen.

sudo gluster volume heal gv0 info split-brain
sudo getfattr -d -m . -e hex /bricks/brick1/gv0/<문제-파일>
sudo stat /bricks/brick1/gv0/<문제-파일>
sudo sha256sum /bricks/brick1/gv0/<문제-파일>

Erst wenn die verantwortlichen Personen und das Anwendungsteam den maßgeblichen Brick bestimmt haben, die betreffende Datei mit source-brick wiederherstellen. Host-, Brick- und Dateipfade im folgenden Befehl anhand der tatsächlichen Prüfung ersetzen.

sudo gluster volume heal gv0 split-brain \
  source-brick gluster01:/bricks/brick1/gv0 /<문제-파일>

sudo gluster volume heal gv0 info split-brain
sudo gluster volume heal gv0 info summary

9. Fehler anhand von Logs und Zustandsdaten untersuchen

Vor einem Serverneustart wegen eines Mount-Fehlers zeitgleich Peer-, Volume- und Brick-Portzustände, Heal, Speicherbelegung, Inodes und Logs erfassen. Ein volles /var/lib/glusterd kann insbesondere den Verwaltungsdaemon beeinträchtigen.

sudo gluster pool list
sudo gluster volume info gv0
sudo gluster volume status gv0 detail
sudo gluster volume heal gv0 info summary
df -hT /var/lib/glusterd /bricks/brick1
df -i /var/lib/glusterd /bricks/brick1
sudo ss -lntp | grep -E ':(2400[78]|4915[2-9]|491[6-9][0-9]|49200)\b'
sudo journalctl -u glusterd -b --no-pager | tail -n 200

Scheitert bereits der Heal-Befehl, glfsheal-Log und Log des betroffenen Bricks prüfen. Logpfade und Prozessports können von Version und Paketierung abhängen; deshalb mit volume status abgleichen.

sudo ls -1 /var/log/glusterfs/
sudo tail -n 200 /var/log/glusterfs/glfsheal-gv0.log
sudo find /var/log/glusterfs/bricks -maxdepth 1 -type f -name '*.log' -print

10. Checkliste für den Betrieb

1. Sicherheits-Supportdauer und Upgrade-Pfad des Paketlieferanten dokumentieren.
2. Die drei Server auf unabhängige Strom-, Rack- und Netzwerkausfalldomänen verteilen.
3. Management- und Brick-Ports nur erforderlichen Quellnetzen erlauben und SELinux aktiv lassen.
4. Peers, Bricks, Heal, Split Brain, Kapazität, Inodes und Latenz fortlaufend überwachen.
5. Unabhängige Sicherungen gegen Löschung und Ransomware erstellen und regelmäßig Wiederherstellungen testen.
6. Knotenaustausch, Paket-Upgrades und die Bestimmung maßgeblicher Kopien bei Split Brain vor Änderungen üben.

Täglich oder durch das Monitoring zu erfassende Mindestwerte

sudo gluster peer status
sudo gluster volume status gv0
sudo gluster volume heal gv0 info summary
df -P /bricks/brick1
df -Pi /bricks/brick1

Weiterführende Artikel

• GlusterFS und DRBD: Replikationsebene, Konsistenz und Hochverfügbarkeit
• Linux: No space left on device diagnostizieren

Zusammenfassung

Ein sicherer GlusterFS-Aufbau beginnt mit der Planung von Fehlerfällen. Eine Replica-3-Topologie ermöglicht Mehrheitsentscheidungen; eigene Bricks, begrenzte Firewallfreigaben, konsistente Namensauflösung, Zustandsprüfungen und Heal-Überwachung bilden den Betriebsablauf. Unabhängige Sicherungen, Wiederherstellungstests und ein unterstützter Paketpfad machen daraus einen betreibbaren Dateidienst.