Arbutus Migration Guide: Difference between revisions

Arbutus Migration Guide (view source)

Revision as of 18:52, 26 October 2018

34 bytes added , 6 years ago

→‎Preliminaries: language & style

Rdickson

Bureaucrats, cc_docs_admin, cc_staff

2,879

edits

@@ Line 7: / Line 7: @@
 == 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 two Clouds:
 '''West Cloud (legacy):''' [https://west.cloud.computecanada.ca https://west.cloud.computecanada.ca]
@@ Line 13: / Line 13: @@
 '''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 have not been validated.
 Your Project (Tenant), Network, and Router will be pre-created for you in Arbutus Cloud. User access will also be pre-populated.
@@ Line 19: / Line 19: @@
 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''': Back up 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:
 #* 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.
-# Copy the OpenStack RC files to the migration host ''cloudmigration.computecanada.ca''; use your Compute Canada credentials for access.
+# Copy the OpenStack RC files to the migration host ''cloudmigration.computecanada.ca''. Use your Compute Canada credentials for access.
-# 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 <code>screen</code> 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 (<code>source oldcloudrc.sh</code>) from the legacy cloud, and in the other SSH session, source the RC file from the new cloud (<code>source newcloudrc.sh</code>). Test your configuration by running a simple openstack command, e.g. <code>openstack list</code>
+# Open two SSH sessions to the migration host: One for the legacy cloud and one for the new cloud. We recommend that you use the <code>screen</code> command in your sessions to maintain them in case of SSH disconnections. (Consult the many [https://www.google.com/search?q=screen+ssh screen tutorials] available on the Internet if you have never used screen before.) In your legacy SSH session, source the RC file (<code>source oldcloudrc.sh</code>) from the legacy cloud, and in the other SSH session, source the RC file from the new cloud (<code>source newcloudrc.sh</code>). Test your configuration by running a simple openstack command, e.g. <code>openstack list</code>
-# Migrate SSH key(s):
+# Migrate SSH keys:
-#* 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 West Cloud, navigate to Access & Security -> Key Pairs. Click on the name of the key pair you want 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.
+#* Your Key Pair should now be imported into Arbutus Cloud. Repeat the above steps for as many keys as you need.
 #* You can also generate new Key Pairs if you choose.
 #* Key Pairs can also be imported via the CLI as follows:
 #: <code>openstack keypair create --public-key <public-keyfile> <name></code>
 # 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 West Cloud, under Compute -> Access & Security -> Security Groups, note the 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):
+#* Security groups and rules can also be created via the CLI as follows. An example is shown for HTTP port 80 only; modify it according to your requirements:
 #: <code>openstack security group create <group-name></code>
 #: <code>openstack security group rule create --proto tcp --remote-ip 0.0.0.0/0 --dst-port 80 <group-name></code>
-#* To view rules via the CLI (will list the available security groups):
+#* To view rules via the CLI:
-#: <code>openstack security group list</code>
+#: <code>openstack security group list</code> to list the available security groups.
-#* To view the rules in the group:
+#: <code>openstack security group rule list</code> to view the rules in the group.
-#: <code>openstack security group rule list</code>
+# Plan an outage window. Generally, shutting down services and then shutting down the instance is the best way to avoid corrupt or inconsistent data after the migration. Smaller volumes can be copied over fairly quickly, i.e. within minutes, but larger volumes will take longer. Plan 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.