Glusterfs

Aus xinux.net
Zur Navigation springen Zur Suche springen

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 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