gluster的迁移

分布式文件系统迁移

首先，遇到的问题是分布式文件系统的迁移，因为当时在环境搭建的时候并没有考虑到机房可能会出现搬迁，更没有想到机房搬迁之后IP地址等网络设置会发生变化，所以在安装配置GlusterFS文件系统的时候都是采用IP地址添加peer以及建立Volume的。接到迁移任务之后，我们首先开始考虑基础数据的问题，考虑各种潜在的数据风险，于是预先就把GlusterFS内的文件拷贝出来以防万一。

在这里特别要称赞GlusterFS文件系统的一个特性，那就是文件在GlusterFS上不会切块进行存储，也不会进行数据格式转换，而是数据文件按照原样存储，这样一旦GlusterFS系统不工作，可以在相应的数据文件目录下将相关的文件拷出直接使用。

如果数据量比较小，那么可以考虑在将数据文件拷出之后，对集群各节点采取以下步骤进行迁移：

1 停止，删除卷

$ gluster volume stop data_vol$ gluster volume delete data_vol

1

2

$gluster volume stop data_vol

$ glustervolume delete data_vol

2 删除节点

$ gluster peer detach node_x

1

$gluster peer detachnode_x

3 修改IP地址 4 添加节点

$ gluster peer probe node_x

1

$gluster peer probenode_x

5 创建，开始卷

$ gluster volume create data_vol ip:path,ip:path$ gluster volume start data_vol

1

2

$gluster volume create data_vol ip:path,ip:path

$ glustervolume start data_vol

6 拷回数据

但是由于我们的GlusterFS存储了云主机镜像文件以及云硬盘的数据，大约有几个TB的数据，所以将数据拷出再拷回来的方法显然不太现实。下面就是如何在不重装，不删卷(Volume)，不重加节点(peer)的情况下更改GlusterFS的地址。

GlusterFS在进行peer probe操作以及create volume的操作之后，会将相应的IP地址信息写入配置文件中，并且某的些文件的文件名也会包含IP地址信息，经过grep以及find命令的查找，需要修改的地方如下(对于编译安装的GlusterFS)：

1 修改 /var/lib/glusterd 下配置文件，peer 在 /var/lib/glusterd/peers/* 下，卷在 /var/lib/glusterd 下

$ grep -rl 192.168.17.1 /var/lib/glusterd | xargs sed -i 's/192.168.17.1/10.0.17.1/g'$ grep -rl 192.168.17.2 /var/lib/glusterd | xargs sed -i 's/192.168.17.2/10.0.17.2/g'$ grep -rl 192.168.17.3 /var/lib/glusterd | xargs sed -i 's/192.168.17.3/10.0.17.3/g'$ grep -rl 192.168.17.4 /var/lib/glusterd | xargs sed -i 's/192.168.17.4/10.0.17.4/g'

1

2

3

4

$grep -rl192.168.17.1 /var/lib/glusterd| xargssed -i's/192.168.17.1/10.0.17.1/g'

$ grep-rl192.168.17.2 /var/lib/glusterd| xargssed -i's/192.168.17.2/10.0.17.2/g'

$grep -rl192.168.17.3 /var/lib/glusterd| xargssed -i's/192.168.17.3/10.0.17.3/g'

$ grep-rl192.168.17.4 /var/lib/glusterd| xargssed -i's/192.168.17.4/10.0.17.4/g'

2 修改 /var/lib/glusterd/vols/ 下的卷配置文件，配置文件的名字上带有HOSTNAME要改

$ cd /var/lib/glusterd/vols/data_vol/$ rename 's/192.168.17.1/10.0.17.1/g' *$ rename 's/192.168.17.2/10.0.17.2/g' *$ rename 's/192.168.17.3/10.0.17.3/g' *$ rename 's/192.168.17.4/10.0.17.4/g' *$ rename 's/192.168.17.1/10.0.17.1/g' */*$ rename 's/192.168.17.2/10.0.17.2/g' */*$ rename 's/192.168.17.3/10.0.17.3/g' */*$ rename 's/192.168.17.4/10.0.17.4/g' */*

1

2

3

4

5

6

7

8

9

10

11

$cd /var/lib/glusterd/vols/data_vol/

 

$rename 's/192.168.17.1/10.0.17.1/g'*

$ rename's/192.168.17.2/10.0.17.2/g'*

$rename 's/192.168.17.3/10.0.17.3/g'*

$ rename's/192.168.17.4/10.0.17.4/g'*

 

$ rename's/192.168.17.1/10.0.17.1/g'*/*

$rename 's/192.168.17.2/10.0.17.2/g'*/*

$ rename's/192.168.17.3/10.0.17.3/g'*/*

$rename 's/192.168.17.4/10.0.17.4/g'*/*

3 通过debug模式执行看是否有问题

/usr/local/sbin/glusterd --debug

1

/usr/local/sbin/glusterd--debug

如果没有问题，开启服务并验证

$ service glusterd restart$ gluster peer status$ gluster volume info

1

2

3

$service glusterd restart

$ glusterpeer status

$gluster volume info

这下算是将分布式文件系统迁移完毕，这给后面的韵味提个醒，最好在搭建之初就想到可能会有系统迁移的情况，因此在peer probe和volume create的时候尽量选用主机名标记各节点，这样如果不幸需要搬迁，只需要修改/etc/hosts文件即可无缝迁移。

3. 总结

首先，底层文件系统的安装，请尽量使用主机名和域名，这会为迁移带来很大的便利。

然后，OpenStack的安装也尽量使用主机名或域名，将对IP地址的依赖减少到最小。

再然后，万不得已别直接修改数据库，如果非要改请先备份，再加一万分认真。

新的网络规划尽量保证与原网络环境的一致，能做到批量修改最好。

最后，不到万不得已，正式环境不要做如此的环境迁移，即便要迁移环境，请尽量保持网络环境跟之前是一致的，如果连这个也无法保证，那么我只能祝您好运了，我在此提到的只是我们所遇到的一些问题，很可能在不同的情况下会遇到不同的问题，请冷静分析解决。