最新消息:

OpenStack 环境整体迁移过程记录

OpenStack admin 5109浏览 0评论

1. 环境概述

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

主机名 角色 eth0 eth1
controller 控制节点,存储节点 192.168.16.1 (VLAN Trunk) 192.168.17.1
node01 计算节点,存储节点 192.168.16.2 (VLAN Trunk) 192.168.17.2
node02 计算节点,存储节点 192.168.16.3 (VLAN Trunk) 192.168.17.3
node03 计算节点,存储节点 192.168.16.4 (VLAN Trunk) 192.168.17.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 环境整体迁移过程记录

您必须 登录 才能发表评论!