Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to carry out Live Migrate operation for everyone. The content of the article is of high quality. Therefore, Xiaobian shares it with you for reference. I hope that after reading this article, you will have a certain understanding of relevant knowledge.

The Migrate operation stops the instance first, which is called a "cold migration." Live Migrate is "hot migration," also known as "online migration," and instance does not stop.

There are two types of Live Migrate:

The source and target nodes do not share storage. During migration, the mirror file needs to be transferred from the source node to the target node. This is called Block Migration.

The source and destination nodes share storage, and the mirror files of instance do not need to be migrated, only the state of instance needs to be migrated to the destination node.

Source and target nodes need to meet a number of conditions to support Live Migration:

The CPU types of the source and destination nodes should be the same.

The Libvirt versions of the source and destination nodes should be consistent.

Source and destination nodes can identify each other's host names, for example by adding each other's entries to/etc/hosts.

Specify TCP protocol for online migration in/etc/nova/nova.conf of source and destination nodes.

Instance uses config driver to save its metadata. During Block Migration, this config driver also needs to be migrated to the target node. Since libvirt currently only supports migrating config drivers of type vfat, you must explicitly specify launch instance to create a config driver of type vfat in/etc/nova/nova.conf.

The Libvirt TCP remote listening service on both the source and destination nodes needs to be turned on. You need to do a little configuration in the following two configuration files.

/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"

Then restart the Libvirtd service

service libvirt-bin restart

Unshared Storage Block Migration

Let's start with Block Migration for non-shared storage. The process is as follows:

Send request to nova-api

A customer (either an OpenStack end user or another program) sends a request to an API (nova-api):"Help me migrate this Instance from Node A Live to Node B"

Here, the source node is devstack-compute1, and the destination node is devstack-controller. Because it is non-shared storage, remember to check "Block Migration".

There is also a "Disk Over Commit" option. If this option is checked, nova checks whether the disk space of the target node is sufficient, based on the maximum capacity defined by the instance disk image file; otherwise, based on the actual size of the disk image file.

The requested URL/logs/n-api.log was not found on this server.

nova-api send message

nova-api sends a message to Messaging (RabbitMQ):"Live Migrate this Instance" source code at/opt/stack/nova/compute/api.py, method live_migrate.

nova-compute performs operations

The source and target nodes execute Live Migrate as follows:

The target node performs the preparatory work before migration. First, it migrates the instance data, mainly including mirror files, virtual networks and other resources. The log is in devstack-controller:/opt/stack/logs/n-cpu. log

Source node starts migration operation, pause instance

Resume instance on target node

Perform post-migration work on the source node, removing instance

Perform post-migration processing on the target node, creating XML, and defining instances in Hypervisor so that they can start properly next time.

Instance does not stop during the whole process of Live Migrate, we observe it through Ping operation

It can be seen that during the migration process, the Ping process is not interrupted, but the delay of a ping packet is increased.

Now let's look at Live Migrate under shared storage of source and target nodes.

Shared Storage Live Migration

Shared storage can be achieved in a variety of ways, such as by placing instance's mirrored files on an NFS server, or using NAS servers, or distributed file systems.

As a learning and experimental approach, we use the NFS scheme here. Other shared storage schemes are essentially the same for Live Migration, only better in performance and high availability.

Building an NFS environment

Devstack-controller as NFS server, sharing its directory/opt/stack/data/nova/instances. devstack-compute1 mounts this directory natively as an NFS client, as follows:

In this way, OpenStack instances implement shared storage on devstack-controller and devstack-compute1.

The migration process of shared storage is basically the same as Block Migrate, except for a few differences:

When submitting a request to nova-api, do not check "Block Migrate"

Because both source and destination nodes have direct access to instance's mirror, the destination node does not need to transfer the mirror file during the preparation phase, and the source node does not need to delete instance's directory during the post-migration processing phase.

Only the state of the instance needs to be transferred from the source node to the target node, and the entire migration express is much faster than Block Migration.

About how to carry out Live Migrate operation to share here, I hope the above content can be of some help to everyone, you can learn more knowledge. If you think the article is good, you can share it so that more people can see it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.