《转》OpenStack Live Migration
This post is based assumption that KVM as hypervisor, and Openstack is running in Grizzly on top of RHEL6.4.
Openstack VM live migration can have 3 categories:
-Block live migration without shared storage
-Shared storage based live migration
-Volume backed VM live migration
Block live migration
Block live migration does not require shared storage among nova-compute nodes, it uses network(TCP) to copy VM disk from source host to destination host, thus it takes longer time to complete than shared storage based live migration. Also during migration,
host performance will be degraded in network and CPU points of view.
To enable block live migration, we need to change libvirtd and nova.conf configurations on every nova-compute hosts:
->Edit /etc/libvirt/libvirtd.conf
listen_tls = 0
listen_tcp = 1
auth_tcp = "none"
->Edit /etc/sysconfig/libvirtd
LIBVIRTD_ARGS="–listen"
->Restart libvirtd
service libvirtd restart
->Edit /etc/nova/nova.conf, add following line:
live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE
|
|
Adding this line is to ask nova-compute to utilize libvirt's true live migration function. By default Migrations done by the nova-compute does not use libvirt's live migration functionality, |
>Restart nova-compute service
service openstack-nova-compute restart
->Check running VMs
nova list
+--------------------------------------+-------------------+--------+---------------------+
| ID | Name | Status | Networks |
+--------------------------------------+-------------------+--------+---------------------+
| 5374577e-7417-4add-b23f-06de3b42c410 | vm-live-migration | ACTIVE | ncep-net=10.20.20.3 |
+--------------------------------------+-------------------+--------+---------------------+
->Check which host the VM in running on
nova show vm-live-migration
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2013-08-06T08:47:13Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-1 |
->Check all available hosts
nova host-list
+--------------+-------------+----------+
| host_name | service | zone |
+--------------+-------------+----------+
| compute-1 | compute | nova |
| compute-2 | compute | nova |
>Let's migrate the vm to host compute-2
nova live-migration --block-migrate vm-live-migration compute-2
>Later when we check vm status again, we cloud see the host changes to compute-2
nova show vm-live-migration
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2013-08-06T09:45:33Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-2 |
>We can just do a migration without specifying destination host, nova-scheduler will choose a free host for you
nova live-migration --block-migrate vm-live-migration
|
|
Block live migration seems a good solution if we don't have/want shared storage , but we still want to do some host level maintenance work without bring downtime to running VMs. |
Shared storage based live migration
This example we use GlusterFS as shared storage for nova-compute nodes. Since VM disk is stored on shared storage, hence live migration much much more faster than block live migration.
1.Setup GlusterFS cluster for nova-compute nodes
->Prepare 4 nodes, each node has an extra disk other than OS disk, dedicated for GlusterFS cluster
Node 1: 10.68.124.18 /dev/sdb 1TB
Node 2: 10.68.124.19 /dev/sdb 1TB
Node 3: 10.68.124.20 /dev/sdb 1TB
Node 4: 10.68.124.21 /dev/sdb 1TB
->Configure Node 1-4
yum install -y xfsprogs.x86_64
mkfs.xfs -f -i size=512 /dev/sdb
mkdir /brick1
echo "/dev/sdb /brick1 xfs defaults 1 2" >> /etc/fstab 1014 cat /etc/fstab
mount -a && mount
mkdir /brick1/sdb
yum install glusterfs-fuse glusterfs-server
/etc/init.d/glusterd start
chkconfig glusterd on
->On Node-1, add peers
gluster peer probe 10.68.125.19
gluster peer probe 10.68.125.20
gluster peer probe 10.68.125.21
->On node-1, create a volume for nova-compute
gluster volume create nova-gluster-vol replica 2 10.68.125.18:/brick1/sdb 10.68.125.19:/brick1/sdb 10.68.125.20:/brick1/sdb 10.68.125.21:/brick1/sdb
gluster volume start nova-gluster-vol
->We can check the volume information
gluster volume info
Volume Name: nova-gluster-vol
Type: Distributed-Replicate
Status: Started
Number of Bricks: 2 x 2 = 4
Transport-type: tcp
Bricks:
Brick1: 10.68.125.18:/brick1/sdb
Brick2: 10.68.125.19:/brick1/sdb
Brick3: 10.68.125.20:/brick1/sdb
Brick4: 10.68.125.21:/brick1/sdb
->On each nova-compute node, mount the GluserFS volume to /var/lib/nova/instances
yum install glusterfs-fuse
mount.glusterfs 10.68.125.18:/nova-gluster-vol /var/lib/nova/instances
echo "10.68.125.18:/nova-gluster-vol /var/lib/nova/instances glusterfs defaults 1 2" >> /etc/fstab
chown -R nova:nova /var/lib/nova/instances
2.Configure libvirt and nova.conf on every nova-compute node
->Edit /etc/libvirt/libvirtd.conf
listen_tls = 0
listen_tcp = 1
auth_tcp = "none"
->Edit /etc/sysconfig/libvirtd
LIBVIRTD_ARGS="–listen"
->Restart libvirtd
service libvirtd restart
->Edit /etc/nova/nova.conf, add following line:
live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE
3.Let's try live migration
->Check running VMs
nova list
+--------------------------------------+-------------------+--------+---------------------+
| ID | Name | Status | Networks |
+--------------------------------------+-------------------+--------+---------------------+
| 5374577e-7417-4add-b23f-06de3b42c410 | vm-live-migration | ACTIVE | ncep-net=10.20.20.3 |
+--------------------------------------+-------------------+--------+---------------------+
->Check which host the VM in running on
nova show vm-live-migration
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2013-08-06T08:47:13Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-1 |
->Check all available hosts
nova host-list
+--------------+-------------+----------+
| host_name | service | zone |
+--------------+-------------+----------+
| compute-1 | compute | nova |
| compute-2 | compute | nova |
>Let's migrate the vm to host compute-2
nova live-migration vm-live-migration compute-2
>Migration should be finished in seconds, let's check vm status again, we cloud see the host changes to compute-2
nova show vm-live-migration
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2013-08-06T09:45:33Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-2 |
>We can just do a migration without specifying destination host, nova-scheduler will choose a free host for us
nova live-migration vm-live-migration
3.Volume backed VM live migration
VMs booted from volume can be also easily and quickly migrated just like shared storage based live migration since both cases VM disks are on top of shared storages.
->Create a bootable volume from an existing image
cinder create --image-id --display-name bootable-vol-rhel6.3 5
->Launch a VM from the bootable volume
nova boot --image --flavor m1.medium --block_device_mapping vda=:::0 vm-boot-from-vol
->Check which host the VM is running on
nova show vm-boot-from-vol
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2013-08-06T10:29:09Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-1 |
->Do live migration
nova live-migration vm-boot-from-vol
->Check VM status again
nova show vm-boot-from-vol
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2013-08-06T10:30:55Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-2 |
VM recovery from failed compute node
If shared storage used, or for VMs booted from volume, we can recovery them if their compute host is failed.
>Launch 1 normal VM and 1 volume backed VM, make they are all running on compute1 node. ( Use live migration if they are not on compute-1)
nova show vm-live-migration
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2013-08-06T10:36:35Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-1 |
nova show vm-boot-from-vol
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2013-08-06T10:31:21Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-1 |
->Shutdown compute-1 node
[root@compute-1 ~]# shutdown now
->Check VM status
nova list
+--------------------------------------+-------------------+---------+---------------------+
| ID | Name | Status | Networks |
+--------------------------------------+-------------------+---------+---------------------+
| 75ddb4f6-9831-4d90-b291-48e098e8f72f | vm-boot-from-vol | SHUTOFF | ncep-net=10.20.20.5 |
| 5374577e-7417-4add-b23f-06de3b42c410 | vm-live-migration | SHUTOFF | ncep-net=10.20.20.3 |
+--------------------------------------+-------------------+---------+---------------------+
Both VMs get into "SHUTOFF" status.
>Recovery them to compute-2 node
nova evacuate vm-boot-from-vol compute-2 --on-shared-storage
nova evacuate vm-live-migration compute-2 --on-shared-storage
->Check VM status
nova show vm-boot-from-vol
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | SHUTOFF |
| updated | 2013-08-06T10:42:32Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-2 |
nova show vm-live-migration
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | SHUTOFF |
| updated | 2013-08-06T10:42:51Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-2 |
Both VMs are managed by compute-2 now
-> Reboot 2 VMs
nova reboot vm-boot-from-vol
nova reboot vm-live-migration
-> Check VMs list
nova list
+--------------------------------------+-------------------+--------+---------------------+
| ID | Name | Status | Networks |
+--------------------------------------+-------------------+--------+---------------------+
| 75ddb4f6-9831-4d90-b291-48e098e8f72f | vm-boot-from-vol | ACTIVE | ncep-net=10.20.20.5 |
| 5374577e-7417-4add-b23f-06de3b42c410 | vm-live-migration | ACTIVE | ncep-net=10.20.20.3 |
+--------------------------------------+-------------------+--------+---------------------+
Both VMs are back to ACTIVE.
Notes
Currently Openstack has no mechanism to detect host and VM failure and automatically to recover/migrate VM to health host, this reply on 3rd party means to do so
There's also an interesting project named openstack-neat, which is intended to provide an extension to OpenStack implementing dynamic consolidation of Virtual Machines
(VMs) using live migration. The major objective of dynamic VM consolidation is to improve the utilization of physical resources and reduce energy consumption by re-allocating VMs using live migration according to their real-time resource demand and switching
idle hosts to the sleep mode. This really like vSphere DRS function.
Project website: http://openstack-neat.org
《转》OpenStack Live Migration的更多相关文章
- openstack live migration性能分析
http://blog.zhaw.ch/icclab/an-analysis-of-the-performance-of-live-migration-in-openstack/ http://blo ...
- OpenStack Live Migration
About live migration of KVM virtual machines with NFS storage, from Mirantis blog: click this link w ...
- OpenStack nova VM migration (live and cold) call flow
OpenStack nova compute supports two flavors of Virtual Machine (VM) migration: Cold migration -- mig ...
- Migration workstation vms to openstack kvm
Migration workstation vms to openstack kvm 分别分成(磁盘是否拆分,vms 是否 有多个磁盘驱动器) 1, linux迁移 vmware workstatio ...
- Openstack虚拟机在线迁移(Live Migration)
Openstack VM live migration can have 3 categories: -Block live migration without shared storage -Sha ...
- Setting up multi nodes live migration in Openstack Juno with devstack
Setting up multi nodes live migration in Openstack Juno with devstack Summary Live migration overvie ...
- migration vmware vms to openstack kvm 修改vmware windows scsi to ide
- vmware vms migration to openstack
Converting a VMware Workstation virtual machine to KVM Leave a commentPosted by rbgeek on August 13, ...
- VMware migration to openstack kvm
随机推荐
- JProtector java应用加密工具
JProtector 专业的java项目加密工具 JProtector简介: JProtector 专业的java项目加密工具.目前java开发的项目发布的时候需要将项目发布到用户手中,但由于一 ...
- 单实例支撑每天上亿个请求的SSDB
SSDB 是一个 C++ 开发的 NoSQL 存储服务器, 支持 zset, map 数据结构, 可替代 Redis, 特别适合存储集合数据. SSDB 被开发和开源出来后, 已经在生产环境经受了3个 ...
- 评侯捷的<深入浅出MFC>和李久进的<MFC深入浅出>
侯捷的<深入浅出mfc>相信大家都已经很熟悉了,论坛上也有很多介绍,这里我就不多说了. 而李久进的<mfc深入浅出>,听说的人可能就少得多.原因听说是这本书当时没有怎么宣传,而 ...
- Android 自动编译、打包生成apk文件 4 - 多渠道批量打包
相关文章列表: < Android 自动编译.打包生成apk文件 1 - 命令行方式> < Android 自动编译.打包生成apk文件 2 - 使用原生Ant方式 > < ...
- 我的Python成长之路---第一天---Python基础(3)---2015年12月26日(雾霾)
四.变量和常量 变量是用来存储程序运行期间需要临时保存可以不断改变的数据的标识符.Python有自身的内存回收机制,所以在开发过程中不用考虑变量的销毁等 Python中的变量名命名有如下规则: 1.变 ...
- fg、bg、jobs、&、nohup、ctrl + z命令
fg.bg.jobs.&.nohup.ctrl + z命令 一.& 加在一个命令的最后,可以把这个命令放到后台执行,如gftp &, 二.ctrl + z 可以将一个正在前台执 ...
- SQL 根据时间和打印状态抽取记录
1.首先要是没有打印的记录. 2.其次是要按照时间,时间是要按照倒序排列. 下载文件的URL and order by 上传时间 desc *是否打印,使用字段bit,0是没有打印,1是已经打印
- excel通过转成xml格式模板,下载成excel文件
源代码: report ztest_down_excel. data: begin of i_file occurs , val() type c, end of i_file. data begin ...
- qingshow “不积跬步无以至千里,不积小流无以成江海”。--荀子《劝学篇》 用tomcat+花生壳搭建自己的web服务器+域名(参考)
链接地址:http://www.blogjava.net/qingshow/archive/2010/01/17/309846.html 用tomcat搭建web服务器 目标:免费拥有自己的网站及域名 ...
- Cocos2dx系列笔记7:一个简单的跑酷游戏《萝莉快跑》的消化(附下载)
懒骨头(http://blog.csdn.com/iamlazybone) 或许有天 我们羡慕和崇拜的人 因为我们的努力 也会来了解我们 说不定 还会成为好友 骨头喜欢这样与哲哲共勉 多少个夜晚 一张 ...