Migrating Instances between Nectar Availability Zones

Migrating Resources between Nectar Availability Zones

Introduction

There are scenarios where you may need to transfer an existing instance between Availability Zones (also called zones or AZs). Examples of these scenarios include:

• Launching an instance in one AZ and then realising that other resources that you require for the instance are only available in another AZ. For instance, Advanced Networking and GPUs are only available in certain AZ, and some kinds of storage quota are tied to specific AZs. 

• The Node managing the hardware that your instance runs on may need to ask you to switch AZs as part of an internal reorganisation.  Alternatively, a Node may be withdrawing from the Nectar Federation.

• For allocations that are classified as “local funded” are only permitted to run in the AZs of the node that approved them.  So if an allocation is reclassified, you may be required to migrate existing instances to a “home” AZ.

While Openstack provides a facility for live migrating instances between compute nodes in an AZ, live migration of instances between AZs is not possible. Instead, instance migration is accomplished by shutting down the current instance, creating a snapshot, and starting a new instance in the new AZ from the snapshot.  Once the instance has been safely migrated, the old (shut down) instance can be terminated.

A consequence of this procedure is that you may lose the IP address of the old instance:

• Static IPs simply cannot be transferred.

• A Floating IP created in one Nectar Node can technically be attached to an instance in another Node.  However, this causes operational issues, so you should avoid doing this except as a short term stop-gap measure.  (For example, it might be necessary if you have neglected to set up a DNS name for the floating IP.)

Although the basic migration procedure is straight forward, some scenarios have complicated factors.   For example, storage associated with an instance needs to be migrated separately, and if you are still using a legacy (m1 or m2) flavor you may need to replace ephemeral storage with volume storage. These complicating factors should not prevent a migration, but they will need to be taken into account and planned for.

Before migrating, determine whether the existing instance is still required. It may be that old instances can be deleted, or take the opportunity to build a new instance with the latest operating system and packages.Nerctar

Flowchart for navigating non-trivial scenarios

In the flowchart, you can skip any circles that don't match your situation. Everyone will need to do the light blue, green and orange circles (respectively start/end, prepare/communicate/test, shutdown/snapshot/relaunch). Many people can skip purple, pink, dark blue and grey (database stop/start, ephemeral data backup/restore to volume, disassociate/re-associate floating IP, detach/reattach volumes).

Overall strategy

• Read all of the relevant migration documentation as the first step.

• Make a migration plan taking account of instance dependencies, contingencies and your end-user requirements. For example, if you are running a service for other people on the instances being migrated, your plan will need to include sending outage notices and a procedure for taking the service off-line.

• Submit an Allocation amendment to request the following resources as required:

  • New quotas needed to run in the new AZ; e.g. volumes will require Volume Storage quota in the new AZ.

  • Temporary quotas needed for safe migration; e.g. Instance and VCPU quotas so that old and new instances can coexist, and Object Storage for backups.

  • Wait for approval of the amendment before proceeding.  If approval needs to be expedited, please submit a support request.

• Perform pre-migration backups for your valuable assets.  (You should already have a backup procedure to mitigate against data loss.)

• Perform the migration steps as per your plan.

• Validate that the migration has been performed successfully; e.g. check that your new instance is working properly and that any important data is intact.

• Shutdown the old resources and cleanup.

• Submit an allocation amendment to relinquish any temporary quotas.

Other resources

• Backing up your data 

• Migrating a normal Instance

• Migrating a Volume

• Migrating a Database

• Migrating a “boot from volume” Instance.

• Dealing with IP addresses, DNS, Firewalls and Whitelisting rules.

• Migrating Instances with legacy Flavors