GlusterFS维护总结

【场景1】某个GlusterFS节点的操作系统Down，需要重装系统和GlusterFS的场景。

解决办法如下：

（1）先别启动GlusterFS服务

重新安装GlusterFS后，设置好对应的Brick目录和挂载完对应的存储，暂时别启动GlusterFS服务。

（2）获取该节点UUID信息

通过观察集群的其他节点保存的节点UUID信息，得到损坏节点的UUID信息。

ls命令查看一个完好节点的“/var/lib/glusterd/peers”目录，可以看到该集群其他节点所有的UUID，如图1所示。

图1

逐个观察各完好节点的本身UUID信息（cat /var/lib/glusterd/peers glusterd.info），如图2所示。

图2

结合图1进行排除，就可以损坏节点的原UUID信息。

（3）在损坏节点配置原UUID信息

在/var/lib/glusterd/peers目录下，新建glusterd.info，按图2的格式，将原UUID和operating-version信息写入该文件。

（4）重启GlusterFS服务

（5）在该节点执行“gluster peer probe gf6”命令探测完好节点。

（6）在该节点执行“gluster peer status”命令观察存储池的状态，如图3所示。

图3

在第（5）步命令中那个完好的节点（gf6），也执行“gluster peer status”命令观察存储池的状态，如图4所示。

图4

可以看到损坏的节点（gf2）在存储池节点的状态为“Peer Rejected (Connected)”。

（7）重启损坏节点（gf2）的GlusterFS服务

在两个节点分别观察存储池节点的状态，应该可以发现损坏的节点，已经正常连接到存储池中。

（8）触发该节点进行数据同步

在客户端的挂载点使用ls命令遍历集群目录，该节点就启动文件自愈功能，从老的备份节点将数据同步过来。

注意：当数据较大时，整个同步过程较为耗时。

（9）测试损坏节点是否可写文件

在客户端的挂载目录，新建多个文件，观察新建的文件能否写在该节点上。

测试如下：通过touch命令，新建数个文件。

图5

在原来损坏的节点的brcik目录下观察能否写入文件

图6

【场景2】日志转储

GlusterFS 3.6版本默认配置了日志转储功能，日志转储的配置保存在/etc/logrotate.d/下。如不存在按以下步骤新建相应的配置文件。

注意：CentOS6.3 Minimal版本因官方遗漏cron，会导致日志转储功能失效，解决办法是手动安装cronie的包。

在/etc/logrotate.conf文件，可以配置日志转储的周期、日志保持的时间、是否压缩日志

在/etc/logrotate.d/目录，可以查看哪些服务配置了日志转储的。GlusterFS配置的文件如下图所示，对glusterd、glusterfsd、glusterfs-fuse和glusterfs-georep进行转储。

初始的glusterd配置为：

通过logrotate –d –f /etc/logrotate.d/glusterd调试观察配置是否生效。

【场景3】替换损坏的Brick

在备份集群中，假设gf4节点出现故障，无法启动GlusterFS服务，而gf5是个备用的节点，准备好gf5的存储和brcik相应的目录，使用replace-brick命令替换损坏节点的brcik

命令如下：glustervolume replace-brick testvol gf4:/srv/sdb1/brick gf5:/srv/sdb1/brick commitforce

testvoI是卷名，gf4:/srv/sdb1/brick是已损坏的brcik，gf5:/srv/sdb1/brick是新的brcik

命令执行后，等待数据的同步，可以观察gf5的/srv/sdb1/brick目录查看同步好的数据。数据较大的情况下，同步过程也较久，请耐心待replace-brick命令的执行。