十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
这篇文章将为大家详细讲解有关如何进行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 操作就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。