2 cluster管理
在创建volume之前需要先将一组存储设备组成一个存储池，通过存储设备提供的bricks来组成卷。
在设备上启动glusterd之后，可通过设备的主机名或IP地址，将设备加到存储池中。
- $gluster peer probe host|ip
- $gluster peer status #查看除本机外的其他设备状态
- $gluster peer detach host|ip #如果希望将某设备从存储池中删除
gluster对于每个节点都会生成一个UUID来标识，因此如果节点的IP或主机名发生了变化，只需要重新执行peer probe即可。不过如果一个主机名曾经用过，想再改回去，则gluster会提示已经保存过。此时只能把节点detach掉，然后重新probe。
3 Volume管理
数据的传输协议支持tcp和infiniband rdma协议。
4 排错
4.1 错误
gluster使用了若干端口，如果出现probe peer或数据无法同步，考虑iptables对应用的影响。
4.2 日志
$gluster volume log rotate mamm-vol #实现日志rotate
4.3 添加卷提示已经路径已在卷中的错误
执行下面的脚本，清除历史数据及属性信息
- path=$1 #参数为待添加目录绝对路径
- rm -rf $path/.glu*
- setfattr -x trusted.glusterfs.volume-id $path
- setfattr -x trusted.gfid $path
4.4 添加卷连接失败
每次向卷中添加brick后，远端的glusterd进程可能会连接关闭一段时间。此时现次执行操作会提示连接失败。等一会再执行即可
5 客户端设置
客户端使用GFS有多种方式，性能最高的方式是使用gluster的native接口，此外还有NFS和CIFS方式。
http://hi.csdn.net/attachment/201103/25/44164_13010488121P5t.png
5.1 native方式
1 安装gluserfs-fuse安装包，
2 挂载卷：mount -t glusterfs host/ip:path mnt-point
注意，这里提供的IP和主机只用来为客户提供volfile信息，后续客户便直接和需要的服务器通信了。
3 设置自动挂载
echo "localhost:/mamm-vol /mnt/glusterfs glusterfs defaults,_netdev 0 0" >>/etc/fstab
5.2 NFS方式
Gluster提供了内置的NFS服务，支持其他实现了NFSv3的客户端直接访问。
- #service nfs stop # 关闭Linux内核自带的NFS服务
- #service rpcbind start # 启动rpc端口映射管理
- #rpc.statd
然后客户端挂载
- mount -t nfs -o vers=3 host/ip:/path mnt-port
window7客户端
程序和功能->打开或关闭windows功能，安装NFS客户端功能，即可使用mount/showmount功能。
5.3 CIFS方式
cifs可以提供给WIN及samba客户端访问，对于windows程序，可以使用//ip/path通过SMB协议来方便的使用远程资源
1 在服务器将glusterfs挂载到/mnt/gfs
2 服务器通过samba配置将/mnt/gfs导出服务，启动smb服务
3 在win客户端上挂载samber服务器导出共享mount -t cifs //ip/path /mnt-point
glusterfs集群文件系统研究：http://blog.csdn.net/liuaigui/article/details/6284551
Infiniband介绍与配置：http://www.ibm.com/developerworks/cn/linux/l-cn-infiniband/
6 关于Glusterfs为何采用哈希分布式算法
若要实现文件均匀分布，用最简单的线性哈希算法--取模运算（根据文件名获取整数，然后根据节点数取模）就可以将文件均匀分布，为何Glusterfs为何还要用这么复杂的哈希算法实现文件的分布式存储呢？
关于这么问题，要从负载均衡说起吧。就拿分布式存储来说，简单的取模运算也可以将文件均匀分布在各个节点之中。但若节点数改变，节点增删的话，这种方法就不可取了，节点增删，文件的取模全部发生变化，导致各个节点上的文件需要全部迁移。这就是Glusterfs要采用哈希分布式存储而不直接采用取模的原因。
为每个节点均匀划分哈希区间，根据文件名计算哈希值，将文件存储到哈希值所在哈希区间对应的存储节点上。若节点有增删，每个节点的哈希区间会增大或变小。只是部分文件需要迁移，这就大大减少了文件的移动。
哈希均衡广泛应用于P2P网络、分布式存储等领域，上述只是Glusterfs采用该算法的一个原因
7 Glusterfs冗余镜像（AFR）修复原理以及脑裂分析
首先，简单描述一下脑裂，所谓脑裂，就是指两个或多个节点都“认为”自身是正常节点而互相“指责”对方，导致不能选取正确的节点进行接管或修复，导致脑裂状态。这种现象出现在数据修复、集群管理等等高可用场景。
Glusterfs的冗余镜像（下文简称AFR）提供了数据副本功能，能够在即使只有一个冗余节点的情况下仍能正常工作，不中断上层应用。当节点恢复后，能够将数据修复到一致状态，保证数据的安全。
AFR工作原理
AFR数据修复主要涉及三个方面：ENTRY，META，DATA，我们以冗余度为2即含有两个副本A和B的DATA修复为例进行讲解。记录描述副本状态的称之为ChangeLog，记录在每个副本文件扩展属性里，读入内存后以矩阵形式判断是否需要修复以及要以哪个副本为Source进行修复。初始值以及正常值为0.（注：ENTRY和META,DATA分布对应着一个数值）。
Write的步骤可分解为：
1）下发Write操作。
2）加锁Lock。
3）向A，B副本的ChangeLog分别加1，记录到各个副本的扩展属性中。
4）对A，B副本进行写操作。
5）若该副本写成功则ChangeLog减1，若该副本写失败则ChangLog值不变，记录到各个副本的扩展属性中。
6）解锁UnLock。
7）向上层返回，只要有一个副本写成功就返回成功。
上述在AFR中是完整的一个transaction动作。根据两个副本记录的ChangeLog的数值确定了副本的几种状态：
1）WISE，智慧的，即该副本的ChangeLog中对方对应的数值大于0而且自身对应的数值等于0.
2）INNOCENT，无辜的，即该副本上的ChangeLog即不指责对方也指责自己，ChangeLog全为0.
3）FOOL，愚蠢的，即该副本上的ChangeLog是指责自己的。
4）IGNORANT，忽略的，即该副本的ChangeLog丢失。
所以一般情况下，会选取WISE的副本作为Sourse进行修复。但是当两个节点都是WISE状态时，这就出现了声名狼藉的脑裂状态。
AFR脑裂
两个副本均为WISE时发生脑裂，那么在哪种场景下会产生脑裂呢？我们还是以冗余度为2的情况举一个简单的例子：某文件X的两个副本位于物理机A和物理机B上，在A和B上分别运行着进程a和进程b，a和b持续通过各自所在的物理机上的客户端对文件X进行不同的写操作。然后物理机A和B之间网络中断，因为AFR在一个副本的情况下仍能不中断上层应用，所以进程a和进程b仍会持续运行，但因为网络中断，文件X在A和B上的副本数据不再一致且都认为对方是异常的，当网络恢复时，两个副本互相“指责”，即出现了脑裂。当然这是脑裂发生的场景之一，有时候是有可能发生脑裂，而有时候是必然发生脑裂。脑裂，也是很多人关心的一个问题，不能一概而论。
7.1 glusterfs中split-brain的重现与修复
假设有两台glusterfs的server
ComputeA 10.0.0.2
ComputeB 10.0.0.3
分别共享本地目录/home/glusterfs/目录作为共享目录，gluster volume挂载在/var/lib/nova/instances/
断开ComputeB的网络
1 | [ComputeB]#echo "bad" > /home/glusterfs/test |
2 | [ComputeA]#echo "good" > /home/glusterfs/test |
重新恢复ComputeB的网络。
这个时候脑裂产生了！
1 | cat /var/lib/nova/instances/test |
3 | gluster volume heal gluster_vol info split-brain |
会显示有问题的文件。
解决办法：
参考链接地址
在ComputeB上面执行
1 | find /home/glusterfs/ -samefile /home/glusterfs/test -print -delete |
2 | /home/glusterfs/.glusterfs/47/0a/470a742c-b0d6-4846-9ab3-2483c3a0c8da |
等一会同步完成之后
1 | cat /var/lib/nova/instances/test |
脑裂修复啦！
2908
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
