|
本博文将介绍glusterfs集群的创建过程；glusterfs的复制，条带，哈希等基本卷类型及实际生产中使用率最高的哈希复制卷类型的基本原理，数据存储方式及各种类型卷的创建和使用方法。
glusterfs的安装方法见： http://wangziyin.blog.51cto.com/6948950/1649838 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 当前版本peer所具有的全部命令 在创建的时候使用ip和主机名都是可以的，但是host需要进行解析 gluster> peer probe 192.168.21.18 使用peer查看当前集群的节点的状态 gluster> peer status 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 gluster> volume info gluster> volume status datavol1 以上是volume的状态信息，可以看到在每一个节点上启动一个volume后，gluster会自动的启动相关的进程，Port机监听的端口。 我们在使用ps去查看的时候此时会有3个进程： glusterd #管理进程 在另外一个节点上会启动相同的进程。
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 可以看见vol1是sto的，vol2是我们刚创建的复制卷，并且左右的都是Online状态，如果发现哪一个brick不是Online，那就得注意检查这个brick节点了。
3.3.5 创建条待卷
条带卷在处理大文件的时候会有一定的作用，它会将文件拆分几个不分，分别存在两个条带上即两个brick上。这个实际用的较少，个人没有用过，所以理解上可能有误。 gluster> volume create datavol3 stripe 2 192.168.21.18:/data0/gluster/data3 192.168.21.19:/data0/gluster/data3 force stripe和replica一样指定了卷的类型，后边的数字是条带的数量
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
gluster> volume status data_rd 上边的status可以看出，只要存在复制卷，就会在每一个节点上启动自恢复进程，用于自我修复数据。
3.4 卷的使用
这里新加了一台vmserver：192.168.21.17作为测试的client 因为一会儿需要将它扩展到之前的节点中去，所以全部安装了server+client的包。 挂载类似与NFS，本地创建一个目录，mount过来就OK了。 所以先创建本地挂载点： # mkdir -p /data0/disperse #挂载哈希卷 # mount -t glusterfs 192.168.21.18:datavol1 /data0/disperse # mount -t glusterfs 192.168.21.19:datavol2 /data0/replica 因为两个节点是完全对等的，所以你在挂哪一个ip地址都是一样的。 写到fstab： 192.168.21.18:datavol1 /data0/disperse glusterfs defaults 0 0 mount -a测试没有报错就表明成功挂载，df看一下吧 192.168.21.18:datavol1 13G 2.2G 11G 18% /data0/disperse 从容量可以看出，哈希卷和条带卷是两个brick容量之和，复制只有一个brick的大小。
3.5 测试：
我们在哈希卷的目录/data0/disperse中写入10个文件 [root@lvs.17.sg1.test disperse]# pwd 我们去192.168.21.18和19的对应的brick上看分别存储的数据。 19： [root@lvs ~]# ls /data0/gluster/data1/ 18： [root@lvs ~]# ls /data0/gluster/data1/ 可以看见哈希卷将完整的数据哈希成两份，分别存在两个brick上，相当于raid0，所以这种方式写入的速度也是最快的。 条待卷： [root@lvs.17.sg1.test stripe]# pwd 在192.168.21.17上有一个140M的文件，复制到挂载了条待卷的目录下 18节点： [root@lvs ~]# ls /data0/gluster/data3/ 19节点： [root@lvs ~]# du -sh /data0/gluster/data3/root.tar.gz 可见条待卷将完成的一个文件分成两个部分存储在不同的brick上，同时拆分数据，与哈希卷不同的是，哈希卷是以文件为单位的哈希分配。
复制卷比较简单不再测试。 下来看一下哈希复制卷： # mkdir -p /data0/data_rd 我们将之前/data0/disperse下10个文件和root.tar.gz复制到/data0/data_rd/下： 18节点： [root@lvs ~]# ls /data0/gluster/data_rd_1/ 19节点： [root@lvs ~]# ls /data0/gluster/data_rd_1/ 可以看到同一个节点下的两个brick构成哈希卷，文件哈希分配到两个brick上，而两个节点对应的brick上都是对方数据的完成副本，这个应该相当于raid10吧。 3.6 简单的故障测试 以下我们模拟以下一个节点宕机的情况吧。这个应该是经常遇到的，不管是意外还是重启还是调整，总之肯定是会出现的。 我们吧192.168.21.19这个节点网卡停掉。 [root@lvs ~]# /etc/init.d/network stop gluster> peer status 这是18这个节点上的peer状态，19这个节点已经失联了。 Status of volume: datavol1 volume的状态也只有18的brick在线。 故障呢，就是这么个情况，正常情况下应该是客户端的对应挂载点下的文件完整可以正常访问，文件数量完整，目录可以创建删除文件。这里哈希卷除外啊，肯定是不完整的，哈希复制卷中如果您没有按照要求构建复制卷的话，也可能是不完整的。 [root@lvs.17.sg1.test data0]# ls /data0/disperse/ 在客户端上可以看出，挂载点目录都是可以正常访问的。哈希卷只有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 文件已经正常写入，并在客户端可以被正常读取，所以挂掉一个节点，完全没有问题的，虽然我们/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 查看复制卷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 故障节点在恢复之后会同步其他节点的配置信息，并将文件同步。 注意： 在实际使用当中，因为网络延迟，副本过多等诸多问题，出现过以下问题： 例如实际中我们在联通和电信的机房内使用了复制卷，因为存在跨运营商跨机房的复制，文件同步速度不是很理想，并且有多个不同的节点挂载了复制卷。就会有这样一个问题，挂载点A vim修改了文件F1,比如数据首先写入到V1节点，同时V2节点就会检测自己的文件和V1文件是否一样，当不一样的时候就会启动自我修复功能，将V1节点的文件同步过来。在这同步的过程中，在其他挂载点可能就出现文件无法访问的情况。 本文出自 “王兹银的博客” 博客，请务必保留此出处http://wangziyin.blog.51cto.com/6948950/1649911 |
|
|
