tripleo-docs/deploy-guide/source/post_deployment/migration.rst
Alex Schultz c6918e5da6 Migrate install to deploy-guide
The deployment guide is currently pointed at triplo-docs but it has been
requested that we actually publish a deployment guide. This change
extracts many of the installation doc pages and moves them into the
deploy-guide source tree.  Once the deploy-guide is published, we will
follow up to reference the deployment guide from tripleo-docs.

Change-Id: I0ebd26f014180a92c6cf4ab0929d99b2d860796f
2019-08-16 15:42:17 -06:00

2.6 KiB

Migrating Workloads from an existing OpenStack cloud

provides the ability to manage changes over time to a cloud that it has deployed. However, it cannot automatically take over the management of existing OpenStack clouds deployed with another installer. Since there can be no one-size-fits-all procedure for upgrading an existing cloud to use , it is recommended that a new cloud be deployed with and any workloads running on an existing cloud be migrated off.

Migrating User Workloads

Since the best way of avoiding or handling any downtime associated with moving an application from one cloud to another is application-dependent, it is preferable to have end users migrate their own applications at a time and in the manner of their choosing. This can also help to spread out the network bandwidth requirements, rather than copying a large number of snapshots in bulk.

Ideally applications can be re-created from first principles (an Orchestration tool such as Heat can help make this repeatable) and any data populated after the fact. This allows the new VMs to be backed by a copy-on-write disk image overlaid on the original base image. The alternative is to export and then import <./vm_snapshot> snapshots of the VM images. This may require considerably more disk space as each VM's base image becomes its snapshot, where previously multiple VMs may have shared the same base image.

Reclaiming Excess Capacity

As workloads are migrated off the previous cloud, compute node hardware can be freed up to reallocate to the new cloud. Since there is likely no guarantee as to the order in which users will migrate, it will be necessary to consolidate the remaining VMs onto a smaller number of machines as utilization drops. This can be done by performing live migration within the old cloud.

Select a compute node to remove from service and follow the procedure for quiesce_compute. Once this is done, the node can be removed from the old cloud and the hardware reused, possibly by adding it to the new cloud.

Adding New Capacity

As utilization of the new cloud increases and hardware becomes available from the old cloud, additional compute nodes can be added to the new cloud with .

First, register and introspect the additional hardware with Ironic just as you would have done when initially deploying <../deployment/install_overcloud> the cloud with . Then scale out <scale_roles> the 'Compute' role in the new overcloud to start making use of the additional capacity.