GlusterFs集群、卷的创建使用与管理

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这个卷,

GlusterFs集群、卷的创建使用与管理_第1张图片

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),但目录的操作还是丝毫没有受到影响。

GlusterFs集群、卷的创建使用与管理_第2张图片

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节点的文件同步过来。在这同步的过程中,在其他挂载点可能就出现文件无法访问的情况。

你可能感兴趣的:(GlusterFs集群、卷的创建使用与管理)