【场景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命令的执行。
