Glusterfs: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
Zeile 44: Zeile 44:
 
  gluster volume start testvol
 
  gluster volume start testvol
  
*It is possible that the above command tells you that the action was not successful:
+
*es ist möglich dass das starten nicht erfolgreich ist
  
 
  root@server1:~# gluster volume start testvol
 
  root@server1:~# gluster volume start testvol
Zeile 50: Zeile 50:
 
  root@server1:~#
 
  root@server1:~#
  
In this case you should check the output of...
+
Wenn dies der Fall ist...:
  
 
  server1.example.com/server2.example.com:
 
  server1.example.com/server2.example.com:
Zeile 56: Zeile 56:
 
  netstat -tap | grep glusterfsd
 
  netstat -tap | grep glusterfsd
  
on both servers.
+
auf beiden Servern.
  
If you get output like this...
+
Wenn es so einen Output gibt...
  
 
  root@server1:~# netstat -tap | grep glusterfsd
 
  root@server1:~# netstat -tap | grep glusterfsd
Zeile 65: Zeile 65:
 
  root@server1:~#
 
  root@server1:~#
  
... everything is fine, but if you don't get any output...
+
... ist alles in ordnung, wenn nicht...
  
 
  root@server2:~# netstat -tap | grep glusterfsd
 
  root@server2:~# netstat -tap | grep glusterfsd
 
  root@server2:~#
 
  root@server2:~#
  
... restart the GlusterFS daemon on the corresponding server (server2.example.com in this case):
+
... starte glusterfs auf dem server neu (server2.example.com in diesem fall):
  
 
server2.example.com:
 
server2.example.com:
Zeile 76: Zeile 76:
 
  /etc/init.d/glusterfs-server restart
 
  /etc/init.d/glusterfs-server restart
  
Then check the output of...
+
danach wieder Output checken...
  
 
  netstat -tap | grep glusterfsd
 
  netstat -tap | grep glusterfsd
 
... again on that server - it should now look like this:
 
  
 
  root@server2:~# netstat -tap | grep glusterfsd
 
  root@server2:~# netstat -tap | grep glusterfsd
Zeile 87: Zeile 85:
 
  root@server2:~#
 
  root@server2:~#
  
Now back to server1.example.com:
+
wieder zurück zu server1.example.com:
  
server1.example.com:
 
  
You can check the status of the volume with the command
+
Man kann den Status von dem Volume mit diesem Befehl checken:
  
 
  gluster volume info
 
  gluster volume info
Zeile 107: Zeile 104:
 
  root@server1:~#
 
  root@server1:~#
  
By default, all clients can connect to the volume. If you want to grant access to client1.example.com (= 192.168.0.102) only, run:
+
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
 
  gluster volume set testvol auth.allow 192.168.0.102
  
Please note that it is possible to use wildcards for the IP addresses (like 192.168.*) and that you can specify multiple IP addresses separated by comma (e.g. 192.168.0.102,192.168.0.103).
+
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).
  
The volume info should now show the updated status:
+
Den Status checken...:
  
 
  gluster volume info
 
  gluster volume info
Zeile 130: Zeile 127:
 
  auth.allow: 192.168.0.102
 
  auth.allow: 192.168.0.102
 
  root@server1:~#
 
  root@server1:~#
 
  
 
=installieren glusterfs client=
 
=installieren glusterfs client=

Aktuelle Version vom 29. Oktober 2012, 07:47 Uhr

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