OpenStack 环境整体迁移过程记录

1. 环境概述

本次迁移的OpenStack环境涉及4台物理服务器，状况如下：

服务器的两块网卡都已启用。

• eth0作为云主机业务的出口，绑定网桥，主要承载云主机的网络业务，设置网关
• eth1作为数据业务的出口，运行分布式文件系统GlusterFS以及OpenStack的系统服务

我们此系统使用OpenStack Fosolm版本。

2. 迁移过程

1. 迁移要求

• 服务器需要全部跨机房搬迁；
• 新机房的基础网络环境需要重新规划，有原来的 192.168.16.0/24, 192.168.17.0/24 网段变成 10.0.16.0/24, 10.0.17.0/24 网段。

2. 分布式文件系统迁移

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

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

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

1 停止，删除卷

$ gluster volume stop data_vol
$ gluster volume delete data_vol

2 删除节点

$ gluster peer detach node_x

3 修改IP地址 4 添加节点

$ gluster peer probe node_x

5 创建，开始卷

$ 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 下

$ 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要改

$ 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

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

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

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

3. OpenStack系统服务调整

这一点单拎出来说，是为了提供一些OpenStack搭建方面的经验。由于OpenStack系统按照模块划分功能，各个模块之间通过API进行通讯，系统核心服务通过消息队列进行任务排序，所以不免的在各个模块的配置文件中都会涉及到需要填写各服务的IP地址信息。

如果在初始平台安装部署的时候没有考虑到迁移的可能性，而全部使用IP地址来填写的话，就会给迁移工作带来极大不便。而我们在进行平台搭建的时候就将各模块的配置文件中涉及到IP地址的部分用主机名或域名来代替，然后在/etc/hosts文件中填写相应的对应关系。涉及到的模块大概有：

nova
keystone
glance
cinder
ceilometer
navigator
savanna
swift

4. 虚拟机网络调整

下面是虚拟机的网络调整，这部分是本次迁移最麻烦的一个步骤，因为我们的OpenStack是采用的VLAN的模式，需要在交换机一侧配置VLAN Trunk，这次整体迁移，划分新网段的同时还需在新交换机上配置相关的VLAN。

采用VLAN模式之后，云主机就不需要绑定浮动IP地址了，此时固定IP即是云主机的IP。并且本次迁移的过程不希望重建云主机，但是IP地址必须要做出调整，所以必须在已有的数据基础上重新配置云主机网络。

以下是我们的执行步骤，因为不能够删虚机，所以不能通过删除资源，创建网络再重新发起的方式来恢复，所以只好直接修改数据库。

在此我要提醒，不是到万不得已请勿直接修改OpenStack数据库，以避免出现数据不一致的状况进而造成严重的问题，如果一定要修改数据库，请预先做好备份工作。

修改步骤:

1.修改数据库 nova.networks

这个表的内容是在根据tenant建立网络的时候记录的信息，包括网络的地址、子网掩码、网关、组播地址、vlan号等信息，需要根据新的网络环境做相应的修改。

2.修改数据库 nova.instance_info_caches

这个表的network_info字段以文本的格式记录了云主机的网络信息，包括地址、所在桥、网关等信息，请一并改掉。当然，挑选未删除的云主机(deleted=0)修改即可，不用所有的都改。

3.修改数据库 nova.fixed_ips

这个表记录的是每个云主机的固定IP映射关系，如果采用的是vlan的模式，需要将这个表中的address字段修改为新的地址段。如果采用其他的网络模式，这张表就不用修改，但是需要修改nova.floating_ips，将对应的新地址填入address字段中。

在此，我们的建议是在更换地址时，保持后两段不变，只改动前两段，例如 (192.168.16.0/24 -> 10.0.16.0/24)，这样的话，原有的虚拟机只需要将地址的前两段更换即可，也可以写脚本批量替换。

4.修改云主机libvirt配置文件

假设云主机的镜像存放路径是 $OPENSTACK_ROOT/data/nova/instances/instance-xxxxxxxx

那么修改文件 $OPENSTACK_ROOT/data/nova/instances/instance-xxxxxxxx/libvirt.xml 将其中相应的地址换成新的。

...
<interface type="bridge">
  <mac address="fa:16:3e:47:c8:3f"/>
  <model type="virtio"/>
  <source bridge="br16"/>
  <filterref filter="nova-instance-instance-00000097-fa163e47c83f">
    <parameter name="IP" value="10.0.16.5"/>
    <parameter name="DHCPSERVER" value="10.0.16.18"/>
    <parameter name="PROJNET" value="10.0.16.0"/>
    <parameter name="PROJMASK" value="255.255.255.0"/>
  </filterref>
</interface>
...

这下重启OpenStack服务应该云主机的网络就能够正常了，如果云主机在启动之后不能够上网，请用virsh edit instance-xxxxxxxx 检查对应的libvirt网络信息是否正确，有可能仍然是之前的地址，如果是的话，改掉即可(virsh edit的使用方法跟vim一样)。

3. 总结

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

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

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

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

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

转载请注明：爱开源 » OpenStack 环境整体迁移过程记录