13518219792
这篇文章将为大家详细讲解有关如何进行Live Migrate 操作，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
创新互联是专业的吉阳网站建设公司，吉阳接单;提供成都网站制作、成都网站设计,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行吉阳网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!
Migrate 操作会先将 instance 停掉，也就是所谓的“冷迁移”。而 Live Migrate 是“热迁移”，也叫“在线迁移”，instance不会停机。
Live Migrate 分两种：
源和目标节点没有共享存储，instance 在迁移的时候需要将其镜像文件从源节点传到目标节点，这叫做 Block Migration（块迁移）
源和目标节点共享存储，instance 的镜像文件不需要迁移，只需要将 instance 的状态迁移到目标节点。
源和目标节点需要满足一些条件才能支持 Live Migration：
源和目标节点的 CPU 类型要一致。
源和目标节点的 Libvirt 版本要一致。
源和目标节点能相互识别对方的主机名称，比如可以在 /etc/hosts 中加入对方的条目。
在源和目标节点的 /etc/nova/nova.conf 中指明在线迁移时使用 TCP 协议。
Instance 使用 config driver 保存其 metadata。在 Block Migration 过程中，该 config driver 也需要迁移到目标节点。由于目前 libvirt 只支持迁移 vfat 类型的 config driver，所以必须在 /etc/nova/nova.conf 中明确指明 launch instance 时创建 vfat 类型的 config driver。
源和目标节点的 Libvirt TCP 远程监听服务得打开，需要在下面两个配置文件中做一点配置。
/etc/default/libvirt-bin
start_libvirtd="yes" libvirtd_opts="-d -l"
/etc/libvirt/libvirtd.conf
listen_tls = 0
listen_tcp = 1
unix_sock_group = "libvirtd"
unix_sock_ro_perms = "0777"
unix_sock_rw_perms = "0770"
auth_unix_ro = "none"
auth_unix_rw = "none"
auth_tcp = "none"
然后重启 Libvirtd 服务
service libvirt-bin restart
我们先讨论非共享存储的 Block Migration。流程如下：
客户（可以是 OpenStack 最终用户，也可以是其他程序）向API（nova-api）发送请求：“帮我将这个 Instance 从节点 A Live Migrate 到节点 B”
这里源节点是 devstack-compute1，目标节点是 devstack-controller，因为是非共享存储，记得将“Block Migration”勾选上。
这里还有一个“Disk Over Commit”选项，如果勾选了此选项，nova 在检查目标节点的磁盘空间是否足够时，是以 instance 磁盘镜像文件定义的最大容量为准；否则，以磁盘镜像文件当前的实际大小为准。
查看日志 /opt/stack/logs/n-api.log
nova-api 发送消息
nova-api 向 Messaging（RabbitMQ）发送了一条消息：“Live Migrate 这个 Instance” 源代码在 /opt/stack/nova/nova/compute/api.py，方法是 live_migrate。
源和目标节点执行 Live Migrate 的操作过程如下：
目标节点执行迁移前的准备工作，首先将 instance 的数据迁移过来，主要包括镜像文件、虚拟网络等资源，日志在 devstack-controller:/opt/stack/logs/n-cpu.log
源节点启动迁移操作，暂停 instance
在目标节点上 Resume instance
在源节点上执行迁移的后处理工作，删除 instance
在目标节点上执行迁移的后处理工作，创建 XML，在 Hypervisor 中定义 instance，使之下次能够正常启动。
Instance 在 Live Migrate 的整个过程中不会停机，我们通过 Ping 操作来观察
可见在迁移过程中，Ping 进程没有中断，只是有一个 ping 包的延迟增加了。
下面我们再来看源和目标节点共享存储下的 Live Migrate。
有多种方式可以实现共享存储，比如可以将 instance 的镜像文件放在 NFS 服务器上，或者使用 NAS 服务器，或者分布式文件系统。
作为学习和实验，这里我们采用 NFS 方案。其他共享存储方案对于 Live Migration 本质上是一样的，只是在性能和高可用性上更好。
将 devstack-controller 作为 NFS 服务器，共享其目录 /opt/stack/data/nova/instances。 devstack-compute1 作为 NFS 客户端将此目录 mount 到本机，如下所示：
这样，OpenStack 的 instance 在 devstack-controller 和 devstack-compute1 上就实现共享存储了。
共享存储的迁移过程与 Block Migrate 基本上一样，只是几个环节有点区别：
向 nova-api 提交请求的时候，不能勾选“Block Migrate”
因为源和目标节点都能直接访问 instance 的镜像，所以目标节点在准备阶段不需要传输镜像文件，源节点在迁移后处理阶段也无需删除 instance 的目录。
只有 instance 的状态需要从源节点传输到的目标节点，整个迁移速递比 Block Migration 快很多。
关于如何进行Live Migrate 操作就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
