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

Foreword:

Live Migrate (dynamic Migration) refers to the migration of clients between different hosts while ensuring the normal operation of application services on the client, which is divided into two ways: Block Migration (Block Migration) without shared storage and shared storage.

The premise of Migrate is that the nova-compute service of the computing host is normal. When a computing host is down or other exceptions cause the service to be unavailable, you can perform Evacuate operation to migrate the instance to another host.

Environment

Openstack version pike control node host openstack-controller (ubuntu 16.04.5) 172.27.34.37

Compute node host openstack-computer (ubuntu 16.04.5) 172.27.34.38instance01

Cirros0001 (172.16.2.3) instance02

Cirros0002 (172.16.2.6)

For details of ubuntu installation, please see the full record of Ubuntu16.04.5 installation in lvm mode.

For more information on openstack installation, please see: OpenStack practice (1): build p version of OpenStack by DevStack under Ubuntu16.04

For details of Flat network construction, please see: OpenStack practice (3): implementation of Flat Network by Linux Bridge

Live Migrate part

Modify nova.conf

Modify the configuration file nova.conf

Stack@openstack-controller:~$ view / etc/nova/nova.conf [vnc] # vncserver_listen = 127.0.0.1server_listen=0.0.0.0

Restart computing services

Root@openstack-controller:~# systemctl restart devstack@n*

Configure the hosts file

Configure a compute node hosts file to identify hostnames with each other

Root@openstack-controller:/# more / etc/hosts

Secret-free access

The root users of each computing node can access the application user stack without secret.

Root@openstack-controller:/# ssh-keygen-t rsa

Root@openstack-controller:~# ssh-copy-id-I / root/.ssh/id_rsa.pub stack@172.27.34.38

Password testing

Root@openstack-controller:~# ssh stack@172.27.34.38

Libvirt configuration

In this experiment, no additional configuration is required for / etc/default/libvirt-bin and / etc/libvirt/libvirtd.conf files, and the default qemu+ssh mode is used for transmission.

Verify connectivity

Root@openstack-controller:~# virsh-c qemu+ssh://stack@openstack-computer/system list-- all

Configure the nfs service

Nfs server configuration

[root@centos7 ~] # mkdir-p / opt/stack/data/nova/instances [root@centos7 ~] # chmod-R 777 / opt/stack/data/nova/instances [root@centos7 ~] # view / etc/exports/opt/stack/data/nova/instances * (rw,sync,fsid=0,no_root_squash) [root@centos7] # exportfs-r [root@centos7 ~] # exportfs-v/opt/stack/data/nova/instances (sync,wdelay,hide,no_subtree_check,fsid=0 Sec=sys,rw,secure,no_root_squash,no_all_squash)

Client mount

Each compute node performs the following operations

Install nfs softwar

Root@openstack-controller:~# apt-get install nfs-common-y

Test the shared directory

Root@openstack-controller:~# showmount-e 172.27.9.181Export list for 172.27.9.181:/opt/stack/data/nova/instances *

Mounting

Root@openstack-controller:~# mount-t nfs 172.27.9.181:/opt/stack/data/nova/instances / opt/stack/data/nova/instances

Turn on automatic mount

Root@openstack-controller:~# view / etc/rc.localmount-t nfs 172.27.9.181:/opt/stack/data/nova/instances / opt/stack/data/nova/instances

For more information on nfs construction, please see NFS server building and client connection configuration under Centos7.

Live Migrate

View the instances to be migrated

The instance is located on the controller node before migration. To verify that it is a hot migration, cirros01 enables the ping service.

Start the migration

The target node selects computer. Because it is a shared storage mode to implement this experiment, the option of "block device migration" is not checked.

Transfer

Migration completed

Instance is successfully migrated from controller node to computer node

The ping service was not interrupted during the migration.

Command mode

Root@openstack-controller:~# nova live-migration d0d5bc75-da89-46a8-be79-1e2639f9eaf8 openstack-controller

D0d5bc75-da89-46a8-be79-1e2639f9eaf8 is the instance id,openstack-controller as the target computing node.

Log analysis

View instances id and req id

View instance id and req id to facilitate log location

Source node nova-api sends messages

Root@openstack-controller:~# journalctl-f-- unit devstack@n-api.service

Target node migration preparation

The source node pauses the instance to start the migration

The target node restores the instance

The source node completes the migration and releases resources

Evacuate part

Close the compute node openstack-computer

Root@openstack-computer:~/.ssh# init 0

View compute node status

View the instance name and the name of the computing node to which it belongs

Root@openstack-controller:~# nova list-fields id,name,status,instance_name,host

Execute evacuate

Root@openstack-controller:~# nova evacuate 80b8a5ff-5082-4864-b05e-5766c144d2b4 openstack-controller

Migrate instance 80b8a5ff-5082-4864-b05e-5766c144d2b4 from compute node openstack-computer to openstack-controller

If the evacuate operation is performed with the host, an error will be reported: The target host can't be the same one. If the settlement node is migrated without downtime, an error will be reported: Compute service of openstack-computer is still in use

Evacuate operation completed

Landing instance

The password, ip, and hostname remain unchanged after the instance is restored.

Log analysis

Nova-api

Nova-scheduler

Nova-computer

Reference to this article

Https://docs.openstack.org/nova/queens/admin/configuring-migrations.html#section-configuring-compute-migrations

Https://docs.openstack.org/nova/queens/configuration/config.html

Https://docs.openstack.org/nova/pike/admin/evacuate.html

Https://blog.51cto.com/cloudman/1786423

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.