《转》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
随机推荐
- bad interpreter: No such file or directory解决
执行shell脚本时出现bad interpreter: No such file or directory错误, 一般是因为linux无法识别出Windows的DOS格式,此时只需将文件格式转换成u ...
- (未解决)在JSTL中,session 和 sessionScope 有什么区别 ??
在JSP页面中,使用JSTL标签获取Session中的值并显示 为何当使用 ${session.user} 时,页面跳转后,第一次能够成功显示, 但是单击按钮重定向的时候,就获取不到了? 而使用 ${ ...
- 鹅厂揭秘——高端大气的App电量測试
怎样评价我们开发出来的应用是耗电还是不耗电,怎样測试?这就是我们今天讨论的主题--电量測试,一个在移动应用中新出现的測试类型. 作者简单介绍 watermark/2/text/aHR0cDovL2Js ...
- android 发送短信 怎样做到一条一条的发送,仅仅有在上一条发送成功之后才发送下一条短信
android发送短信截获上一条发送是否成功,然后再来发送下一条短信 1.问题:在项目中遇到例如以下要求:待发短信有N条,实现一条一条的发送并在上一条短信发送成功之后再来发送下一条. for(int ...
- 关于std::string
主要注意的一个问题是:std::string 实际是类似一个 vector<char>的结构. 它里面是可以存放 ascii为0 的字符不算结尾 (否则 unicode方式的编码存放就有问 ...
- [转]SELinux管理与配置
原文链接:http://blog.csdn.net/huangbiao86/article/details/6641893 1.1 SElinux概述 SELinux(Security-Enhance ...
- MYSQL中delete删除多表数据与删除关联数据
在mysql中删除数据方法有很多种,最常用的是使用delete来删除记录,下面我来介绍delete删除单条记 录与删除多表关联数据的一些简单实例. 1.delete from t1 where 条件 ...
- oralce 简单错误汇集。。。。。
1.ora-12560 TNS:协议适配器错误 实例名被错误修改或者oracle 服务没有正常启动.
- PHP - 类库
常用的PHP类库,PHP开发者必备[转] PHP开发者常用的PHP类库和组件 PDF 生成器 FPDF - 这量一个可以让你生成PDF的纯PHP类库. Excel 相关 你的站点需要生成Excel?没 ...
- ssh登录的时候,根本不给输入密码的机会,直接拒绝,是因为BatchMode的设置
BatchMode no“BatchMode”如果设为“yes”,passphrase/password(交互式输入口令)的提示将被禁止.当不能交互式输入口令的时候,这个选项对脚本文件和批处理任务十分 ...