3 Tier Deployment Setup (HAProxy-PHP-PostgreSQL)

Objective

To create a 3-tiered production-like deployment from scratch using ServerTemplates published by RightScale for a PHP application.

Note: This tutorial uses RightScale's latest revisions of the v13 Infinity ServerTemplates that use Chef cookbooks and recipes instead of RightScripts.

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, Cloud DNS). 
• 'designer' 'actor' and 'security_manager' user role privileges are required, although the 'security_manager' user role privilege may not be required if security groups 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 several of RightScale's ServerTemplates. 

• (HAProxy) Load Balancing servers
• PHP Application servers
• PostgreSQL Database servers

Disclaimers

• This tutorial assumes that you are launching all servers into the same cloud infrastructure. 
• 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 (Manage > Deployments) 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 Cloud-specific Resources

Prerequisites: Requires 'actor' user role privileges in the RightScale account to create SSH Keys and Elastic IPs, and 'security_manager' privileges to create/modify security groups.

Each cloud infrastructure is unique and requires different resources in order to launch a server in their cloud. Depending on the type of cloud infrastructure that you're going to use to launch servers, you will find it useful to create some of the required cloud-specific resources beforehand so that you can select them in the "Add Server Wizard" when you add servers into a deployment. Some cloud resources are also region-specific. For example, you cannot launch an EC2 instance in the 'us-east' region with a 'us-west' security group. 

SSH Key

If the cloud does not require the use an SSH Key, you can ignore this step. 

SSH Keys are used for authentication purposes to create SSH console sessions for root level access to the instance. Although you are required to associate an SSH Key to a server before you can launch it, the private key material is no longer required if managed SSH (Server Login Control) is enabled for the account (Settings > Account Settings > SSH). By default, Server Login Control is enabled at the account level, where a user's own unique RSA key pair (Settings > User Settings > SSH) is used for authentication purposes for establishing SSH console sessions on all RightLink-enabled instances.

You can either use an existing SSH Key or create a new one.

• Amazon EC2
  • Create a New SSH Key

Security Groups

If the cloud does not support Security Groups, you can ignore this step. 

Security groups are firewall settings that apply to instances within a cloud at the infrastructure layer. Security groups are typically used to control ingress communication (i.e. inbound communication to an instance over a particular port and protocol) however, some clouds support the use of security groups to also control egress communication (i.e. outbound requests from the instance). Once you create a security group you can create different firewall rules that control the level of access to instances launched with that particular security group(s). Firewall rules are enforced at the cloud (infrastructure) level using IP-based or Group-based permissions.

If you are building this deployment for demonstration and testing purposes, you can simply create a single security group for all servers in your deployment. 

The steps for creating a single security group are different depending on the type of account and cloud that you are using.

1. For a Unified Cluster Platform (UCP) RightScale account (e.g. us-3.rightscale.com), follow the cloud-specific instructions below. ​
   • Amazon Web Services - EC2
   • OpenStack (Juno)
   • Google Compute Engine
   • CloudStack
2. For a Legacy Platform RightScale account (e.g. my.rightscale.com), follow the cloud-specific instructions below. 
   • Amazon Web Services - EC2
   • OpenStack
   • Google Compute Engine
   • CloudStack

Once you are successful setting up your first multi-tier deployment you can set up more secure firewall permissions that would be more realistic for production environments. See Configuring multiple Security Groups for a multi-tiered Deployment.

Remappable Public IP Addresses

Some clouds support the use of public IP addresses that you can associate with a server at launch time or remap to another running server, as necessary for lifecycle management scenarios. It's recommended that you use this service, if available for front-end load balancer or web servers that are designed to be public facing. If you're using dedicated HAProxy load balancer servers, you should create/reserve one IP address for each load balancer server. Typically, you will have two HAProxy load balancer servers for high-availability and failover purposes. If you are using a cloud's load balancing service such as Amazon Elastic Load Balancers (ELB) or Rackspace Cloud Load Balancers (CLB) you cannot assign remappable IP addresses. In such cases, skip this step.

• Amazon EC2
  • Create a New Elastic IP (EIP)
• Rackspace Private, CloudStack, OpenStack, HP, Datapipe
  • ​Create a New (Public) IP Address

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 diagram below shows a typical example of a 3-tier website architecture.

In this type of architecure, the application servers and any "slave" database 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. If you are also creating DNS records for the front-end load balancer servers, you can use a more conservative TTL than the database tier. (e.g. 1800 seconds)

Note: If you are using Rackspace's Cloud DNS service, you must use a TTL of 300 seconds because that is the lowest allowable TTL. Be sure to change the 'Database DNS TTL Limit' input from 60 (default) to 300.

You will need to create DNS records for the following servers:

• Each Load Balancer Server or Load Balancing service (e.g. Amazon Elastic Load Balancer, Rackspace Cloud Load Balancer, etc.)
• 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.

• Domain Setup with DNSMadeEasy
• Domain Setup with DynDNS
• Domain Setup with Amazon's Route 53 (Aws DNS)
• Domain Setup with Rackspace Cloud DNS

Create 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 Linux 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: a1234
     
• DBAPPLICATION_USER - User name of a database user with user-level privileges. Use this credential for the "Database Application Username" input. Note: For PostgreSQL databases, the username cannot start with a number.
  • 3 Tier Tutorial: johnsmith
• DBAPPLICATION_PASSWORD - Password for DBAPPLICATION_USER. Use this credential for the "Database Application Password" input.
  • 3 Tier Tutorial: 1234z
     
• 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: ic6789
     
• 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).

Set up your desired ROS service(s) and create the recommended user-defined credentials, which you will use when you define inputs for your deployments.

• Set up Amazon S3
• Set up Google Cloud Storage
• Set up Rackspace Cloud Files
• Set up Windows Azure Cloud Storage
• Set up SoftLayer Object Storage
• Set up OpenStack Object Storage (Swift)
• Set up HP Cloud Object Storage

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.

You can also 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)

Load Balancer

If you are using SSL to support HTTPS access, you should create credentials for any of the following values that apply. See How do I create an SSL certificate for my web server?

• LB_STATUS_USERNAME - Optional user name to require in order to log in to the HAProxy status report page.
• LB_STATUS_PASSWORD - Optional password corresponding to LB_STATUS_USERNAME.
• SSL_CERTIFICATE - Contents of the X.509/PEM-format SSL server certificate used for enabling HTTPS communications.
• SSL_CERTIFICATE_CHAIN - The certificate authority (CA) certificate chain associated with the server certificate used to set up HTTPS communications.
• SSL_CERTIFICATE_KEY - The SSL server certificate's private key, in PEM format.
• SSL_PASSPHRASE - If required by an SSL certificate, you must provide the passphrase so Apache can start.

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.

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. Make sure the uploaded file maintains the .gz file extension.

Warning! The filename of the PostgreSQL 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.

• Upload Files to an Amazon S3 Bucket
• Upload Files to a Rackspace Cloud Files Container
• Upload Files to an OpenStack (Swift) Container
• Upload Files to a Google Cloud Storage Bucket
• Upload Files to a Windows Azure Blob Container
• Upload Files to a SoftLayer Object Storage Container

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 PostgreSQL dump file to complete the tutorial. The sample is a gzip (.gz) file.

app_test-20121603072614.gz

Create a Database 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 "Database Manager for PostgreSQL 9.1 Beta (v13.x)" ServerTemplate into your RightScale account. (Note: This ServerTemplate was deprecated from the MultiCloud Marketplace and can no longer be imported.)
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., postgresql-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 FQDN, 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 or Cloud Files container)
  • INPUTS: Backup Primary Secret (default), Backup Primary User (default), Primary Backup Storage Cloud (default),
    Primary Backup Storage Cloud Endpoint URL (default)
• 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)
• 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 PostgreSQL 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 PostgreSQL database will be stored locally on the instance's ephemeral drive. Backups of the database will be stored as binary dump files to the specified object storage container.

Required

Advanced

DB

SYS_DNS

Launch the Master 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, based on the inputs configured for your primary database backups.
• Creates a database backup to primary storage.

• Schedules a cron job to run backups to primary storage once every four hours on the server. (For information on modifying the default backup schedule, see the Database Manager for PostgreSQL 9.1 Beta (v13 Infinity) - 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 PostgreSQL dump file from an ROS location.

Note: If you use a previous backup snapshot instead of a PostgreSQL dump file or initialize a blank PostgreSQL database, refer to the Database Manager for PostgreSQL 9.1 Beta (v13 Infinity) - Runbook for instructions.

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 PostgreSQL 9.1 Beta (v13 Infinity) - Runbook.

Add a Slave Database Server

Although you can run PostgreSQL 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. postgresql-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)

3. 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.
4. 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 PostgreSQL client port (TCP port 5432) 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.

Load Balancer Tier Setup

Add a Server

Follow these steps to add a load balancer server to the deployment.

1. Go to the MultiCloud Marketplace (Design > MultiCloud Marketplace > ServerTemplates) and import the most recently published revision of the "Load Balancer with HAProxy (V14.x)" 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 into which the new server will be placed.
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 load balancer server (e.g., lb1). 
   • Select the appropriate cloud-specific resources 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 load balancer server you will use a different datacenter / zone to ensure high-availability. For more information, see Add Server Assistant.
   • If you are using Elastic IPs (AWS EC2 only), select an existing Elastic IP from the drop-down, or click New to create a new one.
6. Click Confirm, review the server's configuration and click Finish to create the server.

Create another Load Balancer Server

For production environments, it's strongly recommended that you have at least two load balancer servers (preferably in different availability zones or datacenters) for redundancy purposes. The easiest way to create a second load balancer is to simply clone and modify the first load balancer server.

1. Go to the show page of the load balancer server that you just created and click the Clone button.
2. Change the name of the server accordingly. (e.g. lb2)
3. Under the Info tab, click Edit.
4. Select a different zone/datacenter and Elastic IP (if applicable).

Configure Inputs

The next step is to define the properties of your load balancer server or servers by entering values for inputs. As a best practice, you should define required inputs for the servers 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 load balancers, open the deployment's Inputs tab, click Edit, and use the following settings to configure input values. We recommend that you set up credentials for password values and any other sensitive data as shown in the examples.

RS-HAPROXY

Launch the Server

1. Go to the deployment's Servers tab and launch all of the load balancer servers. When you view the input confirmation page, there should not be any required inputs with missing values.  If there are any required inputs that are missing values (highlighted in red) at the input confirmation page, cancel the launch and add values for those inputs 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.
   
   Note: Remember that as a best practice for building high-availability sites, you should have two load balancers that you launch in different availability zones or data centers.

Configure DNS Records

If you are using Elastic IPs or already know the public IP addresses that will be used by the load balancer servers, you might have already set up the DNS records for the load balancing tier. However, if you do not know the public IP addresses that will be assigned to the load balancer servers, you must manually set up the DNS records after the servers have been launched. Once the servers become operational (and have been assigned their respective public IP addresses), create or update the DNS records with your DNS provider. Each load balancer server should have its own DNS record with the same hostname (e.g. www.example.com) that points to its public IP address.

The DNS records for the HAProxy load balancing tier should direct traffic from the associated hostname (FQDN) (e.g. www.example.com) to the application servers in its load balancing pool.

Application Tier Setup

Add a Server

Follow these steps to add a load balancer server to the deployment.

1. Go to the MultiCloud Marketplace (Design > MultiCloud Marketplace > ServerTemplates) and import the most recently published revision of the PHP App Server Beta (v14.0.0) 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 into which the new server will be placed.
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 load balancer server (e.g., lb1).
• Select the appropriate cloud-specific resources 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 load balancer server you will use a different datacenter / zone to ensure high-availability. For more information, see Add Server Assistant.
• If you are using Elastic IPs (AWS EC2 only), select an Elastic IP.

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 application balancer server or servers by entering values for inputs. As a best practice, you should define required inputs for the servers 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 load balancers, open the deployment's Inputs tab, click Edit, and use the following settings to configure input values. We recommend that you set up credentials for password values and any other sensitive data as shown in the examples.

RS-APPLICATION_PHP

Launch the Server

Now that you have finished defining server details, you are ready to launch a server in the cloud with the new settings. Click the server's Launch button.

Review the inputs that you set at the Inputs confirmation page and click Launch.

Test the Deployment

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

Next Steps

Post Tutorial Steps

• Perform a Health Check Test