GlusterFs集群、卷的创建使用与管理
本博文将介绍glusterfs集群的创建过程；glusterfs的复制，条带，哈希等基本卷类型及实际生产中使用率最高的哈希复制卷类型的基本原理，数据存储方式及各种类型卷的创建和使用方法。
1、测试环境
192.168.21.18 rhel6.5 vmserver server1
192.168.21.19 rhel6.5 vmserver server2
192.168.21.17 rhel6.5 vmserver client
请将主机名进行host解析，如果你使用主机名；NTP时间同步；iptables stop；selinux disable
服务启动：
# /etc/init.d/glusterd start
# chkconfig glusterd on
2、创建gluster集群
创建集群是用gluster peer probe 命令
[root@lvs mnt]# gluster
gluster> peer help
peer probe - probe peer specified by
peer detach [force] - detach peer specified by #删除集群节点
peer status - list status of peers #list全部集群节点，显示除自己的其他全部节点
peer help - Help command for peer
pool list - list all the nodes in the pool (including localhost)
当前版本peer所具有的全部命令
在创建的时候使用ip和主机名都是可以的，但是host需要进行解析
gluster> peer probe 192.168.21.18
peer probe: success.
gluster> peer probe 192.168.21.19
peer probe: success. Probe on localhost not needed
使用peer查看当前集群的节点的状态
gluster> peer status
Number of Peers: 1 #看到只有一个节点，gluster默认是不显示loaclhost的，如果去18上也就只能看到19
Hostname: 192.168.21.18
Uuid: 0d556480-b80b-4bff-b825-89bce6be1a3b
State: Peer in Cluster (Connected) #表示18节点已连接
3、创建glusterfs的卷
3.1 glusgerfs卷的类型
基本类型：条带，复制，哈希。然后还有两两组合和三种类型同时使用，总共加起来共7种，新版的还有冗余卷
3.2 创建数据分区
两个节点分别创建/data0/gluster目录，所谓brick的位置，用于存储数据
3.3 创建volume
3.3.1 哈希卷：
哈希卷类似与负载均衡（实际上不是很均衡），他会将完整的数据分成几个不分，分别存储在每一个brick上。
gluster> volume create datavol1 transport tcp 192.168.21.18:/data0/gluster/data1 192.168.21.19:/data0/gluster/data1 force
因为默认是哈希卷，所以卷的类型没有指定，datavol1 这个volume拥有两个brick，分布在两个peer节点；
gluster> volume start datavol1 #启动volume
volume start: datavol1: success
gluster> volume info
Volume Name: datavol1 #卷名
Type: Distribute #哈希卷
Volume ID: e46b32f3-7490-4403-99db-d19ba8968a12
Status: Started #started已经启动
Number of Bricks: 2 #brick数量
Transport-type: tcp
Bricks:
Brick1: 192.168.21.18:/data0/gluster/data1
Brick2: 192.168.21.19:/data0/gluster/data1
gluster> volume status datavol1
Status of volume: datavol1
Gluster process Port Online Pid
------------------------------------------------------------------------------
Brick 192.168.21.18:/data0/gluster/data1 49152 Y 2048
Brick 192.168.21.19:/data0/gluster/data1 49152 Y 16567
NFS Server on localhost 2049 Y 16588
NFS Server on 192.168.21.18 2049 Y 2075
以上是volume的状态信息，可以看到在每一个节点上启动一个volume后，gluster会自动的启动相关的进程，Port机监听的端口。
我们在使用ps去查看的时候此时会有3个进程：
glusterd #管理进程
glusterfsd #brick进程，因为本机上只有一个brick
glusterfs #默认启动的nfs的协议进程，是可以关闭的
在另外一个节点上会启动相同的进程。
3.3.3 创建复制卷
复制卷和条带卷必须要指定卷的类型，复制卷就是每一个brick中的数据都是一样的，都是写入数据的完整备份，相当raid1，所以容量会减少一半，当然性能上也会有所消耗，您想，同一个文件写一次快还是写两次快。
gluster> volume create datavol2 replica 2 transport tcp 192.168.21.18:/data0/gluster/data2 192.168.21.19:/data0/gluster/data2 force
这里需要指定复制卷的数量，目前支持比较好的是2或者3副本，事实上个人觉得3最好了，性能上还可以接受，安全上比2要好，因为是无中心的，2个brick复制可能脑裂的几率会比较大。
为了比较看起来比较爽一点，我们把datavol1 这个哈希卷停掉，然后把复制卷datavol2启动：
gluster> volume stop datavol1
gluster> volume start datavol2
这里仍然会启动glusterd进程
glusterfsd进程，brick的服务进程
/usr/sbin/glusterfs -s localhost --volfile-id gluster/nfs #glusterfs的nfs进程
因为是复制卷会启动一个自修复的进程：
/usr/sbin/glusterfs -s localhost --volfile-id gluster/glustershd
volume status查看卷的状态，如果不指定volume会将所有的volume的状态显示出来：
gluster> volume status
Volume datavol1 is not started
Status of volume: datavol2
Gluster process Port Online Pid
------------------------------------------------------------------------------
Brick 192.168.21.18:/data0/gluster/data2 49153 Y 2222
Brick 192.168.21.19:/data0/gluster/data2 49153 Y 16751
NFS Server on localhost 2049 Y 16767
Self-heal Daemon on localhost N/A Y 16773
NFS Server on 192.168.21.18 2049 Y 2237
Self-heal Daemon on 192.168.21.18 N/A Y 2243
可以看见vol1是sto的，vol2是我们刚创建的复制卷，并且左右的都是Online状态，如果发现哪一个brick不是Online，那就得注意检查这个brick节点了。
3.3.5 创建条带卷
条带卷在处理大文件的时候会有一定的作用，它会将文件拆分几个不分，分别存在两个条带上即两个brick上。这个实际用的较少，个人没有用过，所以理解上可能有误。
gluster volume create bv0 stripe 4 gf1:/share gf2:/share gf3:/share gf4:share force
volume create: datavol3: success: please start the volume to access data
gluster> volume status datavol3
Volume datavol3 is not started
gluster> volume start datavol3
volume start: datavol3: success
stripe和replica一样指定了卷的类型，后边的数字是条带的数量
[root@localhost ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/cl-root 14G 12G 1.6G 89% /
devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 3.9G 351M 3.5G 9% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/sda1 1014M 139M 876M 14% /boot
tmpfs 783M 0 783M 0% /run/user/0
gf1:/models 14G 13G 683M 96% /gluster
gf1:/bv0 128G 57G 71G 45% /dd （是四台服务器硬盘之和）
3.3.6 符合卷
符合卷就是哈希复制，哈希条带，这两个是比较常用的，向条带复制卷，还有三种揉一块儿的用的都比较少
之前单一类型的卷，复制、条带和brick的数量是相同的，但是当我们的brick的数量是复制或条带的倍数的时候就会自动的转换为哈希复制或者哈希条带。
这里我们用4个brick
哈希复制卷是一对一对组成复制卷，所以要选择不同的节点上的brick组成复制卷，这样一个数据的副本就会分布在不同的节点上，不管那个节点宕机，另外一个节点都会数据的完整副本。
上图的红色标记是复制的数量，绿色的是两个节点之间的brick构成复制关系，***的两个brick构成复制关系，192.168.21.18上的data_rd_1和data_rd_2构成哈希关系，19节点同样，所以两个节点都具有数据的完成副本。这里千万不要同一节点的brick间构成复制，两个节点间哈希，这样每个节点上都只保存数据的一部分，任意挂一个节点，你就该哭了。
gluster> volume info data_rd
同样应该start这个卷，
gluster> volume status data_rd
Status of volume: data_rd
Gluster process Port Online Pid
------------------------------------------------------------------------------
Brick 192.168.21.18:/data0/gluster/data_rd_1 49155 Y 2308
Brick 192.168.21.19:/data0/gluster/data_rd_1 49155 Y 16847
Brick 192.168.21.18:/data0/gluster/data_rd_2 49156 Y 2319
Brick 192.168.21.19:/data0/gluster/data_rd_2 49156 Y 16858
NFS Server on localhost 2049 Y 16870
Self-heal Daemon on localhost N/A Y 16879
NFS Server on 192.168.21.18 2049 Y 2331
Self-heal Daemon on 192.168.21.18 N/A Y 2341
上边的status可以看出，只要存在复制卷，就会在每一个节点上启动自恢复进程，用于自我修复数据。
3.4 卷的使用
这里新加了一台vmserver：192.168.21.17作为测试的client 因为一会儿需要将它扩展到之前的节点中去，所以全部安装了server+client的包。
挂载类似与NFS，本地创建一个目录，mount过来就OK了。
所以先创建本地挂载点：
# mkdir -p /data0/disperse #挂载哈希卷
# mkdir -p /data0/replica #挂载复制卷
# mkdir -p /data0/stripe #挂载条带卷
# mount -t glusterfs 192.168.21.18:datavol1 /data0/disperse
# mount -t glusterfs 192.168.21.19:datavol2 /data0/replica
# mount -t glusterfs 192.168.21.19:datavol2 /data0/stripe
因为两个节点是完全对等的，所以你在挂哪一个ip地址都是一样的。
写到fstab：
192.168.21.18:datavol1 /data0/disperse glusterfs defaults 0 0
192.168.21.19:datavol2 /data0/replica glusterfs defaults 0 0
192.168.21.19:datavol3 /data0/stripe glusterfs defaults 0 0
mount -a测试没有报错就表明成功挂载，df看一下吧
192.168.21.18:datavol1 13G 2.2G 11G 18% /data0/disperse
192.168.21.19:datavol2 6.5G 1.3G 5.0G 20% /data0/replica
192.168.21.19:datavol3 6.5G 1.3G 5.0G 20% /data0/stripe
从容量可以看出，哈希卷和条带卷是两个brick容量之和，复制只有一个brick的大小。
3.5 测试：
我们在哈希卷的目录/data0/disperse中写入10个文件
[[email protected] disperse]# pwd
/data0/disperse
[[email protected] disperse]# touch testfile{1,2,3,4,5,6,7,8,9,10}
[[email protected] disperse]# ls
testfile1 testfile10 testfile2 testfile3 testfile4 testfile5 testfile6 testfile7 testfile8 testfile9
我们去192.168.21.18和19的对应的brick上看分别存储的数据。
19：
[root@lvs ~]# ls /data0/gluster/data1/
testfile1 testfile10 testfile2 testfile3 testfile4 testfile6 testfile8
18：
[root@lvs ~]# ls /data0/gluster/data1/
testfile5 testfile7 testfile9
可以看见哈希卷将完整的数据哈希成两份，分别存在两个brick上，相当于raid0，所以这种方式写入的速度也是最快的。
条待卷：
[[email protected] stripe]# pwd
/data0/stripe
[[email protected] stripe]# du -sh /root/root.tar.gz
140M /root/root.tar.gz
[[email protected] stripe]# cp /root/root.tar.gz .
在192.168.21.17上有一个140M的文件，复制到挂载了条待卷的目录下
18节点：
[root@lvs ~]# ls /data0/gluster/data3/
root.tar.gz
[root@lvs ~]# du -sh /data0/gluster/data3/root.tar.gz
70M /data0/gluster/data3/root.tar.gz
19节点：
[root@lvs ~]# du -sh /data0/gluster/data3/root.tar.gz
70M /data0/gluster/data3/root.tar.gz
可见条待卷将完成的一个文件分成两个部分存储在不同的brick上，同时拆分数据，与哈希卷不同的是，哈希卷是以文件为单位的哈希分配。
复制卷比较简单不再测试。
下来看一下哈希复制卷：
# mkdir -p /data0/data_rd
# mount -t glusterfs 192.168.21.18:data_rd /data0/data_rd/
我们将之前/data0/disperse下10个文件和root.tar.gz复制到/data0/data_rd/下：
18节点：
[root@lvs ~]# ls /data0/gluster/data_rd_1/
testfile5 testfile7 testfile9
[root@lvs ~]# ls /data0/gluster/data_rd_2
root.tar.gz testfile1 testfile10 testfile2 testfile3 testfile4 testfile6 testfile8
19节点：
[root@lvs ~]# ls /data0/gluster/data_rd_1/
testfile5 testfile7 testfile9
[root@lvs ~]# ls /data0/gluster/data_rd_2
root.tar.gz testfile1 testfile10 testfile2 testfile3 testfile4 testfile6 testfile8
可以看到同一个节点下的两个brick构成哈希卷，文件哈希分配到两个brick上，而两个节点对应的brick上都是对方数据的完成副本，这个应该相当于raid10吧。
3.6 简单的故障测试
以下我们模拟以下一个节点宕机的情况吧。这个应该是经常遇到的，不管是意外还是重启还是调整，总之肯定是会出现的。
我们吧192.168.21.19这个节点网卡停掉。
[root@lvs ~]# /etc/init.d/network stop
gluster> peer status
Number of Peers: 1
Hostname: 192.168.21.19
Uuid: 2588fd9d-feb0-411e-aa5a-60821c78fddb
State: Peer in Cluster (Disconnected)
这是18这个节点上的peer状态，19这个节点已经失联了。
Status of volume: datavol1
Gluster process Port Online Pid
------------------------------------------------------------------------------
Brick 192.168.21.18:/data0/gluster/data1 49152 Y 2382
NFS Server on localhost 2049 Y 2403
volume的状态也只有18的brick在线。
故障呢，就是这么个情况，正常情况下应该是客户端的对应挂载点下的文件完整可以正常访问，文件数量完整，目录可以创建删除文件。这里哈希卷除外啊，肯定是不完整的，哈希复制卷中如果您没有按照要求构建复制卷的话，也可能是不完整的。
[[email protected] data0]# ls /data0/disperse/
testfile5 testfile7 testfile9
[[email protected] data0]# ls /data0/stripe/
[[email protected] data0]# ls /data0/data_rd/
root.tar.gz testfile1 testfile10 testfile2 testfile3 testfile4 testfile5 testfile6 testfile7 testfile8 testfile9
在客户端上可以看出，挂载点目录都是可以正常访问的。哈希卷只有18节点上文件正常，19上的brick中文件就飞了；条带卷就更坑了，文件完全没有了（条带将文件内容拆分存放，只要一个节点故障，文件就没法重新拼接）；哈希复制卷最给力了，完全没有受到影响。当然如果之前测试了复制卷也是不会有影响的。
接下来我们在复制卷挂载点/data0/replica下创建一个文件，内容为“you are the one”
# echo "you are the one" > /data0/replica/testfile_replica
18上：
[root@lvs ~]# cat /data0/gluster/data2/testfile_replica
you are the one
文件已经正常写入，并在客户端可以被正常读取，所以挂掉一个节点，完全没有问题的，虽然我们/data0/replica挂载的时候连接的是192.168.21.19（mount -t glusterfs 192.168.21.19:datavol2 /data0/replica），但目录的操作还是丝毫没有受到影响。
df看挂载信息，192.168.21.19虽然已经不通了，一样不受影响。事实上，这里挂载的都是192.168.21.18节点只是glusterfs在检测到19节点挂了之后会将挂载路径重定向到其他节点，所以如果你在19挂了之后第一时间来执行df命令，显示的时候肯定会卡一会儿的。
故障恢复:
将19的网络启动，
gluster> peer status
Number of Peers: 1
Hostname: 192.168.21.19
Uuid: 2588fd9d-feb0-411e-aa5a-60821c78fddb
State: Peer in Cluster (Connected)
查看复制卷datavol2的19节点上brick：192.168.21.19:/data0/gluster/data2 的内容，因为我们在它故障的时候写入一个文件：testfile_replica 内容为“you are the one”
19节点：
[root@lvs ~]# cat /data0/gluster/data2/testfile_replica
you are the one
故障节点在恢复之后会同步其他节点的配置信息，并将文件同步。
注意：
在实际使用当中，因为网络延迟，副本过多等诸多问题，出现过以下问题：
例如实际中我们在联通和电信的机房内使用了复制卷，因为存在跨运营商跨机房的复制，文件同步速度不是很理想，并且有多个不同的节点挂载了复制卷。就会有这样一个问题，挂载点A vim修改了文件F1,比如数据首先写入到V1节点，同时V2节点就会检测自己的文件和V1文件是否一样，当不一样的时候就会启动自我修复功能，将V1节点的文件同步过来。在这同步的过程中，在其他挂载点可能就出现文件无法访问的情况。