他的最新文章
他的热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)他的最新文章
他的热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)虚拟机在 OpenStack 里没有共享存储条件下的在线迁移
本文尝试回答与 Live migration 相关的几个问题：Live migration 是什么？为什么要做 Live migration？如何做 Live migration？如果你读完本文，基本了解了这三个问题的答案， 这篇文章的主要目的也就达到了。由于本文介绍的是 OpenStack 平台上动态迁移的实现，所以读者必须对 OpenStack 有一定的了解。虚拟机迁移简介动态迁移包括两方面的意思，一是迁移(Migration)，迁移就是把用户的虚拟机从一台物理主机移到另外一台物理主机。二是动态，动态的意思就是在迁移的过程中，(1):虚拟机还开着机；(2):虚拟机的网路也不受影响；(3):而且上面的运行的用户程序依旧运行。整个过程对用户来说是透明的，对用户可以正常使用迁移途中的虚拟机。OpenStack 支持两种类型的虚拟机迁移：冷迁移(Cold migration)-
冷迁移也叫静态迁移。在迁移过程中虚拟机必须关机，用户也不能访问虚拟机。因为要关机，所以他适用于用户对系统可用性要求不是很高的时候。热迁移(Hot or live migration)-
热迁移也叫动态迁移。在迁移的过程中虚拟机仍旧工作，用户可以继续使用虚拟机。本文就介绍的就是这种类型的迁移。热迁移又分为下面二种类型： (1):虚拟机的数据存在共享磁盘上(Shared storage-based live migration),如图 1 所
示。图 1(2):虚拟机的数据存在本地磁盘(block migration)，如图 2 所示，需要对镜像文件和内存数据同时迁移。OpenStack 通过块迁移实现这这类迁移。图 2虚拟机迁移的作用每个读者都可能会问这样一个问题，虚拟机用的好好的，为啥要迁移呀？也就是迁移的价值和目的在哪里。在数据中心的日常运维中，常常要处理下面几种场景和需求，了解了这些需求，这个问题也就有了答案。需求 1：物理机器硬件系统的维护，故障修复和升级(upgrade)，但运行在这台物理机器上的虚拟机不能关机，因为用户重要的服务跑在上面。需求 2：物理机器软件系统升级，打补丁(patch)，为了不影响上面跑的虚拟机，在升级和打补丁之前，需要把虚拟机迁移到别的物理机器上。需求 3：一个物理机器上的负载太重，需要减少一些虚拟机来释放资源。需求 4：在一个 cluster 里，有的物理机上的虚拟机太多，有的物理机上虚拟机太少，需要做一下资源平衡。除了上面四个主要的需求，从服务的角度来看，Live migration 有下面两个好处：
好处 1：软件和硬件系统的维护升级，不会影响用户的关键服务，提高了服务的高可用性和 用户的满意度。好处 2：系统管理员不用加班加点，在大半夜进行系统升级了，在正常的工作时间就可以完成这项工作，减少了公司的维护费用。有这四个需求和两个好处，所以动态迁移值得一作。动态迁移方法和实现本章详细介绍在 OpenStack 里如何实现动态迁移。在第一节里，提到了有两种类型的动态迁移，本文只介绍图 2 所示的虚拟机的数据存在本地磁盘(block migration)的动态迁移。动态迁移的条件动态迁移是把虚拟机从一个物理主机迁移到另外一个物理主机，所以至少需要有两个物理主机作为计算节点。下面是一个最小的 OpenStack 配置。 三个物理主机，一个用来做 OpenStack 的控制节点，两个用来做计算节点。如图 3 所示。图 3控制节点接受并处理动态迁移的请求，管理员可以从 Horizon、命令行、API 发起动态迁移。 动态迁移就是把客户的 VM 从计算节点 1 迁移到计算节点 2，或者从计算节点 2 迁移到计算节点 1，如图 4 所示。图 4
计算节点上的 Hypervisor 是 KVM，操作系统是 redhat6.5，OpenStack 是 Juno。计算节点 1 和 2 上的虚拟机分别存储在本地文件系统，如图 2 所示。上面提到的 Hypervisor 和 KVM 相关概念，以及 OpenStack 各个模块的详细介绍，您可以阅读参考资料里文档，这里不在做介绍。动态迁移的实现本节分别从基本概念、传输协议和迁移的步骤三个方面介绍动态迁移是如何实现的。基本概念在了解动态迁移之前，必须了解镜像文件的格式 QCOW2。Qcow2 是 QEMU 目前推荐的镜像格式，它支持稀疏文件以节省存储空间，支持加密以提高镜像文件的安全性，支持基于
zlib 的压缩。Qcow2
镜像可以用来保存另一个镜像文件的变化，它并不去修改原始镜像文件，原始镜像文件也叫后端镜像(backing_file)。只记录与原始镜像文件的不同部分的镜像文件，这种镜像文件就叫做
copy-on-write 镜像，它虽然是一个单独的镜像文件，但它的大部分数据都来自原始镜像，只有基于原始镜像文件的增量部分才会被记录下来。本文提及的虚拟机都是
OpenStack 用 Qcow2 格式的镜像文件建立的，如图 5 所示，包含两部分。
后端镜像(libvirt base)
虚拟机单独的增量镜像文件(libvirt instance disks)，copy-on-write 镜像图 5
在物理机的磁盘上，当我们建了一个虚拟机后，就会生成如图 6 列的这些文件。其中_base 下面的文件，就是后端镜像(libvirt base)，目录
6eb5-4fdc-2daab39 下面是虚拟机单独的增量镜像文件(libvirt instance disks)，它只记录和 base 文件不同的内容。图 6用 qemu-img 查看虚拟机单独的增量镜像文件的信息，我们可以看到他的 backing file 是_base 目录下的镜像文件，如图 7 所示。图 7
费了这么多篇幅介绍 QCOW2，您会奇怪，目的何在？其实上面介绍的后端镜像(libvirt Base)，虚拟机单独的增量镜像文件(libvirt instance
disks)，它们就是要被迁移的数据。动态迁移的最终目标就是把它们完整地从源物理主机迁移到目标物理主机。除了他们两个之外，还有一个需要迁移的对象就是内存里运行的虚拟机的数据。总结一下：虚拟机的迁移，其实就是数据的转移，因为计算节点之间没有共享存储，所以要转移的数据包括两部分：静态数据：存储在本地的虚拟机的镜像文件，包括后端镜像(libvirt Base)和虚拟机单独的增量镜像文件(libvirt instance disks)。动态数据：内存里虚拟机的运行时数据，内存里的数据是动态变化的数据，虚拟机里运行的负载的大小直接影响迁移的时间长短。迁移通道和传输协议OpenStack 调用底层的 libvirt 来完成动态迁移。虚拟机的迁移，其实就是数据的转移。libvirt 提供了隧道化的数据传输（libvirt tunnelled transport）方式来完成数据转移。如图 8 所示。图 8数据的转移就涉及数据的传输，数据的传输需要通过网络，本文介绍使用 TCP 网路协议完实现动态迁移。Libvirt 默认情况下不支持 TCP 协议，需要对 libvirt 的配置做修改，使 libvirt 能够支持 TCP 协议，后面的章节会详细的介绍如何配置。
在迁移的过程中，运行在目的物理主机（Dest Host）中的 libvirtd 进程要根据 address 和 port 创建一个 URI，URI 是目的物理主机用来接收数据和发回数据到源物理主机（Source Host）的 libvirtd 进程的，如图 9。图 9
在目的物理主机和源物理主机，只要下面的命令能够执行，就说明能够传输数据了。在 compute01 上执行：[root@compute01]# virsh -c qemu+tcp://nova@compute02/system在 compute02 上执行：[root@compute01]# virsh -c qemu+tcp://nova@compute02/system如下例所示在 compute01 上执行 virsh 命令，如果有图 10 所示的输出，就说明传输通道正常。图 10迁移的步骤
迁移的基本概念弄清楚了，下面我们继续介绍迁移的步骤。OpenStack 做动态迁移一个正常的流程主要包括四部分：迁移前的条件检查、迁移前的预处理、迁移、迁移后的处理。迁移前的条件检查动态迁移要成功执行，一些条件必须满足，所以在执行迁移前必须做一些条件检查。权限检查，执行迁移的用户是否有足够的权限执行动态迁移。参数检查，传递给 API 的参数是否足够和正确，如是否指定了 block-migrate 参数。检查目标物理主机是否存在。检查被迁移的虚拟机是否是 running 状态。检查源和目的物理主机上的 nova-compute service 是否正常运行。检查目的物理主机和源物理主机是否是同一台机器。检查目的物理主机是否有足够的内存(memory)。检查目的和源物理主机器 hypervisor 和 hypervisor 的版本是否相同。迁移前的预处理
在真正执行迁移前，必须做一下热身，做一些准备工作。
在目的物理主机上获得和准备虚拟机挂载的块设备(volume)。 在目的物理主机上设置虚拟机的网络(networks)。目的物理主机上设置虚拟机的防火墙(fireware)。
迁移条件满足并且做完了预处理工作后，就可以执行动态迁移了。主要步骤如下：调用 libvirt python 接口 migrateToURI，来把源主机迁移到目的主机。
dom.migrateToURI(CONF.live_migration_uri % dest,logical_sum,None,CONF.live_migration_bandwidth)
live_migration_uri：这个 URI 就是在 3.2.2 里介绍的 libvirtd 进程定义的。live_migration_bandwidth：这个参数定义了迁移过程中所使用的最大的带宽。以一定的时间间隔（0.5）循环调用 wait_for_live_migration 方法，来检测虚拟机迁移
的状态，一直到虚拟机成功迁移为止。迁移后的处理当虚拟机迁移完成后，要做一些善后工作。在源物理主机上 detach volume。在源物理主机上释放 security group ingress rule。在目的物理主机上更新数据库里虚拟机的状态。在源物理主机上删除虚拟机。上面四步正常完成后，虚拟机就成功的从源物理主机成功地迁移到了目的物理主机了。系统管理员就可以执行第二章所列的哪些管理任务了。动态迁移的配置
本节列出了支持动态迁移的配置，必须确保所有物理主机上配置真确，动态迁移才能成功完成。Libvirtlibvirt 默认情况下支持远程连接的 TLS 协议，不支持 TCP 协议，因此将 listen_tls=0 listen_tcp=1 使 libvirt 能够支持 TCP 协议。
修改/etc/sysconfig/libvirtd 文件。
LIBVIRTD_ARGS="--listen"
在/etc/libvirt/libvirtd.conf 文件中做如下配置。
listen_tls=0
listen_tcp=1
auth_tcp="none"重启 libvirtd 服务物理主机上 DNS配置每个物理主机上的/etc/host，加入每个物理主机的 hostname 和 IP，如下例：192.168.0.1
compute-1.ibm.com
192.168.0.2
compute-2.ibm.com防火墙配置/etc/sysconfig/iptables，打开 TCP 端口 16509。-A INPUT -p tcp -m multiport --ports 16509 -m comment --comment "libvirt" -j ACCEPTOpenStack Nova在/etc/nova/nova.conf 文件里配置 live_migration 标记。live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE动态迁移的实例本节通过下面的例子来演示如何做动态迁移。这个例子的目标就是把虚拟机从 tor01kvm001ccz048 迁移到 tor01kvm002ccz048。如图 11 所示。图 11在 tor01kvm001ccz048 上建一个虚拟机 lm001，如图 12 所示。#nova boot lm001 --image "Red Hat Enterprise Linux 6.5 x86_64" --flavor Standard_1_2 --availability-zone nova:tor01kvm001ccz048 --nic net-id=88ce4c1a--861d-ba4b3dbaa6a3图 12检查虚拟机 lm001 建在了 tor01kvm001ccz048 上，如图 13 所示。图 13执行动态迁移#nova live-migration --block-migrate lm001 tor01kvm002ccz048
我们可以看到虚拟机的 Task State 变成了 migrating 状态，如图 14 所示。图 14检查迁移的结果通过 nova show 命令，可以看到 lm001 已经成功迁移到了 tor01kvm002ccz048，如图 15 所示。图 15总结
从前面的介绍我们可以看出，即使没有共享存储，我们也可以对虚拟机实现无中断的动态迁移，不过所有的计算节点之间需要快的网路支持。另外还需要注意两点：本文使用的是没有没有加密的 TCP/IP socket，所以在生产环境不推荐使用，除非是在一个安全可信的网路里执行动态迁移。在迁移的过程中，虚拟机会有 downtime。详细的信息，可以阅读参考资料里的块迁移的性能报告。
相关主题，了解 OpenStack 关于块迁移的详细的配置和方法步骤。
，了解 Libvirt 里关于块迁移的实现原理，详细的配置步骤。
，了解块迁移的性能测试报告和方法。
，了解 OpenStack 支持的 Image 的格式和类型。
提供了有关云计算的更新资源，包括
云计算 。更新的 ，让您的开发变得轻松， 帮助您成为高效的云开发人员。连接转为云计算设计的 。关于
的活动聚合。
添加或订阅评论，请先或。
有新评论时提醒我
static.content.url=http://www.ibm.com/developerworks/js/artrating/SITE_ID=10Zone=Cloud computingArticleID=1012524ArticleTitle=虚拟机在 OpenStack 里没有共享存储条件下的在线迁移publish-date=前面提到过openstack环境部署及创建虚拟机的完整过程，然后有时候会发现创建的虚拟机规格太小，满足不了业务需求；亦或是虚拟机规格太大，容易造成资源浪费。于是就有了在线拉伸虚拟机规格的需求。所以，今天这里介绍下在openstack里创建vm后，怎么在线调整虚拟机(云主机)的大小？
注意一点：openstack的虚拟机在线调整大小的原理：其实就相当于做了一个云主机在不同宿主机(计算节点)之间的迁移，所以前提是至少需要有两个计算节点。如果是单机部署的openstack（即控制节点和计算节点都在一台机器上），有且只有一个计算节点，那么是无法完成在线调整虚拟机大小的。
同时要注意的是：要在相关迁移云主机间进行无密码访问，由于OpenStack是由Nova组件来管理云主机，所以需要对Nova用户进行无密码访问。
如上图中的centos-004这台云主机的规格采用的是名为kvm001类型,即2核CPU、4G内容，现在需要将这台云主机的规格降为1核2G，即kvm002类型。操作流程如下：
1）修改控制节点和节点节点的nova.conf文件，添加下面两行内容：allow_resize_to_same_host=Truescheduler_default_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter
2）控制节点上重启nova相关服务[root@linux-node1 src]# systemctl restart openstack-nova-api.service openstack-nova-cert.service openstack-nova-consoleauth.service openstack-nova-scheduler.service openstack-nova-conductor.service openstack-nova-novncproxy.service
3）计算节点上重启nova服务[root@linux-node1 nova]# systemctl restart
openstack-nova-compute
4）nova账号的ssh双向认证关系
下面的操作在云主机所在计算节点和其他相关迁移云主机的计算节点上操作。要清楚的是：计算节点可能有多台，但是我们只需要在要调整大小的云主机所在的计算节点和其他的另外一台或多台计算几点上操作就行，并不是要求所有的计算节点都要操作（全部计算节点都操作也是可以的）
将nova账号的shell类型改为/bin/bash，即可以使用nova账号登陆[root@linux-node1 ~]# cat /etc/passwd|grep novanova:x:162:162:OpenStack Nova Daemons:/var/lib/nova:/bin/bash
然后在nova账号下产生公私钥[root@linux-node2 ~]# su - novaLast login: Thu Nov 17 17:32:54 CST 2016 from linux-node2.openstack on pts/11-bash-4.2$ ssh-keygen -t rsa
-bash-4.2$ pwd/var/lib/nova-bash-4.2$ cd .ssh/-bash-4.2$ lsid_rsa
id_rsa.pub
将id_rsa.pub拷贝为authorized_keys-bash-4.2$ cp id_rsa.pub authorized_keys
然后将id_rsa.pub公钥内容拷贝到其他相关迁移云主机的计算节点上的/var/lib/nova/.ssh/authorized_keys文件内，同时也要讲对方的公钥内容拷贝过来，做成双向信任关系(即双方在nova账号下ssh登陆时都不需要输入密码)同时，还要在各计算节点上做nova和root账号的双向信任关系。
修改权限[root@linux-node1 ~]# cd /var/lib/nova/.ssh/[root@linux-node1 .ssh]# lltotal 16-rw-------. 1 nova nova
816 Nov 17 17:32 authorized_keys-rw-------. 1 nova nova 1679 Nov 17 17:12 id_rsa-rw-r--r--. 1 nova nova
408 Nov 17 17:12 id_rsa.pub
修改sudo权限[root@linux-node1 ~]# visudo.....nova
NOPASSWD: ALL
最后测试nova账号间的信任连接，确认ssh无密码连接！
5）接下来登陆dashboard界面，在线调整云主机的大小：
&选择目标flavor&
点击确认修改尺寸&
待调整后，再查询虚拟机新的大小规格，就会发现已经更新了。&
阅读(...) 评论()查看: 72400|回复: 0
OpenStack实现热迁移(live-migration)
主题帖子积分
金牌会员, 积分 6962, 距离下一级还需 3038 积分
金牌会员, 积分 6962, 距离下一级还需 3038 积分
问题导读：
1、什么是热迁移 ？
2、OpenStack有哪两种在线迁移？
3、我们该怎么配置，实现迁移呢？
热迁移（Live Migration，又叫动态迁移、实时迁移），即虚拟机保存/恢复(Save/Restore)：将整个虚拟机的运行状态完整保存下来，同时可以快速的恢复到原有硬件平台甚至是不同硬件平台上。恢复以后，虚拟机仍旧平滑运行，用户不会察觉到任何差异。
openstack热迁移
OpenStack有两种在线迁移类型：live migration和block migration。Livemigration需要实例保存在NFS共享存储中，这种迁移主要是实例的内存状态的迁移，速度应该会很快。Block migration除了实例内存状态要迁移外，还得迁移磁盘文件，速度会慢些，但是它不要求实例存储在共享文件系统中。
* NFS允许一个系统在网络上与他人共享目录和文件。通过使用NFS，用户和程序可以像访问本地文件一样访问远端系统上的文件。
Live Migration 的实现
jovi-controller 是控制节点 192.168.3.10
jovi-compute1 是计算节点 192.168.3.12
jovi-compute3 是计算节点 192.168.3.14
实验阶段，为了避免不必要的麻烦，请用命令service ufw stop关闭各个节点的防火墙，同时修改/etc/hosts文件，确定节点之间能互相ping通主机名。利用id nova命令查看下控制节点nova的uid和gid，并记录，在两个计算节点同样利用id nova查看uid和gid是否和控制节点保持一致，如果不一致则利用usermod -u 控制节点的uid nova和gropumod -g 控制节点的gid nova 两条命令进行修改,同时在所有计算节点运行如下命令，保证所有nova相关文件使用新的uid和gid
[root@vmcom1-mn ~]#service nova-api stop
[root@vmcom1-mn ~]#service libvirt-bin stop
[root@vmcom1-mn ~]#find / -uid 106 -exec chown nova {} \; # note the 106 here is the old nova uid before the change
[root@vmcom1-mn ~]# find / -gid 107 -exec chgrp nova {} \; #note the 107 here is the old nova uid before the change
[root@vmcom1-mn ~]#service nova-api restart
[root@vmcom1-mn ~]#service libvirt-bin restart
2.修改各个节点的nova.conf
vncserver_proxyclient_address=本机ip
vncserver_listen=0.0.0.0
3.控制节点，配置nfs
apt-get install nfs-kernel-server portmap
在/etc/exports中加入/var/lib/nova/instances *(rw,sync,fsid=0,no_root_squash)
重新启动nfs服务,portmap服务
4.计算节点，配置nfs和挂载
apt-get install nfs-common portmap
chmod o+x /var/lib/nova/instances,确保节点有执行和查找目录的权限
在计算节点的/etc/fstab的目录中加入
控制节点ip:/var/lib/nova/instances /var/lib/nova/instances nfs defaults 0 0
挂载目录，执行
mount -a -v
df -k 查看已挂在目录，可以在最后看到远程控制节点的目录已被挂在
5.修改计算节点的相关的四个配置文件，可以手工如下修改
附修改脚本：
sed -i '/vncserver_proxyclient_address/d' /etc/nova/nova.conf
sed -i '/vncserver_listen/d' /etc/nova/nova.conf
sed -i '$a\vncserver_listen=0.0.0.0' /etc/nova/nova.conf
sed -i 's/#listen_tls = 0/listen_tls = 0/g' /etc/libvirt/libvirtd.conf
sed -i 's/#listen_tcp = 1/listen_tcp = 1/g' /etc/libvirt/libvirtd.conf
sed -i '$a\auth_tcp=&none&' /etc/libvirt/libvirtd.conf
sed -i 's/env libvirtd_opts=&-d &/env libvirtd_opts=&-d -l&/g' /etc/init/libvirt-bin.conf
sed -i 's/libvirtd_opts=& -d&/libvirtd_opts=& -d -l&/g' /etc/default/libvirt-bin
sed -i 's/#vnc_listen = “0.0.0.0″/vnc_listen = “0.0.0.0″/g' /etc/libvirt/qemu.conf
sed -i 's/#user = &root&/user = &root&/g' /etc/libvirt/qemu.conf
sed -i 's/#group = &root&/group = &root&/g' /etc/libvirt/qemu.conf
6.重新启动libvirt-bin
service libvirt-bin restart
确定进程已启动。
ps -ef | grep libvirt
确定有libvirtd -d -l进程存在
root :06 ? 00:00:01/usr/sbin/libvirtd -d -l
7.重新启动nova-compute服务，portmap服务
service nova-compute restart
service portmap restart
root@jovi-controller:~# nova list 查看实例
root@jovi-controller:~# nova show 11fdcdb-94d0-d8f 查看需要迁移的实例
root@jovi-controller:~# nova-manage service list查看可用的计算节点
root@jovi-controller:~# nova-manage service describe_resource compute-node2查看目标节点资源
root@jovi-controller:~#nova live-migration 11fdcdb-94d0-d8f jovi-compute3 迁移成功，应该没有输出。
相关问题的总结：
部署过程中曾遇到两个导致无法迁移成功的错误，一个是在日志文件中发现cpu info incapable，另外一个问题是在日志文件中发现failed to connect remote host uri，经过与最后实验成功的环境相对照，发现实际上导致这两个问题的最终原因是计算节点的计算资源不匹配，例如之前失败的情况是compute1节点 cpu 4核心，8g内存，compute3节点 cpu 2核心，内存4g，所以提示出现上述错误。
本质是因为在openstack源码中，有一段针对热迁移时节点计算资源检测的函数，该函数的作用检测迁移的源节点和目的节点的计算资源是否匹配，从而判断能否承载实例的运行。
因此后来将两个计算节点都调整为双核，4g内存，按之前方案配置后，即可成功实现迁移。
另外网上的部署方案都提到了要修改nova.conf中vncserver_proxyclient_address=127.0.0.1，笔者经过测试，这这种方法只适用于单网卡的计算节点，多网卡情况下应该注意填写的是与控制节点以及其他计算节点互联网口的ip，这样dashboard中的vnc才可以成功运行，否则会提示faild to connect to server错误。
欢迎加入about云群 、 ，云计算爱好者群，关注
积极上进，爱好学习
经常参与各类话题的讨论，发帖内容较有主见
长期对论坛的繁荣而不断努力，或多次提出建设性意见
为论坛做出突出贡献的会员
站长推荐 /2
会员注册不成功的原因
新手获取积分方法
Powered by}