3 Tier Deployment (11H1)

Create Cloud Resources

Use the following instructions to create a security group, an SSH key, and the Elastic IPs (EIPs) necessary for this tutorial. Collectively these are referred to as cloud resources.

Important! You must create the cloud resources in the specific AWS region (e.g. US East, US West, ect.) where you will launch your servers. This tutorial uses the US-East region.

First, you need a security group. You can use an existing one (if you have one) or simply create a new one.

Important! You must create the following cloud resources (security group, SSH key, and Elastic IPs) in the specific AWS region (e.g. US-East, US-West, etc.) where you will launch servers. In this tutorial, we launch servers in the US-East region.

Create Your Security Group

To create your security group, see Create a New EC2 Security Group.

Tips:

• Initially, use a single security group. If you are interested later, you can modify your deployment to use a layered security group approach to increase security.
  Note: Using a single security group is not considered a best practice for a production environment. In a production environment, the best practice is to create different security groups for each layer of your web architecture.
• Open the following ports: 22 (SSH) and 80 (HTTP). Use 0.0.0.0/0 CIDR notation for both ports. Optionally, you can also open port 443 for SSL (HTTPS) communication.
• Enable ICMP so that you can run ping tests. Use Type: -1 and Code: -1 for IPs 0.0.0.0/0.
  Note: Leaving ICMP enabled in a production environment is not recommended as this protocol presents a potential security risk.

After you have created your security group, add it to itself for all protocols (TCP/UDP/ICMP) and ports.
Important! When you add a security group, you must manually enter the name of the security group. Do not use the default name. In this case, the name is going to be the name of the new security group you are creating. You cannot achieve the same results using the “default” group. For more information, see Add a Security Group to Itself.

In the following example, the security group name is “production” and it has the following port permissions. The final list of permissions for your security group should look similar.

Create a new SSH Key

If you don’t have one already, you need to create a new SSH key. Even if your deployment uses strictly RightLink-enabled images, which do not require SSH to communicate, you need to use SSH to connect to your servers for testing and debugging purposes during this tutorial.

To create your SSH Key, see Create an SSH Key.

Create Elastic IPs

You will need two Elastic IP Addresses (EIPs) for your front-end load balancers. Name the EIPs appropriately (‘my-lb1’ and ‘my-lb2’). Be sure to record your EIP names and the associated IP addresses. You’ll need this information later in the tutorial.

To create your EIPs, see Create Elastic IPs (EIP)

Create S3 Buckets

Create two S3 buckets, one for the sample application file and one for your database dump file (and subsequent snapshots). Later in the tutorial, you will configure the Inputs for your ServerTemplates to point to these files. When servers are launched from the ServerTemplates, the servers access the files and create application and database servers.

To create the S3 buckets, see Create a New S3 Bucket.

Download the Sample Application and Database Files

To download the sample application and database dump file, click the following links. Make sure that the filenames are not modified by your operating system or browser when you download and save the files. Sometimes, extra characters are added to the filenames or the file extensions are changed or missing. The files must have the correct names to work.

• Sample PHP application: myapp.tgz
• MySQL database dump file: myapp_prod_dump-200804161345.gz

Alternatively, our services team provides another sample PHP application (in .tgz format) and MySQL database dump file listed below (further known as the 'world' application/database). The database dump is the 'world' test database provided directly by MySQL.

• Sample RS Services PHP application: Rightscale PHP/MySQL Test Application
• Sample RS Services database dump file: MySQL 'world' test database

Once you have a .tgz file for the sample application, you can upload them to your own web server or S3 bucket for use in the APPLICATION_CODE_PACKAGE input later in the tutorial. The MySQL dump .gz file should also be uploaded to an S3 bucket which will later be used in conjunction with the DB_MYSQLDUMP_FILENAME and DB_MYSQLDUMP_BUCKET inputs. Use a text value of 'world' for the DB_SCHEMA_NAME input later in the 'Database Tier Setup' section.

Upload the application and database files

Upload the application and database dump files to their respective S3 buckets. After you upload a file, you need to refresh the browser window to view the file in the S3 bucket.

Note: When you upload a file to an S3 bucket, its access permissions are automatically set to “private” and can only be accessed with your AWS account credentials. Our scripts can use your AWS account credentials to access the files if they are located inside your AWS account buckets, even when the files are “private”. However, if you are using files stored in S3 buckets that do not belong to your AWS account, you must change the file permissions to “public-read”. You can do this by updating the file permissions from the drop-down menu.

Configure Your DNS Records

The 11H1 ServerTemplates support the use of multiple DNS solutions including DNSMadeEasy, DynDNS, and Route 53. The information required for your ServerTemplates varies depending on the DNS solution you choose. The instructions that follow are for DNSMadeEasy. However, you can use these same steps to configure one of the other providers.

First, log into your DNSMadeEasy (DME) account.  Then use the following information to create “A Records” for your Master and Slave Database Server and for your two Load Balancers.

For your Master Database Server:

• Create an A Record and name it something simple. For example, your initials followed by “masterdb” (e.g. John Doe would be “jd-masterdb”).
• Give the record any legal, temporary IP address (e.g. 1.2.3.4). The actual value doesn’t matter since it is only a placeholder address that will be replaced later. 
• Set the time-to-live (TTL) to 60 seconds (e.g. TTL=60).
• Be sure to check the Dynamic DNS option. This allows the RightScripts to dynamically replace the temporary IP address (1.2.3.4 set above) with the actual IP address of the cloud server after it boots up.
• Leave the password blank (if prompted).
• Double click on the name of your newly-created A record and record the DDNSID of the Master Database Server.
   

For your Slave Database Server:

• Name it similarly to the Master Database Server (e.g. jd-slavedb).
• Set the same parameters that you did for your Master. You can use the same temporary IP address (1.2.3.4) for this server. The IP address will be replaced in the event that you need to promote the Slave database.
• Record the DDNSID of the Slave Database Server.
   

For your first load balancer (Load Balancer One):

• Create an A Record in your domain (e.g. “my-www”). For this basic example, the fully qualified domain name would be: my-www.example.com.
• Set the IP address to the first EIP you created earlier in the tutorial. See Create Elastic IPs (EIP).
• Uncheck DDNS.
• Leave the password blank (if prompted).
• Set the TTL to 1800 (TTL=1800). Since this is a load balancer it is appropriate to use a longer TTL.

For your second load balancer (Load Balancer Two):

• Create an A Record in your domain (e.g. “my-www”). You must use the same name that you used for the first load balancer.
• Set the IP address to the second EIP you created earlier in the tutorial. See Create Elastic IPs (EIP).
• Uncheck DDNS.
• Leave the password blank (if prompted).
• Set the TTL to 1800 (TTL=1800). Since this is a load balancer it is appropriate to use a longer TTL.
   

Important! The only difference between the records for the Load Balancers is that the records have different Elastic IPs (EIPs).

The final records should look similar to the following screenshot.

Configure RightScale Credentials

Create the Credentials from the following list in the RightScale Credentials store. Creating Credentials is very simple to do (Design > Credentials), but quite easy to get wrong by entering the wrong values or by misusing the Credentials later on in this tutorial. Incorrect Credential names or values are common errors.

To create your Credentials, follow the instructions in Create Credentials for Common Inputs. Refer to the following table for guidance on setting the Credential values correctly.

Warning! The following values are examples only. Please provide your own unique values for these credentials to avoid using identical credentials as other users of this tutorial.

• DBAPPLICATION_USER - Enter the username that the application uses to access the database. For the example application in this tutorial, set this to "1234".
• DBAPPLICATION_PASSWORD - Enter the password that the application uses to access the database. For the example application in this tutorial, set this to "1234".
• DNS_USER - Enter the username that is used to access your DNS records with your chosen DNS solution.
• DNS_PASSWORD - Enter the password that is used to access your DNS records with your chosen DNS solution.

• DBADMIN_USER - Enter the username of the database administrator. For the example database in this tutorial, set this to "admindb."
• DBADMIN_PASSWORD - Enter the password of the database administrator. For the example database in this tutorial, set this to "admindb."
• DBREPLICATION_USER - Enter the username used for database replication. The ServerTemplates use this value later. For the example database in this tutorial, set this to "dbrpl."
• DBREPLICATION_PASSWORD - Enter the password used for database replication. For the example database in this tutorial, set this to "dbrpl."

Create the Database Servers

Create a Deployment (if needed)

If you already have a Deployment for this tutorial, skip this section.

To create a Deployment, go to Manage > Deployments and click New. Provide a title and a brief description. Later, when you add Servers to the Deployment, you can set a specific Availability Zone. The Availability Zone that is defined at the Deployment level only takes effect if you add a Server with ‘-any-‘ as its Availability Zone.

For this tutorial, ignore the Default VPC Subnet and Default Placement Group and keep the default ‘None’ settings.

When you are ready, click Save to finish creating your Deployment.

Add Servers to the Deployment

The Database Manager for MySQL ServerTemplates are based on Amazon Elastic Block Store (EBS) Snapshots. Snapshots are highly efficient backups representing an EBS volume at a specific point in time. New EBS Volumes are created from a snapshot and are attached to a master/slave instance. When you launch a new Server using a Database Manager for MySQL ServerTemplate, the template uses the most recent EBS snapshot (or snapshots if you’re using a set of striped EBS volumes) available to begin the boot process.

Because you are creating this EBS setup from scratch, you don’t yet have a backup of the database (i.e. an existing set of EBS Snapshots). Therefore, the first step is to create your first backup of the database. When dealing with EBS Volumes, you should always attach fresh volumes that were created from the most recent snapshots.

Go to Design > MultiCloud Marketplace and import the following components:

• ServerTemplates: Database Manager with MySQL 5.0 – 11H1 and/or Database Manager with MySQL 5.1 – 11H1. Import the appropriate ServerTemplate for the type MySQL dump file that you’re using (5.0 or 5.1). If you’re using the sample dump file included in this tutorial, import the Database Manager for MySQL 5.0 ServerTemplate.
• RightScripts: DB Create MySQL EBS stripe volume – 11H1 and DNS Master DB register – 11H1. You can also download the matching “Toolbox” ServerTemplates from the MultiCloud Marketplace if you want to import all of the related MySQL scripts. At a minimum, you will need those two RightScripts to complete this tutorial.

Note: If you plan to make modifications to the ServerTemplates or RightScripts, make sure to clone the templates or scripts before you modify them.

From the Deployment’s Servers tab (Manage > Deployments > deployment name), select the cloud region where you want to create your database setup (e.g. AWS US-East) and click the Add Server button.

Select either the imported or cloned version of the “Database Manager for MySQL 5.0/5.1” ServerTemplate. Provide a nickname (i.e. my-db1) and select your SSH Key and Security Group.

For the Availability Zone, you can either launch the Master and Slave Servers in the same or different zones. For production environments, you might want to have your database servers in separate zones. But for testing purposes, you can launch the servers in the same zones.

Select a particular Availability Zone (e.g. us-east-1a). Click Confirm, double-check your selections and click Finish.

This first server is your Master Database Server. Although a running Slave Database Server is technically not required to have a functional site, it’s strongly recommended for replication and failover purposes. Fortunately, you can use the same ServerTemplate to add a second database server that will become the “slave” for the Master Database.

While you can repeat the steps above to create a second server, an easier method is to clone the existing server. Click on the Master Database Server’s Nickname link. Then click the Clone button. Give the second server a new name (e.g. jd-db2).

For high-availability purposes, we recommend that you launch the Slave Database Server in a different availability zone than the Master Database Server. Under the Info tab for the Slave Database Server, click the Edit button. Select a different availability zone for the slave (e.g. us-east-1b).

Define Inputs for the Deployment

Next, as a best practice, we will define some common Input parameters at the Deployment level. Defining the Input parameters at the Deployment level ensures that all of the Servers in the Deployment inherit the Inputs and their values. This means that you only have to define the Inputs and set the values once.

Go to the Deployment’s Inputs tab and click Edit .

Notice that most of the Inputs are inherited from the ServerTemplate. However, there are a few required Inputs that you need to define, as well as a few others whose values you might want to change.  Hover over the Info icon next to the Input name for a detailed description and a sample value. The values that you need to provide depend on the DNS solution you are using.

By default, the Inputs with missing values have “Inherit” selected as the data type. Use thepull-down menu to select the appropriate data type for the Input (e.g. Text, Cred (entail), SSH, etc.).

Database

DNS

SSH

After setting the Input values using the preceding tables, click Save.

Launch the Master Database Server

Go back to the Deployment’s Servers tab (Manage > Deployments > deployment name) and launch the first database server (e.g. my-db1). This server will become your Master Database Server. To launch the server, click the Launch action icon.

When the Input Confirmation screen opens, verify that the INIT_SLAVE_AT_BOOT Input parameter is set to "False" (default). Since this server will be your Master Database Server, it is important to make sure that the server does not initialize as a slave database server at boot time.

Click the Launch action button to continue launching your database server.

Note: Do not launch your slave database server until you back up the database of the master server. Master server backup is covered in a later section of this tutorial.

In a few minutes, you will have a new server instance with MySQL installed, but it has an empty database. Be sure to wait for the server to boot up and enter the operational state before continuing to the next step (about 5-10 minutes).

Note: If you receive an error message about missing Input parameters and no Input is highlighted in red, it’s most likely because some of the required RightScale Credentials do not exist. The ServerTemplates have been preconfigured to use certain Credentials and assume that you’ve already created them.

If you did not complete the Create Credentials for Common Inputs step in the Deployment Setup section properly, you may not have created the required credentials that the ServerTeplates are trying to use. Once you’ve created those credentials, you should be able to successfully launch the server without receiving any missing Input error messages.  

Set up MySQL Database

The next step is to create and attach an Amazon Elastic Block Store (EBS) volume, or stripe of EBS volumes, to the running instance where your MySQL data will be stored.  To do this, you use the DB Create MySQL EBS stripe volume – 11H1 RightScript, which creates and attaches an EBS stripe designed for a MySQL server.  By default, it creates a blank MySQL database with no striping that includes all the necessary privileges for replication, administration, and application purposes.

Go to the the Scripts tab of the running server. Under the Any Script section, select the latest revision of the DB Create MySQL EBS stripe volume – 11H1 script. If you do not see this script in the list, you can import it from the MultiCloud Marketplace (Design > MultiCloud Marketplace > RightScripts). See DB Create MySQL EBS stripe volume - 11H1.

After you select the script, click Run.

Note: If you run revision 9 of the script, you may receive the following Audit Entry: “failed: DB Create MySQL EBS stripe volume – 11H1”. This is not an issue. The script executed successfully and imported the database into the attached volumes. There is a check that needs to be modified in this script to prevent this Audit Entry from being logged. A modified version of the script will be published soon, but in the meantime you can continue with the rest of the tutorial.

Before the script executes, you are prompted to provide values for some of the Input parameters. Use the following tables to set these values. When all of the required Inputs have values and you are ready, click Continue to execute the script.

Backup

Cloud

Database

Register the Master Database Server with your DNS Provider

In order for the automatic backup RightScript to function properly, you first need to designate the running instance as the Master Database Server. Then you need to run a script that makes the server function as a Master Database Server. To do this, you use the DNS Master DB register – 11H1 RightScript. This script registers the server as the “Master-DB” and updates your DNS A Records accordingly.

Go to the Scripts tab of the running server. Under the Any Script section, select and run the DNS Master DB register – 11H1 script. Select the latest revision of the script. If you do not see this script in the list, you can import it from the MultiCloud Marketplace (Design > MultiCloud MarketPlace > RightScripts). See DNS Master DB register - 11H1.

After you select the script and the revision, click Run.

When the Inputs confirmation window appears, enter any missing Input parameter values. Be sure to use the same values that you defined earlier at the Deployment level. When you run an Any Script, these Inputs are not pre-populated from the values you defined at the Deployment level.

The followingInputs are used by the script and are pre-populated from the Deployment level: MASTER_DB_DNSID, DNS_PASSWORD, DNS_USER. You do not need to set the values for these Inputs again.

When the script executes, the running server's Private IP Address is reported to your DNS provider and the A Record that you previously defined for your Master Database Server is updated. To quickly verify this change, log into your DNS provider and check your A Records. The IP address of the "Master-DB" A Record should match the private (not public) IP address of your Master Database Server. Notice that because the Slave Database Server is not up and running yet, the A Record for the “Slave-DB” still has its placeholder IP address (1.2.3.4). Later, when you launch the Slave Database Server, this A Record will be automatically updated by one of the boot scripts.

The following screenshot shows an example for DNSMadEasy.

Back Up the Master Database

The next step is to manually create a snapshot (backup) of the EBS volume(s) for the MySQL database. This step is required before you launch the Slave Database Server. When you launch the Slave Database Server, it uses the most recent database backup to restore the database. This enables the server to come up and get in-sync with the Master Database in a much shorter timeframe.

Go to the Scripts tab of the running server and run the "DB EBS backup - 11H1" operational RightScript. This script makes a backup of your MySQL database by creating a snapshot for each attached volume in the stripe.

Important! You must wait for all of the snapshots to be 100% complete before continuing the tutorial. Go to Clouds > your AWS Region > EBS Snapshots to check the status. If there are multiple pages of snapshots, use the Filter by Nickname option and search for the value that you set for the DB_LINEAGE_NAME Input to quickly find your related snapshots (e.g. mystripe). You should find a snapshot for each volume in the stripe.

The time it takes to complete the initial EBS snapshots varies depending on the size of the EBS volumes. For example, it can take a long time (over an hour) for large volumes, where smaller volumes might complete in just 5-10 minutes.

You now have a backup of your MySQL database in the form of a set of EBS snapshots that you can use to launch a fresh, new database server using the same ServerTemplate. Notice that each snapshot has the same name and timestamp, but has a unique ID and a tag which denotes the stripe order.

Launch a Slave Database Server

When the database backup is 100% complete, you are ready to launch your Slave Database Server (e.g. my-db2). 

Before you launch your Slave Database Server, you might want to consider changing its Availability Zone. Since you created the slave server by cloning the master server, the slave server is configured to launch an instance into the same Availability Zone as the master. If you want added redundancy (and are willing to pay for the additional data transfer costs), we recommend that you launch the slave server in a different Availability Zone from the master server. This allows you to have a running and in-sync backup server that you can use for failover and recovery scenarios if there is ever a major failure in the Availability Zone of your master server. You can edit the slave server's Availability Zone under the server’s Info tab.

Click the Launch action button of the second server in your Deployment. This new server will become a replicating slave server of the existing master server.

The ServerTemplate finds the most recent database snapshots using the DB_LINEAGE_NAME Input parameter (e.g. mystripe). The snapshots have a matching prefix (e.g. mystripe-master-yyyymmddttmm). For optimization purposes, the ServerTemplate automatically uses the most recent completed set of backup snapshots regardless of whether they are "slave" or "master” backups. This way, the slave server launches and is synchronized with the master server in a shorter timeframe.

Important! Set the INIT_SLAVE_AT_BOOT Input parameter to "true" (under the "Database" category's advanced inputs section) since you have a Master Database Server that's currently running. Setting this Input to "true" instructs the instance to initialize MySQL as a "Slave-DB" server during the boot process. Click the Launch, not Save and Launch button.

Congratulations! In a few minutes, when the server enters the "operational" state, you will have a MySQL master/slave database setup with data replication and automatic backups saved as EBS snapshots.

Note: In this example, we purposely did not name the first database server "master" (in the Dashboard) and the other one "slave" because we do not want the server names to become a source of confusion. Remember, over the lifecycle of your Deployment you'll most likely have to promote a "slave" to become the new "master" database server for troubleshooting purposes, or for performing various upgrades (e.g. vertical scaling from a 'small' to 'large' instance type). 

Because you defined this server to be a Slave Database Server at launch time, one of the scripts reported the server’s Private IP Address to your DNS provider. Verify this change by logging into your DNS provider and checking your A Records. You should see that both of the A Records for your database servers are properly pointing to the Private IP Addresses of your Master and Slave Database Servers.

The following screenshot hows an example for DNSMadeEasy.

Important! If for any reason both servers are shut down, and you want to recreate the master/slave setup, it doesn't matter which server you launch first. Simply launch the first server with INIT_SLAVE_AT_BOOT set to false. Once the server becomes operational, run "DB EBS restore and become master" RightScript to make it the "master" server. Then you can launch the other server as the "slave" with INIT_SLAVE_AT_BOOT set to true. See the Database Manager for MySQL Stripe Runbook for other common scenarios.

Shutting down a Database Server

If you ever need to shut down a database server, be sure to terminate it by running the 'DB TERMINATE SERVER' operational script, which will automatically delete the detached EBS volumes. If you terminate an instance using the "Terminate" action button in the Dashboard, the detached EBS volumes will not be deleted. You will need to manually delete them.

Create Load Balancers

Import the RightScale Load Balancer with Apache/HAProxy - 11H1 ServerTemplate from the MultiCloud Marketplace (Design > MultiCloud Marketplace > ServerTemplates). Select the ServerTemplate for the 11H1 Compatibility Release. When possible, always read a ServerTemplate's description in the MultiCloud Marketplace. The descriptions contain helpful information.

Because you should not have to customize this ServerTemplate, there is no need to clone and rename it. Simply leave the Input values as they are, they will get set correctly later at the Deployment level.

Add two load balancers to your Deployment.

Tips:

• First you must select the cloud where you are going to launch your servers. Choose the same cloud/region where you created your SSH key,
  Elastic IP, and Security Group, otherwise you will not be able to select and use those cloud resources when defining the server
• Use the ServerTemplate you just imported
• Use the SSH Key and Security Group you created earlierUse your first EIP for one load balancer, use your second EIP for the other load balancer.
• For high availability purposes, launch the load balancers into different Availability Zones from each other. Typically, you'll want to use the same zones as the database servers so that each zone will contain a load balancer and a database server.
• Use the default settings for the rest of the settings.

Configure Inputs

Set the following inputs at the deployment level.

Application

DNS

Load Balancer

Launch the Load Balancers

Launch both of your load balancers. There should be no missing Inputs, nor should you have to override any of the Inputs.

Once the load balancers are operational, your Deployment includes:

• Operational load balancers running Apache and HAProxy on the frontend
• Operational Master and Slave Database Servers on the backend
• A Server Array for Application Servers; these servers are not yet operational
• If you check your DNS provider account, you should see the following:
  • The A Records for the database servers point to the database server’s Private IP addresses
  • The A Records for the load balancers point to the Elastic IP (EIP) addresses of the servers. In the RightScale Dashboard, the Public IP addresses of the load balancers should match their assigned EIP addresses. When an instance is first launched, it is assigned a random IP address during the boot up phase. However, once the server becomes operational, the Public IP address is assigned its specified EIP.
  • No A Records that are still pointing to placeholder IP addresses (e.g. 1.2.3.4).

Clone and Customize the Application ServerTemplate

Before you create a server array that will serve as the application tier of the 3-tier deployment, you must first customize the ServerTemplate that you will use to launch each application server in the array. In this example, we're going to use a ServerTemplate for hosting a PHP application.

Go to Design > MultiCloud Marketplace > ServerTemplates. Find and import the PHP5 App Server – 11H1 ServerTemplate. If possible, read the ServerTemplate description.

After you import the ServerTemplate, clone it so that you can make changes to its scripts. Change the name of the ServerTemplate to something descriptive, perhaps including your initials or first name.

By default, the ServerTemplate is configured to pull the application code from an SVN repository. If you are using the example application in this tutorial, we instructed you to upload the example application to an S3 bucket. Because of this, you need to make a minor change to the ServerTemplate so that it can get the application code from this location. The next steps add a new RightScript to the ServerTemplate that checks out the application code from S3. The steps also delete the default RightScript that checks out the code from SVN.

Go to Design > MultiCloud Marketplace > RightScripts. Find and import the WEB Application s3 code checkout – 11H1 RightScript.

Add the script to your ServerTemplate as a Boot Script. Drag the new S3 code checkout script and place it before the WEB Application svn code checkout – 11H1 script. To do this, use the Arrow icon that appears on the right at the end of the script line to drag and drop the script into the appropriate position.

Delete the WEB Application svn code checkout – 11H1 script from the ServerTemplate.

Create a New RightScript

After you launch the all of the servers, we recommend you perform a quick test of the load balancers to see how incoming requests are sent to the application servers in a rotating fashion.

Important: It's important that the OPT_SESSION_STICKINESS input is set to "false" in order for the test to work properly. You will set this Input when you configure the Deployment's Inputs in a later step.

To perform the load balancing test, you need to create a new RightScript that installs a few basic HTML files that are used to test your load balancers. As always, try to name things in a descriptive manner (e.g. Load Balancer Test). In the script text box, copy and paste the following Bash code snippet:

#!/bin/bash -ex
cat > /home/webapps/$APPLICATION/current/hc.html << EOF
OK
EOF
cat > /home/webapps/$APPLICATION/current/servername.html << EOF 
<html><body><center><h1>This is server <font color="blue"> 
EOF
cat /var/spool/ec2/meta-data/instance-id >> /home/webapps/$APPLICATION/current/servername.html
cat >> /home/webapps/$APPLICATION/current/servername.html << EOF 
</font></h1></center></body></html>
EOF

After you paste the code into the script text box, click the Identify action button. You should see that one Input was discovered in the code called, APPLICATION, which is actually used by other scripts and is already defined at the Deployment level. As a best practice, whenever you create a new RightScript, you should provide a helpful tooltip description for the value that should be entered for an Input (e.g. “Name of the application”). Leave the “Value type” of the script set to “Any” so that you can enter a text value when setting the Input.

Look over the RightScript to make sure the formatting looks correct. Click Save when you are ready to save your new RightScript. Since you are testing this Deployment for the first time, do not commit the script and leave it as a HEAD version so that you can make changes later if necessary.

Add your new script as a Boot Script to your ServerTemplate. Since you are adding a private script that you have not published, you will be able to find the script using the 3-column selector under the “Unpublished” category. Place your new script before the LB Application to HAProxy connect – 11H1 boot script.

Important! The placement of your script before the LB Application to HAProxy connect – 11H1 script is critical.

The cloned ServerTemplate’s Scripts tab should look like the following screenshot.

Create and configure a scalable Server Array

Now that you've customized the ServerTemplate for your Application Servers to pull the application code from an S3 bucket and added a new script for testing the load balancers at the end of the tutorial, you are ready to create and configure a Server Array for horizontally auto-scaling the application tier.

First, you need to create a new alert-based Server Array. Go to Manage > Arrays and perform the  following steps that follow.

• Use the appropriate action button from the top of the Arrays page to create the array in the correct cloud\region for your Deployment (e.g. New AWS US-East).
• Select your Deployment so that the new Server Array is associated with the correct Deployment.
   

Note: A Server Array must be associated with a particular Deployment; a Deployment can have multiple Server Arrays associated with it.

• Leave the array “inactive” for now.
• Select your cloned ServerTemplate (you will find it in the “Unpublished” category) use the cloud resources you created earlier: the same SSH Key, Security Group, and so on.
• Change the following parameters for the Server Array. Leave the rest of the parameters set to their default values.
  • Minimum = 2 servers
  • Maximum = 5 servers
  • Resize Up by = 3
  • Resize Down by = 1
  • Resize calm time = 8

Click Save when ready.

Note: You should receive a message that your server array was successfully created. However, you may also receive a warning similar to the one that follows. Receiving this message is not a problem because you are going to clean up the remaining inputs soon.

"Some of the Input parameters for boot scripts are missing. Please update them to launch instances successfully."

Now that you’ve set up how the Server Array will automatically grow and shrink, the next step is to configure when the array changes size by defining the appropriate Alert specifications. There are actually two different ways to set up auto-scaling for this example. The most important thing to keep in mind is that any server that you think needs to be able to vote for grow/shrink actions must have the appropriate Alert specifications for triggering auto-scaling. Remember, a server can inherit Alert specifications from the ServerTemplate or Server Array levels. Because you might use the cloned application ServerTemplate in other Deployments, we’re going to add the Alert specifications at the Server Array level.

You need to add two new Alert specifications to trigger auto-scaling. Under the Server Array’s Next Alerts tab, you can add your new specifications to the existing Alert specifications that were inherited from the ServerTemplate. For this tutorial, you can use the suggested parameters that follow, but when you set up your own custom Deployment, you will want to pick appropriate metrics and thresholds that make sense for auto-scaling your own application. 

• Scale Up:If cpu-0/cpu-idle.value < ‘30’ for 5 min, then vote to grow array by setting the tag to the name of your server array. The example uses the tag ‘3tier’.

• Scale Down: If cpu-0/cpu-idle.value > ‘80’ for 5 min, then vote to shrink array by setting the tag ‘3tier’.
   

The server array's Next Alerts tab should now list two new alerts and look like the following screenshot:
 

Configure Inputs

Before launching your application servers, you must set the following inputs at the deployment level.

Important!  Be sure to use the same values for inputs that you used when you set up the database servers.

Tips: 

• Remember to hover over the blue Info icon () in the Dashboard for a description of each Input.
• Although many Inputs are displayed, most of them have already been set at the ServerTemplate level. If an Input has already been set, the Dashboard shows the Input’s value, the ServerTemplate from which the value was inherited, and the RightScript(s) that use the Input.
• When making multiple edits, make sure to click Save occasionally to avoid losing your work.

Application

Cloud

Database

Load Balancer

Enable and Launch the Application Server Array

Now that you have operational load balancers on the frontend that are ready to accept requests, and master and slave database servers on the backend, you are ready to start up the server array to run your application. Typically, you might want to launch a test server before you enable the entire array. The Launch action button allows you to manually launch a single server instance into an array. If you are using this tutorial as a learning tool, simply enable the server array.

Navigate back to the top level of your Deployment and select the server array name (this will be a hyperlink). Click the Enable action link on the Info tab (see the Status field). Because you set the Server Array’s Default Min Count to 2, two new servers will be automatically launched into the array.  By default, resize actions are displayed in the Events pane.  It may take a few minutes before the new servers are actually launched because RightScale's elasticity daemon evaluates server arrays every minute or so.

After you enable the array, the Events pane should show the two servers in your array coming up. You may have to wait a few minutes before the new servers are actually launched because RightScale's elasticity daemon evaluates server arrays every minute or so.

Verify the Application Servers in the Load Balancing Pool

To see the Application Servers that are available to your Load Balancers, use SSH to log into one of the Load Balancer Servers and view the contents of the HAProxy configuration file. The configuration file is located on the servers at /etc/haproxy/haproxy.cfg.

In the RightScale Dashboard, navigate to your Deployment and click the SSH icon next to one of the Load Balancer Servers. After you are connected to the server, go to the /home/haproxydirectory (cd/home/haproxy). Use the less command to view the contents of the rightscale_lb.cfgfile (less rightscale_lb.cfg).

Scroll to the bottom of the file using the spacebar. You should see entries similar to the following for each application server in the load balancer pool.

server i-9c8859f1 10.203.85.169:8000 check inter 3000 rise 2 fall 3 maxconn 255

server i-8a8859e7 10.204.97.84:8000 check inter 3000 rise 2 fall 3 maxconn 255

Note: The file maps the AWS ID of the servers in the array to their internal, private IP addresses. If you examine the private IP addresses, you can see that traffic to these servers is routed over port 8000 (10.203.85.169:8000). To allow communication between servers, this port must be open in the Security Group to which the Server Array belongs. For the purposes of this tutorial, that’s not important since all servers are in the same Security Group and can talk to each other because you added the Security Group to itself. However, if you required additional security, you might need to take this fact into consideration. For example, you might want to create separate Security Groups for each layer in your architecture (e.g. load balancers, application servers, and database servers). This approach provides additional control and server isolation. For more information, see Configuring Multiple Security Groups for a Multi-Tiered Deployment.

Verify the HA Proxy Status

You can use the HAProxy Status page to check the status of the Application Servers in the load balancing pool. The page is located off of the main URL for the Deployment at haproxy-status (e.g. http://my-www.example.com/haproxy-status). 

When you access the page, you will see the Application Servers in the pool. The load balancers will only establish client connections with "green" application servers that have passed the health check test (HEALTH_CHECK_URI). Application servers that are highlighted in "red" will not receive any traffic because it is not in a serviceable state. For example, the server is still booting up or it was unable to properly connect to the load balancer servers because the firewall permissions are not set up properly.  

Note: The operational servers shown in the status table should have the same server IDs displayed in the servername.html page that you checked earlier.

Verify Round-Robin Load Balancing

Use the following instructions to verify that your Load Balancer Servers are properly sending requests to the Application Servers in your Server Array in a round-robin fashion.

Earlier in the tutorial you created a RightScript to install the servername.html page on each of the Application Servers in the Server Array (see Create and configure a scalable Server Array). This is a simple page that shows which server in the array is responding to the request. The servername.html page is located directly off of the main URL for your Deployment and should be something like http://my-www.example.com/servername.html. 

To test that your load balancing is working correctly and that requests are being sent to each of the servers in your array, open a browser and access the servername.html page. The page displays the unique AWS ID for the server responding to the request. Take note of the ID and then refresh your browser. Again take note of the server ID.

You should see that each page request gets handled by a different server in the array. For example, if you had two servers in the array, you might see something like the following:

• This is server i-8a8859e7
• This is server i-9c8859f1
• This is server i-8a8859e7 (...)

This test confirms thatrequests are getting routed through your Load Balancers and that responses are coming back from your Application Servers in round-robin fashion.

Note: Due to some differences in how some browsers cache pages, it's recommended that you perform this test using Firefox.

Verify which Application Servers are in the Load Balancer Pool

You can also perform a quick test using SSH to see which application servers are connected to your load balancer.

• SSH into one of the load balancers and view the HAProxy configuration file /etc/haproxy/haproxy.cfg
  • At the Deployment's show page, click on the SSH icon next to one of the load balancers.
  • Type the following UNIX commands:
    • cd /home/haproxy/
    • less rightscale_lb.cfg
• Scroll to the bottom of the return message (spacebar) and you should see entries for each application server in the load balancer pool, similar to the following:

        server i-9c8859f1 10.203.85.169:8000 check inter 3000 rise 2 fall 3 maxconn 255
        server i-8a8859e7 10.204.97.84:8000 check inter 3000 rise 2 fall 3 maxconn 255

This shows a mapping of the Resource ID of the array servers with their Internal, Private IP Address. You can see that traffic to these servers is routed over port 8000. Hence this port must be open in the security group that the server arrays belong to. For the purposes of this tutorial that's not important, since all servers are in the same security group and can talk to each other as we added the security group to itself. However, if you required additional security, you might need to take this fact into consideration. For example, you might want to create separate security groups for each layer in your site architecture (e.g. load balancers, application server, database servers) for additional control and server isolation. See Configuring Multiple Security Groups for a Multi-Tiered Deployment.

Verify Auto-scaling of Application Servers

Follow the Adding Httperf Load Tester tutorial to launch an HTTP Perf Server that you can use to send traffic to your Deployment and trigger a scale up action that will launch additional Application Servers into the Server Array. When you run the script to send traffic, be sure to set the PERF_SERVER1 Input parameter to the main URL for your Deployment (my-www.example.com).

After a few minutes of running the traffic generating script, you should start to see a scale up action in the Events pane of the RightScale Dashboard. The Events will show additional servers being added to the Server Array. Likewise, when you stop the traffic generation script, the Events pane will show servers being terminated as the array scales down.

View the Contents of the Database

• Time and interest permitting, SHH into the Master Database Server and view the contents of the database manually. To do this, use the MySQL commands in the graphic below.

  Note: Remember to use your database schema name, which may not be “photo_demo_production” as seen in the following screenshot.
   

Perform a Complete End-to-End Test

To check if the database is communicating with the Application Server correctly, create a new RightScript called ‘3TierTestScript’ and copy and paste the following PHP.

#!/bin/bash -ex
cat > /home/webapps/$APPLICATION/current/3tier.php << EOF

<html>
 <head>
  <title>Application Node and MySQL Table Viewer</title>
 </head>
<body bgcolor="#C0C0C0">

<center><h1>Instance Resource ID: <font color="blue">
EOF

cat /var/spool/ec2/meta-data/instance-id >> /home/webapps/$APPLICATION/current/3tier.php

cat >> /home/webapps/$APPLICATION/current/3tier.php << EOF
</font></h1>
EOF
cat >> /home/webapps/$APPLICATION/current/3tier.php << EOF
<center><h1>Availability Zone: <font color="blue">
EOF
cat /var/spool/ec2/meta-data/placement-availability-zone >> /home/webapps/$APPLICATION/current/3tier.php

cat >> /home/webapps/$APPLICATION/current/3tier.php << EOF
</font></h1>
EOF
cat >> /home/webapps/$APPLICATION/current/3tier.php << EOF
<center><h1>Security Group(s): <font color="blue">
EOF
cat /var/spool/ec2/meta-data/security-groups >> /home/webapps/$APPLICATION/current/3tier.php


cat >> /home/webapps/$APPLICATION/current/3tier.php << EOF
</font></h1>

<h1>Below is the contents of the Database</h1>

<?php
\$dbhandle = mysql_connect("$MASTER_DB_DNSNAME", $DBADMIN_USER, $DBADMIN_PASSWORD);
if (!\$dbhandle)
  {
  die('Could not connect: ' . mysql_error());
  }
mysql_select_db("$DB_SCHEMA_NAME", \$dbhandle);

\$result = mysql_query("SELECT * FROM phptest");
?>

<table border='1'>
<tr>
<th>ID</th>
<th>Firstname</th>
<th>Lastname</th>
</tr>

<?
while(\$row = mysql_fetch_array(\$result))
  {
  echo "<tr>";
  echo "<td>" . \$row['id'] . "</td>";
  echo "<td>" . \$row['firstname'] . "</td>";
  echo "<td>" . \$row['lastname'] . "</td>";
  echo "</tr>";
  }

echo "</table><br/>";

mysql_close(\$dbhandle);?>

<form action="insert.php" method="post" style="width:440px;">
<fieldset>
<legend>Add a Record</legend>
ID: <input type="text" name="id"><br>
Firstname: <input type="text" name="firstname"><br>
Lastname: <input type="text" name="lastname"><br>
<input type="Submit">
</fieldset>
</form><br/>


<form action="delete.php" method="post" style="width:440px;">
<fieldset>
<legend>Remove a Record</legend>
ID: <input type="text" name="id"><br>\
<input type="Submit">
</fieldset>
</form>

</center>
</body>
</html>
EOF

cat > /home/webapps/$APPLICATION/current/insert.php << EOF
<?php
\$dbhandle = mysql_connect("$MASTER_DB_DNSNAME", "$DBADMIN_USER", "$DBADMIN_PASSWORD");
if (!\$dbhandle)
  {
  die('Could not connect: ' . mysql_error());
  }
mysql_select_db("$DB_SCHEMA_NAME", \$dbhandle);

\$sql="INSERT INTO phptest (id, firstname, lastname)
VALUES
('\$_POST[id]','\$_POST[firstname]','\$_POST[lastname]')";

if (!mysql_query(\$sql,\$dbhandle))
  {
  die('Error: ' . mysql_error());
  }
echo "1 record added";
echo "<br />";
echo "<a href=\"3tier.php\">Click here to return to previous page.</a>";

mysql_close(\$dbhandle);
?>

EOF

cat > /home/webapps/$APPLICATION/current/delete.php << EOF
<?php
\$dbhandle = mysql_connect("$MASTER_DB_DNSNAME", $DBADMIN_USER, $DBADMIN_PASSWORD);
if (!\$dbhandle)
  {
  die('Could not connect: ' . mysql_error());
  }
mysql_select_db("$DB_SCHEMA_NAME", \$dbhandle);

\$sql="DELETE FROM phptest WHERE id = ('\$_POST[id]')";

if (!mysql_query(\$sql,\$dbhandle))
  {
  die('Error: ' . mysql_error());
  }
echo "1 record deleted";
echo "<br />";
echo "<a href=\"3tier.php\">Click here to return to previous page.</a>";

mysql_close(\$dbhandle);
?>

EOF

After you've pasted this into the RightScript, click the Identify action button to retrieve the Inputs.

• Enter values for the following Inputs: APPLICATION, DBADMIN_PASSWORD, DBADMIN_USER, DB_SCHEMA_NAME, and MASTER_DB_DNSNAME. The values for these are already defined for the Deployment. Refer to the Set Deployment-Level Inputs section earlier in this tutorial.
• Uncheck the box for the "_POST" Input. The "$_POST" variable in the PHP script is not an actual Input.

Then click the Save action button.

When you are ready, click the Save action button to save the new script.

Now go back to your Deployment and access the attached Server Array. Under the array’s Scripts tab, use the Any Script option to run the new RightScript on all the servers in the array. Select the script entitled “3TierTestScript” from within the Unpublished section. When prompted for the servers that you want to run the script against, select the run on all action button. The script reuses the Inputs that you've already defined so the appropriate credentials and values are automatically pre-selected on the Input confirmation screen. Click the Run action button to run the script.

Open a browser and access the 3tier.php page off of the main URL for the Deployment (e.g. my-www.example.com/3tier.php). After you access the page, refresh your browser a few times. With each refresh you should see a simple page that shows the Application Server in the array that is responding to the request as well as the contents of the database. Enter some new entries to the database and you should see the user table reflect your additions.