原文地址:http://kevinsj.com/?p=321
由于业务发展需要,需要将原有正在运行的OpenStack环境迁移到市郊的新机房中。迁移之后需要重新规划网络划分,重新分配网段,但是又不想原有运行的虚拟机业务受到影响,不希望重建虚拟机,不希望重建云硬盘等。所以这给迁移工作带来了不小的挑战。
内容 [hide]
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 停止,删除卷
2 删除节点
3 修改IP地址
4 添加节点
5 创建,开始卷
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 下
2 修改 /var/lib/glusterd/vols/ 下的卷配置文件,配置文件的名字上带有HOSTNAME要改
3 通过debug模式执行看是否有问题
如果没有问题,开启服务并验证
这下算是将分布式文件系统迁移完毕,这给后面的韵味提个醒,最好在搭建之初就想到可能会有系统迁移的情况,因此在peer probe和volume create的时候尽量选用主机名标记各节点,这样如果不幸需要搬迁,只需要修改/etc/hosts文件即可无缝迁移。
3. OpenStack系统服务调整
这一点单拎出来说,是为了提供一些OpenStack搭建方面的经验。由于OpenStack系统按照模块划分功能,各个模块之间通过API进行通讯,系统核心服务通过消息队列进行任务排序,所以不免的在各个模块的配置文件中都会涉及到需要填写各服务的IP地址信息。
如果在初始平台安装部署的时候没有考虑到迁移的可能性,而全部使用IP地址来填写的话,就会给迁移工作带来极大不便。而我们在进行平台搭建的时候就将各模块的配置文件中涉及到IP地址的部分用主机名或域名来代替,然后在/etc/hosts文件中填写相应的对应关系。涉及到的模块大概有:
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 将其中相应的地址换成新的。
这下重启OpenStack服务应该云主机的网络就能够正常了,如果云主机在启动之后不能够上网,请用virsh edit instance-xxxxxxxx 检查对应的libvirt网络信息是否正确,有可能仍然是之前的地址,如果是的话,改掉即可(virsh edit的使用方法跟vim一样)。
3. 总结
首先,底层文件系统的安装,请尽量使用主机名和域名,这会为迁移带来很大的便利。
然后,OpenStack的安装也尽量使用主机名或域名,将对IP地址的依赖减少到最小。
再然后,万不得已别直接修改数据库,如果非要改请先备份,再加一万分认真。
新的网络规划尽量保证与原网络环境的一致,能做到批量修改最好。
最后,不到万不得已,正式环境不要做如此的环境迁移,即便要迁移环境,请尽量保持网络环境跟之前是一致的,如果连这个也无法保证,那么我只能祝您好运了,我在此提到的只是我们所遇到的一些问题,很可能在不同的情况下会遇到不同的问题,请冷静分析解决。
Have Fun