Note: Please go to docs.rightscale.com to access the current RightScale documentation set. Also, feel free to Chat with us!
Home > ServerTemplates > v12.11 LTS > Supplemental > 11H1 to v12.11 LTS Migration

11H1 to v12.11 LTS Migration

Objective

To migrate a running production deployment where the servers are based off of the 11H1 compatibility release ServerTemplates to the new v12.11 LTS/Infinity release, which uses Chef-based instead of RightScript-based ServerTemplates.

Table of Contents

Prerequisites

  • 'actor', 'designer', 'library' user role privileges
  • An operational deployment that contains database servers that are based off of the Database Manager with MySQL 5.0 - 11H1 or Database Manager with MySQL 5.1 - 11H1 ServerTemplates.

Overview

This tutorial describes the best practices for performing a live migration on an active deployment.

Warning!  It's strongly recommended that you first perform the migration procedure on a staging deployment before performing a live migration on a production environment.

Steps

Prepare Production Deployment for Migration

Clone Production Deployment

As a safety precaution, you should clone the production deployment before you perform any of the migration steps below so that you will have a "backup" deployment that you can use to revert back to the original setup if you experience problems during the migration process. 

(Optional) You may want to launch servers in the "backup" deployment so that they are operational and ready to be put into service if you need to failover to the cloned deployment. Be sure to change their inputs accordingly so that the servers do no accidentally steal public IP addresses (e.g. Elastic IPs) from your production servers or update DNS records for your production site.

Create a Backup

As a safety precaution, create a final backup of the database before you begin the migration process. 

  1. Go to the master database server's Scripts tab and run the db::do_primary_backup operational script.
  2. (Optional) Create a secondary backup. (db::do_secondary_backup)

Record Current Inputs

You should also create a report of the deployment's current input settings so that you have a reference of your current inputs settings prior to the migration process.

  1. Go to the production deployment's Inputs tab and click the Download CSV of External References button and save the .csv file for archiving purposes.

Load Balancing Tier Migration

The next step is to duplicate the load balancing tier in the new deployment. For example, if you're using RightScale's HAProxy load balancer ServerTemplates, add two new load balancers to the new deployment.

  1. Import the Load Balancer with HAProxy ServerTemplate from the MultiCloud Marketplace and use the ServerTemplate to add a server to the production deployment.
  2. Go to the deployment's Inputs tab and specify the following parameters. The inputs of the new Chef-based ServerTemplates have a slightly different syntax than their RightScripts counterparts. Therefore, you will need to update the Chef-based inputs with the appropriate values that are probably already defined for inputs with similar names. Use the table below to map the old inputs with the new inputs. You will need to update the following missing inputs for the Chef-based ServerTemplate.

 

Input Name (11H1) Input Name (v12.11)
Example Value
APPLICATION Application Name

text:  myapp

WEBSITE_DNS Virtual Host Names

text:  default

HEALTH_CHECK_URI Health Check URI

text: /

 

Launch the Servers

Launch the new load balancer servers.

Application Tier Migration

For the 11H1 application ServerTemplates, you could use different scripts to retrieve application code from a software repository (e.g. SVN) or an Amazon S3 bucket. The v12.11 LTS/Infinity releases have scripts that can retrieve application code from other ROS locations (e.g. Amazon S3, Rackspace Cloud Files, etc.) or software repositories (e.g. GitHub or SVN). 

  1. Import the PHP App Server ServerTemplate from the MultiCloud Marketplace and use the ServerTemplate to add a server to the migration deployment.
  2. Go to the deployment's Inputs tab and specify the following parameters. The inputs of the new Chef-based ServerTemplates have a slightly different syntax than their RightScript counterparts. Therefore, you will need to update the Chef-based inputs with the appropriate values that are probably already defined for inputs with similar names. Use the table below to map the old inputs with the new inputs. You will need to update the following missing inputs for the Chef-based ServerTemplate.

 

Input Name (11H1) Input Name (v12.11)
Example Value
MASTER_DB_DNSNAME  Database Master FQDN  text:  my-master.example.com
N/A MySQL Version

text: 5.1

APPLICATION Application Name

text:  myapp

APPLICATION_CODE_BUCKET ROS Container text:  my-bucket
APPLICATION_CODE_PACKAGE ROS Prefix

(11H1) text: myapp.tgz

(v12.11) text: myapp

AWS_ACCESS_KEY_ID ROS Storage Account ID cred:  AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY  ROS Storage Account Secret cred:  AWS_SECRET_ACCESS_KEY
DBAPPLICATION_PASSWORD Database Application Password cred:  DBAPPLICATION_PASSWORD
DBAPPLICATION_USER Database Application User cred:  DBAPPLICATION_USER
SVN_APP_REPOSITORY Repository URL

text:  http://mysvn.net/app

OPT_SVN_PASSWORD SVN Password cred: SVN_PASSWORD
OPT_SVN_USERNAME SVN Username

cred: SVN_USER

N/A Repository Provider text:  repo_ros
N/A Repository Branch/Tag/Commit  text:  my_branch
DB_SCHEMA_NAME Database Schema Name

text: myschema

 

Launch the Servers

Launch the new application servers.

Database Tier Migration

Add Tags

In the v12.11 LTS release that's based on Chef cookbooks and recipes, tags are used to identify the different types of servers (e.g. load balancer, application server, etc.). Scripts use the tags to perform various operations across servers in a deployment to allow/deny access to a particular server. For the database tier, tags are used to identify the "master" and "slave" database servers to each other as well as grant access based on those same tags.

  1. Go to the Info tab of the current "master" database server (that's based off of an '11H1' Database Manager with MySQL 5.0/5.1 ServerTemplate).
    screen_11H1-DB-Tags_v1.png
  2. Click the Edit Tags text link on the current master info tab. You will need to add the following tags with information that's specific to your master database server.
    • rs_dbrepl:master_active=true
    • rs_dbrepl:master_instance_uuid=<RIGHTSCALE_UUID>
    • server:private_ip_0=<PRIVATE_IP_ADDRESS>
    • ec2:instance_id=<EC2_INSTANCE_ID>


screen_12H1-DB-Tags_v1.png

Add a new v12.11 Database Server

The next step is to add a new database server to the production deployment using the new v12.11 LTS version of the ServerTemplate. This server will become a slave of the current master database server. Later, you will promote it to become the new master database server.

For detailed instructions on how to add a server and configure the inputs correctly, see the Database Manager for MySQL 5.1/5.5 Database Setup tutorial.

  1. Import the Database Manager for MySQL 5.1 or Database Manager for MySQL 5.5 ServerTemplate from the MultiCloud Marketplace and add a server to the production deployment. Name the server accordingly. It will eventually become the new master database server. (e.g. new-db1)
  2. Go to the deployment's Inputs tab and specify any missing inputs that are required. See the tutorial referenced above for details. The inputs of the new Chef-based ServerTemplates have a slightly different syntax than their RightScript counterparts and are grouped by their cookbook name instead of a RightScript category. Therefore, you will need to update the Chef-based inputs with the appropriate matching values of the 11H1 inputs. Many of the inputs have similar names. Use the table below to map the 11H1 inputs with the new Chef-based inputs. You must use the same values for the following inputs.

 

Input Name (11H1) Input Name (v12.11)
Example Value
DBADMIN_PASSWORD Database Admin Password

cred:  DBADMIN_PASSWORD

DBADMIN_USER Database Admin Username

cred:  DBADMIN_USER

DBREPLICATION_PASSWORD Database Application Password

cred:  DBREPLICATION_PASSWORD

DBREPLICATION_USER

Database Application Username

cred:  DBREPLICATION_USER

MASTER_DB_DNSID Database Master DNS Record ID text: 1234567
MASTER_DB_DNSNAME Database Master FQDN text:  my-master.example.com
SLAVE_DB_DNSID Database Slave DNS Record ID text:  2223334
DNS_PASSWORD DNS Password cred: DNS_PASSWORD
DNS_PROVIDER DNS Service Provider text:  DNSMadeEasy
DNS_USER DNS User cred: DNS_USER
EBS_STRIPE_COUNT Number of Volumes in the Stripe (1)

Important! If you are using volumes, you must use the same stripe count.

text: 1

DB_SCHEMA_NAME Database Schema Name text: myschema

 

  1. Change the Database Lineage Name
    Important!  Specify a different value than the 11H1 lineage name so the backup snapshots of the new (v12.11) database servers will have a different lineage name and not be accidentally confused with the 11H1 backups.
Input Name (11H1) Input Name (v12.11)
Example Value
DB_LINEAGE_NAME Database Backup Lineage

11H1
text: original_lineage

v12.11
text: new_lineage

 

  1. Change the Total Volume Size
    For improved performance, the new Database Manager now takes a local LVM snapshot of your data before persisting it to the cloud. To support this feature, by default, 10% of your 'Total Volume Size' will be reserved for the local snapshot and is not available for data storage. 

    Important! Because this is not a true migration, but rather a modification of the filesystem created by the 11H1 Database Manager, you must increas e the 'Total Volume Size' to account for the space required for LVM snapshots. Therefore, you cannot use the same value that you used for the 11H1 setup because it must be at least 10% larger. For example, if the 11H1 database server setup has the 'EBS_TOTAL_VOLUME_GROUP_SIZE' input set to 10GB, you must set the 'Total Volume Size (1)' input to 11GB (or larger) for the v12.11 setup.

    Note: If you are pushing the limits of your current storage allocation on your 11H1 Database Server, you may want to grow your storage and increase the 'Total Volume Size (1)' input by more than 10%.

 

Input Name (11H1) Input Name (v12.11)
Example Value
EBS_TOTAL_VOLUME_GROUP_SIZE Total Volume Size (1)

Important!  Specify a new value that is at least 10% larger than the value that was used for the 11H1 database servers. 

11H1
text: 10

v12.11
text: 11

N/A Percentage of the LVM used for data (1)

Important!  If you change the default value (90) for this input, you must change the 'Total Volume Size (1)' input proportionally. For example, if you change this value to 75, you must increase the value for the 'Total Volume Size (1)' input by at least 25%.

text: 90

 

  1. Save the changes to the inputs.

Launch the v12.11 Database Servers

  1. Launch the new v12.11 database server. (e.g. new-db1)
  2. Locate the most recently completed 11H1 lineage based  backup snapshot. Note: The snapshot must be "completed 100%" before you Go to Clouds > AWS Region > EBS Snapshots.

     

    screen_11H1-Snapshot-Tags_v1.png

  3. Once the server becomes operational, go to the "current" server's Inputs tab and set the following inputs:
Input Name (v12.11) Description
Example Value
Database Replication Password Specify the password that will be used for replication purposes between the master and slave database servers. cred:  DBREPLICATION_PASSWORD
Database Replication Username Specify the username that will be used for replication purposes between the master and slave database servers. cred:  DBREPLICATION_USER
Database Restore Lineage Override Enter the lineage name for the 11H1 ServerTemplates. The value should be the same as the DB_LINEAGE_NAME input.

text:  11H1-lineage

Backup restore version check Set this value to 'true' if you are using the same MySQL version. (e.g. 5.1) Set to 'false' if you are changing MySQL versions and want to ignore the version check. (e.g. 5.1 to 5.5)

text:  true

Database Restore Timestamp Override Since you are restoring the database using an existing backup snapshot, enter the specific timestamp of the snapshot.

text: 1340833987

  1. Save the input changes.
  2. Go to the "current" 12.11 server's Scripts tab and run the db::do_primary_init_slave operational script.
  3. Wait for the script to be completed and the volume(s) to be attached to the server. A primary backup will also be initiated on the v12.11 database server, which is currently a slave of the 11H1 master database server. Check the server's Volumes tab and wait for the volume to be "attached" before proceeding to the next step.
  4. (Optional) If you are performing this migration on a live production environment, you may want to take your site temporarily offline and put up a maintenance page on your site.
  5. Before you promote the v12.11 database server to become the new "master" database server, you should first check the replication status between the master and slave database servers. SSH into the v12.11 database server, which is currently a slave of the 11H1 master database server and make sure it is fully caught up with the master before you perform a promotion. (e.g. Seconds_Behind_Master: 0)
    • # sudo -i mysql
      mysql> show slave status \G;
  6. SSH into the current master database server (11H1) and stop MySQL to lock the database and prevent any new writes to the database during the database migration.
    • mysql> service mysql stop
      
  7. Under the "current" 12.11 server's Scripts tab and run the db::do_promote_to_master operational script. The DNS record that points the "master" database server ('Database Master DNS Record ID' input) will be updated with your DNS provider with the server's private IP address and a new backup will be created using the new database lineage name ('Database Backup Lineage' input). MySQL will also be started automatically.
  8. Wait for the new backup to be 100% complete.
  9. Clone the new 12.11 "master" database server. Rename the server and change its availability zone accordingly. (e.g. new-db2) The cloned server will become a slave of the new master database server. 
  10. Terminate the old 11H1 database servers.
  11. Launch the cloned 12.11 server. (e.g. new-db2)
  12. At the input confirmation screen, change the Init Slave at Boot input under the "Advanced" section of the DB inputs to the "text:true" dropdown option. Note: You will need to click the "Show advanced" input option to view this input. Click the Launch (not the Save and Launch) button since you only want to launch the server at this particular time to become a slave database server.
  13. Once the new slave database server becomes fully operational you will have a redundant database tier using the new v12.11 ServerTemplates.

     

Post Tutorial Steps

Deployment Clean-up

  1. Remove the old 11H1 servers from the deployment so that only the new v12.11 servers and related inputs are listed.
  2. Remove the values that you used to perform the database migration for the "override" inputs to ensure that if you need to promote the new slave to master that it will not try and use an old 11H1 backup. Go to each (v12) server's "current" Inputs tab and remove the specified values for the following inputs. Also, no values should be set for these inputs at the deployment level.
    • Database Restore Lineage Override
    • Database Restore Timestamp Override
You must to post a comment.
Last modified
00:37, 17 May 2013

Tags

Classifications

This page has no classifications.

Announcements

None


© 2006-2014 RightScale, Inc. All rights reserved.
RightScale is a registered trademark of RightScale, Inc. All other products and services may be trademarks or servicemarks of their respective owners.