Glusterfs: Unterschied zwischen den Versionen
(Die Seite wurde neu angelegt: „orig. Link: http://www.howtoforge.com/high-availability-storage-with-glusterfs-3.2.x-on-ubuntu-11.10-automatic-file-replication-across-two-storage-servers-p2 =in…“) |
|||
(4 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
orig. Link: http://www.howtoforge.com/high-availability-storage-with-glusterfs-3.2.x-on-ubuntu-11.10-automatic-file-replication-across-two-storage-servers-p2 | orig. Link: http://www.howtoforge.com/high-availability-storage-with-glusterfs-3.2.x-on-ubuntu-11.10-automatic-file-replication-across-two-storage-servers-p2 | ||
− | =installieren glusterfs= | + | |
+ | =installieren glusterfs server= | ||
+ | |||
+ | server1.example.com/server2.example.com: | ||
+ | |||
+ | apt-get install glusterfs-server | ||
+ | |||
+ | glusterfsd --version (zeigt die aktuelle version an) | ||
+ | |||
+ | |||
+ | If you use a firewall, ensure that TCP ports 111, 24007, 24008, 24009-(24009 + number of bricks across all volumes) are open on server1.example.com and server2.example.com. | ||
+ | |||
+ | Als Nächstes wird server2.example.com als vertrauenswürdiger Speicher-Pool angegeben (alle GlusterFS Konfigurationsbefehle gehen von server1.example.com aus | ||
+ | server1.example.com: | ||
+ | |||
+ | ====server1.example.com==== | ||
+ | |||
+ | gluster peer probe server2.example.com | ||
+ | |||
+ | Probe successful (müsste output sein) | ||
+ | |||
+ | *Der Status von den/dem vertrauenswürdigen/em Speicher-Pool müsste so aussehen: | ||
+ | gluster peer status | ||
+ | |||
+ | root@server1:~# gluster peer status | ||
+ | Number of Peers: 1 | ||
+ | Hostname: server2.example.com | ||
+ | Uuid: 7cd93007-fccb-4fcb-8063-133e6ba81cd9 | ||
+ | State: Peer in Cluster (Connected) | ||
+ | root@server1:~# | ||
+ | |||
+ | Als nächstes wird ein testvol mit zwei Kopien erstellt (bitte beachten Sie, dass die Anzahl der Repliken gleich der Anzahl der Server in diesem Fall ist / auf server1.example.com und server2.example.com in das Verzeichnis / data (dies wird erstellt, wenn es nicht vorhanden ist): | ||
+ | |||
+ | gluster volume create testvol replica 2 transport tcp server1.example.com:/data server2.example.com:/data | ||
+ | |||
+ | root@server1:~# gluster volume create testvol replica 2 transport tcp server1.example.com:/data server2.example.com:/data | ||
+ | Creation of volume testvol has been successful. Please start the volume to access data. | ||
+ | root@server1:~# | ||
+ | |||
+ | ====Start the volume:==== | ||
+ | |||
+ | gluster volume start testvol | ||
+ | |||
+ | *es ist möglich dass das starten nicht erfolgreich ist | ||
+ | |||
+ | root@server1:~# gluster volume start testvol | ||
+ | Starting volume testvol has been unsuccessful | ||
+ | root@server1:~# | ||
+ | |||
+ | Wenn dies der Fall ist...: | ||
+ | |||
+ | server1.example.com/server2.example.com: | ||
+ | |||
+ | netstat -tap | grep glusterfsd | ||
+ | |||
+ | auf beiden Servern. | ||
+ | |||
+ | Wenn es so einen Output gibt... | ||
+ | |||
+ | root@server1:~# netstat -tap | grep glusterfsd | ||
+ | tcp 0 0 *:24009 *:* LISTEN 1548/glusterfsd | ||
+ | tcp 0 0 localhost.localdom:1019 localhost.localdo:24007 ESTABLISHED 1548/glusterfsd | ||
+ | root@server1:~# | ||
+ | |||
+ | ... ist alles in ordnung, wenn nicht... | ||
+ | |||
+ | root@server2:~# netstat -tap | grep glusterfsd | ||
+ | root@server2:~# | ||
+ | |||
+ | ... starte glusterfs auf dem server neu (server2.example.com in diesem fall): | ||
+ | |||
+ | server2.example.com: | ||
+ | |||
+ | /etc/init.d/glusterfs-server restart | ||
+ | |||
+ | danach wieder Output checken... | ||
+ | |||
+ | netstat -tap | grep glusterfsd | ||
+ | |||
+ | root@server2:~# netstat -tap | grep glusterfsd | ||
+ | tcp 0 0 *:24010 *:* LISTEN 1458/glusterfsd | ||
+ | tcp 0 0 localhost.localdom:1021 localhost.localdo:24007 ESTABLISHED 1458/glusterfsd | ||
+ | root@server2:~# | ||
+ | |||
+ | wieder zurück zu server1.example.com: | ||
+ | |||
+ | |||
+ | Man kann den Status von dem Volume mit diesem Befehl checken: | ||
+ | |||
+ | gluster volume info | ||
+ | |||
+ | root@server1:~# gluster volume info | ||
+ | |||
+ | Volume Name: testvol | ||
+ | Type: Replicate | ||
+ | Status: Started | ||
+ | Number of Bricks: 2 | ||
+ | Transport-type: tcp | ||
+ | Bricks: | ||
+ | Brick1: server1.example.com:/data | ||
+ | Brick2: server2.example.com:/data | ||
+ | root@server1:~# | ||
+ | |||
+ | Standardmäßig können alle Clients mit dem Volumen verbinden. Wenn Sie den Zugriff auf client1.example.com (= 192.168.0.102) gewähren möchten ... ausführen: | ||
+ | |||
+ | gluster volume set testvol auth.allow 192.168.0.102 | ||
+ | |||
+ | Bitte beachten Sie, dass es möglich ist, Platzhalter für die IP-Adressen zu verwenden (wie zb.: 192.168. *) Und dass Sie mehrere IP-Adressen durch Kommas trennen können (zB 192.168.0.102,192.168.0.103). | ||
+ | |||
+ | Den Status checken...: | ||
+ | |||
+ | gluster volume info | ||
+ | |||
+ | root@server1:~# gluster volume info | ||
+ | |||
+ | Volume Name: testvol | ||
+ | Type: Replicate | ||
+ | Status: Started | ||
+ | Number of Bricks: 2 | ||
+ | Transport-type: tcp | ||
+ | Bricks: | ||
+ | Brick1: server1.example.com:/data | ||
+ | Brick2: server2.example.com:/data | ||
+ | Options Reconfigured: | ||
+ | auth.allow: 192.168.0.102 | ||
+ | root@server1:~# | ||
+ | |||
+ | =installieren glusterfs client= | ||
apt-get install glusterfs-client | apt-get install glusterfs-client | ||
Zeile 76: | Zeile 203: | ||
====server1.example.com:==== | ====server1.example.com:==== | ||
* As you see, server1.example.com hasn't noticed the changes that happened while it was down. | * As you see, server1.example.com hasn't noticed the changes that happened while it was down. | ||
− | * This is easy to fix, all we need to do is invoke a read command, | + | * This is easy to fix, all we need to do is invoke a read command, on the GlusterFS share on client1.example.com,: |
− | |||
ls -l /data | ls -l /data | ||
Aktuelle Version vom 29. Oktober 2012, 07:47 Uhr
installieren glusterfs server
server1.example.com/server2.example.com:
apt-get install glusterfs-server
glusterfsd --version (zeigt die aktuelle version an)
If you use a firewall, ensure that TCP ports 111, 24007, 24008, 24009-(24009 + number of bricks across all volumes) are open on server1.example.com and server2.example.com.
Als Nächstes wird server2.example.com als vertrauenswürdiger Speicher-Pool angegeben (alle GlusterFS Konfigurationsbefehle gehen von server1.example.com aus server1.example.com:
server1.example.com
gluster peer probe server2.example.com
Probe successful (müsste output sein)
- Der Status von den/dem vertrauenswürdigen/em Speicher-Pool müsste so aussehen:
gluster peer status
root@server1:~# gluster peer status Number of Peers: 1 Hostname: server2.example.com Uuid: 7cd93007-fccb-4fcb-8063-133e6ba81cd9 State: Peer in Cluster (Connected) root@server1:~#
Als nächstes wird ein testvol mit zwei Kopien erstellt (bitte beachten Sie, dass die Anzahl der Repliken gleich der Anzahl der Server in diesem Fall ist / auf server1.example.com und server2.example.com in das Verzeichnis / data (dies wird erstellt, wenn es nicht vorhanden ist):
gluster volume create testvol replica 2 transport tcp server1.example.com:/data server2.example.com:/data
root@server1:~# gluster volume create testvol replica 2 transport tcp server1.example.com:/data server2.example.com:/data Creation of volume testvol has been successful. Please start the volume to access data. root@server1:~#
Start the volume:
gluster volume start testvol
- es ist möglich dass das starten nicht erfolgreich ist
root@server1:~# gluster volume start testvol Starting volume testvol has been unsuccessful root@server1:~#
Wenn dies der Fall ist...:
server1.example.com/server2.example.com:
netstat -tap | grep glusterfsd
auf beiden Servern.
Wenn es so einen Output gibt...
root@server1:~# netstat -tap | grep glusterfsd tcp 0 0 *:24009 *:* LISTEN 1548/glusterfsd tcp 0 0 localhost.localdom:1019 localhost.localdo:24007 ESTABLISHED 1548/glusterfsd root@server1:~#
... ist alles in ordnung, wenn nicht...
root@server2:~# netstat -tap | grep glusterfsd root@server2:~#
... starte glusterfs auf dem server neu (server2.example.com in diesem fall):
server2.example.com:
/etc/init.d/glusterfs-server restart
danach wieder Output checken...
netstat -tap | grep glusterfsd
root@server2:~# netstat -tap | grep glusterfsd tcp 0 0 *:24010 *:* LISTEN 1458/glusterfsd tcp 0 0 localhost.localdom:1021 localhost.localdo:24007 ESTABLISHED 1458/glusterfsd root@server2:~#
wieder zurück zu server1.example.com:
Man kann den Status von dem Volume mit diesem Befehl checken:
gluster volume info
root@server1:~# gluster volume info
Volume Name: testvol Type: Replicate Status: Started Number of Bricks: 2 Transport-type: tcp Bricks: Brick1: server1.example.com:/data Brick2: server2.example.com:/data root@server1:~#
Standardmäßig können alle Clients mit dem Volumen verbinden. Wenn Sie den Zugriff auf client1.example.com (= 192.168.0.102) gewähren möchten ... ausführen:
gluster volume set testvol auth.allow 192.168.0.102
Bitte beachten Sie, dass es möglich ist, Platzhalter für die IP-Adressen zu verwenden (wie zb.: 192.168. *) Und dass Sie mehrere IP-Adressen durch Kommas trennen können (zB 192.168.0.102,192.168.0.103).
Den Status checken...:
gluster volume info
root@server1:~# gluster volume info
Volume Name: testvol Type: Replicate Status: Started Number of Bricks: 2 Transport-type: tcp Bricks: Brick1: server1.example.com:/data Brick2: server2.example.com:/data Options Reconfigured: auth.allow: 192.168.0.102 root@server1:~#
installieren glusterfs client
apt-get install glusterfs-client mkdir /mnt/glusterfs mount -t glusterfs server1.example.com:/testvol /mnt/glusterfs mount
- output sollte so aussehen:
root@client1:~# mount /dev/mapper/server3-root on / type ext4 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) fusectl on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) udev on /dev type devtmpfs (rw,mode=0755) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755) none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880) none on /run/shm type tmpfs (rw,nosuid,nodev) /dev/sda1 on /boot type ext2 (rw) server1.example.com:/testvol on /mnt/glusterfs type fuse.glusterfs (rw,allow_other,default_permissions,max_read=131072) root@client1:~#
df -h
root@client1:~# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/server3-root 29G 1.1G 27G 4% / udev 238M 4.0K 238M 1% /dev tmpfs 99M 212K 99M 1% /run none 5.0M 0 5.0M 0% /run/lock none 247M 0 247M 0% /run/shm /dev/sda1 228M 24M 193M 11% /boot server1.example.com:/testvol 29G 1.1G 27G 4% /mnt/glusterfs root@client1:~#
- Instead of mounting the GlusterFS share manually on the client, you could modify /etc/fstab,
- so that the share gets mounted automatically when the client boots.
- Open /etc/fstab and append the ollowing line:
vi /etc/fstab
- das kommt rein:
server1.example.com:/testvol /mnt/glusterfs glusterfs defaults,_netdev 0 0
reboot df -h mount
some testfiles
touch /mnt/glusterfs/test1 touch /mnt/glusterfs/test2
ls -l /data
server1.example.com:
- Now we shut down server1.example.com and add/delete some files on the GlusterFS share on client1.example.com.
shutdown -h now
client1.example.com:
touch /mnt/glusterfs/test3 touch /mnt/glusterfs/test4 rm -f /mnt/glusterfs/test2
server2.example.com:
- The changes should be visible in the /data directory on server2.example.com
ls -l /data
server1.example.com:
- As you see, server1.example.com hasn't noticed the changes that happened while it was down.
- This is easy to fix, all we need to do is invoke a read command, on the GlusterFS share on client1.example.com,:
ls -l /data
client1.example.com:
- Now take a look at the /data directory on server1.example.com again,
- and you should see that the changes have been replicated to that node:
ls -l /mnt/glusterfs/
server1.example.com:
- ls -l /data