Speicherlösungen · 9 min read · Nov 29, 2025

Hochverfügbarkeits-Speicher mit GlusterFS auf CentOS 7 - Spiegelung über zwei Speicher-Server

Dieses Tutorial zeigt, wie man einen hochverfügbaren Speicher mit zwei Speicher-Servern (CentOS 7.2) einrichtet, die GlusterFS verwenden. Jeder Speicher-Server wird ein Spiegel des anderen Speicher-Servers sein, und Dateien werden automatisch über beide Speicher-Server repliziert. Das Client-System (ebenfalls CentOS 7.2) wird in der Lage sein, auf den Speicher zuzugreifen, als wäre es ein lokales Dateisystem. GlusterFS ist ein clusterfähiges Dateisystem, das auf mehrere Petabyte skalierbar ist. Es aggregiert verschiedene Speicherbausteine über Infiniband RDMA oder TCP/IP-Verbindungen zu einem großen parallelen Netzwerkdateisystem. Speicherbausteine können aus beliebiger handelsüblicher Hardware wie x86_64-Servern mit SATA-II-RAID und Infiniband HBA bestehen.

1 Vorbemerkung

In diesem Tutorial verwende ich drei Systeme, zwei Server und einen Client:

  • server1.example.com: IP-Adresse 192.168.0.100 (Server)
  • server2.example.com: IP-Adresse 192.168.0.101 (Server)
  • client1.example.com: IP-Adresse 192.168.0.102 (Client)

Alle drei Systeme sollten in der Lage sein, die Hostnamen der anderen Systeme aufzulösen. Wenn dies nicht über DNS möglich ist, sollten Sie die Datei /etc/hosts bearbeiten, sodass sie auf allen drei Systemen wie folgt aussieht:

nano /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
192.168.0.100   server1.example.com     server1
192.168.0.101   server2.example.com     server2
192.168.0.102   client1.example.com     client1

::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

(Es ist auch möglich, IP-Adressen anstelle von Hostnamen in der folgenden Einrichtung zu verwenden. Wenn Sie IP-Adressen verwenden möchten, müssen Sie sich keine Gedanken darüber machen, ob die Hostnamen aufgelöst werden können oder nicht.)

2 Zusätzliche Repositories aktivieren

server1.example.com/server2.example.com/client1.example.com:

Zuerst importieren wir die GPG-Schlüssel für Softwarepakete:

rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY*

Dann aktivieren wir das EPEL 7-Repository auf unseren CentOS-Systemen:

yum -y install epel-release
yum -y install yum-priorities

Bearbeiten Sie /etc/yum.repos.d/epel.repo…

nano /etc/yum.repos.d/epel.repo

… und fügen Sie die Zeile priority=10 zum Abschnitt [epel] hinzu:

[epel]
name=Extra Packages for Enterprise Linux 7 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch
failovermethod=priority
enabled=1
priority=10
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
[...]

Dann aktualisieren wir unsere vorhandenen Pakete auf dem System:

yum -y update

3 Einrichten der GlusterFS-Server

server1.example.com/server2.example.com:

GlusterFS ist im Repository der CentOS Storage Special Interest Group verfügbar. Installieren Sie das Repository mit diesem Befehl:

yum -y install centos-release-gluster

Installieren Sie dann den GlusterFS-Server wie folgt:

yum -y install glusterfs-server

Erstellen Sie die Systemstartverknüpfungen für den Gluster-Daemon und starten Sie ihn:

systemctl enable glusterd.service  
systemctl start glusterd.service

Der Befehl

glusterfsd --version

sollte jetzt die GlusterFS-Version anzeigen, die Sie gerade installiert haben (in diesem Fall 3.7.12):

[root@server1 ~]# glusterfsd --version  
glusterfs 3.7.12 built on Jun 24 2016 14:11:19  
Repository revision: git://git.gluster.com/glusterfs.git  
Copyright (c) 2006-2013 Red Hat, Inc.   
GlusterFS kommt ohne jegliche Gewährleistung.  
Es wird Ihnen unter Ihrer Wahl der GNU Lesser  
General Public License, Version 3 oder einer späteren Version (LGPLv3  
oder später) oder der GNU General Public License, Version 2 (GPLv2),  
in allen Fällen, wie von der Free Software Foundation veröffentlicht, lizenziert.

Wenn Sie eine Firewall verwenden, stellen Sie sicher, dass die TCP-Ports 111, 24007, 24008, 24009-(24009 + Anzahl der Bausteine über alle Volumes) auf server1.example.com und server2.example.com geöffnet sind.

Als nächstes müssen wir server2.example.com zum vertrauenswürdigen Speicherpool hinzufügen (bitte beachten Sie, dass ich alle GlusterFS-Konfigurationsbefehle von server1.example.com ausführe, aber Sie können sie auch von server2.example.com ausführen, da die Konfiguration zwischen den GlusterFS-Knoten repliziert wird - stellen Sie nur sicher, dass Sie die richtigen Hostnamen oder IP-Adressen verwenden):

server1.example.com:

Führen Sie auf server1.example.com aus

gluster peer probe server2.example.com
[root@server1 ~]# gluster peer probe server2.example.com  
peer probe: success.

Der Status des vertrauenswürdigen Speicherpools sollte jetzt ähnlich wie folgt aussehen:

gluster peer status
[root@server1 ~]# gluster peer status
Number of Peers: 1
Hostname: server2.example.com  
Uuid: 582e10da-aa1b-40b8-908c-213f16f57fe5  
State: Peer in Cluster (Connected)

Als nächstes erstellen wir den Share mit dem Namen testvol mit zwei Replikaten (bitte beachten Sie, dass die Anzahl der Replikate in diesem Fall der Anzahl der Server entspricht, da wir eine Spiegelung einrichten möchten) auf server1.example.com und server2.example.com im Verzeichnis /data (dies wird erstellt, wenn es nicht existiert):

gluster volume create testvol replica 2 transport tcp server1.example.com:/data server2.example.com:/data force
[root@server1 ~]# gluster volume create testvol replica 2 transport tcp server1.example.com:/data server2.example.com:/data force  
volume create: testvol: success: please start the volume to access data  
[root@server1 ~]#

Starten Sie das Volume:

gluster volume start testvol

Das Ergebnis sollte sein:

[root@server1 ~]# gluster volume start testvol  
volume start: testvol: success  
[root@server1 ~]#

Es ist möglich, dass der obige Befehl Ihnen mitteilt, dass die Aktion nicht erfolgreich war:

[root@server1 ~]# gluster volume start testvol  
Starting volume testvol has been unsuccessful  
[root@server1 ~]#

In diesem Fall sollten Sie die Ausgabe von…

server1.example.com/server2.example.com:

netstat -tap | grep glusterfsd

auf beiden Servern überprüfen.

Wenn Sie eine Ausgabe wie diese erhalten…

[root@server1 ~]# netstat -tap | grep glusterfsd  
tcp 0 0 0.0.0.0:49152 0.0.0.0:* LISTEN 22880/glusterfsd  
tcp 0 0 server1.example.c:49152 server2.example.c:49148 ESTABLISHED 22880/glusterfsd  
tcp 0 0 server1.example.c:49152 server1.example.c:49148 ESTABLISHED 22880/glusterfsd  
tcp 0 0 server1.example.c:49150 server1.example.c:24007 ESTABLISHED 22880/glusterfsd  
tcp 0 0 server1.example.c:49152 server2.example.c:49142 ESTABLISHED 22880/glusterfsd  
tcp 0 0 server1.example.c:49152 server1.example.c:49149 ESTABLISHED 22880/glusterfsd  
[root@server1 ~]#

… ist alles in Ordnung, aber wenn Sie keine Ausgabe erhalten…

[root@server2 ~]# netstat -tap | grep glusterfsd  
[root@server2 ~]#

… starten Sie den GlusterFS-Daemon auf dem entsprechenden Server (server2.example.com in diesem Fall):

server2.example.com:

systemctl restart glusterd.service

Überprüfen Sie dann erneut die Ausgabe von…

netstat -tap | grep glusterfsd

… auf diesem Server - es sollte jetzt so aussehen:

[root@server2 ~]# netstat -tap | grep glusterfsd  
tcp 0 0 0.0.0.0:49152 0.0.0.0:* LISTEN 10971/glusterfsd  
tcp 0 0 server2.example.c:49152 server1.example.c:49140 ESTABLISHED 10971/glusterfsd  
tcp 0 0 server2.example.c:49152 server2.example.c:49149 ESTABLISHED 10971/glusterfsd  
tcp 0 0 server2.example.c:49152 server2.example.c:49143 ESTABLISHED 10971/glusterfsd  
tcp 0 0 server2.example.c:49152 server1.example.c:49142 ESTABLISHED 10971/glusterfsd  
tcp 0 0 server2.example.c:49150 server2.example.c:24007 ESTABLISHED 10971/glusterfsd  
[root@server2 ~]#

Jetzt zurück zu server1.example.com:

server1.example.com:

Sie können den Status des Volumes mit dem Befehl

gluster volume info

[root@server1 ~]# gluster volume info

Volume Name: testvol  
Type: Replicate  
Volume ID: e1f825ca-c9d9-4eeb-b6c5-d62c4aa02376  
Status: Started  
Number of Bricks: 1 x 2 = 2  
Transport-type: tcp  
Bricks:  
Brick1: server1.example.com:/data  
Brick2: server2.example.com:/data  
Options Reconfigured:  
performance.readdir-ahead: on  
[root@server1 ~]#

Standardmäßig können alle Clients eine Verbindung zum Volume herstellen. Wenn Sie nur client1.example.com (= 192.168.1.102) Zugriff gewähren möchten, führen Sie aus:

gluster volume set testvol auth.allow 192.168.1.102

Bitte beachten Sie, dass es möglich ist, Platzhalter für die IP-Adressen zu verwenden (wie 192.168.*) und dass Sie mehrere IP-Adressen durch Kommas getrennt angeben können (z. B. 192.168.1.102,192.168.1.103).

Die Volume-Info sollte jetzt den aktualisierten Status anzeigen:

gluster volume info
[root@server1 ~]# gluster volume info
Volume Name: testvol  
Type: Replicate  
Volume ID: e1f825ca-c9d9-4eeb-b6c5-d62c4aa02376  
Status: Started  
Number of Bricks: 1 x 2 = 2  
Transport-type: tcp  
Bricks:  
Brick1: server1.example.com:/data  
Brick2: server2.example.com:/data  
Options Reconfigured:  
auth.allow: 192.168.1.102  
performance.readdir-ahead: on  
[root@server1 ~]#

4 Einrichten des GlusterFS-Clients

client1.example.com:

Auf dem Client können wir den GlusterFS-Client wie folgt installieren:

yum -y install glusterfs-client

Dann erstellen wir das folgende Verzeichnis:

mkdir /mnt/glusterfs

Das war’s! Jetzt können wir das GlusterFS-Dateisystem mit dem folgenden Befehl in /mnt/glusterfs einhängen:

mount.glusterfs server1.example.com:/testvol /mnt/glusterfs

(Statt server1.example.com können Sie auch server2.example.com im obigen Befehl verwenden!)

Sie sollten jetzt den neuen Share in den Ausgaben von…

mount
[root@client1 ~]# mount  
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel)  
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)  
devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=930336k,nr_inodes=232584,mode=755)  
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)  
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel)  
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000)  
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)  
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,seclabel,mode=755)  
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)  
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)  
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)  
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)  
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)  
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)  
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)  
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)  
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)  
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)  
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)  
configfs on /sys/kernel/config type configfs (rw,relatime)  
/dev/mapper/centos-root on / type xfs (rw,relatime,seclabel,attr2,inode64,noquota)  
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)  
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=34,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)  
debugfs on /sys/kernel/debug type debugfs (rw,relatime)  
mqueue on /dev/mqueue type mqueue (rw,relatime,seclabel)  
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,seclabel)  
/dev/sda1 on /boot type xfs (rw,relatime,seclabel,attr2,inode64,noquota)  
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=188060k,mode=700)  
server1.example.com:/testvol on /mnt/glusterfs type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072)  
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)  
[root@client1 ~]#

… und…

df -h
[root@client1 ~]# df -h  
Filesystem Size Used Avail Use% Mounted on  
/dev/mapper/centos-root 28G 1.3G 27G 5% /  
devtmpfs 909M 0 909M 0% /dev  
tmpfs 919M 0 919M 0% /dev/shm  
tmpfs 919M 8.6M 910M 1% /run  
tmpfs 919M 0 919M 0% /sys/fs/cgroup  
/dev/sda1 497M 192M 306M 39% /boot  
tmpfs 184M 0 184M 0% /run/user/0  
server1.example.com:/testvol 28G 12G 17G 41% /mnt/glusterfs  
[root@client1 ~]#

Anstatt das GlusterFS-Share manuell auf dem Client zu mounten, fügen Sie den Mount-Befehl zur Datei /etc/rc.local hinzu. Ich werde es nicht zu /etc/fstab hinzufügen, da rc.local immer nach dem Hochfahren des Netzwerks ausgeführt wird, was für ein Netzwerkdateisystem erforderlich ist.

Öffnen Sie /etc/rc.local und fügen Sie die folgende Zeile hinzu:

nano /etc/rc.local
[...]  
/usr/sbin/mount.glusterfs server1.example.com:/testvol /mnt/glusterfs

(Nochmals, anstelle von server1.example.com können Sie auch server2.example.com verwenden!)

Um zu testen, ob Ihre modifizierte /etc/rc.local funktioniert, starten Sie den Client neu:

reboot

Nach dem Neustart sollten Sie den Share in den Ausgaben von…

df -h

… und…

mount

5 Testen

Jetzt lassen Sie uns einige Testdateien auf dem GlusterFS-Share erstellen:

client1.example.com:

touch /mnt/glusterfs/test1  
touch /mnt/glusterfs/test2

Jetzt überprüfen wir das Verzeichnis /data auf server1.example.com und server2.example.com. Die Dateien test1 und test2 sollten auf jedem Knoten vorhanden sein:

server1.example.com/server2.example.com:

ls -l /data
[root@server1 ~]# ls -l /data  
total 0  
-rw-r--r--. 2 root root 0 Jul 1 2016 test1  
-rw-r--r--. 2 root root 0 Jul 1 2016 test2  
[root@server1 ~]

Jetzt fahren wir server1.example.com herunter und fügen/löschen einige Dateien auf dem GlusterFS-Share auf client1.example.com.

server1.example.com:

shutdown -h now

client1.example.com:

touch /mnt/glusterfs/test3  
touch /mnt/glusterfs/test4  
rm -f /mnt/glusterfs/test2

Die Befehle können einige Zeit in Anspruch nehmen, da GlusterFS zu server2 wechselt, nachdem er server1 nicht mehr erreichen kann. Wir können hier die Fehlertoleranz des Systems sehen, da wir weiterhin an unserem Datenspeicher-Share arbeiten können, wenn server1 offline ist. Die Änderungen sollten im Verzeichnis /data auf server2.example.com sichtbar sein:

server2.example.com:

ls -l /data
[root@server2 ~]# ls -l /data  
total 8  
-rw-r--r--. 2 root root 0 Jul 1 15:17 test1  
-rw-r--r--. 2 root root 0 Jul 1 15:19 test3  
-rw-r--r--. 2 root root 0 Jul 1 15:19 test4

Lassen Sie uns server1.example.com wieder hochfahren und einen Blick auf das Verzeichnis /data werfen:

server1.example.com:

ls -l /data
[root@server1 ~]# ls -l /data  
total 8  
-rw-r--r--. 2 root root 0 Jul 1 15:17 test1  
-rw-r--r--. 2 root root 0 Jul 1 15:19 test2  
[root@server1 ~]#

Wie Sie sehen, hat server1.example.com automatisch die Änderungen synchronisiert. Falls die Änderung noch nicht synchronisiert wurde, ist das leicht zu beheben, alles, was wir tun müssen, ist, einen Lese-Befehl auf dem GlusterFS-Share auf client1.example.com auszuführen, z. B.:

client1.example.com:

ls -l /mnt/glusterfs/
[root@client1 ~]# ls -l /data  
total 8  
-rw-r--r--. 2 root root 0 Jul 1 15:17 test1  
-rw-r--r--. 2 root root 0 Jul 1 15:19 test3  
-rw-r--r--. 2 root root 0 Jul 1 15:19 test4  
[root@server1 ~]#

Jetzt werfen Sie einen Blick auf das Verzeichnis /data auf server1.example.com erneut, und Sie sollten sehen, dass die Änderungen auf diesem Knoten repliziert wurden:

server1.example.com:

ls -l /data
[root@server1 ~]# ls -l /data  
total 8  
-rw-r--r--. 2 root root 0 Jul 1 15:17 test1  
-rw-r--r--. 2 root root 0 Jul 1 15:19 test3  
-rw-r--r--. 2 root root 0 Jul 1 15:19 test4  
[root@server1 ~]#

6 Links

Share: X/Twitter LinkedIn
#Speicherlösungen

Erhalte neue Beiträge in deinem Posteingang.

Kein Spam. Jederzeit abmelden.