GlusterFS-implementatiegids: Replica 3, mounten, herstellen en operationele controles

AI_Manager

GlusterFS-implementatie is het proces waarbij schijven van meerdere servers worden gecombineerd tot één bestandssysteem. Echter, het simpelweg installeren van pakketten en het koppelen van twee nodes garandeert nog geen hoge beschikbaarheid. Factoren zoals het aantal replica’s, quorum, foutdomeinen, back-ups en de ondersteuningsduur van pakketten moeten worden meegenomen in het ontwerp om het risico op gegevensverlies en split-brain te minimaliseren.

Dit artikel beschrijft de volgorde voor het implementeren van GlusterFS op basis van een Replica 3-oefening, waarbij alle gegevens over drie servers worden gerepliceerd. Alle opdrachten en configuratievoorbeelden zijn in codeblokken geplaatst, en voor elke stap zijn controleopdrachten en stopcondities toegevoegd. Controleer in productieomgevingen altijd eerst de apparaatnamen, netwerkbereiken en de ondersteuningsomvang van de pakketleverancier voordat u de onderstaande voorbeelden kopieert.

Huidige versie en ondersteuningsbereik om te controleren vóór GlusterFS-implementatie

De nieuwste community-release die in de officiële downloadmap wordt vermeld, is 11.1. Aangezien het officiële releasebeleid echter aangeeft dat de onderhoudsperiode voor een hoofdversie ongeveer 12 maanden bedraagt, kan 11.1 niet zomaar worden aanbevolen voor nieuwe besturingssystemen in 2026. Controleer of uw distributie of commerciële leverancier beveiligingsupdates biedt; als er geen ondersteuningstraject is, moeten alternatieven zoals Ceph, NFS HA of cloud-gebaseerde bestandsservices ook worden geëvalueerd. De opdrachten in dit artikel zijn bedoeld als oefening, uitgaande van een reeds voorbereide en gevalideerde EL9-repository.

Officiële documentatie: bekijk de tabel met community-pakketten, de GlusterFS 11.1 release notes en de Quick Start Guide.

Voorbeeldtopologie voor GlusterFS-implementatie

• Plaats de drie servers in verschillende foutdomeinen en controleer de tijdsynchronisatie en de voorwaartse en achterwaartse naamomzetting.
• Scheid het besturingssysteem en de brick-gegevens op aparte schijven of aparte logische volumes.
• Omdat Replica 3 drie volledige kopieën van de gegevens opslaat, is ongeveer drie keer de capaciteit van de originele gegevens vereist.
• Replicatie verspreidt ook verwijderingen, versleuteling en toepassingsfouten, dus een aparte back-up is absoluut noodzakelijk.

Controleer de naamomzetting en tijdsynchronisatie op alle knooppunten.

getent hosts gluster01 gluster02 gluster03
chronyc tracking
timedatectl status

Voorbeeld van host-mapping

10.20.30.11  gluster01
10.20.30.12  gluster02
10.20.30.13  gluster03

GlusterFS-opbouw stap 1: Voorbereiden van de speciale brick-schijf

De volgende stap kan bestaande gegevens op het apparaat wissen. Controleer eerst op elke server de werkelijke apparaatnaam en of deze is aangekoppeld, en zorg voor back-ups en goedkeuring voor de wijziging. De apparaatnaam in het voorbeeld is /dev/sdb; pas dit aan aan uw omgeving.

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

Het onderstaande mkfs-commando vernietigt het bestaande bestandssysteem op het doelapparaat. Voer dit niet uit voordat de resultaten van lsblk, findmnt en wipefs –no-act handmatig zijn gecontroleerd.

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

Gebruik de UUID die is gevonden met blkid om de volgende vermelding toe te voegen aan /etc/fstab op elke server.

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

GlusterFS-opbouw stap 2: Controle van pakketten en de glusterd-service

Controleer in de EL9-familie eerst of de repository het glusterfs-server-pakket daadwerkelijk aanbiedt. Als het pakket ontbreekt of als de bron of handtekening onduidelijk is, download dan geen willekeurige oude RPM’s en stop hier.

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

GlusterFS-opbouw stap 3: Beperk de firewall tot het opslagnetwerk

Vanaf Gluster 10 worden brick-poorten willekeurig gekozen binnen het ingestelde bereik van base-port en max-port. Sta het beheerpoortbereik 24007-24008 en het werkelijke brick-poortbereik alleen toe voor het opslag-subnet. Het onderstaande bereik is een voorbeeld; pas dit aan tijdens een onderhoudsvenster nadat het aantal bricks en de glusterd-instellingen zijn afgestemd.

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

Omzeil problemen niet door SELinux of firewalld uit te schakelen. Als u vermoedt dat beleid blokkeert, controleer dan de audit-logs en het SELinux-beleid dat door het installatiepakket wordt geleverd, en beperk het toegestane bereik tot het Gluster-knooppunt en het clientnetwerk.

Voor nieuwe testsystemen die het bovenstaande firewallvoorbeeld gebruiken, stelt u option base-port 49152 en option max-port 49200 in binnen het bestaande volume management-blok in /etc/glusterfs/glusterd.vol op elk knooppunt en start u glusterd opnieuw. Voeg niet dubbel dezelfde opties toe aan het bestand. Controleer bij operationele volumes de werkelijke poorten en het aantal gebruikte bricks om het bestaande bereik eerst toe te staan, en verklein het poortbereik niet zonder onderhoudsprocedure.

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

GlusterFS-opbouw stap 4: Configuratie van de trusted storage pool

Voer een probe uit vanaf gluster01 naar de overige twee servers en voer ook eenmaal een probe uit vanaf gluster02 naar gluster01 zodat de hostnamen consistent worden geregistreerd. Maak geen volumes aan voordat alle peers de status Connected hebben.

# Uitvoeren op gluster01
sudo gluster peer probe gluster02
sudo gluster peer probe gluster03
sudo gluster peer status
sudo gluster pool list

# Uitvoeren op gluster02
sudo gluster peer probe gluster01
sudo gluster peer status

GlusterFS-opbouw stap 5: Aanmaken en verifiëren van het Replica 3-volume

Replica 3 repliceert bestanden naar drie bricks. Een eenvoudig distributed volume vergroot wel de capaciteit, maar heeft geen replica’s, waardoor een defect aan één brick kan leiden tot het verlies van dat bestand. Als u hoge beschikbaarheid beoogt, controleer dan altijd het Type en de brick-array in de uitvoer van volume create.

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

Controleer na het starten van het volume of alle drie de bricks Online zijn. De optie force kan waarschuwingen over onjuiste paden en topologie negeren; gebruik deze niet als u de oorzaak niet begrijpt.

6. Client-mount en verificatie na herstart

Installeer glusterfs-fuse op de client. Specificeer de andere twee servers als backup-volfile-servers voor het geval de eerste volfile-server niet reageert, maar houd er rekening mee dat deze optie de datareplicatie zelf niet vervangt.

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

Als automatisch aankoppelen na een herstart vereist is, voeg dan de volgende vermelding toe aan /etc/fstab op de client.

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. Testen van schrijven, replicatie en herstel bij defecten

Controleer het basis-schrijven en de replicatie met een apart testbestand voordat u operationele gegevens plaatst. Als een toepassing het brick-pad direct leest of schrijft, omzeilt dit de Gluster-metadata; clients moeten daarom altijd het Gluster-aankoppelpunt gebruiken.

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

Voer geplande tests bij defecten uit tijdens een onderhoudsvenster waarbij back-up- en herstelplannen zijn gecontroleerd. Voeg testbestanden toe terwijl één knooppunt is geïsoleerd en controleer of het aantal wachtende heal-items naar 0 convergeert nadat het knooppunt is teruggekeerd. Sta schrijven niet geforceerd toe in een toestand met verlies van quorum en schrijf niet tegelijkertijd naar meerdere gesplitste segmenten.

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. Veilig omgaan met heal en split-brain

Wachtende heal-items zijn onderworpen aan automatisch herstel, maar split-brain is een toestand waarin Gluster niet kan bepalen welke kopie als de bron van waarheid moet worden gekozen. Het blindelings kiezen van de nieuwste wijzigingstijd of het grootste bestand kan leiden tot het overschrijven van correcte gegevens. Stop eerst het schrijven door toepassingen, maak back-ups en vergelijk de betekenis van de bestanden en de checksums.

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/<문제-파일>

Herstel het bestand pas via de source-brick-methode nadat de bron-brick is bevestigd door mensen en de verantwoordelijken voor de toepassing. Vervang de host-, brick- en bestandspaden in het onderstaande commando door de werkelijke resultaten van uw controle.

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

Het beleid latest-mtime of bigger-file is handig, maar garandeert de betekenis van de gegevens niet. Voor bestanden waarvoor applicatieconsistentie vereist is, zoals databasebestanden of images van virtuele machines, moet de service worden gestopt en moeten de herstelprocedures van het betreffende product als eerste worden toegepast.

9. Foutdiagnose door logs en status samen te bekijken

Voordat u de server opnieuw opstart alleen op basis van een mount-fout, verzamelt u op hetzelfde moment de peer-, volume-, brick-poort-, heal-, capaciteits-, inode- en loggegevens. Vooral als /var/lib/glusterd vol raakt, kan de beheer-daemon abnormaal gaan functioneren.

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

Als het heal-commando zelf mislukt, controleer dan de glfsheal-logs en de bijbehorende brick-logs. Omdat logpaden en procespoorten kunnen variëren afhankelijk van de versie en de verpakking, dient u deze te vergelijken met de resultaten van volume status.

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. Operationele checklist

1. Documenteer de ondersteuningsperiode voor beveiliging van de pakketleverancier en de upgradepaden.
2. Plaats de drie servers in onafhankelijke storingsdomeinen voor stroom, rack en netwerk.
3. Sta beheerpoorten en brick-poorten alleen toe voor de benodigde bronnetwerken en behoud SELinux.
4. Monitor continu peer, brick, heal, split-brain, capaciteit, inode en latentie.
5. Maak aparte back-ups voor verwijderingen en ransomware, en voer regelmatig hersteltests uit.
6. Oefen procedures voor het vervangen van nodes, het upgraden van pakketten en het selecteren van de juiste versie bij split-brain voordat u wijzigingen doorvoert.

Minimale items die dagelijks of via een monitoringsysteem moeten worden verzameld

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

Gerelateerde artikelen

• GlusterFS vs DRBD: Keuzegids voor replicatie-eenheid, consistentie en HA
• Diagnosegids voor ‘No space left on device’ in Linux

Conclusie

Een veilige GlusterFS-implementatie. De kern ligt niet in het aantal commando’s, maar in het vooraf ontwerpen van faalcondities. U moet een topologie creëren met Replica 3 die besluitvorming op basis van een meerderheid mogelijk maakt, en opereren met een workflow die toegewijde bricks, beperkte firewalls, consistente naamresolutie, statusverificatie en heal-observatie omvat. Pas wanneer hier onafhankelijke back-ups, hersteltests en ondersteunde pakketpaden aan worden toegevoegd, ontstaat er een operationele bestandsservice.