Arbutus Migration Guide: Difference between revisions

From Alliance Doc
Jump to navigation Jump to search
(Arbutus Migration guide first version)
 
(standardize formatting, simplify some language)
Line 1: Line 1:
This document aims to describe the methods by which instances can be migrated from the legacy West Cloud to the new Arbutus Cloud. User workloads are typically application dependent, hence the recommended best practice is to enable users to migrate their instances according to their application requirements and on their schedule.
This document aims to describe how to migrate virtual machine (VM) instances from the legacy West Cloud to the new Arbutus Cloud.  
 
You know your workload best, so we recommend that you migrate your instances according to your own application requirements and schedule.
 
== '''Preliminaries''' ==


== Preliminaries ==


Note the following URLs for accessing the Horizon Web UI for the 2 Clouds:
Note the following URLs for accessing the Horizon Web UI for the 2 Clouds:


<span style="color:#000000;">West Cloud (legacy): </span>[https://west.cloud.computecanada.ca https://west.cloud.computecanada.ca]
'''West Cloud (legacy):''' [https://west.cloud.computecanada.ca https://west.cloud.computecanada.ca]


<span style="color:#000000;">Arbutus Cloud (new): </span>[https://arbutus.cloud.computecanada.ca https://arbutus.cloud.computecanada.ca]
'''Arbutus Cloud (new):''' [https://arbutus.cloud.computecanada.ca https://arbutus.cloud.computecanada.ca]


Firefox and Chrome browsers are supported. Safari and Edge may work but are not validated.
Firefox and Chrome browsers are supported. Safari and Edge may work but are not validated.
Line 15: Line 14:
Your Project (Tenant), Network, and Router will be pre-created for you in Arbutus Cloud. User access will also be pre-populated.
Your Project (Tenant), Network, and Router will be pre-created for you in Arbutus Cloud. User access will also be pre-populated.


Prior to migrating instances, it is recommended that the following preliminaries are completed to prepare the necessary environment for migration.
Prior to migrating instances, we recommend that you complete the following preliminaries to prepare the necessary environment for migration.
 


'''IMPORTANT''': Backup any critical data. While the Cloud has redundant storage systems, no backups of any instances are taken.
'''IMPORTANT''': Backup any critical data. While the Cloud has redundant storage systems, no backups of any instances are taken.


# Get RC files (used to set environment variables used by the OpenStack command-line tools) after logging in to the URLs above with your Compute Canada credentials:
# Get RC files (used to set environment variables used by the OpenStack command-line tools) after logging in to the URLs above with your Compute Canada credentials:
Line 47: Line 44:
# Plan an outage window. Generally, shutting down services and the instance(s) is the best way to avoid corrupt or inconsistent data after the migration. Smaller volumes should copy over fairly quickly i.e. within minutes, but larger volumes will take longer. Plan accordingly for this. Additionally, floating IP addresses will change, so ensure the TTL of your DNS records is set to a small value so that the changes propagate as quickly as possible.  
# Plan an outage window. Generally, shutting down services and the instance(s) is the best way to avoid corrupt or inconsistent data after the migration. Smaller volumes should copy over fairly quickly i.e. within minutes, but larger volumes will take longer. Plan accordingly for this. Additionally, floating IP addresses will change, so ensure the TTL of your DNS records is set to a small value so that the changes propagate as quickly as possible.  


There are three general migration scenarios to consider. Depending on your applications and current instance setup, you may use any or all of these scenarios to migrate from the West Cloud to the Arbutus Cloud.


There are 3 general migration scenarios to consider and depending on your applications and current instance setup, you may use any or all scenarios to migrate from the West Cloud to the Arbutus Cloud.
== Manual or orchestrated migration ==
 
 
== '''Manual or Orchestrated Migration''' ==
 


In essence, this will be a “net new” infrastructure provisioning. Instances and volumes are created in Arbutus with the same specifications as that on West Cloud. The general approach would be:
In essence, this will be a “net new” infrastructure provisioning. Instances and volumes are created in Arbutus with the same specifications as that on West Cloud. The general approach would be:
Line 61: Line 55:
# Assign floating IP(s) to the new instance(s) and update DNS.
# Assign floating IP(s) to the new instance(s) and update DNS.
# Decommission old instance(s) and delete old volume(s).
# Decommission old instance(s) and delete old volume(s).


The above steps can be done manually or orchestrated via various configuration management tools. The use of such tools is beyond the scope of this document, but if you were already using orchestration tools on West Cloud, they should work with Arbutus Cloud as well.
The above steps can be done manually or orchestrated via various configuration management tools. The use of such tools is beyond the scope of this document, but if you were already using orchestration tools on West Cloud, they should work with Arbutus Cloud as well.


 
== Migrating volume-backed instances ==
== '''Migrating Volume-backed Instances''' ==
 


Volume-backed instances as their name implies have a persistent volume attached to them containing the operating system and any required data. General best practices would involve a smaller volume for the operating system and a larger volume for data sets.
Volume-backed instances as their name implies have a persistent volume attached to them containing the operating system and any required data. General best practices would involve a smaller volume for the operating system and a larger volume for data sets.


 
=== Migration using Glance images ===
=== '''Migration Using Glance Images''' ===
 


This method is recommended for volumes less than 150GB in size. For volumes larger than that, creating new volumes in Arbutus Cloud and copying the required data across from West Cloud is preferred to creating Glance images and transferring the images between clouds.
This method is recommended for volumes less than 150GB in size. For volumes larger than that, creating new volumes in Arbutus Cloud and copying the required data across from West Cloud is preferred to creating Glance images and transferring the images between clouds.


# SSH to the migration host ''cloudmigration.computecanada.ca'' with your Compute Canada credentials.
# SSH to the migration host ''cloudmigration.computecanada.ca'' with your Compute Canada credentials.
Line 90: Line 78:
# Once your instances/volumes are migrated & validated and any associated DNS records updated, please delete your old instances/volumes on the legacy West Cloud.
# Once your instances/volumes are migrated & validated and any associated DNS records updated, please delete your old instances/volumes on the legacy West Cloud.


 
=== Alternative method: Migrating a volume-backed instance using Linux 'dd' ===
=== '''Alternative method: Migrating a Volume-backed Instance using Linux dd''' ===
 


# Launch a temporary instance on West Cloud with the smallest flavor possible “p1-1.5gb”. The instructions below assume CentOS 7, but any Linux distribution with Python and Pip available should work.
# Launch a temporary instance on West Cloud with the smallest flavor possible “p1-1.5gb”. The instructions below assume CentOS 7, but any Linux distribution with Python and Pip available should work.
Line 110: Line 96:
# Once your instances/volumes are migrated & validated and any associated DNS records updated, please delete your old instances/volumes on the legacy West Cloud.
# Once your instances/volumes are migrated & validated and any associated DNS records updated, please delete your old instances/volumes on the legacy West Cloud.


== Migrating ephemeral instances ==


== '''Migrating Ephemeral Instances''' ==
=== Migration using Glance images and volume snapshots ===
 
 
=== '''Migration Using Glance Images and Volume Snapshots''' ===
 


This method is recommended for instances with ephemeral storage less than 150GB in size. For instances with storage larger than that, creating new instances in Arbutus Cloud and copying the required data across from West Cloud is preferred to creating Glance images and transferring the images between clouds. You will still need to copy data from any non-boot ephemeral storage (i.e. mounted under <code>/mnt</code>) separately. Consult the section on methods to copy data for this.
This method is recommended for instances with ephemeral storage less than 150GB in size. For instances with storage larger than that, creating new instances in Arbutus Cloud and copying the required data across from West Cloud is preferred to creating Glance images and transferring the images between clouds. You will still need to copy data from any non-boot ephemeral storage (i.e. mounted under <code>/mnt</code>) separately. Consult the section on methods to copy data for this.


# SSH to the migration host ''cloudmigration.computecanada.ca'' with your Compute Canada credentials.
# SSH to the migration host ''cloudmigration.computecanada.ca'' with your Compute Canada credentials.
Line 133: Line 115:
# Once your instances/data are migrated & validated and any associated DNS records updated, please delete your old instances on the legacy West Cloud.
# Once your instances/data are migrated & validated and any associated DNS records updated, please delete your old instances on the legacy West Cloud.


 
=== Alternative method: Migrating an ephemeral instance using Linux 'dd' ===
=== '''Alternative method: Migrating an Ephemeral Instance using Linux dd''' ===
 


# Login to the instance running on West Cloud via SSH. When migrating an ephemeral instance (an instance without a backing volume as aforementioned), it is important to shut down as many unnecessary services as possible on the instance prior to migration e.g. httpd, databases, etc. Ideally, leave only SSH running.
# Login to the instance running on West Cloud via SSH. When migrating an ephemeral instance (an instance without a backing volume as aforementioned), it is important to shut down as many unnecessary services as possible on the instance prior to migration e.g. httpd, databases, etc. Ideally, leave only SSH running.
Line 151: Line 131:
# Once your instances/data are migrated & validated and any associated DNS records updated, please delete your old instances on the legacy West Cloud.
# Once your instances/data are migrated & validated and any associated DNS records updated, please delete your old instances on the legacy West Cloud.


== Methods to copy data ==


== '''Methods to Copy Data''' ==
There are a couple of recommended approaches for copying data between instances running in the two clouds. The most appropriate method would depend upon the size of the data volumes in your tenant. For very large volumes greater than 5TB, Globus is recommended. Please see here for configuration details: [https://computecanada.github.io/DHSI-cloud-course/globus/ https://computecanada.github.io/DHSI-cloud-course/globus/]
 
 
There are a couple of recommended approaches for copying data between instances running in the 2 clouds. The most appropriate method would depend upon the size of the data volumes in your tenant. For very large volumes greater than 5TB, Globus is recommended. Please see here for configuration details: [https://computecanada.github.io/DHSI-cloud-course/globus/ https://computecanada.github.io/DHSI-cloud-course/globus/]


If you have very large volumes, we recommend submitting a support ticket as well.
If you have very large volumes, we recommend submitting a support ticket as well.


For volumes in the several hundred GB to low TB range, rsync+ssh provides good transfer speeds and can also work in an incremental way. A typical use case would be:
For volumes in the several hundred GB to low TB range, rsync+ssh provides good transfer speeds and can also work in an incremental way. A typical use case would be:


# SSH to the West Cloud instance which has the large volume attached and note the absolute path you want synced over to the instance on Arbutus Cloud.
# SSH to the West Cloud instance which has the large volume attached and note the absolute path you want synced over to the instance on Arbutus Cloud.
Line 166: Line 143:
#: <code> rsync -avzP -e 'ssh -i ~/.ssh/key.pem' /local/path/ remoteuser@remotehost:/path/to/files/ </code>
#: <code> rsync -avzP -e 'ssh -i ~/.ssh/key.pem' /local/path/ remoteuser@remotehost:/path/to/files/ </code>
# Validate the data successfully copied over on the instance in Arbutus Cloud. Please delete any data from the legacy West Cloud once you have completed validation on Arbutus Cloud.
# Validate the data successfully copied over on the instance in Arbutus Cloud. Please delete any data from the legacy West Cloud once you have completed validation on Arbutus Cloud.


You may also use any other method you are familiar with for transferring data.
You may also use any other method you are familiar with for transferring data.


 
== Support ==
== '''Support''' ==
 


Support requests can be sent to the usual Cloud support address at [mailto:cloud@computecanada.ca cloud@computecanada.ca]
Support requests can be sent to the usual Cloud support address at [mailto:cloud@computecanada.ca cloud@computecanada.ca]

Revision as of 12:38, 24 October 2018

This document aims to describe how to migrate virtual machine (VM) instances from the legacy West Cloud to the new Arbutus Cloud. You know your workload best, so we recommend that you migrate your instances according to your own application requirements and schedule.

Preliminaries[edit]

Note the following URLs for accessing the Horizon Web UI for the 2 Clouds:

West Cloud (legacy): https://west.cloud.computecanada.ca

Arbutus Cloud (new): https://arbutus.cloud.computecanada.ca

Firefox and Chrome browsers are supported. Safari and Edge may work but are not validated.

Your Project (Tenant), Network, and Router will be pre-created for you in Arbutus Cloud. User access will also be pre-populated.

Prior to migrating instances, we recommend that you complete the following preliminaries to prepare the necessary environment for migration.

IMPORTANT: Backup any critical data. While the Cloud has redundant storage systems, no backups of any instances are taken.

  1. Get RC files (used to set environment variables used by the OpenStack command-line tools) after logging in to the URLs above with your Compute Canada credentials:
    • West Cloud: Under Compute -> Access & Security -> API Access tab, select the “Download OpenStack RC File” button.
    • Arbutus Cloud: Under Project -> API Access -> Download OpenStack RC File (use the OpenStack RC File (Identity API v3) option.
  2. Copy the OpenStack RC files to the migration host cloudmigration.computecanada.ca; use your Compute Canada credentials for access.
  3. Open 2 SSH sessions to the migration host, one for the legacy cloud and one for the new cloud. It is recommended that you use the screen command in your sessions to maintain them in case of SSH disconnections (consult the many screen tutorials available on the Internet if you have never used screen before). In your legacy SSH session, source the RC file (source oldcloudrc.sh) from the legacy cloud, and in the other SSH session, source the RC file from the new cloud (source newcloudrc.sh). Test your configuration by running a simple openstack command, e.g. openstack list
  4. Migrate SSH key(s):
    • Using the Horizon dashboard on West Cloud, navigate to Access & Security -> Key Pairs. Click on the key pair name you want to retrieve the public key for and copy the public key value.
    • Using the Horizon dashboard on Arbutus Cloud, navigate to Compute -> Key Pairs.
    • Click Import Public Key: give your Key Pair a name and paste in the public key from West Cloud.
    • Your Key Pair should now be imported into Arbutus Cloud. Repeat this step as necessary.
    • You can also generate new Key Pairs if you choose.
    • Key Pairs can also be imported via the CLI as follows:
    openstack keypair create --public-key <public-keyfile> <name>
  5. Migrate security groups and rules:
    • On West Cloud, under Compute -> Access & Security -> Security Groups, note the currently existing security groups and their associated rules.
    • On Arbutus Cloud, under Network -> Security Groups, re-create the security groups and their associated rules as needed.
    • Do not delete any of the Egress security rules for IPv4 and IPv6 created by default. Deleting these rules can cause your instances to fail to retrieve configuration data from the OpenStack metadata service and a host of other issues.
    • Security groups and rules can also be created via the CLI as follows (rule shown is an example for HTTP port 80 only, adjust accordingly per your requirements):
    openstack security group create <group-name>
    openstack security group rule create --proto tcp --remote-ip 0.0.0.0/0 --dst-port 80 <group-name>
    • To view rules via the CLI (will list the available security groups):
    openstack security group list
    • To view the rules in the group:
    openstack security group rule list
  6. Plan an outage window. Generally, shutting down services and the instance(s) is the best way to avoid corrupt or inconsistent data after the migration. Smaller volumes should copy over fairly quickly i.e. within minutes, but larger volumes will take longer. Plan accordingly for this. Additionally, floating IP addresses will change, so ensure the TTL of your DNS records is set to a small value so that the changes propagate as quickly as possible.

There are three general migration scenarios to consider. Depending on your applications and current instance setup, you may use any or all of these scenarios to migrate from the West Cloud to the Arbutus Cloud.

Manual or orchestrated migration[edit]

In essence, this will be a “net new” infrastructure provisioning. Instances and volumes are created in Arbutus with the same specifications as that on West Cloud. The general approach would be:

  1. Copy any glance images from West Cloud to Arbutus Cloud if you are using any customized images. You may also simply start with a fresh base image in Arbutus Cloud.
  2. Install and configure services on the instance(s).
  3. Copy data from the old instance(s) to the new instance(s); see the section on methods to copy data.
  4. Assign floating IP(s) to the new instance(s) and update DNS.
  5. Decommission old instance(s) and delete old volume(s).

The above steps can be done manually or orchestrated via various configuration management tools. The use of such tools is beyond the scope of this document, but if you were already using orchestration tools on West Cloud, they should work with Arbutus Cloud as well.

Migrating volume-backed instances[edit]

Volume-backed instances as their name implies have a persistent volume attached to them containing the operating system and any required data. General best practices would involve a smaller volume for the operating system and a larger volume for data sets.

Migration using Glance images[edit]

This method is recommended for volumes less than 150GB in size. For volumes larger than that, creating new volumes in Arbutus Cloud and copying the required data across from West Cloud is preferred to creating Glance images and transferring the images between clouds.

  1. SSH to the migration host cloudmigration.computecanada.ca with your Compute Canada credentials.
  2. In one session, source the OpenStack RC file for West Cloud. In the other session, source the OpenStack RC file for Arbutus Cloud. As mentioned earlier, use of the screen command is recommended in case of SSH disconnections.
  3. In the West Cloud web UI, create an image of the desired volume (Compute -> Volumes and Upload to Image from the drop down menu). It is recommended that the volume is not in use, but the force option can be used if it is. The command line can also be used to do this:
    cinder --os-volume-api-version 2 upload-to-image <volumename> <imagename> --force
  4. Once the image is created, it will show up under Compute -> Images with the name specified in the previous step. You can obtain the id of the image by clicking on the name.
  5. In the West Cloud session on the migration host, download the image (replace the <filename> and <imageid> with real values):
    glance image-download --progress --file <filename> <imageid>
  6. In the Arbutus Cloud session on the migration host, upload the image (replace the <filename> with the name from the previous step; the <imagename> can be anything)
    glance image-create --progress --visibility private --container-format bare --disk-format qcow2 --name <imagename> --file <filename>
  7. A volume can now be created from the uploaded image. In the Arbutus Cloud web UI, navigate to Compute -> Images. The uploaded image from the previous step should be there. In the drop down menu for the image, there is an option to Create Volume. Select this option and the volume will be created from the image. The created volume can then be attached to instances or used to boot a new instance.
  8. Once your instances/volumes are migrated & validated and any associated DNS records updated, please delete your old instances/volumes on the legacy West Cloud.

Alternative method: Migrating a volume-backed instance using Linux 'dd'[edit]

  1. Launch a temporary instance on West Cloud with the smallest flavor possible “p1-1.5gb”. The instructions below assume CentOS 7, but any Linux distribution with Python and Pip available should work.
  2. Login to the instance via SSH and install the OpenStack CLI in a root shell:
    yum install epel-release
    yum install python-devel python-pip gcc
    pip install python-openstackclient
  3. The OpenStack CLI should now be installed. To verify, try executing openstack on the command line. For further instructions, including installing the OpenStack CLI on systems other than CentOS, see: https://docs.openstack.org/newton/user-guide/common/cli-install-openstack-command-line-clients.html
  4. Copy your OpenStack RC file from Arbutus to the instance and source it. Verify that you can connect to the OpenStack API on Arbutus by executing the following command:
    openstack image list
  5. Delete the instance to be moved; however do NOT delete the volume it is attached to.
  6. The volume is now free to be attached to the temporary migration host we created. Attach the volume to the temporary migration host by going to Compute -> Volumes in the West Cloud web UI. Select “Manage Attachments” from the drop down menu and attach the volume to the temporary migration host.
  7. Note the device that the volume is attached as (typically /dev/vdb or /dev/vdc).
  8. Use the dd utility to create an image from the attached disk of the instance (You can call the image whatever you prefer other than the example “volumemigrate”. When the command completes, you will receive output showing the details of the image created):
    dd if=/dev/vdb | openstack image create --private --container-format bare --disk-format raw "volumemigrate"
  9. You should now be able to see the image under Compute -> Images in the Arbutus Cloud web UI. This image can now be used to launch instance(s) on Arbutus. Make sure to create a new volume when launching the instance if you want the data to be persistent.
  10. Once your instances/volumes are migrated & validated and any associated DNS records updated, please delete your old instances/volumes on the legacy West Cloud.

Migrating ephemeral instances[edit]

Migration using Glance images and volume snapshots[edit]

This method is recommended for instances with ephemeral storage less than 150GB in size. For instances with storage larger than that, creating new instances in Arbutus Cloud and copying the required data across from West Cloud is preferred to creating Glance images and transferring the images between clouds. You will still need to copy data from any non-boot ephemeral storage (i.e. mounted under /mnt) separately. Consult the section on methods to copy data for this.

  1. SSH to the migration host cloudmigration.computecanada.ca with your Compute Canada credentials.
  2. In one session, source the OpenStack RC file for West Cloud. In the other session, source the OpenStack RC file for Arbutus Cloud. As mentioned earlier, use of the screen command is recommended in case of SSH disconnections.
  3. In the West Cloud web UI, create a snapshot of the desired instance (Compute -> Instances and Create Snapshot from the drop down menu). The CLI can also be used:
    nova list
    nova image-create --poll <instancename> <snapshotname>
  4. The snapshot created in the previous step will show up under Compute -> Images. You can obtain the id of the snapshot by clicking on the name.
  5. In the West Cloud session on the migration host, download the snapshot (replace the <filename> and <imageid> with real values):
    glance image-download --progress --file <filename> <imageid>
  6. In the Arbutus Cloud session on the migration host, upload the snapshot (replace the <filename> with the name from the previous step; the <imagename> can be anything)
    glance image-create --progress --visibility private --container-format bare --disk-format qcow2 --name <imagename> --file <filename>
  7. New instances can now be launched on Arbutus Cloud from this image.
  8. Once your instances/data are migrated & validated and any associated DNS records updated, please delete your old instances on the legacy West Cloud.

Alternative method: Migrating an ephemeral instance using Linux 'dd'[edit]

  1. Login to the instance running on West Cloud via SSH. When migrating an ephemeral instance (an instance without a backing volume as aforementioned), it is important to shut down as many unnecessary services as possible on the instance prior to migration e.g. httpd, databases, etc. Ideally, leave only SSH running.
  2. As root, install the OpenStack CLI if not already installed:
    yum install epel-release
    yum install python-devel python-pip gcc
    pip install python-openstackclient
  3. The OpenStack CLI should now be installed. To verify, try executing openstack on the command line. For further instructions, including installing the OpenStack CLI on systems other than CentOS, see: https://docs.openstack.org/newton/user-guide/common/cli-install-openstack-command-line-clients.html
  4. Copy your OpenStack RC file from Arbutus to the instance and source it. Verify that you can connect to the OpenStack API on Arbutus by executing the following command:
    openstack image list
  5. The root disk on the instance is typically /dev/vda1; verify this using the df command.
  6. Use the dd utility to create an image from the root disk of the instance (You can call the image whatever you prefer other than the example “ephemeralmigrate” above. When the command completes, you will receive output showing the details of the image created):
    dd if=/dev/vda | openstack image create --private --container-format bare --disk-format raw "ephemeralmigrate"
  7. You should now be able to see the image under Compute -> Images in the Arbutus Cloud web UI. This image can now be used to launch instance(s) on Arbutus.
  8. Once your instances/data are migrated & validated and any associated DNS records updated, please delete your old instances on the legacy West Cloud.

Methods to copy data[edit]

There are a couple of recommended approaches for copying data between instances running in the two clouds. The most appropriate method would depend upon the size of the data volumes in your tenant. For very large volumes greater than 5TB, Globus is recommended. Please see here for configuration details: https://computecanada.github.io/DHSI-cloud-course/globus/

If you have very large volumes, we recommend submitting a support ticket as well.

For volumes in the several hundred GB to low TB range, rsync+ssh provides good transfer speeds and can also work in an incremental way. A typical use case would be:

  1. SSH to the West Cloud instance which has the large volume attached and note the absolute path you want synced over to the instance on Arbutus Cloud.
  2. Execute rsync over SSH (the example below assumes that password-less login via keys has already been setup between the instances). Replace the placeholders above with real values:
    rsync -avzP -e 'ssh -i ~/.ssh/key.pem' /local/path/ remoteuser@remotehost:/path/to/files/
  3. Validate the data successfully copied over on the instance in Arbutus Cloud. Please delete any data from the legacy West Cloud once you have completed validation on Arbutus Cloud.

You may also use any other method you are familiar with for transferring data.

Support[edit]

Support requests can be sent to the usual Cloud support address at cloud@computecanada.ca