首先,遇到的问题是分布式文件系统的迁移,因为当时在环境搭建的时候并没有考虑到机房可能会出现搬迁,更没有想到机房搬迁之后IP地址等网络设置会发生变化,所以在安装配置GlusterFS文件系统的时候都是采用IP地址添加peer以及建立Volume的。接到迁移任务之后,我们首先开始考虑基础数据的问题,考虑各种潜在的数据风险,于是预先就把GlusterFS内的文件拷贝出来以防万一。
在这里特别要称赞GlusterFS文件系统的一个特性,那就是文件在GlusterFS上不会切块进行存储,也不会进行数据格式转换,而是数据文件按照原样存储,这样一旦GlusterFS系统不工作,可以在相应的数据文件目录下将相关的文件拷出直接使用。
如果数据量比较小,那么可以考虑在将数据文件拷出之后,对集群各节点采取以下步骤进行迁移:
1 停止,删除卷
1
2
|
$
gluster
volume
stop
data
_vol
$
gluster
volume
delete
data_vol
|
2 删除节点
1
|
$
gluster
peer
detach
node_x
|
3 修改IP地址
4 添加节点
1
|
$
gluster
peer
probe
node_x
|
5 创建,开始卷
1
2
|
$
gluster
volume
create
data_vol
ip
:
path
,
ip
:
path
$
gluster
volume
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 下
1
2
3
4
|
$
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'
|
2 修改 /var/lib/glusterd/vols/ 下的卷配置文件,配置文件的名字上带有HOSTNAME要改
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模式执行看是否有问题
1
|
/
usr
/
local
/
sbin
/
glusterd
--
debug
|
如果没有问题,开启服务并验证
1
2
3
|
$
service
glusterd
restart
$
gluster
peer
status
$
gluster
volume
info
|
这下算是将分布式文件系统迁移完毕,这给后面的韵味提个醒,最好在搭建之初就想到可能会有系统迁移的情况,因此在peer probe和volume create的时候尽量选用主机名标记各节点,这样如果不幸需要搬迁,只需要修改/etc/hosts文件即可无缝迁移。
首先,底层文件系统的安装,请尽量使用主机名和域名,这会为迁移带来很大的便利。
然后,OpenStack的安装也尽量使用主机名或域名,将对IP地址的依赖减少到最小。
再然后,万不得已别直接修改数据库,如果非要改请先备份,再加一万分认真。
新的网络规划尽量保证与原网络环境的一致,能做到批量修改最好。
最后,不到万不得已,正式环境不要做如此的环境迁移,即便要迁移环境,请尽量保持网络环境跟之前是一致的,如果连这个也无法保证,那么我只能祝您好运了,我在此提到的只是我们所遇到的一些问题,很可能在不同的情况下会遇到不同的问题,请冷静分析解决。