glusterfs分布式文件系统高级修复
事出总是有因的，我们由于前期机器紧张因此在组建glusterfs的时候使用了4台虚拟机的方式进行初期组件，在后来逐步用物理机替换glusterfs的过程中发现gluster的add-brick和remove-brick功能非常实用，但是毕竟文件系统变大了，在remove的时候会很久而且会遇到很多未预期的问题。当然这次的问题我感觉是最严重的一次，当然通过研究也对glusterfs更加了解了。这次严重的问题并未导致服务中断，所以研究这个系统的压力相对小一些，都是在实验环境进行的，下面就跟大家分享一下。有不准确的地方还请要指正。
glusterfs是分布式的无主网络文件系统，自然他的配置文件其实在任何一个节点都是有一个备份的。但是glusterfs管理使用gluster命令，所有操作在任何一台机器上使用gluster命令都可以对集群进行操作，命令行功能非常强大这样也就不需要进行配置文件管理了。当然越自动化的东西越不容易理解，还是对配置文件直接控制会比较简单一点。
先说说我们遇到的问题，我们的生产环境由于添加删除brick导致peer和volume info信息不一致：
volume info Volume Name: nfsdata Type: Distributed-Replicate Volume ID: ec0a6ac2-28ed-4a75-84ac-9d1c0fc2ae95 Status: Started Number of Bricks: 4 x 2 = 8 Transport-type: tcp Bricks: Brick1: 192.168.4.12:/opt/gdata Brick2: 192.168.4.13:/opt/gdata Brick3: 192.168.4.14:/opt/gdata Brick4: 192.168.4.15:/opt/gdata Brick5: 192.168.4.20:/opt/gdata Brick6: 192.168.4.21:/opt/gdata Brick7: 192.168.4.22:/opt/gdata Brick8: 192.168.4.23:/opt/gdata Options Reconfigured: performance.cache-size: 256MB performance.io-thread-count: 64 cluster.self-heal-daemon: on gluster peer status Number of Peers: 5 Hostname: 192.168.4.15 Uuid: f62a605a-f5a1-4117-bf30-9588372f6d31 State: Peer in Cluster (Connected) Hostname: 192.168.4.22 Uuid: 643beff8-fa89-45e3-9508-79e51f30f600 State: Peer in Cluster (Connected) Hostname: 192.168.4.23 Uuid: 66b7c55f-7a08-43a2-9276-fa74ad388745 State: Peer in Cluster (Connected) Hostname: 192.168.4.21 Uuid: 99662596-b189-4a0d-8f8e-520819042c5e State: Peer in Cluster (Connected) Hostname: 192.168.4.20 Uuid: cddad505-b4da-43d3-875a-4de905cdafce State: Peer in Cluster (Connected)
你肯定会发现我之前就已经把4.12和4.13给移除了，甚至peer部分都已经probe了。但是info中还能显示出来，是不是很奇怪？
而且我现在需要移除4.14和4.15居然报错：
Incorrect brick 192.168.4.14:/opt/gdata for volume nfsdata
所以这也是我苦恼的原因虽然不影响使用，但是目前已经无法对集群进行编辑了。因此我打算彻底解决这个事情
分析
首先我用的版本是glusterfs-3.3.1编译安装以后大致有以下几个重要的目录：
/usr/local/glusterfs 其中有配置文件etc和var/log
/var/lib/glusterfs 这个才是真正的gluster运行的配置文件的存放地。之前那个etc中放的都是些无关痛痒的配置，gluster 命令修改的配置都在这里
/opt/project 这个目录就是gluster创建volume指定的brick的目录，目录中你什么都看不到，提供服务以后文件实体会放在目录中你就能看到了，.glusterfs文件夹则是存放索引的文件夹
主要来看看/var/lib/glusterfs的目录结构：
. ├── geo-replication │ └── gsyncd.conf ├── glusterd.info //存放UUID不要同步该目录 ├── glustershd ├── groups ├── hooks //hook进行各种操作的前置和后置动作 │ └── 1 │ ├── add-brick │ ├── create │ ├── delete │ ├── remove-brick │ ├── set │ ├── start │ └── stop ├── nfs │ ├── nfs-server.vol //*nfs客户端挂载需要的文件，手工需要修改 │ └── run │ └── nfs.pid ├── peers │ └── 8567abef-087b-4025-bc04-57b399644529 └── vols └── nfs ├── bricks //bricks信息，手工需要修改 ├── cksum //随机校验和，手工无所谓修改集群各机器一致即可 ├── info //gluster volume info信息，需要修改各项参数值，包括集群机器数量 ├── nfs.10.7.254.35.opt-nfs.vol //集群配置volume的文件，如果需要剔除brick此文件需要修改 ├── nfs.10.7.254.37.opt-nfsbackup.vol ├── nfs-fuse.vol //*nfsfuse信息，手工变更brick信息需要修改 ├── node_state.info ├── rbstate ├── rebalance ├── run └── trusted-nfs-fuse.vol //*nfs信息，手工变更brick信息需要修改
注意：*是我还没太弄明白的地方，不过跟着我的思路修改是可以用的。
目录内容进行了适当的说明，下面我说说配置修改流程
写在前面：glusterfs启动的时候有3个进程，3个进程一个是glusterd我理解是主服务进程，glustershd我理解是提供shell接口的同时能够同步配置文件，glusterfs这个进程应该是提供volume的直接访问的。
刚才提到glustershd提供了同步配置的功能我想就是vols/project/cksum这个文件体现出来的，这个文件中有一个id值会随你对gluster进行配置而变化，然而变化是随机的不是递增的。开始以为它很棘手，但是其实不用管他也好。
强烈建议：调整这个过程中全部集群gluster相关3个进程都终止，当然代表着中断服务。不中断的方法我也在思考，成熟了再跟大家分享。
实验环境 A和B两台机器，建立一般的distribute模式集群，写入数据A和B各写一半的模式。
1.停止所有进程
2.修改nfs/nfs-server.vol，如果想去掉一台机器（10.7.254.35）则将对应volume nfs-client-0段的配置和subvolumes nfs-client-0 nfs-client-1的nfs-client-1删掉，修改volume nfs-client-1为0。这么说不知道是不是有点啰嗦
volume nfs-client-0
type protocol/client
option remote-host 10.7.254.35
option remote-subvolume /opt/nfs
option transport-type tcp
option username 4dae3b48-79cf-4bd3-9c83-14e43f6585d4
option password ec3953be-1d8a-4460-a50c-1792ddc29417
end-volume
volume nfs-client-1
type protocol/client
option remote-host 10.7.254.37
option remote-subvolume /opt/nfsbackup
option transport-type tcp
option username 4dae3b48-79cf-4bd3-9c83-14e43f6585d4
option password ec3953be-1d8a-4460-a50c-1792ddc29417
end-volume
volume nfs-dht
type cluster/distribute
option decommissioned-bricks nfs-client-0
subvolumes nfs-client-0 nfs-client-1
end-volume
…
3.删掉vols/project中project.brickinfo.vol文件和对应的bricks文件夹中的主机文件
nfs.10.7.254.35.opt-nfs.vol
bricks/10.7.254.35:-opt-nfs
4.编辑info文件重新计算集群数量以及比例
type=0
count=2 //需要修改
status=1
sub_count=0
stripe_count=1
replica_count=1
version=7
transport-type=0
volume-id=cb1212f1-91a4-4aea-8c40-939f52fbef8c
username=4dae3b48-79cf-4bd3-9c83-14e43f6585d4
password=ec3953be-1d8a-4460-a50c-1792ddc29417
brick-0=10.7.254.35:-opt-nfs //需要修改
brick-1=10.7.254.37:-opt-nfsbackup
5.修改nfs-fuse.vol和trusted-nfs-fuse.vol文件，修改方法参加2
6.好了大功告成了。启动你还需使用的机器，应该能够启动成功，可以查看log排查问题。我这里写的都是移除brick并没写添加，当然不能照搬这个过程，因为添加需要涉及到peer的添加，因此可能需要动peers文件夹。这个很重要
7.启动以后当然其他机器启动是需要同步这台机器配置文件的，可以将vols和nfs文件夹进行同步即可，切莫图省事儿将整个/var/lib/gluster文件夹同步，glusterd.info中记录的UUID是每台机器独有的，我没敢试，推荐你也别冒险。
实验验证
功能上来说都是正常的，我已经验证过。
还发现一起好玩的事情，当然是因为我没有同步配置文件的原因，我在10.7.254.37上完成修改完了配置剔除掉了10.7.254.35.启动是正常的，然后我没有同步配置直接启动了10.7.254.35这时候两台机器的配置是不同的，同理也是不同步的。但是在10.7.254.37的volume info已经看不到35的机器，但是在35的机器还能看到37的机器。然后我找了一台机器写先挂37写输入再挂35分别写数据。
结果就是37上写数据不会再与35进行distrute，但是35上写数据还会与37distrubute。
That’s ALL
