Virtual machine online migration without shared storage conditions in OpenStack [go]

Original link: http://www.ibm.com/developerworks/cn/cloud/library/1508_wangyx_openstacklivemigrate/

Migration (migration) is the move of a virtual machine from one physical host to another, and dynamic (live) is that the virtual machine works during the migration without affecting the user's use. For system administrators, dynamic migration is a very useful tool, when planning to update or upgrade a physical host (Update/upgrade), the administrator does not need to shut down the virtual machine on the physical host, but before the update or upgrade to the virtual machine dynamic migration to another physical host, After the update or upgrade work is completed, the migration is back. From the user's point of view, it seems that this process has not happened. Virtual machines move in and out, but do not affect the user's use in the slightest.

This article tries to answer a few questions related to live migration: What is live migration? Why Live Migration? How to do Live migration? If you have read this article and have basically understood the answers to these three questions, the main purpose of this article has been achieved. Because this article describes the implementation of dynamic migrations on the OpenStack platform, readers must have a certain understanding of OpenStack.

Introduction to Virtual machine migration

Dynamic migration consists of two meanings, one is migration (migration), and migration is to move a user's virtual machine from one physical host to another. The second is dynamic, the dynamic meaning is in the process of migration, (1): The virtual machine is also open machine, (2): The virtual machine network is not affected, (3): And the above running user program is still running. The entire process is transparent to the user, and the user is able to use the virtual machine on the move in a normal way.

OpenStack supports two types of virtual machine migrations:

• Cold migration-cold migration is also called static migration. During migration, the virtual machine must be shut down and the user cannot access the virtual machine. Because of the need to shut down, he is suitable for users when the system availability requirements are not very high.

• Thermal migration (hot or live migration)-thermal migration is also called dynamic migration. The virtual machine still works during the migration, and the user can continue to use the virtual machine. This is the type of migration that is described in this article. Thermal migration is divided into the following two types:

• (1): The virtual machine data exists on the shared disk (GKFX storage-based Live Migration), as shown in 1.

  Figure 1

• (2): The virtual machine data exists on the local disk (block migration), 2, the image file and memory data needs to be migrated simultaneously. OpenStack implements this type of migration through block migrations.

  Figure 2

The role of virtual machine migration

Each reader may ask such a question, the virtual machine with the good, why to migrate it? That is, the value and purpose of the migration. In the daily operations of the data center, it is often necessary to deal with the following scenarios and requirements to understand these requirements, and this question has the answer.

• Requirement 1: Maintenance of physical machine hardware system, fault repair and upgrade (upgrade), but the virtual machine running on this physical machine cannot shut down because the user important service runs on it.
• Requirement 2: Physical machine software system upgrade, patching (patch), in order to not affect the running of the virtual machine, before upgrading and patching, the need to move the virtual machine to another physical machine.
• Requirement 3: The load on a physical machine is too heavy and some virtual machines need to be reduced to free up resources.
• Requirement 4: In a cluster, there are too many virtual machines on the physical machine, some of the virtual machines on the physical machine are too few, need to do a balance of resources.

In addition to the above four main requirements, from a service point of view, Live migration has the following two benefits:

• Benefit 1: Maintenance upgrades of software and hardware systems do not affect users ' critical services, improve service availability and user satisfaction.
• Benefit 2: System administrators do not have to work overtime, in the middle of the night to upgrade the system, in normal working hours to complete the work, reducing the company's maintenance costs.

There are four requirements and two benefits, so dynamic migration is worth doing.

Dynamic migration method and implementation

This chapter details how to implement dynamic migration in OpenStack. In the first section, it is mentioned that there are two types of dynamic migrations, and this article only describes the dynamic migration of local disks (block migration) for the data of the virtual machines shown in Figure 2.

Conditions for dynamic migration

Dynamic migration is the migration of virtual machines from one physical host to another, so at least two physical hosts are required as compute nodes. The following is a minimal OpenStack configuration. Three physical hosts, one for OpenStack control nodes, and two for compute nodes. As shown in 3.

Figure 3

The control node accepts and processes requests for dynamic migrations, and administrators can initiate dynamic migrations from Horizon, the command line, and the API. Dynamic migration is the migration of the client's VMS from COMPUTE node 1 to compute Node 2, or from compute Node 2 to compute Node 1, 4.

Figure 4

The Hypervisor on the compute node is KVM, and the operating system is Redhat6.5,openstack is Juno. The virtual machines on compute nodes 1 and 2 are stored on the local file system, respectively, as shown in 2.

The above mentioned Hypervisor and KVM related concepts, as well as the detailed introduction of OpenStack modules, you can read the documentation in the resources, here is not the introduction.

Implementation of dynamic migration

This section describes how dynamic migration is implemented from the basic concepts, transport protocols, and the steps of migration in three different ways.

Basic concepts

Before you understand the dynamic migration, you must understand the format of the image file QCOW2. Qcow2 is the currently recommended image format for QEMU, which supports sparse files to conserve storage space, supports encryption to improve the security of image files, and supports Zlib-based compression. Qcow2 image can be used to save the change of another image file, it does not modify the original image file, the original image file is also called back-end Mirror (backing_file). Only the image file with a different part of the original image file is recorded, which is called the copy-on-write image, although it is a separate image file, but most of its data comes from the original image, only the incremental part based on the original image file will be recorded. The virtual machines mentioned in this article are created by OpenStack in a Qcow2 format image file, shown in 5, with two parts.

• Back-end mirroring (libvirt base)
• Virtual machine separate incremental image file (libvirt instance disks), Copy-on-write Mirror

Figure 5

On the physical machine's disk, when we have built a virtual machine, we generate 6 columns of these files. where _base the following file, is the back-end mirror (libvirt base), the directory 6e783272-31b5-4fdc-8828-2b8892daab39 the following is the virtual machine separate incremental image file (libvirt instance disks), It only records content that differs from the base file.

Figure 6

Using QEMU-IMG to view the information of a separate incremental image file for a virtual machine, we can see that his backing file is the image of the _base directory, as shown in 7.

Figure 7

With so much space to introduce QCOW2, you wonder, what is the purpose? In fact, the back-end image described above (Libvirt Base), the virtual machine separate incremental image files (libvirt instance disks), they are the data to be migrated. The ultimate goal of dynamic migration is to migrate them completely from the source physical host to the target physical host. In addition to the two of them, there is another object that needs to be migrated is the data of the virtual machines running in memory.

To summarize: the migration of virtual machines is actually the transfer of data, because there is no shared storage between compute nodes, so the data to be transferred consists of two parts:

1. Static data: A mirrored file that is stored on a local virtual machine, including a back-end mirror (Libvirt Base) and a separate incremental image file for the virtual machine (libvirt instance disks).
2. Dynamic Data: In-memory virtual machine runtime data, in-memory data is dynamically changing data, the size of the load running in the virtual machine directly affects the length of time of migration.

Migrating channels and transport protocols

OpenStack invokes the underlying libvirt to complete the dynamic migration. The migration of virtual machines is actually the transfer of data. The Libvirt provides a tunneled data transfer (Libvirt tunnelled transport) to complete the transition. As shown in 8.

Figure 8

The transfer of data involves the transmission of data, the transmission of data needs to pass through the network, this article describes the use of TCP network protocol to achieve dynamic migration. Libvirt the TCP protocol is not supported by default, the configuration of Libvirt needs to be modified so that Libvirt can support the TCP protocol, and later chapters will describe how to configure it in detail. During the migration process, the LIBVIRTD process running in the destination physical host (Dest host) is creating a uri,uri based on address and port LIBVIRTD the destination physical host is used to receive data and send data back to the source host. Of the process, 9.

Figure 9

In the destination physical host and the source physical host, as long as the following command can be executed, it indicates the ability to transfer data.

Execute on COMPUTE01:

[Email protected]]# virsh-c qemu+tcp://[email Protected]/system

Execute on COMPUTE02:

[Email protected]]# virsh-c qemu+tcp://[email Protected]/system

Execute the Virsh command on COMPUTE01 as shown in the following example, if the output shown in Figure 10 shows that the transport channel is normal.

Figure 10

Steps for Migration

The basic concept of migration is clear, so let's move on to the migration steps below. OpenStack does dynamic migration a normal process consists of four parts: pre-migration condition checks, pre-migration preprocessing, migration, post-migration processing.

Pre-migration Condition checks

For a dynamic migration to execute successfully, some conditions must be met, so some condition checks must be made before the migration is performed.

1. Permission checks to see if the user performing the migration has sufficient privileges to perform a dynamic migration.
2. Parameter checks whether the parameters passed to the API are sufficient and correct, such as whether the Block-migrate parameter is specified.
3. Check that the target physical host is present.
4. Check if the migrated virtual machine is a running state.
5. Check that the Nova-compute service is working correctly on the source and destination physical hosts.
6. Check whether the destination physical host and the source physical host are the same machine.
7. Check to see if the destination physical host has enough memory.
8. Check the purpose and the source physical master machine hypervisor and hypervisor versions are the same.

Pre-migration preprocessing

Before you actually perform the migration, you must warm up and do some preparatory work.

1. Obtain and prepare the virtual machine mounted Block device (volume) on the destination physical host.
2. Set the virtual machine's network (networks) on the destination physical host.
3. Purpose to set the virtual machine's firewall (fireware) on the physical host.

Migration

After the conditions are met and the preprocessing is done, you can perform a dynamic migration. The main steps are as follows:

1. Call the Libvirt Python interface Migratetouri to migrate the source host to the destination host.
   • Dom.migratetouri (conf.live_migration_uri% dest,logical_sum,none,conf.live_migration_bandwidth)
   • Live_migration_uri: This URI is defined by the LIBVIRTD process described in 3.2.2.
   • Live_migration_bandwidth: This parameter defines the maximum bandwidth that is used during the migration process.
2. Call the Wait_for_live_migration method at a certain time interval (0.5) to detect the state of the virtual machine migration until the virtual machine is successfully migrated.

Post-migration processing

After the virtual machine migration is complete, do some cleanup work.

1. Detach volume on the source physical host.
2. Release security group Ingress rule on the source physical host.
3. Update the state of the virtual machine in the database on the destination physical host.
4. Delete the virtual machine on the source physical host.

When the above four steps are completed properly, the virtual machine successfully migrated from the source physical host to the destination physical host. The administrative tasks listed in chapter II can be performed by the system administrator.

Configuration for dynamic migration

This section lists the configurations that support dynamic migration, and you must ensure that all physical hosts are configured on a true, dynamic migration to complete successfully.

Libvirt

Libvirt supports the TLS protocol for remote connections by default and does not support the TCP protocol, so listen_tls=0 Listen_tcp=1 enables Libvirt to support the TCP protocol.

1. Modify the/etc/sysconfig/libvirtd file.

   Libvirtd_args= "--listen"

2. Make the following configuration in the/etc/libvirt/libvirtd.conf file.

   Listen_tls=0listen_tcp=1auth_tcp= "None"

3. Restart LIBVIRTD Service

DNS on physical host

Configure the/etc/host on each physical host to join the hostname and IPs for each physical host, as in the following example:

192.168.0.1 compute-1 compute-1.ibm.com192.168.0.2 compute-2 compute-2.ibm.com

Firewall

Configure/etc/sysconfig/iptables to open TCP port 16509.

-A input-p tcp-m multiport--ports 16509-m comment--comment "libvirt"-j ACCEPT

OpenStack Nova

Configure the live_migration tag in the/etc/nova/nova.conf file. Live_migration_flag=vir_migrate_undefine_source,vir_migrate_peer2peer,vir_migrate_live

Instances of dynamic migration

This section demonstrates how to do a dynamic migration using the following example. The goal of this example is to migrate the virtual machine from tor01kvm001ccz048 to tor01kvm002ccz048. As shown in 11.

Figure 11

1. Build a virtual machine on tor01kvm001ccz048 lm001, shown in 12.

   Click to view the code listing

   Figure 12

2. Check that the virtual machine lm001 is built on tor01kvm001ccz048, as shown in 13.

   Figure 13

3. Perform a dynamic migration

   #nova live-migration--block-migrate lm001 tor01kvm002ccz048

   We can see that the Task state of the virtual machine becomes the migrating status, as shown in 14.

   Figure 14

4. Check the results of the migration

   With the Nova Show command, you can see that the lm001 has migrated successfully to tor01kvm002ccz048, as shown in 15.

   Figure 15

Summarize

As we can see from the previous introduction, even without shared storage, we can implement a non-disruptive dynamic migration of virtual machines, but there is a need for fast network support between all compute nodes. There are also two points to keep in mind:

1. This article uses a TCP/IP socket that is not encrypted, so it is not recommended in a production environment unless you are performing a dynamic migration in a secure and trusted network.
2. In the process of migration, virtual opportunities are downtime. For detailed information, you can read the performance reports for block migrations in the Resources section.

Virtual machine online migration without shared storage conditions in OpenStack [go]