GlusterFS维护总结

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

解决办法如下:

(1)先别启动GlusterFS服务

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

(2)获取该节点UUID信息

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

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

GlusterFS维护总结_第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所示。

GlusterFS维护总结_第2张图片

图3

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

GlusterFS维护总结_第3张图片

图4

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

(7)重启损坏节点(gf2)的GlusterFS服务

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

(8)触发该节点进行数据同步

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

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

(9)测试损坏节点是否可写文件

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

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

GlusterFS维护总结_第4张图片

图5

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

GlusterFS维护总结_第5张图片

图6

【场景2】日志转储

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

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

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

GlusterFS维护总结_第6张图片

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

GlusterFS维护总结_第7张图片

初始的glusterd配置为:

GlusterFS维护总结_第8张图片

通过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命令的执行。

你可能感兴趣的:(GlusterFs)