当前位置: 游戏平台 > 互联网科技 > 正文

OpenStack在线迁移

时间:2019-11-08 22:33来源:互联网科技
注意事项 修改vncserver_listen后创建的实例才能迁移 在我的实验中,哪怕我手动修改实例的libvirt.xml文件,将vnc的监听ip改为0.0.0.0并重启nova-compute且让实例也重启仍然失败了。迁移过程中

注意事项

修改vncserver_listen后创建的实例才能迁移
在我的实验中,哪怕我手动修改实例的libvirt.xml文件,将vnc的监听ip改为0.0.0.0并重启nova-compute且让实例也重启仍然失败了。迁移过程中我看到在目的计算节点上已经创建了实例的相关文件,但是很快又被删除了,没有任何报错,实例仍然在源计算节点运行,状态从migrating恢复为active。

如果实例有挂载volume一定要先卸载再迁移
这点更重要,我对挂载有volume的实例进行迁移,结果一直处于mirating状态,所挂载的卷也处于migrating状态,通过Virual Machine Manager观察实例在源计算节点和目的计算节点的状态都为paused。我尝试重启两个节点的nova-compute服务,并配置让实例跟随重启。结果源节点报Domain not found错,且在Virual Machine Manager观察到实例被删除,但实例文件还在,服务也因报错启动失败。目的节点实例启动成功,且能识别挂载的卷,但是文件中缺少libvirt.xml文件,且不受OpenStack管理了,通过客户端查询实例信息,显示的信息为实例仍在源节点上,状态为正在迁移。尝试手动修改数据库使状态一致没有成功。

实例迁移过程会有短暂的无法联通情况
迁移过程我用ping命令测试,在迁移快完成的时候丢失了5个包,多次测试一样。

会在目的节点_base文件夹下创建额外的镜像文件
尽管我的目的节点_base下已经有了创建该实例所需要的镜像文件,但仍然会创建新的镜像文件,新文件文件名只是多加了个"_11",大小一样,如果直接使用已有的镜像不创建新就好了,当然如果已经有这个带后缀"_11"的文件存在就不会再创建了。

澳门皇冠金沙网站 1

2、安装NFS服务器

由于迁移需要用到共享存储,我们在controller节点配置一个被所有计算节点共同使用的共享存储。这里使用NFS服务。

NFS服务了解更多可参考:NFS(Network File System)服务配置和使用

controller节点:

第一步,安装nfs服务

# apt-get install nfs-kernel-server nfs-common 

第二步,创建一个目录作为nfs服务挂载的目录

# mkdir /var/nfs-storage

第三步,配置/etc/exports

root@controller:~# cat /etc/exports
# /etc/exports: the access control list for filesystems which may be exported
#               to NFS clients.  See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes       hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes  gss/krb5i(rw,sync,no_subtree_check)
#

/var/nfs-storage  *(rw,sync,fsid=0,no_root_squash)
root@controller:~# exportfs -rv

迁移时候一般看的日志有:
1.目的节点上的/var/log/libvirt/qemu/instances–xxx.log
2.目的节点上的/var/log/nova/compute.log
3.源节点上的/var/log/nova/compute.log
有时候迁移失败,命令行执行后报错:
ERROR: Live migration of instance bd785968-72f6-4f70-a066-b22b63821c3b to host compute-13 failed (HTTP 400) (Request-ID: req-180d27b5-9dc7-484f-9d9a-f34cccd6daa2)
但在上述的三个日志文件中都看不到任何的错误信息。
解决办法:
在控制节点或者是在操作迁移命令的节点上/var/log/nova/api.log有错误信息

修改配置

主要是修改nova和libvirt的配置,让nova的vncserver监听0.0.0.0而不是计算节点的内部ip,让libvirt监听tcp,注意这里的关于修改libvirt配置的命令是针对CentOS的,Ubuntu等的修改请参照参考文档。命令如下:

sed -i 's/vncserver_listen.*/vncserver_listen=0.0.0.0/' /etc/nova/nova.conf
sed -i -e 's/#listen_tls/listen_tls/' -e 's/#listen_tcp = 1/listen_tcp = 1nauth_tcp = "none"/' /etc/libvirt/libvirtd.conf
sed -i 's/#LIBVIRTD_ARGS/LIBVIRTD_ARGS/' /etc/sysconfig/libvirtd
service libvirtd restart

1、环境

OpenStack三个节点icehouse-gre模式部署一文部署了的OpenStack环境。

IP如下:

controller:10.1.101.11

network:10.1.101.21

compute:10.1.101.31

compute2:10.1.101.41

确保环境配置正确。

修改各个节点的nova.conf中vncserver_listen为:

vncserver_listen = 0.0.0.0

Ubuntu下Hadoop环境的配置 http://www.linuxidc.com/Linux/2012-11/74539.htm

OpenStack在线迁移的类型

澳门皇冠金沙网站,OpenStack有两种在线迁移类型:live migration和block migration。Live migration需要实例保存在共享存储中,否则会报错,这种迁移主要是实例的内存状态的迁移,速度应该会很快。Block migration除了实例内存状态要迁移外,还得迁移磁盘文件,速度会慢些,但是它不要求实例存储在共享文件系统中。这里我所进行的是block migration。这两种迁移方式在nova client都通过命令nova live-migration实现。带参数--block_migrate表示后一种,不带表示前一种。要进行该操作需要用户在实例所在的tenant有admin角色。

二、修改所有计算节点libvirt

第一步,修改/etc/libvirt/libvirtd.conf 【注意该目录还有一个libvirt.conf,不要弄错了】
改前:#listen_tls = 0

改后:listen_tls = 0

改前:#listen_tcp = 1

改后:listen_tcp = 1

改前:#auth_tcp = "sasl"

改后:auth_tcp = "none"

第二步,修改/etc/default/libvirt-bin

改前:libvirtd_opts="-d"

改后:libvirtd_opts="-d -l"

第三步,去掉 /etc/libvirt/qemu.conf 中以下三行注释

vnc_listen = "0.0.0.0"
user = "root"
group = "root"

第四步,重启libvirt-bin

service libvirt-bin restart

确认进程已启动

root@compute1:~# ps -ef |grep libvirt
root      9518     1  0 Jan20 ?        00:01:23 /usr/sbin/libvirtd -d -l

重启nova-compute服务

service nova-compute restart 

到此配置成功!注意/var/lib/nova/instances目录权限:

root@compute1:~# ll /var/lib/nova/
total 36
drwxr-xr-x  9 nova nova 4096 Jan 20 15:40 ./
drwxr-xr-x 42 root root 4096 Jan 20 13:59 ../
drwxr-xr-x  2 nova nova 4096 May 15  2014 buckets/
drwxr-xr-x  6 nova nova 4096 Jan  6 17:15 CA/
drwxr-xr-x  2 nova nova 4096 May 15  2014 images/
drwxr-xr-x  6 nova root 4096 Jan 20 17:06 instances/
drwxr-xr-x  2 nova nova 4096 May 15  2014 keys/
drwxr-xr-x  2 nova nova 4096 May 15  2014 networks/
drwxr-xr-x  2 nova nova 4096 May 15  2014 tmp/

before : #listen_tls = 0
after : listen_tls = 0
before : #listen_tcp = 1
after : listen_tcp = 1
add: auth_tcp = "none" 

修复BUG

要实现block migration首先得修复这个bug,方法在这里,或者实例采用没有设置Root Disk和Ephemeral Disk大小的flavor。我查看了源文件在nova-2012.1.2中这个bug已经修复,但是我我进行的仍然是后一种。

三、测试迁移

把compute1的虚拟机迁移到compue2上,先看compute1上有哪些虚拟机

# nova-manage vm list | grep compute_one | awk '{print $1}'

root@controller:~# nova-manage vm list
instance   node            type       state      launched                   image     kernel    ramdisk    project    user       zone       index
vm001      compute2        m1.tiny    active     2015-01-20 08:30:21        a1de861a-be9c-4223-9a7a-cf5917489ce9                     60a10cd7a61b493d910eabd353c07567 be1db0d2fd134025accd2654cfc66056 nova       0    
vm002      compute1        m1.tiny    active     2015-01-20 08:55:02        a1de861a-be9c-4223-9a7a-cf5917489ce9                     60a10cd7a61b493d910eabd353c07567 be1db0d2fd134025accd2654cfc66056 nova       0    
root@controller:~#  nova-manage vm list |grep compute1 |awk '{print $1}'
vm002

要查看需要迁移的实例vm001实例的名字

root@controller:~# nova show 190364a5-a5a7-4e5d-8f46-6c43fb5c3446
+--------------------------------------+------------------------------------------------------------+
| Property                             | Value                                                      |
+--------------------------------------+------------------------------------------------------------+
| OS-DCF:diskConfig                    | AUTO                                                       |
| OS-EXT-AZ:availability_zone          | nova                                                       |
| OS-EXT-SRV-ATTR:host                 | compute1                                                   |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | compute1                                                   |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000036                                          |
| OS-EXT-STS:power_state               | 1                                                          |
| OS-EXT-STS:task_state                | -                                                          |
| OS-EXT-STS:vm_state                  | active                                                     |
| OS-SRV-USG:launched_at               | 2015-01-20T08:55:02.000000                                 |
| OS-SRV-USG:terminated_at             | -                                                          |
| accessIPv4                           |                                                            |
| accessIPv6                           |                                                            |
| config_drive                         |                                                            |
| created                              | 2015-01-20T08:54:04Z                                       |
| flavor                               | m1.tiny (1)                                                |
| hostId                               | af2b0609eb984606e572ddc5135b10b0d992dc73a5f9cc581f01baec   |
| id                                   | 190364a5-a5a7-4e5d-8f46-6c43fb5c3446                       |
| image                                | cirros-0.3.2-x86_64 (a1de861a-be9c-4223-9a7a-cf5917489ce9) |
| key_name                             | -                                                          |
| metadata                             | {}                                                         |
| name                                 | vm002                                                      |
| os-extended-volumes:volumes_attached | []                                                         |
| progress                             | 0                                                          |
| security_groups                      | default                                                    |
| status                               | ACTIVE                                                     |
| tenantA-Net network                  | 10.0.0.29, 10.1.101.83                                     |
| tenant_id                            | 60a10cd7a61b493d910eabd353c07567                           |
| updated                              | 2015-01-20T08:55:03Z                                       |
| user_id                              | be1db0d2fd134025accd2654cfc66056                           |
+--------------------------------------+------------------------------------------------------------+
root@controller:~# nova show 190364a5-a5a7-4e5d-8f46-6c43fb5c3446 |grep instance_name
| OS-EXT-SRV-ATTR:instance_name        | instance-00000036                                          |
root@controller:~# nova show 190364a5-a5a7-4e5d-8f46-6c43fb5c3446 |grep instance_name | awk '{print $4}'
instance-00000036

 控制节点执行:

root@controller:~# nova-manage host list
host                            zone                
controller                      internal       
compute1                        nova           
compute2                        nova   

 查看可用的计算节点:

root@controller:~# nova-manage service list
Binary           Host                                 Zone             Status     State Updated_At
nova-cert        controller                           internal         enabled    :-)   2015-01-20 08:57:09
nova-consoleauth controller                           internal         enabled    :-)   2015-01-20 08:57:10
nova-scheduler   controller                           internal         enabled    :-)   2015-01-20 08:57:11
nova-conductor   controller                           internal         enabled    :-)   2015-01-20 08:57:08
nova-compute     compute1                             nova             enabled    :-)   2015-01-20 08:57:13
nova-compute     compute2                             nova             enabled    :-)   2015-01-20 08:57:05
nova-compute     controller                           nova             enabled    XXX   2015-01-19 06:52:42

查看目标节点资源:

root@controller:~# nova-manage service describe_resource compute2
HOST                              PROJECT     cpu mem(mb)     hdd
compute2        (total)                         2    2997      18
compute2        (used_now)                      1    1024       1
compute2        (used_max)                      1     512       1
compute2                 60a10cd7a61b493d910eabd353c07567       1     512       1

迁移成功,没有输出

root@controller:~# nova live-migration 190364a5-a5a7-4e5d-8f46-6c43fb5c3446 compute2
root@controller:~# 

 迁移成功,再看虚拟机vm002运行在了compute2节点

root@controller:~# nova-manage vm list
instance   node            type       state      launched                   image     kernel    ramdisk    project    user       zone       index
vm001      compute2        m1.tiny    active     2015-01-20 08:30:21        a1de861a-be9c-4223-9a7a-cf5917489ce9                     60a10cd7a61b493d910eabd353c07567 be1db0d2fd134025accd2654cfc66056 nova       0    
vm002      compute2        m1.tiny    active     2015-01-20 08:55:02        a1de861a-be9c-4223-9a7a-cf5917489ce9                     60a10cd7a61b493d910eabd353c07567 be1db0d2fd134025accd2654cfc66056 nova       0

澳门皇冠金沙网站 2

澳门皇冠金沙网站 3

6.重启计算节点上nova

参考文档:

3、在compute和comput1两个计算节点挂载NFS目录

Note:

a、挂载点必须是nova.conf配置文件中state_path=/var/lib/nova指定的目录,两个计算节点目录必须一致。

b、建议在配置前先删除计算节点的所有实例,不然会造成僵尸实例的产生。

确保计算节点有执行和查找目录的权限:

chmod o+x /var/lib/nova/instances

安装nfs服务

#  apt-get install nfs-kernel-server nfs-common 

开机自动挂载:

root@compute1:/var/log/libvirt/qemu# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid 0       0
# / was on /dev/xvda1 during installation
UUID=0c681b37-97ed-4d10-bd79-8d5931c443f8 /               ext4    errors=remount-ro 0       1
# swap was on /dev/xvda5 during installation
UUID=9e2efc1b-ef13-4b7c-b616-34d2a62f04ea none            swap    sw              0       0
10.1.101.11:/var/nfs-storage  /var/lib/nova/instances nfs  defaults 0 0 

root@compute1:/var/log/libvirt/qemu# mount -a
root@compute1:~# df -k
Filesystem                   1K-blocks    Used Available Use% Mounted on
/dev/xvda1                    19478204 2754448  15711276  15% /
udev                           2530276       4   2530272   1% /dev
tmpfs                           512512     224    512288   1% /run
none                              5120       0      5120   0% /run/lock
none                           2562556       0   2562556   0% /run/shm
cgroup                         2562556       0   2562556   0% /sys/fs/cgroup
10.1.101.11:/var/nfs-storage  19478528 3164672  15301632  18% /var/lib/nova/instances

2.qemu1.4的一个bug导致迁移失败

一、配置共享存储

1.尝试不用修改nova.conf里的vncserver_listen参数为0.0.0.0,

OpenStack迁移需要将虚拟机创建运行在共享存储上才可以进行迁移。

将/var/run/log/libvirt/qemu/instances--xxx.log里的vnc改成目的节点的ip,重启libvritd,然后进行迁移,可以成功,但如果迁移失败,当需要重新虚机的时候,虚机启动失败,在/var/log/libvrit/qemu/instances-xx.log的错误是
Failed to start VNC server on `172.18.2.15:0': Failed to bind socket: Cannot assign requested address
而/mnt/instances/instance--xxx/libvirt.xml里没有修改成目的节点的Ip。不知道这个参数被保存到了哪里

一直想和大家分享虚拟机的在线迁移,考虑到稳定性,我们在线上运行了几个月比较稳定后,再总结出来和大家分享。

openstack认为在CentOS上磁盘cache mod为writethrough时,迁移是不安全的。
解决的办法 :在nova.conf live_migration_flag参数后面增加VIR_MIGRATE_UNSAFE,官方在线迁移配置文件里没有这个参数。

1.修改Nova.conf文件

大致描述一下场景:系统采用了计算存储松耦合结构,虚机的映像文件在远端共享存储上,所以迁移起来速度很快。在我们系统中,最快一个用了6秒,即完成了在线迁移,这是真正的live migration,我们一边迁移,一边故意在虚机里写数据,也正常完成。

虚拟机的迁移是指在源物理主机上运行的虚拟机操作系统及应用程序移动到目标物理主机上或虚拟机上,并且在目标主机上能够正常运行。在openstack中,openstack自带虚拟机的迁移功能,允许一个正在running的虚拟机实例从一个compute node迁移到另一个compute node。下面给大家推荐一篇相关的实战案例,作者是用友公有云技术总监,中国计算机学会高级会员,大数据专委会委员,前中科院副研究员。

遇到的问题和解决办法

迁移失败,在目的节点上/var/log/libvrit/qemu/instances--xxxx.log里:
char device redirected to /dev/pts/1 (label charserial1)
qemu: warning: error while loading state section id 2
load of migration failed
解决办法:
1.在源计算节点上修改要迁移虚机的/var/run/libvirt/qemu/instance–xxx.xml文中删除migrate-qemu-fd这一行
2.重启源计算节点上的libvirtd
3.然后再执行nova live-migration命令
这个操作已经编写了一个程序自动执行。

添加:
image_cache_manager_interval=0
live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE,VIR_MIGRATE_UNSAFE
修改:
vncserver_listen=0.0.0.0

before :# LIBVIRTD_ARGS="--listen"
after :LIBVIRTD_ARGS="–listen"

编辑:互联网科技 本文来源:OpenStack在线迁移

关键词: