Note: Please go to docs.rightscale.com to access the current RightScale documentation set. Also, feel free to Chat with us!
Home > ServerTemplates > v13.5 LTS > Supplemental > 3 Tier Deployment Setup (ELB-Tomcat6-MySQL)

3 Tier Deployment Setup (ELB-Tomcat6-MySQL)

Table of Contents

Objective

To create a 3-tiered production-like deployment in Amazon EC2 using Amazon's Elastic Load Balancing service and ServerTemplates published by RightScale for launching an Tomcat application.

Table of Contents

  1. Overview
  2. Deployment Setup
  3. Database Setup
  4. Load Balancer Setup
  5. Application Setup
  6. Test the Deployment
  7. Next Steps

Prerequisites

  • Access to add/create/edit DNS records with a supported DNS provider (e.g. DNSMadeEasy, DynDNS, Route53)
  • A paid edition of RightScale.
  • 'designer' 'actor' and 'security_manager' user role privileges are required, although the 'security_manager' user role privilege may not be required if security group with the appropriate firewall permissions already exist.

Overview

Although this end-to-end tutorial was originally designed as a hands-on exercise in an Instructor Led Training course, anyone can follow the tutorial and use it as a learning tool as well. The class environment influences naming conventions, hence we often precede names with initials or names in our examples. (For example, an A Record for John Doe named "jd-www", rather than simply "www"). Be sure to provide enough time for yourself to complete the end-to-end exercise. (Estimate: 1-3hrs) 

This tutorial will demonstrate how to build a common 3-tier website architecture in the cloud using some of RightScale's ServerTemplates. 

  • Amazon Elastic Load Balancing
  • Tomcat Application servers
  • MySQL Database servers

 

diag-3tierELB-v1.png

Disclaimers

  • This tutorial assumes that you are launching all servers into the same Amazon EC2 region. 
  • As a best practice, it's encouraged to deploy over multiple Datacenters / Zones (if supported by the cloud) for high-availability.

Deployment Setup

Create a Deployment

It's recommended that you create a new deployment for each new project or reference architecture that you're going to build because you do not want to accidentally inherit any unknown configuration settings.

See Create a New Deployment. (Requires 'actor' user role privileges.)

Tip: It's recommended that you create a bookmark to the deployment's Servers tab for quick navigation back to the deployment at any time.

Create DNS Records

In a typical 3-tier architecture setup, DNS A records are used to create fully qualified domain names (FQDNs) that map to a particular server or tier of servers. The digram below shows a typical example of a 3-tier website architecture.

For example, the application servers locate the "master" database server by using Master-DB's FQDN (e.g., db-master.example.com), which points to the Master-DB's private IP address. Similarly, front-end web traffic can be routed to a FQDN (e.g. www.example.com) where each load balancer server has a DNS record for that FQDN so that incoming requests are routed to one of the load balancer servers. Since the IP address of an instance in the cloud is often dynamically assigned at launch time, you are required to use a DNS provider that supports dynamic DNS (i.e. the ability to dynamically update the IP address of an A record) for the Master-DB server (at a minimum). You can also use the same DNS provider for creating FQDNs for the load balancer servers. However, since they do not require the use of dynamic DNS, any DNS provider can be used.

TTLs

When you create the DNS records, it's important to set appropriate TTLs to ensure that servers will not stay connected to an old IP address that is no longer assigned to a functional server. For example, the DNS record that points to the "master" database server should have a low TTL to ensure that the application servers will connect to the correct server within a reasonable amount of time. It's strongly recommended that you use a TTL of 60 seconds for the DNS record that points to the "master" database server.

diag-3tier_ELB_DNS-v1.png

You will need to create DNS records for the database servers and a CNAME for the Elastic Load Balancer:

  • Elastic Load Balancer
  • Master Database Server
  • Slave Database Server (optional)


RightScale's ServerTemplates contain scripts that support one of the following DNS providers. Create an account with one of the DNS providers below and set up the A records accordingly.

Create Common Credentials

Prerequisites: Requires 'designer' user role privileges in the RightScale account to create a new credential.

Important!
Only the user who created the credential and any 'admin' users will be able to view and modify an existing credential. 

Credentials are a way of passing sensitive information to a script (as an input) in a discrete manner without making the actual value visible in the Dashboard. As a best practice, many of the ServerTemplates published by RightScale are preconfigured to use certain credentials. It's recommended that you create these common credentials in your own account. If they already exist and apply to a different deployment, you might want to create a new set of credentials to avoid any conflicts. In such cases, it's helpful to use a common prefix to group the credentials together. (e.g. APP1_DBADMIN_USER)

If you try to launch a server where one of the inputs references a credential that does not exist in the RightScale account, you will receive an error message and will not be able to launch the server. Therefore, it's best to create any required credentials before you configure and launch a server. Depending on your cloud provider and backup storage selections, you may want to create additional credentials.

At a minimum, create the following credentials. See Create a New Credential for more information.

Common Credentials for a 3-Tier Architecture

If you are going through a 3-tier tutorial you should create the following credentials with your own values or you can use the example values, if desired.

  • DBADMIN_USER - Username of a database user with administrator privileges. Use this credential for the "Database Admin Username" input.
    • 3 Tier Tutorial: admindb
  • DBADMIN_PASSWORD - Password for DBADMIN_USER. Use this credential for the "Database Admin Password" input.
    • 3 Tier Tutorial: admindb
       
  • DBAPPLICATION_USER - User name of a database user with user-level privileges. Use this credential for the "Database Application Username" input.
    • 3 Tier Tutorial: 1234
  • DBAPPLICATION_PASSWORD - Password for DBAPPLICATION_USER. Use this credential for the "Database Application Password" input.
    • 3 Tier Tutorial: 1234
       
  • DBREPLICATION_USER - Username of a database user with replication permissions on the server. Use this credential for the "Database Replication Username" input.
    • 3 Tier Tutorial: dbrpl
  • DBREPLICATION_PASSWORD - Password for DBREPLICATION_USER. Use this credential for the "Database Replication Password" input.
    • 3 Tier Tutorial: dbrpl
       
  • DNS_USER* - Username that's used to log into your DNS provider and update DNS records. It's commonly used to update the A record with the private IP address of the "master" database server. Use this credential for the "DNS User" input.
  • DNS_PASSWORD* - Password for DNS_USER. Use this credential for the "DNS Password" input.

If you use Amazon Route 53 or Rackspace Cloud DNS as your DNS provider, you do not need to set up separate DNS user name and password credentials because your cloud credentials are used for authentication purposes. 

Remote Object Storage (ROS)

ServerTemplates published by RightScale have built-in support for several remote object storage (ROS) solutions. Valid cloud credentials are required to retrieve "private" files from an ROS container, create a new container, or store files in a container (such as a binary database backup files). It's recommended that you create the following credentials before you start building a deployment for each ROS service you plan to use.

Amazon S3

The following credentials are automatically created for you when you add AWS cloud credentials to a RightScale account. Although, they are available for use when you define your inputs, they will not be listed with the other credentials. (Design > Credentials). Note: AWS credentials are located at the account level (Settings > Account Settings > Clouds). See Sign up for Amazon Web Services (AWS).

  • AWS_ACCESS_KEY_ID - Amazon access key ID for authentication.
  • AWS_SECRET_ACCESS_KEY - Amazon secret key corresponding to AWS_ACCESS_KEY_ID.
Rackspace Cloud Files

See Add Rackspace Open Cloud to a RightScale Account.

  • RACKSPACE_USERNAME - The username used to log into Rackspace's Cloud Control Panel. Use this credential for the "Backup Primary User" and/or the "Secondary Backup User" input if you are using Rackspace Cloud Files for primary and/or secondary backups. 
  • RACKSPACE_AUTH_KEY - The Rackspace account API key. Use this credential for the "Backup Primary Secret" and/or the "Secondary Backup Secret" input if you are using Rackspace Cloud Files for primary and/or secondary backups.
Google Compute Engine
  • GOOGLE_ACCESS_KEY -  (e.g. GO5MTPOCQSPF5MBCOTPO)
  • GOOGLE_SECRET_ACCESS_KEY - (e.g. G2tr2637tr2it/ivVoYi+pVoYw7tr291LXLcx2t+)
Microsoft Azure Blob Storage
  • AZURE_ACCOUNT_NAME - The Blob Storage Account Name. (e.g. myname)
  • AZURE_PRIMARY_ACCESS_KEY -  The Primary Access Key. (e.g. Fdu9hoCOnOznjWN5l2qhMZHaRu9HTtLYOs4ejE5aWzrybL1Q49jrCHTtLYOs4ejE5eymS+ErBGlMYA3mpz3siIg==)
OpenStack Object Storage (swift)
  • SWIFT_ACCOUNT_ID - OpenStack Object Storage (Swift) Account ID. (tenantID:username) (e.g. OSOS123456-1:123456)
  • SWIFT_ACCOUNT_PASSWORD - OpenStack Object Storage (Swift) Account Password. (e.g. 68734787202aecdef123767678asdf72364872asdf468273478237as287df67)
SoftLayer Object Storage

See Set up SoftLayer Object Storage.

  • SOFTLAYER_USER_ID - The username of a SoftLayer User with API privileges. Use this credential for the "Backup Primary User" and/or the "Secondary Backup User" input if you are using SoftLayer Object Storage for primary and/or secondary backups. (e.g. SLOS123456-1:SL123456) 
  • SOFTLAYER_API_KEY - The matching SoftLayer API Access Key for the specified SoftLayer user. Use this credential for the "Backup Primary Secret" and/or the "Secondary Backup Secret" input if you are using SoftLayer Object Storage for primary and/or secondary backups. (e.g. 68734787202aecdef123767678asdf72364872asdf468273478237as287df67)

Software Repositories

Source Control Management (SVN, GitHub, FTP, rsync)

If you are using a source control management (SCM) system to host your application code, you will need to create the appropriate credentials to retrieve your source code from the specified repository.

  • GIT_SSH_KEY - A valid SSH Key for accessing a private repository hosted on GitHub.com. Use this credential for the "Account credential" input. 
     
  • SVN_USERNAME - The SVN username that has access to the specified repository. Use this credential for the "Account name" input.
  • SVN_PASSWORD - Password for SVN_USERNAME. Use this credential for the "Account credential" input.

 

  • FTP_USERNAME - The username that you use to log into the FTP server to access your software repository. Use this credential for the "Account name" input.
  • FTP_PASSWORD - Password for FTP_USERNAME. Use this credential for the "Account credential" input.

Other

rsync

Download application source code from rsync sources.

  • RSYNC_USERNAME - The username to log into the remote host. Use this credential for the "Account name" input.
  • RSYNC_SSH_KEY - If the remote host supports SSH key authentication, create an SSH Key for rsyncing data between servers. Use this credential for the "Account credential" input.

Secure Sockets Layer (SSL)

Database

If you are using the public network to connect to the master database server, it's recommended that you use SSL to encrypt the data being transfered between the master database server and the associated slave and/or application servers. Note: SSL is currently only supported in the Database Manager for MySQL 5.1/5.5 ServerTemplates.

  • MYSQL_SSL_CERT - The name of your CA SSL Certificate.
  • MYSQL_SSL_MASTER_CERT - The name of your Master SSL Certificate.
  • MYSQL_SSL_MASTER_KEY - The name of your Master SSL Key.
  • MYSQL_SSL_SLAVE_CERT - The name of your Slave SSL Certificate.
  • MYSQL_SSL_SLAVE_KEY - The name of your Slave SSL Key.

Create Cloud-specific Resources

EC2

S3

Simple Storage Service (S3) is Amazon's remote object store (ROS) where you can store static files that can be used by EC2 instances in any AWS region. For example, you can store a database dump file in an S3 bucket and then launch an EC2 instance that will retrieve the file from the S3 bucket. S3 buckets are also used to store binary backups of a database. 


Database Tier Setup

Upload the Database Dump File

The ServerTemplate contains scripts that can retrieve a database dump file from a container in one of the supported Remote Object Storage (ROS) providers (e.g. Amazon S3, Rackspace Cloud Files). See Database Dump Retrieval.

Create a new bucket/container and upload your database dump file. The file can remain a 'private' object because your cloud credentials can be used (as inputs) for authentication purposes to retrieve the file. Supported file types include .gz, .bz2, and .zip.  Make sure the uploaded file maintains the its file extension.

Warning! The filename of the MySQL dump file cannot contain a dash (-) in its prefix name. For example, if your dump file is named, 'my-app-201205030022.gz', you must manually rename it to be 'my_app-201205030022.gz' where you use an underscore (_) to replace the dash, otherwise the script (do::do_dump_import) that imports the database dump file into the instance will fail.


If you are setting up a database server for testing purposes or if you do not have your own dump file, you can use the following sample MySQL dump file to complete the tutorial. The sample is a gzip (.gz) file.

Add a Server

Follow these steps to add a database server to the deployment.

  1. Go to the MultiCloud Marketplace (Design MultiCloud Marketplace > ServerTemplates) and import the most recently published revision of the following ServerTemplate into the RightScale account.
  2. From the imported ServerTemplate's show page, click the Add Server button.
  3. Select the cloud for which you will configure a server. 
  4. Select the deployment for the new server.
  5. Next, the Add Server Assistant wizard will walk you through the remaining steps that are required to create a server based on the selected cloud.
    • Server Name - Provide a nickname for your new database server (e.g., mysql-db1). Do not include "master" or "slave" in the name, because a database server's role can change in the future.
    • Select the appropriate cloud-specific resources (e.g. SSH Key, Security Group, etc.) that are required in order to launch a server into the chosen cloud. The required cloud resources may differ depending on the type of cloud infrastructure. If the cloud supports multiple datacenters/zones, select a specific zone. Later, when you create the other database server you will use a different datacenter/zone to ensure high-availability. For more information, see Add Server Assistant.
    • Important! If you are not using volumes to store the database, you must select an instance type that has disk space that's at least twice as large as your database because LVM snapshots are performed locally on the instance before they are gzipped and saved to the specified ROS location. Also, although these ServerTemplates will work with any instance size, you may experience degraded performance with small instance sizes (such as EC2 micro, Rackspace 256MB etc) due to lack of system resources. We do not recommend smaller instance types for production use.
  6. Click Confirm, review the server's configuration and click Finish to create the server.

Configure Inputs

The next step is to define the properties of your database server or servers by entering values for inputs. It is simplest and best to do this at the deployment level. For a detailed explanation of how inputs are defined and used in Chef recipes and RightScripts, see Understanding Inputs.

The inputs that you need to provide values for will depend on which options you're going to use. The ServerTemplate is very flexible and supports a variety of different configurations. You must provide values for the required inputs based on the chosen options.

  • Where will the contents of the database be stored?
    • On volumes attached to the instance.
    • On the local/ephemeral drive.
  • If you're using volumes, are you going to use a stripe?
    • Yes - Use a stripe of multiple volumes.
    • No - Use a single volume. 
    • INPUTS: Block Device Mount Directory (1), Nickname (1), Number of Volumes in the Stripe (1), Total Volume Size (1)
  • Are you building a master-slave database setup?
    • Yes
    • No
    • INPUTS: Database Master FQDN, Database Master DNS Record ID, Database Slave DNS Record ID, Database Replication Password, Database Replication Username
  • Will there be replication between master-slave database servers across different clouds/regions? If yes, you should set up SSL.
    • Yes
    • No
    • INPUTS: CA SSL Certificate, Master SSL Certificate, Master SSL Key, Slave SSL Certificate, Slave SSL Key
  • What are you going to use to take "primary" backups of the database?
    • Volume Snapshots
    • Binary Dumps to an ROS container (e.g. S3 bucket, Cloud Files container, etc.)
    • INPUTS: Primary Backup Secret (default), Primary Backup User (default), Primary Backup Storage Cloud (default), Primary Backup Storage Cloud Endpoint URL (default), Database Backup Lineage
  • Are you going to take "secondary" backups of the database? If yes, which ROS provider will you use?
    • Amazon S3, Rackspace Cloud Files (US or UK), Google Cloud Storage, Azure Blob Storage, Swift-based Storage, SoftLayer Object Storage
    • INPUTS: Secondary Backup Storage Cloud (default), Secondary Backup Secret (default), Secondary Backup User (default), Secondary Backup Storage Container (1), Secondary Backup Storage Cloud Endpoint URL (default), Secondary Backup Storage Container (2)
  • Which DNS provider are you using for dynamic DNS at the database level?
    • DNS Made Easy
    • DynDNS
    • Amazon Route 53
    • Rackspace Cloud DNS
    • INPUTS: DNS Service Provider, DNS Password, DNS User, Database Master FQDN, Database Master DNS Record ID, Database Slave DNS Record ID, Cloud DNS region

Set Inputs at the Deployment Level

Go to the deployment's Inputs tab (Manage > Deployments > your deployment > Inputs) and click Edit.

Although you can enter values for missing inputs as text values, it's strongly recommended that you set up credentials for passing sensitive information to scripts such as passwords or any other sensitive data.

Rackspace only
If you use Rackspace for your database servers and backup storage (i.e., Cloud Files) the storage-related Chef recipes will use Rackspace Service Net (SNET) by default. SNET is Rackspace's internal private networking service for optimized communication between Rackspace Cloud Servers and Cloud Files. If SNET is not supported in your Rackspace environment, you must set the "Rackspace SNET Enabled for Backup" input to false; otherwise, all backup and restore operations that rely on Cloud Files will fail.

Block Device

If the cloud supports the use of mountable volumes (e.g. AWS EBS Volumes, CloudStack volumes, etc.), primary backups will be saved as volume snapshots. It's strongly recommended that you use volumes to store the contents of the MySQL database for efficiency and performance reasons.

However, if the cloud does not support mountable volumes (e.g. Rackspace First Generation), primary backups must be saved to a Remote Object Storage location. In such cases, the contents of the MySQL database will be stored locally on the instance's ephemeral drive and backups of the database will be stored as binary dump files to the specified object storage container.

Required

Base

Input Name Description Example Value
Primary Backup Secret (default)

Input is ignored if volume snapshots are supported for taking primary backups.

Required cloud credential to store a file in the ROS location specified by the Primary Backup Storage Cloud (default) input.

  • Amazon S3 - AWS Secret Access Key (e.g. cred: AWS_SECRET_ACCESS_KEY)
  • Rackspace Cloud Files - Rackspace Account API Key (e.g. cred: RACKSPACE_AUTH_KEY)
  • Google Cloud Storage - Google Secret Access Key (e.g. cred: GOOGLE_SECRET_ACCESS_KEY)
  • Microsoft Azure Blob Storage - Microsoft Primary Access Key (e.g. cred: AZURE_PRIMARY_ACCESS_KEY)
  • Swift - OpenStack Object Storage (Swift) Account Password (e.g. SWIFT_ACCOUNT_PASSWORD)
  • HP - HP Secret Access Key (e.g. cred: HP_SECRET_ACCESS_KEY)
  • SoftLayer Object Storage - SoftLayer API Access Key (e.g. cred: SOFTLAYER_API_KEY)

No value/Ignore

cred:  AWS_SECRET_ACCESS_KEY

Primary Backup User (default)

Input is ignored if volume snapshots are supported.

Required cloud credential to store a file in the ROS location specified by the Primary Backup Storage Cloud (default) input.

  • Amazon S3 - Amazon Access Key ID (e.g. cred: AWS_ACCESS_KEY_ID)
  • Rackspace Cloud Files - Rackspace login username (e.g. cred: RACKSPACE_USERNAME)
  • Google Cloud Storage - Google Access Key (e.g. cred: GOOGLE_ACCESS_KEY_ID)
  • Microsoft Azure Blob Storage - Azure Storage Account Name (e.g. cred: AZURE_ACCOUNT_NAME)
  • Swift - OpenStack Object Storage (Swift) Account ID (tenantID:username)  (e.g. SWIFT_ACCOUNT_ID)
  • HP - HP Object Storage Account ID (account number:tenantID) (e.g. cred: HP_ACCESS_KEY_ID)
  • SoftLayer Object Storage - Username of a SoftLayer user with API privileges (e.g. cred: SOFTLAYER_USER_ID)

No value/Ignore

cred:  AWS_ACCESS_KEY_ID

Secondary Backup Storage Cloud (default)

The cloud provider of the specified ROS container where the secondary backup will be stored.

  • s3 - Amazon S3
  • Cloud_Files - Rackspace Cloud Files (United States)
  • Cloud_Files_UK - Rackspace Cloud Files (United Kingdom)
  • google - Google Cloud Storage
  • azure - Microsoft Azure Blob Storage
  • swift - OpenStack Object Storage (Swift)
  • hp - Hewlett Packard Cloud Object Storage
  • SoftLayer_Dallas - SoftLayer's Dallas (USA) cloud
  • SoftLayer_Singapore - SoftLayer's Singapore cloud
  • SoftLayer_Amsterdam - SoftLayer's Amsterdam cloud
text:  Cloud_Files
Secondary Backup Secret (default)

Required cloud credential to store a file in the ROS location specified by the Secondary Backup Storage Cloud (default) input.

  • Amazon S3 - AWS Secret Access Key (e.g. cred: AWS_SECRET_ACCESS_KEY)
  • Rackspace Cloud Files - Rackspace Account API Key (e.g. cred: RACKSPACE_AUTH_KEY)
  • Google Cloud Storage - Google Secret Access Key (e.g. cred: GOOGLE_SECRET_ACCESS_KEY)
  • Microsoft Azure Blob Storage - Microsoft Primary Access Key (e.g. cred: AZURE_PRIMARY_ACCESS_KEY)
  • Swift - OpenStack Object Storage (Swift) Account Password (e.g. SWIFT_ACCOUNT_PASSWORD)
  • HP - HP Secret Access Key (e.g. cred: HP_SECRET_ACCESS_KEY)
  • SoftLayer Object Storage - SoftLayer API Access Key (e.g. cred: SOFTLAYER_API_KEY)
cred: RACKSPACE_AUTH_KEY
Secondary Backup User (default)

Required cloud credential to store a file in the ROS location specified by the Secondary Backup Storage Cloud (default) input.

  • Amazon S3 - Amazon Access Key ID (e.g. cred: AWS_ACCESS_KEY_ID)
  • Rackspace Cloud Files - Rackspace login username (e.g. cred: RACKSPACE_USERNAME)
  • Google Cloud Storage - Google Secret Access Key (e.g. cred: GOOGLE_ACCESS_KEY_ID)
  • Microsoft Azure Blob Storage - Azure Storage Account Name (e.g. cred: AZURE_ACCOUNT_NAME)
  • Swift - OpenStack Object Storage (Swift) Account ID (tenantID:username)  (e.g. SWIFT_ACCOUNT_ID)
  • hp - HP Object Storage Account ID (account number:tenantID) (e.g. cred: HP_ACCESS_KEY_ID)
  • SoftLayer Object Storage - Username of a SoftLayer user with API privileges (e.g. cred: SOFTLAYER_USER_ID)
cred:  RACKSPACE_USERNAME
Secondary Backup Storage Container (1)

The name of the ROS container where the secondary backups will be saved to or restored from. If undefined, secondary backups will be saved to a container name that matches the value specified for the 'Database Backup Lineage' input. If the container does not exist, a new container will be created using the lineage name in the default ROS region. (S3: us-east, Cloud Files: Dallas) The script will fail if a container cannot be created, which may occur in ROS services where container names use a global namespace and a container with that name already exists. (e.g. Amazon S3)

Tip: If you want the secondary container to be in a specific region for performance reasons, you should create the container before launching any servers.
text:  mysqlbackups
Block Device Mount Directory (1)

Input is ignored if volumes are not supported.

For cloud providers supporting volume-based storage, the mount point for your backup volume or volumes. (Default is /mnt/storage.)

text:  /mnt/storage
Nickname (1)

Input is ignored if volumes are not supported.

For cloud providers supporting volume-based storage, the nickname will be used to name the created volumes and snapshots along with an epoch timestamp. (e.g. data_storage-201203100927) By default, this input is set to 'data_storage' however it's recommended that you create a nickname that describes your application or deployment, which will make it easier to identify the created volumes and snapshots.

text:  my_deployment
Number of Volumes in the Stripe (1) To use striped volumes with your databases, specify a volume quantity. The default is 1, indicating no volume striping. Ignored for clouds that do not support volume-based storage (e.g. Rackspace First Generation). text:  1
Total Volume Size (1)

Specify the total size, in GB, of the volume or striped volume set used for primary storage. If dividing this value by the stripe volume quantity does not yield a whole number, then each volume's size is rounded up to the nearest whole integer. For example, if "Number of Volumes in the Stripe" is 3 and you specify a "Total Volume Size" of 5 GB, each volume will be 2 GB.

If deploying on a CloudStack-based cloud that does not allow custom volume sizes, the smallest predefined volume size is used instead of the size specified here. This input is ignored for clouds that do not support volume storage (e.g., Rackspace First Generation).

Important! The value for this input does not describe the actual amount of space that's available for data storage because a percent is reserved for taking LVM snapshots. Use the 'Percentage of the LVM used for data (1)' input to control how much of the volume stripe is used for data storage (default: 10%). Be sure to account for additional space that will be required to accommodate the growth of your database over time.

text:  10

 

NOTE: For Rackspace Open Cloud, the minimum volume size is 100 GB

Percentage of the LVM used for data (1) The percentage of the total Volume Group extents (LVM) that is used for data storage. The remaining percent is reserved for taking LVM snapshots.  (e.g. 90% for data storage and the remaining 10% for overhead and snapshots)

WARNING: If the database experiences a large amount of writes/changes, LVM snapshots may fail. In such cases, use a more conservative value for this input. (e.g. 50%) Be sure to adjust the 'Total Volume Size (1)' input accordingly.
text: 90%

 

Advanced

Input Name Description Example Value
Primary Backup Storage Cloud (default)

Input is ignored if volume snapshots are supported for taking primary backups.

If the instance is launched into a cloud that does not support volume snapshots, you must specify which ROS solution to use for storing primary backups. You must use ROS for primary backups if the database server is launched into one of the following cloud types.

  • CloudStack (for non-Xen hypervisors)
  • OpenStack
  • Rackspace Private
  • SoftLayer
  • HP Cloud
  • Rackspace (First Generation; not OpenCloud)

Primary backups to ROS are saved as binary dump files to a container that matches the value specified for the Database Backup Lineage input. If a matching container in your account does not exist, one will be created for you. However, if the ROS service has a global namespace (e.g. Amazon S3), and you specify a name that is owned by another account, the primary backup scripts will fail. Therefore, it's recommended that you create an ROS container that matches the value for the Database Backup Lineage input.

  • s3 - Amazon S3
  • Cloud_Files - Rackspace Cloud Files (United States)
  • Cloud_Files_UK - Rackspace Cloud Files (United Kingdom)
  • google - Google Cloud Storage
  • azure - Microsoft Azure Blob Storage
  • swift - OpenStack Object Storage (Swift)
  • hp - Hewlett Packard Cloud Object Storage
  • SoftLayer_Dallas - SoftLayer's Dallas (USA) cloud
  • SoftLayer_Singapore - SoftLayer's Singapore cloud
  • SoftLayer_Amsterdam - SoftLayer's Amsterdam cloud

No value/Ignore

text: s3

Primary Backup Storage Cloud Endpoint URL (default)

The endpoint URL for the primary backup storage cloud. You must specify this value for Swift-based ROS services.

  • Swift (OpenStack)

This URL is used to set the default endpoint for making API requests to the specified ROS service. Typically not required for public clouds because the endpoint is already known. However, if you are using a private cloud (e.g. OpenStack) where you've set up a local object storage service (e.g. Swift), you must provide this value so that the script knows where to make the API request.

Example: http://endpoint_ip:5000/v2.0/tokens

text: http://endpoint_ip:5000/v2.0/tokens
Secondary Backup Storage Cloud Endpoint URL (default)

The endpoint URL for the secondary backup storage cloud. You must specify this value for Swift-based ROS services.

  • Swift (OpenStack)

This URL is used to set the default endpoint for making API requests to the specified ROS service. Typically not required for public clouds because the endpoint is already known. However, if you are using a private cloud (e.g. OpenStack) where you've set up a local object storage service (e.g. Swift), you must provide this value so that the script knows where to make the API request.

Example: http://endpoint_ip:5000/v2.0/tokens

text: http://endpoint_ip:5000/v2.0/tokens

DB

Input Name Description Example Value

Database Admin Password

Database Admin Username

Username and password of a database user with administrator privileges. The admin username and password are used for tasks that require administrator access to the database.

cred:  DBADMIN_PASSWORD

cred:  DBADMIN_USER

Database Application Password

Database Application Username

Username and password of a database user with user-level privileges. The application username and password allow the application to access the database in a restricted fashion.

cred:  DBAPPLICATION_PASSWORD

cred:  DBAPPLICATION_USER

Database Backup Lineage

The name associated with your primary and secondary database backups. It's used to associate them with your database environment for maintenance, restore, and replication purposes. Backup volume snapshots will automatically be tagged with this value. (e.g. rs_backup:lineage=mysqlbackup) Backups are identified by their lineage name.

 

If volume snapshots are not supported.

Primary backups are saved to an ROS container that matches the value specified for this input. If the container does not exist, a new container will be created using the lineage name in the default ROS region. (S3: us-east, Cloud Files: Dallas)  The script will fail if a container cannot be created, which may occur in ROS services where container names use a global namespace and a container with that name already exists. (e.g. Amazon S3)

 

Similarly, if you are setting up secondary backups and do not provide a value for the 'Secondary Backup Storage Container (1)' input, the backups are saved to an ROS container that matches the value specified for this input. If the container does not exist, a new container will be created using the lineage name in the default ROS region. (S3: us-east, Cloud Files: Dallas)  

 

Tip: If you want the container to be in a specific region for performance reasons, you should create the container before launching any servers.

text:  mysqlbackup
Database Master FQDN The fully qualified domain name that points to the master database server. Slave database servers and application servers will use the FQDN to locate the "master" database server. Typically, the DNS record will point to the Master-DB server's private IP address. text:  master-db.example.com
Database Master DNS Record ID

The record ID or hostname used to identify your master database server to your DNS provider. See Deployment Prerequisites (Linux) for more information.

Examples:

  • DNSMadeEasy: 1234567  (Dynamic DNS ID)
  • Route53: Z3DSDFSDFX:master-db.example.com
  • DynDNS: db-master.example.com
  • Cloud DNS: 3334445:A-1234567  (<Domain ID>:<Record ID>)
text:  1234567

Database Replication Password

Database Replication User

Username and password of a database user with replication permissions on the MySQL server. The replication username and password are used for replication between the "master" and "slave" database servers.

cred:  DBREPLICATION_PASSWORD

cred:  DBREPLICATION_USER

Database DNS TTL Limit The specified TTL limit of the database servers' dynamic DNS records. It's recommended that you use a low TTL for your database servers DNS records to promote quick failovers. The default is set to 60 (seconds). If you are using Rackspace's Cloud DNS service for Rackspace cloud servers, set this value to 300 (which is the lowest allowable TTL for Cloud DNS).

text: 60

text: 300 (Cloud DNS only)

Database Replication Network Interface

Defines the network interface to use for database replication. If the master and slave database servers are in the same cloud, you should establish replication using the private network. However, if a slave database server exists in a different cloud/region than the master database server, you must perform replication over the public network. In such cases, replication must be performed over the public network. Therefore, it's strongly recommended that you use SSL to encrypt the transferred data for security reasons.

The chosen network selection will also determine which IP address (private or public) of the master database server that is used to update the DNS record, which is defined by the Database Master FQDN input.

  • private (default)
  • public
text: private
Force Promote to Master

Determines whether or not the slave checks if there is a current running master database server and changes the current master into a slave after a database server promotion. This input applies to scripts and cookbooks that use the db::do_promote_to_master operational script.

  • false (default) - Slave verifies that there is a running master database server before it promotes itself to become the new master. The old master will become a slave of the new master after the promotion.
  • true - Slave will not check with the master before being promoted to assume the master role. If there is a running master database server, it will not become a slave of the new master after the promotion. You will not have database replication until a new slave database server is launched.
text: false

DB_MYSQL

Most of the MySQL-specific inputs are preconfigured with acceptable default values, but you can change any values, as necessary.

However, if you are setting up master-slave database replication between database servers located in different clouds/regions, you are forced to use the public network for replication. Therefore, you have to perform database replication over the public network (Database Replication Network Interface = public).

Input Name Description Example Value
CA SSL Certificate The name of your CA SSL Certificate, which is required for encrypted replication over the public network. Use a credential to store this value. (e.g. cred: MYSQL_SSL_CA_CERT) cred: MYSQL_SSL_CA_CERT
Master SSL Certificate The name of your Master SSL Certificate, which is required for encrypted replication over the public network. Use a credential to store this value. (e.g. cred: MYSQL_SSL_MASTER_CERT) cred: MYSQL_SSL_MASTER_CERT
Master SSL Key The name of your Master SSL Key, which is required for encrypted replication over the public network. Use a credential to store this value. (e.g. cred: MYSQL_SSL_MASTER_KEY) cred: MYSQL_SSL_MASTER_KEY
Slave SSL Certificate The name of your Slave SSL Certificate, which is required for encrypted replication over the public network. Use a credential to store this value. (e.g. cred: MYSQL_SSL_SLAVE_CERT) cred: MYSQL_SSL_SLAVE_CERT
Slave SSL Key The name of your Slave SSL Key, which is required for encrypted replication over the public network. Use a credential to store this value. (e.g. cred: MYSQL_SSL_SLAVE_KEY) cred: MYSQL_SSL_SLAVE_KEY

SYS_DNS

Input Name Description Example Value
DNS Service Provider

Select the DNS provider that you used to create the DNS records for the database servers.

  • DNSMadeEasy
  • DynDNS
  • Route53 (Amazon Route 53)
  • CloudDNS
text:  DNSMadeEasy
DNS Password

The password/key required to update the DNS record of a master/slave database server with the specified DNS service provider.

  • DNSMadeEasy - DME Password
  • DynDNS - DynDNS Password
  • Amazon Route 53 - AWS Secret Access Key
  • Rackspace CloudDNS - Rackspace Password
cred:  DNS_PASSWORD

DNS User

The username required to update the DNS record of a master/slave database server with the specified DNS service provider.

  • DNSMadeEasy - DME Username
  • DynDNS - DynDNS Username
  • Amazon Route 53 - AWS Access Key ID
  • Rackspace CloudDNS - Rackspace Username

cred:  DNS_USER

Cloud DNS region

If 'CloudDNS' is the chosen 'DNS Service Provider', use the dropdown menu to select the appropriate cloud region based on the location of the Rackspace cloud servers.

Note: This input is ignored unless you are using CloudDNS.

text:  Chicago

Launch the Database Server

After configuring your inputs, launch your newly configured master database server.

  1. Go to the deployment's Servers tab and launch the database server. When you view the input confirmation page, there should not be any missing values (highlighted in red) for inputs that are required by any of the server's boot scripts. If there are any inputs highlighted in red, cancel the launch and add the missing values at the deployment level before launching the server again. Refer to the instructions in Launch a Server if you are not familiar with this process. Click the Launch (not 'Save and Launch') button at the bottom of the input confirmation page. 

Initialize the Master Database Server

Wait for the server to reach the "operational" state before you run a script to initialize the database server.

  1. Go to the "current" server's Scripts tab and run the db::do_init_and_become_master operational script to initialize it as the "Master" database server.
  2. (Optional) You can go to the "current" server's Audit Entries tab to track the status of the operation.


The script performs the following actions:

  • Registers it as the "master" database server and assign appropriate replication privileges and machine tags. (e.g. rs_dbrepl:master_instance_uuid=01-AVMV4MFHJQOK0 and rs_dbrepl:master_active=20130313200931-bob)
  • For cloud providers with volume support, it creates and mounts either a single volume or group of striped volumes for data storage.
  • Creates a database backup to primary storage.
  • Schedules a cron job to run backups to primary storage once every hour from a "slave" and once per day from the "master" server. A random time is chosen for taking the backups, however inputs are available for setting a specific time for backups. For example, you may want to make sure that the daily backup from the "master" server is taken at off-peak teams. (For information on modifying the default backup schedule, see the Database Manager for MySQL 5.1/5.5 Runbook.)
  • Updates the dynamic DNS record for the "Master" database with the DNS provider. The DNS record is updated with the server's IP address. By default, it will use the instance's private IP address (Database Replication Network Interface = private). The default TTL of the "master" DNS record must also be set to 60 seconds or less (Database DNS TTL Limit = 60) unless you are using Rackspace's Cloud DNS service, where the lowest allowable TTL is 300 seconds.

Disable Scheduled Primary Backups

Since you have not loaded an actual database onto the server there is no reason to create a primary backup of the database.

Go to the "current" server's Scripts tab and run the db::do_primary_backup_schedule_disable operational script to disable your scheduled backups (cron jobs). 

Later, once you have imported your database you will reverse this action and enable continuous backups.

Set Up the Database

After initializing the master database server and disabling scheduled backups, you will need to add your database (or databases) and records to it.

  1. Go to the "current" server's Scripts tab and run the db::do_dump_import operational script to import a MySQL dump file from an ROS location.


Note: If you use a previous backup snapshot instead of a MySQL dump file or initialize a blank MySQL database, refer to the Database Manager for MySQL 5.1/5.5 Runbook for instructions.

Input Name Description Example Value
Dump Container Name of the ROS container that contains the MySQL database dump file.  text:  mysqldumps
Database Schema Name

Name of the MySQL database schema to restore from the MySQL dump file identified by the "Dump Prefix" input. This name is set when you import the dump file into MySQL. The name is only defined within the MySQL instance and not within the actual dump file. As a result the name is somewhat arbitrary but should be descriptive.

Important!
Be sure to record this value. You will need to specify this value again when you set up the application server tier so that they can connect to the correct database schema.

text:  my_db_schema

 

For the 'app_test-201109010029.gz' MySQL dump file:

text: app_test

Dump Prefix

The prefix of the MySQL dump file without the associated file extension (.gz, .bz2, or .zip) to retrieve from the ROS container specified by the "Dump Container" input. You can specify either the entire file name including the timestamp or just the file prefix without the timestamp, which selects the most recent dump file available with that prefix.

Example: If your dump file is named "mydb-201112202212.gz," you could specify either "mydb-201112202212" or "mydb."

If you are using the attached sample MySQL dump file (app_test-201109010029.gz), use "app_test" as the value.

text:  app_test

Dump Storage Account ID

Required cloud credential to retrieve a private file from the specified ROS location. Set to 'Ignore' if the file is publicly accessible.

  • Amazon S3 - Amazon Access Key ID (e.g. cred: AWS_ACCESS_KEY_ID)
  • Rackspace Cloud Files - Rackspace login username (e.g. cred: RACKSPACE_USERNAME)
  • Google Cloud Storage - Google Secret Access Key (e.g. cred: GOOGLE_ACCESS_KEY)
  • Microsoft Azure Blob Storage - Azure Storage Account Name (e.g. cred: AZURE_ACCOUNT_NAME)
  • Swift - OpenStack Object Storage (Swift) Account ID (tenantID:username)  (e.g. SWIFT_ACCOUNT_ID)
  • SoftLayer Object Storage - Username of a SoftLayer user with API privileges (e.g. cred: SOFTLAYER_USER_ID)

cred:  AWS_ACCESS_KEY_ID

cred:  RACKSPACE_USERNAME

 

Dump Storage Account Secret

Required cloud credential to retrieve a private file from the specified ROS location. Set to 'Ignore' if the file is publicly accessible.

  • Amazon S3 - AWS Secret Access Key (e.g. cred: AWS_SECRET_ACCESS_KEY)
  • Rackspace Cloud Files - Rackspace Account API Key (e.g. cred: RACKSPACE_AUTH_KEY)
  • Google Cloud Storage - Google Secret Access Key (e.g. cred: GOOGLE_SECRET_ACCESS_KEY)
  • Microsoft Azure Blob Storage - Microsoft Primary Access Key (e.g. cred: AZURE_PRIMARY_ACCESS_KEY)
  • Swift - OpenStack Object Storage (Swift) Account Password (e.g. SWIFT_ACCOUNT_PASSWORD)
  • SoftLayer Object Storage - SoftLayer API Access Key (e.g. cred: SOFTLAYER_API_KEY)

cred:  AWS_SECRET_ACCESS_KEY

cred:  RACKSPACE_AUTH_KEY

Dump Storage Account Provider

The remote object storage provider where your MySQL dump file is stored.

  • s3 - Amazon S3 
  • Cloud_Files - Rackspace Cloud Files (United States)
  • Cloud_Files_UK - Rackspace Cloud Files (United Kingdom)
  • google - Google Cloud Storage
  • azure - Microsoft Azure Blob Storage
  • SoftLayer_Dallas - SoftLayer's Dallas (USA) cloud
  • SoftLayer_Singapore - SoftLayer's Singapore cloud
  • SoftLayer_Amsterdam - SoftLayer's Amsterdam cloud
text:  s3

Create a Primary Backup

You are now ready to create the first primary backup of the database. You will need a completed backup in order to initialize a slave database server.

  1. Go to the "current" server's Scripts tab and run the db::do_primary_backup operational script to manually generate a primary backup of your database server.

Enable Scheduled Primary Backups

It is now safe to enable continuous backups of the database server.

  1. Go to the "current" server's Scripts tab and run the db::do_primary_backup_schedule_enable operational script.


For more information about configuring and modifying your scheduled backup policy, see the Database Manager for MySQL 5.1/5.5 Runbook.

Add a Slave Database Server

Although you can run MySQL in single-server mode and having a separate slave server for replication purposes is not required, this is strongly recommended for failover purposes. Create a slave server in your deployment.

  1. Clone the Master-DB server. See Clone a Server.
  2. Rename the server accordingly. (e.g. mysql-db2) Remember, you do not want to include the word "slave" in the nickname because this server may become the "master" server during a failover scenario. You don't want the server's nickname to potentially cause any confusion.
  3. Under the server's Info tab, click Edit and change the server's availability zone. In order to ensure high availability, it's strongly recommended that you launch the Slave-DB server in a different availability zone as the Master-DB.  Note: Cross-zone data transfer costs may apply.

Launch the Slave Database Server

Make sure the following conditions are true before you launch the second database server.

  • The master database server state is "operational."
  • The initial primary backup of the master database server is 100% complete. If you are using a cloud that supports snapshots for backups, you can track the status in the dashboard (Clouds > region > Snapshots). The time required to complete the initial primary backup will vary based on factors such as storage type, volume size, etc.


You are now ready to launch a "slave" database server for failover and redundancy purposes. 

  1. Go to the deployment's Servers tab and launch the server that will be the slave database server. 
  2. When you view the input confirmation page, change the value for the following input because you have an operational master database server an a completed database backup. 

DB (advanced)

Input Name Description Example Value
Init Slave at Boot

Set to 'True' to have the instance initialize with a running master database server as a "slave" on boot. 

text:  true
  1. If there are any required inputs that are missing values (highlighted in red), cancel the launch and add the missing values at the deployment level before launching the server again. Refer to the instructions in Launch a Server if you are not familiar with this process.
  2. Click the Launch (not Save and Launch) button at the bottom of the input confirmation page because you do not want to override this input at the server level. You may not want this server to become a slave the next time it is launched or relaunched.

The scripts perform the following actions:

  • Assigns the "slave" role to the server.
  • Uses the most recently completed database backup (default) to initially populate the database in order to reduce the time needed for the slave to become in-sync with the master.
  • Sends a request to the master server to allow connections from the slave server's private IP address and opens the default MySQL client port (TCP port 3306) on the master server's firewall (i.e. iptables) for this purpose.
  • Schedules a cron job to run primary backups of the database once per hour (default). 

(Optional) Update the DNS Record for the Slave Database Server

If you created a DNS record for the slave database server, you can set a value for the Database Slave DNS Record ID input and run the db::do_set_dns_slave operational script.

Test Database Setup (optional)

If you want to test the status of the "master" and "slave" database servers, see Check Database Status of Master or Slave.

 


Load Balancer Tier Setup

Create a Load Balancer

  1. Go to Clouds > AWS Region > Load Balancing
  2. Click Create ELB and fill out the required form fields:

 

screen-create-ELB_v1.png

 

General Info

  • Load Balancer name - The name of our Elastic Load Balancer. It must be unique within your AWS account.
  • VPC - The Virtual Private Cloud you'd like to associate to this load balancer.
  • Internal Load Balancer - Select this option to create an internal load balancer. A DNS name will be created and it will contain the private IP address of the load balancer. This option is only available if you set a value for VPC.
  • Subnets - Your load balancer can interface with instances in one or more subnets. Only subnets in the selected VPC are available. This option is only visible if you set a value for VPC.
  • Security Groups - One or more security groups to manage traffic communicating with your load balancer. This option is only visible if you set a value for VPC.
  • Availability Zone(s) - Select all of the availability zones for which the ELB will service. (Tip: Click in the box to view and select additional zones.) An ELB will only load balance across instances in the selected availability zones. An ELB is region-specific; it cannot load balance across multiple regions. For example, you cannot load balance your application traffic amongst instances in the 'us-east' and 'us-west' regions. Note: This field is not displayed if you have selected a value for VPC.

 

Default Listener

  • LB Protocol - The routing transport protocol that will be used by the ELB. (TCP, HTTP, HTTPS)
  • LB Port - External port that the ELB will listen on to accept client requests. Valid ports are 80, 443, 1024-65535.
    • For an example (v13.5 LTS) 3-tier deployment, use HTTP:80.
  • Instance Protocol - The routing transport protocol that the ELB will use to connect to the instances (i.e. application servers) in its load balancing pool. (HTTP, HTTPS, TCP, SSL)  If you are using one of the application ServerTemplates (v12+) published by RightScale, select 'HTTP' for the protocol. Note: The Load Balancer and Instance Protocols must match. You can create additional listener rules after you create the ELB.]
  • Instance Port - The port that the ELB will use to send traffic to the application instances. Valid ports are 1 to 65535. The Instance Port does not have to match the Load Balancer Port. If you are using one of the application ServerTemplates (v12+) published by RightScale, the default application listener port is '8000'.
    • For an example (v13.5 LTS) 3-tier deployment, use HTTP:8000.
  • Stickiness - This is where you can create a session sticky policy for your load balancer (stickiness meaning that once a session starts, all requests will attempt to routed subsequent to the same server for that given session). You can select one of the following options:
    • Disable Stickiness - Does not allow session stickiness the load balancer and application server. 
    • Load Balancer Generated Cookie Stickiness - A special cookie is used to track the backend server instance for each request. When the LB receives a request, it checks to see if this cookie is present in the request. If so, the load balancer sends the request to the application server specified in the cookie. If not, the request is sent to a server chosen based on the existing load balancing algorithm. This option creates a stickiness policy with sticky session lifetime controlled by the lifetime of the browser or a specified expiration period. This only works with HTTP/HTTPS listeners.
    • Application Generated Cookie Stickiness - This is similar to the Load Balancer Generated Cookie Stickiness option, with the following exception: once a cookie is explicitly removed or expires, the session stops being sticky until a new application cookie is issued.
  1. Click Save.
  2. Configure the Health Check test for the ELB and click Save.

screen-ELB_Health_Check-v1.png

Add Additional Listeners (optional)

Elastic Load Balancers support both HTTP and HTTPS (SSL) requests. When you create an ELB, you must define a default listener. If you wish to set up additional listeners (e.g. HTTPS), you can configure them after the ELB is created.

File:12-Guides/Dashboard_Users_Guide/Clouds/AWS_Regions/Load_Balancing_(beta)/Actions/Create_an_AWS_Elastic_Load_Balancer/diag-3tierELB_http_https-v1.png

Listener ports should be defined when your ELB is created. If you are setting up an ELB to load balance across applications servers launched with one of RightScale's v12.11 or v13.5 LTS ServerTemplates, you may need to modify your ELB and add additional listeners, as necessary.

  1. Click on the Elastic Load Balancer you would like to modify. 
  2. Check the configuration of the application ServerTemplate that will be used to launch the application servers that will connect to the ELB. Make sure that the application servers are configured to listen for requests from the ELB on the correct port. You will need to set up the listener appropriately, depending on how the application servers will be configured. (e.g. Application Listen Port (8000), LB_PORT (80), etc.)
  3. To configure HTTP access, add a listener to forward requests to the appropriate port (e.g. 8000) for the application server. Click Add Listener to create a new listener for the ELB.
    • LB Protocol: Select 'HTTP'
    • LB Port: Enter '80'
    • Instance Protocol: Select 'HTTP'
    • Instance Port: Use '8000' (for v12.11 or v13.5 LTS ServerTemplates); use '8080' (for v14 ServerTemplates)
    • Stickiness: You can choose either to have stickiness disabled or generate a sticky session based on either load balancer or application generated HTTP cookies.
  4. To allow HTTPS (SSL) access, add a listener to forward requests to the appropriate port (e.g. 8000) for the application servers. Click Add Listener to create a new listener for the ELB.
    • LB Protocol: Select 'HTTPS'
    • LB Port: Enter '443'
    • Instance Protocol: Select 'HTTPS'
    • Instance Port: Use '8000' (for v12.11 or v13.5 LTS ServerTemplates); use '8080' (for v14 ServerTemplates)
    • Stickiness: You can choose either to have stickiness disabled or generate a sticky session based on either load balancer or application generated HTTP cookies.
    • Certificate: Select an SSL Certificate. See Create an AWS Server Certificate.

Update the DNS Records

Once you've created your ELB, find its DNS name (e.g. elbname-12345678.us-east-1.elb.amazonaws.com) and use it to create a CNAME with your DNS provider. For an ELB, you cannot create a DNS record that points to an IP address because it could change over time.  

  1. Go to the Elastic Load Balancer's Info tab in the RightScale Dashboard. 
  2. Copy the "DNS name" for the ELB. (e.g. elb-name-2005463590.us-west-1.elb.amazonaws.com)

screen-ELB_Info-v2.png

  1. Create a CNAME with your DNS provider (e.g. AWS Route 53, DNS Made Easy, DynDNS, etc.)


Example: Amazon Route 53

screen-ELB_Create_CNAME-v1.png

Create a Security Group for Application Servers

The next step is to create or update a security group that will be used by application servers to allows ingress communication from an ELB. By default, RightScale's Linux-based application ServerTemplates (e.g. PHP, Rails, Tomcat) listen on TCP port 8000 and the Windows-based application ServerTemplate (e.g. Microsoft IIS App) listens on TCP port 80.

  1. Create or modify a security group in the AWS region where the ELB will service requests to the application servers. Later, you will configure the application servers to use this security group in order to connect to the ELB. 
  2. Create the desired port permissions. At a minimum, you will need to open up port 80 for HTTP access. You can also open up 443 for HTTPS (SSL) access. Specify the following information to create a permission for an ELB.
    • Direction: Inbound
    • Protocol: TCP - Group
    • Ports:
      • For v12.11 or v13.5 LTS ServerTemplates, use 8000..8000 (PHP, Rails, Tomcat, Django); 80..80 (Microsoft IIS)
      • For v14 ServerTemplates, use 8080..8080 (PHP, Rails, Tomcat, Django); 80..80 (Microsoft IIS)

    • Owner: amazon-elb
    • Group: amazon-elb-sg

File:12-Guides/Dashboard_Users_Guide/Clouds/AWS_Regions/Load_Balancing_(beta)/Actions/Create_an_AWS_Elastic_Load_Balancer/screen-Security_Group_for_ELB-v1.png

  1. Click Save.
  2. Later, when you set up your application servers and/or server array, be sure to use the above security group for the application servers will connect to the Elastic Load Balancer. 

Note: You cannot add a new security group to a running instance. In such cases, it's recommended that you add the security group to the "next" server and relaunch the server.


Application Tier Setup

Prepare Application Code

PHP App Server (v14 Infinity) - Tutorial

Sample Application

If you need an example application for testing purposes, you can use the application code from the following git repository.

  • Repository URL/ROS Container - git://github.com/rightscale/examples.git
  • Account Credential - Set to "Inherit: No value to inherit" because the sample application is located in a 'public-read' repository.
  • Repository Provider - repo_git
  • Repository Branch/Tag/Commit - unified_tomcat

Add a Server

Follow these steps to add an application server to the deployment.

 

  1. Go to the MultiCloud Marketplace (Design MultiCloud Marketplace > ServerTemplates) and import the most recently published revision of the following ServerTemplate into the RightScale account.
  2. (Optional) If you expect to make changes to the ServerTemplate, you will need to clone it to create an editable copy.  Click the Clone button and rename the ServerTemplate accordingly. (e.g. My App Server) Before you make any changes to the ServerTemplate, click the Commit button so that the first revision of the ServerTemplate matches the original revision, which will make it easier to perform differentials in the future to see what changes were made to the "original" version. When committing the ServerTemplate you can use a simple commit message. (e.g. Original version. No changes.) If you are actively developing the ServerTemplate, you may find it useful to use the HEAD version of the ServerTemplate to create the application server tier. However, for production environments, you should always use static, committed revisions of a ServerTemplate to launch servers.
  3. From the imported ServerTemplate's show page, click the Add Server button.
  4. Select the cloud for which you will configure a server. 
  5. Select the deployment for the new server.
  6. Next, the Add Server Assistant wizard will walk you through the remaining steps that are required to create a server based on the selected cloud.
    • Server Name - Provide a nickname for your new application server (e.g., app1).
    • Select the appropriate cloud-specific resources (e.g. SSH Key, Security Group, etc.) that are required in order to launch a server into the chosen cloud. The required cloud resources may differ depending on the type of cloud infrastructure. If the cloud supports multiple datacenters/zones, select a specific zone. For more information, see Add Server Assistant.
  7. Click Confirm, review the server's configuration and click Finish to create the server.
  8. If you are setting up a multi-tier deployment, it's strongly recommended that you create at least two application servers for high availability purposes.
    • The easiest way to create the second server is to clone the first one. Be sure to change the name of the server accordingly (e.g. app2) and its availability zone (if available) under the the Info tab. You can either add application servers directly into a deployment or create an server array of application servers for autoscaling. 

Configure Inputs

The next step is to define the properties of your application server by entering values for inputs. It is best to do this at the deployment level. For a detailed explanation of how inputs are defined and used in Chef recipes and RightScripts, see Inputs and their Hierarchy.

To enter inputs for the Chef recipes that will run on your application servers, open the deployment's Inputs tab and click Edit, then follow the directions below to configure input values. We recommend that you set up credentials for password values and any other sensitive data as shown in the examples.

Note: Some inputs referenced in this tutorial are considered "advanced" are not initially displayed in the Dashboard. If you are unable to find an input in the Dashboard, be sure to use the "Show advanced inputs" option to view all related inputs of a particular input category.

Important! The ServerTemplate supports multiple configuration permutations. Read each input description carefully. You must provide appropriate values depending on your chosen configuration.

APP

Input Name Description Example Value
Database Schema Name Enter the name of the database schema to which applications will connect to. The database schema should have been created when the initial database was first set up. This input will be used to set the application server's database configuration file so that applications can connect to the correct schema within the database. This input is also used for database dump backups in order to determine which schema will be backed up.

text:  db_schema_name

 

For the 'app_test-201109010029.gz' MySQL dump file:

text: app_test

Application IP Type Given to Load Balancer

Specify the type of IP address that the application service will listen on. Before making this selection, make sure your firewall permissions are properly configured to accept requests on its public or private IP address.

  • private
  • public
text: private

Application Listen Port

The port that the application service listens on to accept requests from the load balancer. If you specify another port than the 8000 (default), be sure to add the port to the "Firewall Rule Port" input and make sure that the security group's settings also allow access (if applicable).

text:  8000

APP_TOMCAT

Many of the Tomcat-specific inputs have default values. Click the "Show advanced inputs" to view all of the inputs.

Input Name Description Example Value

War file for ROOT

The full path, including filename, to the source application WAR file relative to the project root directory, which is defined by the 'Project App root' input (default /home/webapps/<app_name>). The retrieved WAR file will be renamed ROOT.war and placed into the 'Project App Root' directory.

text: /path/to/app.war

For the provided sample application:
text:  /dist/app_test.war

DB

Input Name Description Example Value

Database Application Password

Database Application Username

Database username and password to add to the MySQL database server for application access.

cred:  DBAPPLICATION_USER

cred:  DBAPPLICATION_PASSWORD

Database Master FQDN

Fully qualified domain name for the master MySQL database server. Application servers use this input to locate the "master" database server.

text:  master-db.example.com
Database Provider type

The type of database that the application will connect to on the client side. Select one of the predefined options in the dropdown menu or use the "Override" option to specify a custom option. The value must be a string that contains the name of the cookbook that contains the matching provider resource and version of the database (optional).

  • db_mysql_5.1
  • db_mysql_5.5
  • db_postgres_9.1
text: db_mysql_5.5

LB

Input Name Description Example Value

Load Balance Provider

Select the type of load balancer (or service) that the application server(s) will connect to. 

  • lb_client - Load balancer servers launched with ServerTemplates (HAProxy, aiCache, etc.) Select this option if you are using the "Load Balancer with HAProxy" ServerTemplate.
  • lb_elb - Amazon Elastic Load Balancing (ELB) service
  • lb_clb - Rackspace Cloud Load Balancing (CLB) service

text:  lb_client

Load Balance Pools

Specify the load balancing pool(s) to which the application server belongs. Typically, an application server will belong to one load balancing pool, however an HAProxy load balancing server can service multiple pools. An application server can also connect to multiple load balancing pools, if desired. 

Specify the load balancing pool that the application server will connect to or disconnect from by using one of the following types:

  • Virtual Hostname (e.g. default)
  • URI (e.g. /myapp)
  • FQDN (e.g. myapp.example.com)

text:  default

Load Balance Service ID

Load Balance Service Secret

For CLB, specify the Rackspace username and API key to use for authentication purposes.

For ELB, specify the Amazon access key ID and secret access key for authentication purposes.

Note: For HAProxy, aiCache, and other load balancers launched with ServerTemplates, set to 'ignore'.

cred: RACKSPACE_USERNAME
cred: RACKSPACE_AUTH_KEY

cred: AWS_ACCESS_KEY_ID
cred: AWS_SECRET_ACCESS_KEY

Load Balance Service Name

The name of the Amazon Elastic Load Balancer (ELB) or Rackspace Cloud Load Balancer (CLB).

Note: For HAProxy, aiCache, and other load balancers launched with ServerTemplates, set to 'ignore'.

text: my-lb-name
Load Balance Service Region

Note: Input only applies to a Rackspace Cloud Load Balancer (CLB).

For a CLB, select the Rackspace region of the Cloud Load Balancer. It's recommended that you create your CLB in a region as close to your application servers as possible.

  • ORD (Chicago)
  • LON (London)
  • DFW (Dallas/ Ft. Worth)
text: ORD

REPO

The values that you use for the repository inputs will depend on where the application code will be retrieved from. The selection for the Repository Provider input will determine which inputs will be used to retrieve the application. Unrelated inputs are ignored.

ALL Repositories (ROS, Git, SVN, FTP)

The following inputs are used to retrieve the application from either a Git/SVN software repository or an ROS location. Specify the appropriate inputs based upon the selection for the 'Repository Provider' input.

Input Name Description Example Value
Repository Provider

Specify where the application code should be checked out from.

  • repo_git - Git repository
  • repo_svn - SVN repository
  • repo_ros - Remote Object Store. (e.g. Amazon S3,  Rackspace Cloud Files, etc.) Select this option to download a tarball (.tgz) of your application code.
  • repo_ftp - File Transfer Protocol (FTP) service
  • repo_rsync - Code will be retrieved using rsync instead of from Repose. Typically used for cookbook development workflows.

text:  repo_ros

For the provided sample application:
text:  repo_git

Repository URL/ROS Container

The name of the Remote Object Storage (ROS) container where a tarball (.tgz) of the application code will be retrieved from or the URI that points to the location of the application code repository.

  • ROS - container/bucket name
  • GitHub/SVN - Specify the URI that points to the location of the repository that contains the application code. Specify a "read-only" URL. See the examples below.
    • GitHub: git://github.com/username/myapp.git
    • SVN: https://mysvn.net/app

text:  my-container

For the provided sample application:
text: git://github.com/rightscale/examples.git

Project App root

The destination location where the application code will be placed on the local instance. If you want the application code to be placed in the root directory, use a forward slash (/) otherwise you will need to specify the full path (e.g. /path/to/code). If set to 'ignore' the default location (/home/webapps) will be used. The 'Application Name' input is used to name the destination folder into which the application code will be placed (e.g., /home/webapps/my_app/). Apache and Tomcat will look for the application in this path.

text:  /home/webapps

For the provided sample application:
text:  /home/webapps

Action

Specify how the application code will be pulled from the specified repository.

  • pull - standard repository pull
  • capistrano_pull - standard repository pull plus a capistrano deployment style is applied.

text:  pull

For the provided sample application:
text:  pull

Known Hosts SSH Key Use the credential you created earlier in the tutorial. This input will allow verification of the destination host by comparing its IP, FQDN and SSH-RSA with the record in the  /root/.ssh/known_hosts file. This input provides improved security by preventing MiTM attacks. cred:SSH_KNOWN_HOST_KEY
Git Repository

Important!
If you are checking out code from a Git repository, specify values for the following inputs.

Input Name Description Example Value
Account credential In order to check out application code from a private (not public) Git repository, you must provide the repository's SSH key (e.g. Git SSH Key) for authentication purposes. Set to 'ignore' if you are using an application in a repository that allows 'public-read' access.

cred:  GIT_SSH_KEY

For the provided sample application:
inherit:  no value to inherit

Repository Branch/Tag/Commit

The specific branch/tag/SHA of the specified Git repository that the application code should be checked out from. (e.g. mybranch) Use "master" to retrieve the master branch from the repository.

text:  mybranch

For the provided sample application:
text:  unified_tomcat

SVN Repository

Important!
If you are checking out code from a SVN repository, specify values for the following inputs.

Input Name Description Example Value

Account name
Account credential

The username and password required to access and retrieve the application code from the specified SVN repository.

cred:  SVN_USER

cred:  SVN_PASSWORD

Repository Branch/Tag/Commit The specific branch or tag of the specified SVN repository that the application code should be checked out from. (e.g. mybranch) Use "trunk" to retrieve the main branch from the repository. text:  mybranch
Remote Object Storage (ROS)

Important!
If you are checking out code from a Remote Object Storage (ROS) location, specify values for the following inputs.

Input Name Description Example Value

ROS Prefix

The prefix that will be used to locate the correct tarball of the application. For example, if you're using 'myapp.tgz' specify 'myapp' as the ROS Prefix.

text:  myapp

Account name

In order to retrieve a tarball of the application code that's a "private" object within the specified Remote Object Storage (ROS) location, you must provide proper cloud authentication credentials. For security reasons, it's recommended that you create and use credentials for these values instead of entering the text value.

  • Amazon S3 - Amazon Access Key ID (e.g. cred: AWS_ACCESS_KEY_ID)
  • Rackspace Cloud Files - Rackspace login username (e.g. cred: RACKSPACE_USERNAME)
  • Google Cloud Storage - Google Secret Access Key (e.g. cred: GOOGLE_ACCESS_KEY)
  • Microsoft Azure Blob Storage - Azure Storage Account Name (e.g. cred: AZURE_ACCOUNT_NAME)
  • swift - Authentication Token (string)
  • SoftLayer Object Storage - SoftLayer Account ID (e.g. cred: SOFTLAYER_USER_ID)
text:  AWS_ACCESS_KEY_ID
Account credential

In order to retrieve a tarball of the application code that's a "private" object within the specified Remote Object Storage (ROS) location, you must provide proper cloud authentication credentials. For security reasons, it's recommended that you create and use credentials for these values instead of entering the text value.

  • Amazon S3 - AWS Secret Access Key (e.g. cred: AWS_SECRET_ACCESS_KEY)
  • Rackspace Cloud Files - Rackspace Account API Key (e.g. cred: RACKSPACE_AUTH_KEY)
  • Google Cloud Storage - Google Secret Access Key (e.g. cred: GOOGLE_SECRET_ACCESS_KEY)
  • Microsoft Azure Blob Storage - Microsoft Primary Access Key (e.g. cred: AZURE_PRIMARY_ACCESS_KEY)
  • swift - Authentication Token (string)
  • SoftLayer Object Storage - SoftLayer Authentication Token (e.g. cred: SOFTLAYER_API_KEY)
cred:  AWS_SECRET_ACCESS_KEY
ROS Storage Account Provider

The Remote Object Storage (ROS) service where the tarball of the application code will be retrieved from.

  • s3 - Amazon S3 
  • Cloud_Files - Rackspace Cloud Files (United States)
  • Cloud_Files_UK - Rackspace Cloud Files (United Kingdom)
  • google - Google Cloud Storage
  • azure - Microsoft Azure Blob Storage
  • swift - OpenStack Object Storage
  • SoftLayer_Dallas - SoftLayer's Dallas (USA) cloud
  • SoftLayer_Singapore - SoftLayer's Singapore cloud
  • SoftLayer_Amsterdam - SoftLayer's Amsterdam cloud
text:  s3

WEB_APACHE

Input Name Description Example Value
Application Name

On your application servers, the server subdirectory where your application code files are stored.

If you are using dedicated load balancer servers launched with RightScale's "Load Balancer with HAProxy" ServerTemplate, this value must match the Application Name input for your load balancer servers.

text:  myapp
Multi-Processing Module Set to "worker" for a Tomcat application server. text:  worker

Launch the Server

After configuring your inputs, launch all of the Tomcat application servers. Refer to the instructions in Launch a Server if you are not already familiar with this process.


Test the Deployment

Once all of the servers are operational you can perform the following tests.

Check the Landing Page

If you set up your DNS records and firewall permissions (e.g. security groups) correctly, incoming web requests to your hostname (e.g. www.example.com) will be sent to the Elastic Load Balancer, which will establish a connection with one of the connected application servers.

Based on your DNS records, enter the hostname (FQDN) associated with your load balancer servers into a browser window. (e.g. www.example.com) You should see your application's default landing page. If you are using the sample application from RightScale, you should see the following landing page.

screen-RSLandingPage-v1.png

Next Steps

Set up an Autoscaling Application Tier

To replace the static application servers in the deployment (under the deployment's Servers tab) with a scalable server array for dynamically autoscaling the application tier, follow the Add a Scalable Application Server Array to a Deployment tutorial.

Safely Shutdown the Servers

If you completed the tutorial for testing purposes and no longer need the running servers, follow the steps below to safely shutdown the deployment.

  1. Delete or change the DNS A records that point to the ELB load balancing service.
  2. Delete the Elastic Load Balancer.
  3. Terminate the Master and Slave Database Servers. (If you are using volumes, see the Database Manager for MySQL 5.1/5.5 Runbook for proper instructions.)
  4. Terminate the application servers.
  5. Delete the deployment if you do not plan to relaunch the servers in the deployment again.

 

 

You must to post a comment.
Last modified
10:31, 29 Apr 2014

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.