Distributed Replicated Storage Across Four Storage Nodes With GlusterFS On Ubuntu 9.10 - Page 2
This tutorial exists for these OS versions
- Ubuntu 12.10 (Quantal Quetzal)
- Ubuntu 12.04 LTS (Precise Pangolin)
- Ubuntu 11.10 (Oneiric Ocelot)
- Ubuntu 9.10 (Karmic Koala)
On this page
3 Setting Up The GlusterFS Client
client1.example.com:
On the client, we can install the GlusterFS client as follows:
aptitude install glusterfs-client glusterfs-server
Then we create the following directory:
mkdir /mnt/glusterfs
Next we create the file /etc/glusterfs/glusterfs.vol (we make a backup of the original /etc/glusterfs/glusterfs.vol file first):
cp /etc/glusterfs/glusterfs.vol /etc/glusterfs/glusterfs.vol_orig
cat /dev/null > /etc/glusterfs/glusterfs.vol
vi /etc/glusterfs/glusterfs.vol
volume remote1 type protocol/client option transport-type tcp option remote-host server1.example.com option remote-subvolume brick end-volume volume remote2 type protocol/client option transport-type tcp option remote-host server2.example.com option remote-subvolume brick end-volume volume remote3 type protocol/client option transport-type tcp option remote-host server3.example.com option remote-subvolume brick end-volume volume remote4 type protocol/client option transport-type tcp option remote-host server4.example.com option remote-subvolume brick end-volume volume replicate1 type cluster/replicate subvolumes remote1 remote2 end-volume volume replicate2 type cluster/replicate subvolumes remote3 remote4 end-volume volume distribute type cluster/distribute subvolumes replicate1 replicate2 end-volume volume writebehind type performance/write-behind option window-size 1MB subvolumes distribute end-volume volume cache type performance/io-cache option cache-size 512MB subvolumes writebehind end-volume |
Make sure you use the correct server hostnames or IP addresses in the option remote-host lines!
That's it! Now we can mount the GlusterFS filesystem to /mnt/glusterfs with one of the following two commands:
glusterfs -f /etc/glusterfs/glusterfs.vol /mnt/glusterfs
or
mount -t glusterfs /etc/glusterfs/glusterfs.vol /mnt/glusterfs
You should now see the new share in the outputs of...
mount
root@client1:~# mount
/dev/mapper/client1-root on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
none 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 tmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
/dev/sda5 on /boot type ext2 (rw)
/etc/glusterfs/glusterfs.vol on /mnt/glusterfs type fuse.glusterfs (rw,max_read=131072,allow_other,default_permissions)
root@client1:~#
... and...
df -h
root@client1:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/client1-root
29G 808M 27G 3% /
udev 122M 152K 121M 1% /dev
none 122M 0 122M 0% /dev/shm
none 122M 36K 122M 1% /var/run
none 122M 0 122M 0% /var/lock
none 122M 0 122M 0% /lib/init/rw
/dev/sda5 228M 15M 202M 7% /boot
/etc/glusterfs/glusterfs.vol
47G 1.6G 43G 4% /mnt/glusterfs
root@client1:~#
(The size of the distributed storage is calculated by replication1 + replication2, where both replication volumes are as big as the smallest brick.)
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 following line:
vi /etc/fstab
[...] /etc/glusterfs/glusterfs.vol /mnt/glusterfs glusterfs defaults 0 0 |
To test if your modified /etc/fstab is working, reboot the client:
reboot
After the reboot, you should find the share in the outputs of...
df -h
... and...
mount
4 Testing
Now let's create some test files on the GlusterFS share:
client1.example.com:
touch /mnt/glusterfs/test1
touch /mnt/glusterfs/test2
touch /mnt/glusterfs/test3
touch /mnt/glusterfs/test4
touch /mnt/glusterfs/test5
touch /mnt/glusterfs/test6
Now let's check the /data/export directory on server1.example.com, server2.example.com, server3.example.com, and server4.example.com. You will notice that replication1 as well as replication2 hold only a part of the files/directories that make up the GlusterFS share on the client, but the nodes that make up replication1 (server1 and server2) or replication2 (server3 and server4) contain the same files (mirroring):
server1.example.com:
ls -l /data/export
root@server1:~# ls -l /data/export
total 0
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test1
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test2
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test4
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test5
root@server1:~#
server2.example.com:
ls -l /data/export
root@server2:~# ls -l /data/export
total 0
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test1
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test2
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test4
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test5
root@server2:~#
server3.example.com:
ls -l /data/export
root@server3:~# ls -l /data/export
total 0
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test3
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test6
root@server3:~#
server4.example.com:
ls -l /data/export
root@server4:~# ls -l /data/export
total 0
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test3
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test6
root@server4:~#
Now we shut down server1.example.com and server4.example.com and add/delete some files on the GlusterFS share on client1.example.com.
server1.example.com/server4.example.com:
shutdown -h now
client1.example.com:
rm -f /mnt/glusterfs/test5
rm -f /mnt/glusterfs/test6
The changes should be visible in the /data/export directory on server2.example.com and server3.example.com:
server2.example.com:
ls -l /data/export
root@server2:~# ls -l /data/export
total 0
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test1
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test2
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test4
root@server2:~#
server3.example.com:
ls -l /data/export
root@server3:~# ls -l /data/export
total 0
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test3
root@server3:~#
Let's boot server1.example.com and server4.example.com again and take a look at the /data/export directory:
server1.example.com:
ls -l /data/export
root@server1:~# ls -l /data/export
total 0
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test1
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test2
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test4
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test5
root@server1:~#
server4.example.com:
ls -l /data/export
root@server4:~# ls -l /data/export
total 0
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test3
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test6
root@server4:~#
As you see, server1.example.com and server4.example.com haven't noticed the changes that happened while they were down. This is easy to fix, all we need to do is invoke a read command on the GlusterFS share on client1.example.com, e.g.:
client1.example.com:
ls -l /mnt/glusterfs/
root@client1:~# ls -l /mnt/glusterfs/
total 0
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test1
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test2
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test3
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test4
root@client1:~#
Now take a look at the /data/export directory on server1.example.com and server4.example.com again, and you should see that the changes have been replicated to these nodes:
server1.example.com:
ls -l /data/export
root@server1:~# ls -l /data/export
total 0
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test1
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test2
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test4
root@server1:~#
server4.example.com:
ls -l /data/export
root@server4:~# ls -l /data/export
total 0
-rw-r--r-- 1 root root 0 2009-12-21 15:41 test3
root@server4:~#
5 Links
- GlusterFS: http://www.gluster.org/
- Ubuntu: http://www.ubuntu.com/
