Note: Please go to docs.rightscale.com to access the current RightScale documentation set. Also, feel free to Chat with us!
Home > ServerTemplates > v12.11 LTS > Supplemental > 3 Tier Deployment Setup (HAProxy-IIS-SQL)

3 Tier Deployment Setup (HAProxy-IIS-SQL)

Prerequisites

  • Access to add/create/edit DNS records with a supported DNS provider (e.g. DNSMadeEasy, DynDNS, Route53, Cloud DNS). 
  • 'designer' 'actor' 'library' 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

It's recommended that you follow the tutorial using the provided sample files before you attempt to build a similar deployment for production use. (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. 

  • (HAProxy) Load Balancing servers
  • Microsoft IIS Application servers
  • Microsoft SQL Database servers (Standalone or Mirrored Setup)

 

diag-3tier_windows-v1.png

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

Prerequisites: Requires 'actor' user role privileges in the RightScale account.

The first step is to create a new deployment for the project. It's not recommended that you use the "Default" deployment or an existing deployment for new development because you do not want to accidentally inherit any unknown configuration settings. Therefore, it's recommended to always create a new deployment when you start a new project. Be sure to use a unique and descriptive nickname for each deployment. (e.g. My Project Name)

  1. Go to Manage > Deployments. Click New and provide the following information:
    • Nickname - User-defined name for the deployment. 
    • Description - A short, internal-only description of the deployment.

Tip: Most users find it useful to create a bookmark in the left-hand pane of the dashboard that links to the deployment's Servers tab.

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 standalone or principal SQL database server by using the database server's FQDN (e.g., db-principal.example.com), which points to the server'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 standalone/principal 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 standalone/principal 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 standalone/principal database server.

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 'DNS_TTL' input from 60 (default) to 300.

diag-3tier_ga_Win-v1.png

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

  • Each HAProxy Load Balancer Server
  • Standalone/Principal Database Server
  • Mirror 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.

Important! The tutorials below assume that you are creating records for a Linux-based architecture. However, you can follow the general steps to create the DNS records that are required for Windows.

Create Common Credentials

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

Note: 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. ProjectX-SQL_APPLICATION_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.

Windows

By default, when you launch a Windows server in the cloud, an initial password is automatically generated for the Windows 'Administrator' user. However, each Windows-based ServerTemplate published by RightScale contains a boot script ('SYS Set admin account') that allows you to change the password for the 'Administrator' user with the ADMIN_PASSWORD input or create a new user with administrative privileges by using the ADMIN_ACCOUNT_NAME input. It's strongly recommended that you create a credential and use that value for the ADMIN_PASSWORD input in order to use your own password instead of the randomly generated one. Use the username and password to start a Remote Desktop Protocol (RDP) connection.

  • WINDOWS_ADMIN_PASSWORD - Password for the Windows 'Administrator' user (default) or specified user with administrative privileges. You must specify a value that satisfies the minimum password requirements, otherwise the initial Windows password will be used instead. For example, a valid password should contain at least 7 characters and include at least one upper case letter, one lower case letter, and one digit. See Password Policy for details.


Amazon S3

If you are using Amazon S3 to store binary database backups or retrieve private files from an S3 bucket, you must use the following AWS credentials for authentication purposes. Fortunately, these credentials are automatically created when AWS credentials are added to a RightScale account. Although, they are available for use when you define your inputs, they will not be listed under Design > Credentials.
Note: AWS credentials are located under Settings > Account Settings > Clouds.

  • 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

If you want to use Rackspace Cloud Files for storing binary database backups or retrieving files from a private container, you will need to create the following credentials.

  • RACKSPACE_USERNAME - The username used to log into Rackspace's Cloud Control Panel.
  • RACKSPACE_AUTH_KEY - The Rackspace account API key.

 

DNS

  • 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 "principal" database server.
  • DNS_PASSWORD* - Password for DNS_USER.

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

Source Control Management (SVN, GitHub)

If you are using a source control management (SCM) system to host your application code, you will need to create the following 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.
     
  • SVN_USERNAME - The SVN username that has access to the specified repository.
  • SVN_PASSWORD - Password for SVN_USERNAME.


Microsoft IIS/SQL

If you are setting up a multi-tier deployment using ServerTemplates based on RightScale's IIS and SQL ServerTemplates, a SQL user with application privileges is required by the application to connect to the SQL database.

  • SQL_APPLICATION_USER - SQL database user with login privileges to the specified user database.
  • SQL_APPLICATION_PASSWORD - Password for the SQL database user with login privileges to the specified user database.

 

Secure Sockets Layer (SSL)

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?

  • 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.

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 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. Cloud resources are also cloud-specific. For example, you cannot launch an EC2 instance in the 'us-east' region with an 'us-west' security group. 

Warning!
If you are following a standard 3-tier tutorial for testing and demonstration purposes only, you can create a single security group with the following permissions. If you are building a 3-tier deployment for a production environment, you should consider using more robust security group settings. See Configure Multiple Security Groups for a Multi-Tiered Deployment.

Windows

At a minimum, the security group should contain the following firewall permissions.  Note: Port 443 is only required for SSL support (HTTPS).

The example below shows the firewall permissions for an EC2 security group called '3tier-microsoft-all-tiers' that contains all of the required permissions if you used the same security group for all the servers, which should only be used in a demo or test environment.

screen-Security_Group_Win_All-v1.png

Amazon Web Services (EC2 and S3)

EC2

  • Create a New SSH Key You are required to select an SSH Key when you launch an EC2 instance. Although it can be used to establish a remote connection with the instance, Server Login Control is used instead.
  • Create a New EC2 Security Group Although you can use the same security group for all servers in the same region, you may want to consider creating separate security groups for each tier of your site architecture for additional security. See Configure Multiple Security Groups for a Multi-Tiered Deployment.
  • Create Elastic IPs (EIP) If you are launching load balancer servers in EC2, it's recommended that you use Elastic IPs for your public facing load balancer servers if you're using RightScale's "Load Balancer" ServerTemplates. Typically, you will have two load balancers for redundancy purposes. You must create an Elastic IP for each load balancer.

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. 

If S3 is not activated for your AWS account, please sign-up for the service now. (http://aws.amazon.com/s3/)

CloudStack


Database Tier Setup

Upload the Database Dump File

The ServerTemplate contains scripts that can retrieve a Microsoft SQL database backup file from a Remote Object Storage (ROS) location such as an Amazon S3 bucket or a Rackspace Cloud Files container. Create a new bucket/container and upload your database backup file. You can either restore the database using a SQL backup file (.bak) or attach an existing database file (.mdf). The file can remain a 'private' object because your cloud credentials can be used (as inputs) for authentication purposes to retrieve the file.

Warning! The filename of the backup 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, you may use the following sample SQL backup file to complete the tutorial.

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 Microsoft SQL Server ServerTemplate into your 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., sql-db1). Do not include "primary" or "mirror" 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 will need to provide the necessary values as inputs based on which options you want to use.

Set Inputs at the Deployment Level

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

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

BACKUP

By default, the server will be configured to take continuous backups of the SQL database. Backups will either be saved as snapshots (if volumes and snapshots are supported by the cloud) or as backup files (.bak) to an ROS location such as an Amazon S3 bucket or Rackspace Cloud Files container. If you are setting up the SQL database with this ServerTemplate for the first time, you can either use an existing database (.mdf) or backup (.bak) file stored in an ROS container. If you are using the provided example, provide the appropriate inputs to use the backup file (DotNetNuke.bak).

Input Name
Description
Example Value
BACKUP_FILE_NAME

The name of the database backup file that you previously uploaded to an ROS container.  (e.g. sql-database.bak)

If you are going to use a database file (.mdf), leave this field empty and use the MDF_FILE_NAME input instead.

For the provided sample file use:

text:  DotNetNuke.bak

BACKUP_METHOD

Select the type of backup storage that will be used for taking backups of the database.

  • Snapshots - Volume snapshots such as Amazon's Elastic Block Store (EBS).
  • Remote Storage - Remote Object Store (ROS) location such as an Amazon S3 bucket or Rackspace Cloud Files container.
text:  Snapshots
DB_BACKUP_KEEP_DAILY, _LAST, _MONTHLY, _WEEKLY, _YEARLY
 

If you are using snapshots (BACKUP_METHOD=Snapshots) to create database backups, you can use these inputs to specify the preferred backup policy. 

Input is ignored if you are using 'Remote Storage' for BACKUP_METHOD.

 
MDF_FILE_NAME

The name of the database file that you previously uploaded to an ROS container.  (e.g. sql-database.mdf)

If you are going to use a database backup file (.bak), leave this field empty and use the BACKUP_FILE_NAME input instead.

text:  sql-database.mdf

Cloud

In order to create volumes or retrieve objects such as a database or backup file from an ROS container, you must provide the required cloud credentials for authentication purposes.

Input Name
Description
Example Value

AWS_ACCESS_KEY_ID

AWS_SECRET_ACCESS_KEY

Specify valid cloud credentials to retrieve the file from an Amazon S3 bucket.

cred:  AWS_ACCESS_KEY_ID

cred:  AWS_SECRET_ACCESS_KEY

RACKSPACE_AUTH_KEY

RACKSPACE_USERNAME

Specify valid cloud credentials to retrieve the file from a Rackspace Cloud Files container.

Note: Only Rackspace Cloud Files US, not UK is supported.

cred:  RACKSPACE_AUTH_KEY

cred:  RACKSPACE_USERNAME

STORAGE_CONTAINER_NAME

Specify the name of the remote object storage (ROS) container where the backup (.bak) or database (.mdf) file will be retrieved from such as the name of the Amazon S3 bucket or Cloud Files container. 

Note: Only Rackspace Cloud Files US, not UK is supported.

Note: By default, primary backups will also be stored to the same location. To change the ROS location for primary backups, change this input at the server level and run the 'DB SQLS Init principal' boot script after the server is operational. Then change the input at the deployment level.

text:  my-bucket
STORAGE_TYPE

Select the type of remote object storage (ROS) location where the file will be retrieved.

  • S3 - Amazon S3 Bucket
  • Cloud Files - Rackspace Cloud Files Container
Note: Only Rackspace Cloud Files US, not UK is supported.
text:  S3

 

Database

Important!
If you are configuring a mirrored setup (consisting of a Principal and Mirror server) and you want to launch the Mirror server in a different availability zone as the Principal server, you must use the 'Remote Storage' option for the INIT_MIRRORING_METHOD input.

Input Name
Description
Example Value
DATA_VOLUME_SIZE

The size of each volume that will be used store the SQL database.  For example, if the NUMBER_STRIPES input is '2' and you specify a DATA_VOLUME_SIZE of '5', two 5-GB volumes are created. It's recommended that you specify a large enough value that provides enough space for the database to grow over time and provide optimal r/w performance.

WarningIf your are deploying on a CloudStack-based cloud that does not allow custom volume sizes, enter a predefined CloudStack volume size (e.g., 'Small' or 'Large') rather than a numeric value here.

text:  10
DB_LINEAGE_NAME The lineage of the database backups. This is a string that is used to track all backups in a certain 'set', usually deployment wide. Ex: mymssqlserver text:  LineageName
DB_NAME

Enter the name of the default database to assign to the created SQL Server login. This value is not an arbitrary value. The name of the database is already set. If there are multiple databases, you can list a comma-separated list of all the database names. Ex: DatabaseName

text:  mydb

For the provided sample file use:

text:  DotNetNuke

INIT_MIRRORING_METHOD

The method for setting up a SQL database mirroring session between two servers. A backup (.bak) of the database and a self-signed certificate are used to authenticate a mirror session between a principal and mirror database server. If you want to launch the mirror in a different availability zone as the principal server, you must use an ROS location. If the cloud supports volumes and you want to launch the mirror in the same availability zone as the principal, select the 'Volumes' option.

  • Volumes (default) - A separate volume is used to transport the database backup file and certificate between the principal and mirror servers. If you select this option, both the Principal and Mirror servers must be launched into the same availability zone.
  • Remote Storage - An ROS container is used to store and transfer the database backup file and certificate between the principal and mirror servers. Select this option if you want to launch the Principal and Mirror servers into different availability zones.
text:  Volumes
LOGS_VOLUME_SIZE

Size of volume (in GB) for storing log files. Ex: 1

To optimize your Tempdb, this should be 1gb greater than your instance core count.

text:  1
NUMBER_STRIPES

If the cloud supports the use of volumes, you can create a drive (e.g. D:\) that consists of a stripe of volumes. This input applies to both the data and log drives. If you do not want to use a stripe of volumes, keep the default setting. (Default: 1)

WarningYou can set this to a numeric value between 1 and 5 when launching your server in the Amazon EC2 cloud; however, do not set it to values greater than 2 for CloudStack-based servers. This restriction is due to a difference in the quantity of block devices supported for CloudStack-based clouds.

text: 1

DNS

Input Name
Description
Example Value
DNS_DOMAIN_NAME

If you are using a DNS service provider that references records by a FQDN instead of an string ID, use this input to specify the fully qualified domain name that points to the standalone or principal database server. (e.g. my-principal.example.com)

Examples:

  • DynDNS:  my-principal.example.com  (FQDN)
text:  my-principal.example.com
DNS_ID

If you are using a DNS service provider that references records by a unique string ID, use this input to identify your standalone or principal database server to your DNS provider. See Deployment Prerequisites for more information.

Examples:

  • DNS Made Easy:  1234567  (Dynamic DNS ID)
  • Rackspace Cloud DNS (US):  a1234567  (Dynamic DNS ID)
  • Rackspace Cloud DNS (UK):  a1234567  (Dynamic DNS ID)
  • Amazon Route53:  Z3DSDFSDFX (Hosted Zone ID)
text: 1234567
DNS_PASSWORD

The password used to log into your DNS provider. 

  • DNS Made Easy - DME Password
  • DynDNS - DynDNS Password
  • Amazon Route 53 - AWS Secret Access Key
  • Rackspace Cloud DNS - Rackspace Password
cred:  DNS_PASSWORD
DNS_SERVICE

Select the DNS provider that will be used to update the DNS record of the principal database server.

  • DNS Made Easy
  • DynDNS
  • Rackspace Cloud DNS (US region)
  • Rackspace Cloud DNS (UK region)
  • Route53
text:  DNS Made Easy

DNS_USER

The username used to log into your DNS provider. 

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

cred:  DNS_USER

OPT_USE_PUBLIC_IP Defines whether or not a mirror database server will use the public (not private) IP address to connect to the principal database server.
  • True - Use public IP address for mirroring connection
  • False - Use private IP address for mirroring connection
text:  False

SYSTEM

Input Name
Description
Example Value
ADMIN_PASSWORD

Set the new password for the local Administrator account. The password must satisfy Window's minimum requirements for a Windows administrator password, otherwise the random password that is generated for you at boot time (located under the server's Info tab,'Initial Admin Password' field) will be used instead. The password should be at least 7 characters long with at least one upper case letter, one lower case letter and one digit. 

When you RDP into the server, you will use this password to log in as the Windows 'Administrator' user.

It's strongly recommended that you use a credential to hide this value. However, anyone who needs to log into the server will need to know the actual value.

cred:  WINDOWS_ADMIN_PASSWORD  
SYS_WINDOWS_TZINFO

Sets the system timezone to the timezone specified, which must be a valid Windows timezone entry. You can find a list of valid examples in "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones". Some examples have been provided in the dropdown, which you may override if you do not see your timezone listed.

It's strongly recommended that you use, "GMT Standard Time" (Greenwich Mean Time).

text: GMT Standard Time

Launch a Standalone Database Server

After configuring your inputs, launch the database server that will serve as either the standalone or principal server.

  1. Go to the deployment's Servers tab and launch the database server.
  2. When you view the input confirmation page, make sure the database server's mode is set to 'Standalone' mode. If you are setting up a mirrored Principal-Mirror setup, you will later run an operational script on this server that will change its mode to be a Principal.

DATABASE

Input Name
Description
Example Value
SERVER_MODE
Select the databaser server's role/mode. 
  • Standalone (default)  
  • Principal
  • Mirror
text:  Standalone
  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. 
  3. (Optional)  If you are launching a server in a cloud that uses volumes (e.g. AWS) you can go to the server's Volumes tab once it's operational to view the volumes that were created for the database server.  

screen-volumes-v1.png

Load the Database

The next step is to load the database onto the server by either using a backup (.bak) or database file (.mdf) from an ROS container.

  1. Go to the "current" server's Scripts tab.
  2. Run the appropriate operational script depending on the type of file.
    • For a backup file (.bak), run the 'DB SQLS Restore database from disk / S3 / Cloud Files' script.
    • For a database file (.mdf), run the 'DB SQLS Attach database from disk / S3 / Cloud Files' script.
  3. Provide values for the appropriate inputs depending on whether you're going to load the database from either a backup or database file.
  4. (Optional) Check the server to verify that the database was properly loaded. Click the server's RDP button to open up a Remote Desktop Connection to the instance. Navigate to Start > All Programs > Microsft SQL Server 2008 R2 > SQL Server Management Studio. (When asked to connect to the database, click Connect.) You should see the imported database listed under the "Databases" section.

screen-ShowDotNetNuke-v1.png

Create a Database Backup

The next step is to create your first backup of the database, which adds a set of tags (such as the lineage name) to the backup file. The tags are used by the ServerTemplate's scripts to properly locate and retrieve backups for initial setups and database restorations.

  1. Go to the "current" server's Scripts tab.
  2. Create a backup of the database.
    • If volumes are supported (e.g. AWS EC2), run the 'DB SQLS Backup Data and Log volumes' operational script. If you are using volumes, a snapshot of the data and log volumes will be created and properly tagged.
    • If volumes are not supported (e.g. Rackspace First Generation), run the 'DB SQLS Backup database to disk / S3 / Cloud Files' operational script. A backup file (.bak) will be saved to the specified ROS location (STORAGE_CONTAINER_NAME).

Update DNS Record

Assuming that application servers or clients in your environment will access your principal or stand-alone SQL Server using a fully qualified domain name (FQDN) rather than IP address, update the DNS record (that points to the standalone/principal database server) with your DNS provider. 

  1. Go to the "current" server's Scripts tab.
  2. Run the DNS Register IP operational script. Note: You should have set the required inputs for the script at the deployment level before you launched the server. 
  3. (Optional) Check the DNS record to make sure it was updated with the expected IP address. If you set the DNS_IP_ADDRESS input to 'Private IP' (default) the DNS record should match the instance's Private IP Address under the "current" server's Info tab because you typically want to IIS application servers to connect to the database over the private network.


screen-DNS_Update-v1.png

Set up a SQL Mirroring Configuration with a Principal and Mirror Server

Important!  If you only want a standalone SQL database server your configuration is complete. However, if you want to set up a mirrored SQL configuration that contains a dedicated principal and mirror database server for high-availability purposes, please follow the remaining steps.

Change Server from Standalone to Principal Mode

The first step is to change the existing database server from "standalone" to "principal" mode.

  1. Go to the "current" server's Scripts tab.
  2. Run the 'DB SQLS Init principal' operational script. All of the required inputs should have been previously defined at the deployment level. Note: You will not see a 'completed: DNS SQLS Init Principal' audit entry until there is a "mirror" server is connected to the principal.

Launch the Mirror Database Server

Next, launch a new server that will become a mirror of the principal server.

If you are setting up a synchronous mirrored SQL Server environment, you will need to launch another SQL database server that will act as a "mirror" of the "principal" server. Ignore this step if you are only setting up a stand-alone SQL Server environment.

  1. Clone the 'principal' database server.
  2. Rename the cloned server. (e.g. db2)  Note: Do not put "mirror" in the name because you do not want the server's name to cause confusion if you ever need to promote the mirror to become the new principal database server.
  3. (Recommended)  If possible, change the server's availability zone to promote high availability. Note: You can only use this option if you're using Remote Storage as the method for setting up a mirroring configuration. (INIT_MIRRORING_METHOD = text: Remote Storage) 
  4. Before you launch the server, make sure that first backup snapshot is 100% complete. The mirror server will use the backup file to restore the database before it starts synchronizing with the principal server.
  5. Launch the server. (You do not have to wait for the principal server to be operational before you launch the mirror server.)
  6. When you view the input confirmation page, change the database server's mode to 'Mirror' mode. 
DATABASE
Input Name
Description
Example Value
SERVER_MODE

Since you already have a 'Principal' server running, set this input to 'Mirror'.

text:  Mirror
  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. 
  3. Once the "mirror" server becomes operational, you will need to wait a few more minutes for the mirroring setup to become completed. Wait for all of the principal and mirror tags to be updated (as seen in the screenshot below) before proceeding to the next step. Machine tags are used to clearly identify the "Principal" and "Mirror" servers. Note: You can only have a single mirror server.

screen-PM_Servers-v1.png

  1. (Optional) Check the servers to verify that you have a synchronous mirrored SQL Server environment. For example, you can RDP into the principal server. Open "SQL Server Management Studio" and under the "Databases" section you now see that the database is the "principal" server in a synchronized setup.
    screen-SQL_Synchronized-v1.png

Create a SQL User

Note: If you are only setting up a standalone SQL database server, you can skip this step. 

If you are going to connect an IIS application server to the database, create a SQL user. Application servers will access the database using the created SQL user's username and password. If you want to use credentials to hide the actual username and password values, create appropriately named credentials prior to running the script below.

  1. Go to the Scripts tab of the Standalone/Principal SQL database server.
  2. Run the 'DB SQLS Create login' operational script.
Database
Input Name
Description
Example Value
DB_NAME

The name of the SQL database for which you are creating a user.

For the provided sample file use:

text:  DotNetNuke

DB_NEW_LOGIN_NAME

If an IIS application server will connect to this database server, you can create a SQL database user and password with database login privileges for the specified database. The IIS web application will use the created SQL user to access the database. 

After the server is operational, run the 'DB SQLS Create login' script to create the SQL database user. 

Note: You can also create a user with a script in the IIS application ServerTemplate. 

text:  dbuser

cred: SQL_SERVER_USER

DB_NEW_LOGIN_PASSWORD

Password of the SQL database user (DB_NEW_LOGIN_NAME). 

Note: Password must meet standard Windows 2008 server password complexity requirements. It should be at least 7 characters long with at least one upper case letter, one lower case letter, and one digit. 

text:  4MicroSoft!

cred: SQL_SERVER_PASSWORD

Optimize Tempdb System Database (Recommended)

Since the size, recovery model, and growth settings for the SQL Server tempdb system database can impact server performance, you should configure the database according to Microsoft's optimization recommendations, described in the Microsoft Developer Network (MSDN) article Optimizing tempdb Performance.

To configure these optimization settings automatically, run the DB SQLS Configure TempDB operational script, which will:

  • Change the tempdb database's recovery model to 'Simple'
  • Change the autogrowth settings for the database and log files to autogrow by 10% (unrestricted growth)
  • Create one tempdb data (.mdf) file per virtual core (CPU) on the server, based on Microsoft's configuration recommendations. Use the OPT_TEMPDB_DATAFILE_SIZE input to specify initial file sizes (in GB) for your data files, if needed. For the sample file, use a value of 1. (e.g. Text: 1)

NOTE: Make sure that this value multiplied by the number of instance cores does not exceed your value for LOGS_VOLUME_SIZE.


Application Tier Setup

Upload the Application

The ServerTemplate contains scripts that can retrieve application code from either an SVN or Git repository, or from an ROS container. If you do not have an application, you can upload the example below to an ROS container. If you used the 'DotNetNuke.bak' example to launch the Microsoft SQL database server, use the matching sample application below.


Upload the sample application to the ROS container you created above.

Import the ServerTemplate

  1. Go to the MultiCloud Marketplace (Design > MultiCloud Marketplace > ServerTemplates) and import the most recently published revision of the Microsoft IIS App Server Server ServerTemplate into your RightScale account.

Customize the ServerTemplate

By default, the application ServerTemplate is configured to connect to an HAProxy load balancer server launched with the Load Balancer with HAProxy ServerTemplate. The ServerTemplate contains scripts that will connect to the load balancers at boot time and disconnect from the load balancers at decommission time when the server is terminated. If you are going to connect to an HAProxy load balancer or launch a standalone application server, no customizations are required. Please proceed to the next step.

If you are going to connect the IIS application server to either an Amazon Elastic Load Balancer (ELB) or a Rackspace Cloud Load Balancer (CLB), you must customize the ServerTemplate's scripts accordingly. Follow the instructions below.

For ELB 

  1. Clone and rename the ServerTemplate.
  2. Go the Scripts tab of the cloned ServerTemplate.
  3. Replace the LB Register with HAProxy script in the Boot Script list with the AWS Register with ELB script.
  4. Replace the LB Deregister from HAProxy script in the Decommission Script list with the AWS Deregister from ELB script.


For CLB 

  1. Clone and rename the ServerTemplate.
  2. Go the Scripts tab of the cloned ServerTemplate.
  3. Replace the LB Register with HAProxy script in the Boot Script list with the LB Register with CLB script.
  4. Replace the LB Deregister from HAProxy script in the Decommission Script list with the LB Deregister from CLB script.

Create a Server or Server Array

When you create a server or server array, you will first need to select a deployment and the cloud where the server will eventually be launched into (e.g. AWS us-east). Based on the chosen cloud provider, you will need to complete the configuration process that's specific for that cloud. For example, some cloud providers support features that are unique to their specific cloud.

Go to the imported or cloned ServerTemplate's show page and click the Add Server or Add Array button.

  • To create a server, click the Add Server button and complete the steps in the wizard. See Add Server Assistant for details. If you are setting up a multi-tier deployment, it's strongly recommended that you create at least two application servers for redundancy 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.
  • To create a scalable server array, click the Add Array button and complete the steps in the wizard. See Add Server Array Assistant for details. 

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 will need to provide the necessary values as inputs based on which options you want to use.

Set Inputs at the Deployment Level

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

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

APPLICATION

The application code can be retrieved from several different location. You must specify the appropriate inputs depending on the option.

  • SVN Repository - Application files are retrieved from a specified repository. Username and password may be required for authentication purposes.
  • ROS Container (e.g. S3 bucket or Cloud Files container) - A zip file of the application code is retrieved from an ROS container. Cloud credentials may be required for authentication purposes.
  • URL - Specify a full url to where a zip file of the application code can be retrieved. The zip file must be publicly accessible.
     
Input Name Description Example Value
SVN_APP_PATH

The full URL to access the application code in your SVN repository. Supports SVN, HTTP, and HTTPS protocols. When specifying this input, set the ZIP_URL input to "ignore." Ex: http://myserver.com/path/repo

text:  http://myserver.com/path/repo

SVN_PASSWORD Login password for the SVN repository, if required. Leave set to "ignore" if using a public repository that does not require login credentials.

 

cred:  SVN_PASSWORD
SVN_USERNAME

Login user name for the SVN repository, if required. Leave set to "ignore" if using a public repository that does not require login credentials.

cred:  SVN_USERNAME
ZIP_FILE_NAME The filename of the application zip file (*.zip) that is stored in an ROS container specified by the STORAGE_CONTAINER_NAME input.

For the provided sample file use:

text:  DotNetNuke.zip

ZIP_URL

Full URL to a zip file (*.zip) containing application code. Supports HTTP and HTTPS protocols. Ex: http://myserver.com/path/archive.zip

text:  http://myserver.com/app.zip

Cloud

In order to create volumes or retrieve objects such as a database or backup file from an ROS container, you must provide the required cloud credentials for authentication purposes.

Input Name Description Example Value

AWS_ACCESS_KEY_ID

AWS_SECRET_ACCESS_KEY

Specify valid cloud credentials to retrieve a private application (*.zip) file from an Amazon S3 bucket.

cred:  AWS_ACCESS_KEY_ID

cred:  AWS_SECRET_ACCESS_KEY

RACKSPACE_AUTH_KEY

RACKSPACE_USERNAME

Specify valid cloud credentials to retrieve the application (*.zip) file from a Rackspace Cloud Files container.

cred:  RACKSPACE_AUTH_KEY

cred:  RACKSPACE_USERNAME

RACKSPACE_REGION

The location of the Cloud Load Balancer (CLB) that the IIS application server will connect to for load balancing purposes. If you are not using a CLB, set this input to 'ignore'.

  • us - Rackspace US
  • uk - Rackspace UK
text: us
STORAGE_CONTAINER_NAME

Specify the name of the remote object storage (ROS) container where the application (*.zip) file will be retrieved from such as the name of the Amazon S3 bucket or Cloud Files container. It's also used to store IIS log files (older than 1 day).

text:  my-container
STORAGE_TYPE

Select the type of remote object storage (ROS) location where the file will be retrieved.

  • S3 - Amazon S3 Bucket
  • Cloud Files - Rackspace Cloud Files Container
text:  S3

Database

Important!
If you are configuring a mirrored setup (consisting of a Principal and Mirror server) and you want to launch the Mirror server in a different availability zone as the Principal server, you must use the 'Remote Storage' option for the INIT_MIRRORING_METHOD input.

Input Name Description Example Value
DB_NAME

The name of the target Microsoft SQL database that the IIS application will connect to. (e.g. My Database Name)

For the provided sample file use:

text:  DotNetNuke

OPT_CONNECTION_STRING_DB_NAME Name of the target SQL Server Database.

For the provided sample file use:

text:  DotNetNuke

OPT_CONNECTION_STRING_DB_SERVER_NAME

Fully qualified domain name or IP address of the (standalone or principal) Microsoft SQL database server that contains the target database (OPT_CONNECTION_STRING_DB_NAME). The application server will make a connection request to the database server using this value. It's recommended to establish connections using the server's private IP.

If it uses a TCP communications port other than TCP 1433 (default), specify the specific port number after the server name, separated by a colon. (e.g. my-db1.example.com:56)

text:  my-db1.example.com

text:  180.12.34.567

OPT_CONNECTION_STRING_DB_USER_ID

The IIS application will connect to the database by logging in with a SQL user that has database privileges. Specify the username of this SQL Server user. 

Important!  If you previously created the SQL Server user on the database user using the 'DB SQLS Create login' operational script, use the same value that you used for the DB_NEW_LOGIN_NAME input. 

cred:  SQL_SERVER_USER
OPT_CONNECTION_STRING_DB_USER_PASSWORD

The password of the SQL Server user that the application will use to log into SQL database.

Important!  If you previously created the SQL Server user on the database user using the 'DB SQLS Create login' operational script, use the same value that you used for the DB_NEW_LOGIN_PASSWORD input. 

cred:  SQL_SERVER_PASSWORD
OPT_CONNECTION_STRING_NAME

The name of the connection string that the IIS application will use to connect to the database specified by the OPT_CONNECTION_STRING_DB_NAME input. 

For the provided sample file use:

text:  SiteSqlServer

LOAD BALANCER

If you are launching a standalone application server that will not connect to any load balancing tier, ignore the inputs below.

Input Name Description Example Value

ELB_NAME

(For ELB only)

The name of the Amazon Elastic Load Balancer (ELB) that the IIS application server will connect to for load balancing purposes.

Important! You must launch the IIS application server into the same EC2 region as the ELB.

If you are not using an ELB, set this input to 'ignore'. 

text:  my-elb
LB_PORT

The port that the load balancers will use to connect to the IIS application servers. By default, the IIS application server listens on TCP port 80.

text: 80

LB_VHOST_NAME

(For HAProxy only)

The name of the virtual host that the application server will connect to. If you are connecting to an load balancer launched with RightScale's 'Load Balancer with HAProxy' ServerTemplate, this value should match the 'Virtual Host Names' input for the load balancer servers. You can specify an application listener name (e.g. default) or hostname of the load balancer servers (e.g. my-www.example.com)

Machine tags are used to establish a connection between an application server and the HAProxy load balancer servers. For example, if you are using the 'default' vhost name, the tag on the application server would be 'loadbalancer:default=app'.

If you are not using HAProxy for load balancing, set this input to 'ignore'.  

text:  default

RACKSPACE_CLB_NAME

(For CLB only)

The name of the Rackspace Cloud Load Balancer (CLB) that the IIS application server will connect to for load balancing purposes. If you are not using a CLB, set this input to 'ignore'. 

text:  my-clb

RACKSPACE_CLB_REGION

(For CLB only)

The location of the Rackspace Cloud Load Balancer (CLB). If you are not using a CLB, set this input to 'ignore'.

Important! You must launch the IIS application server into the same datacenter as the CLB.

  • lon - London (UK)
  • ord - Chicago (US)
  • dfw - Dallas / Fort Worth (US)

text:  ord

Launch the Application Server

After configuring your inputs, launch the application server. 

  1. Go to the deployment's Servers tab and launch the server.
  2. 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), 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. Because there are no required inputs that are missing values for any boot scripts, you can click the Launch button at the bottom of the input confirmation page. 
  3. (Optional) Clone the current application server to launch another application server. As a best practice, you should launch application servers into different availability zones for high-availability purposes. Repeat the process to launch additional application servers or configure a server array for autoscaling purposes.

Load Balancer Tier Setup

Create a Load Balancer 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 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.

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.

LB

Input Name
Description
Example Value
Virtual Host Names

Comma-separated list of host names for which the load balancer will answer website requests and forward to the correct backend pool of application servers. This value is used to name backend server pools. A single entry of any name, e.g. 'default' or 'applistener', will mimic basic behavior of one load balancer with one pool of application servers. 

If you are using multiple virtual host names, the first entry will be the default backend and will answer for all host names that are not listed. Typically, you will specify hostnames for each load balancing pool. (e.g. app1.example.com,app2.example.com)

Note: Application servers can only provide a single host name and will join server pool backends using this name (for example, default, www.mysite.com, api.mysite.com, default.mysite.com).

Single vhost:
text:  default

Multiple vhosts:
text: app1.example.com,app2.example.com

Health Check URI

Relative URI (resource path), including the preceding forward slash, pointing to the health-check page on your application servers. For example, /hlthchk378923.html points to the file hlthchk378923.html in the application directory on your application servers. During the testing phase, you may leave this input set to the default (/) value, indicating that health check pages are not included on the application servers.

For the DotNetNuke 3 tier example, use 'text:/Default.aspx

text:  /

Use Session Stickiness Leave this value set to "true" to enable session persistence (stickiness). In this case, the load balancer will route client requests made in the same session to the same application server, via a cookie. Set to "false" to disable session stickiness, in which case the load balancer routes each new client request to the next available application server, regardless of session.

text:  true

For the 3-tier tutorial, use:
text:  false

Status Page Password

Status Page Username

Username and password (if required) to access the HAProxy status report page, which is accessible from the URI set in Status URI.

cred:  LB_STATUS_PASSWORD

cred:  LB_STATUS_USERNAME

Status URI

Relative URI (resource path) pointing to the HAProxy status report page. If you use the default value (/haproxy-status) you can append this value to the hostname or public DNS/IP address for your load balancer to access the status report—for example, http://example.com/haproxy-status or http://192.123.123.12/haproxy-status.

text:  /haproxy-status

WEB_APACHE

Input Name
Description
Example Value
Application Name On your application servers, the server subdirectory where your application code files are stored. This must match the Application Name input for your application servers. text:  myapp
Multi-Processing Module Set to the value matching the application servers that your load balancer will connect to: "prefork" for PHP servers, or "worker" for Rails, Apache Tomcat, and stand-alone application servers. text:  prefork
SSL Certificate Contents of the X.509/PEM-format SSL server certificate used for enabling HTTPS communications.

cred:  SSL_CERTIFICATE

SSL Certificate Chain The certificate authority (CA) certificate chain associated with the server certificate used to set up HTTPS communications.

cred:  SSL_CERTIFICATE_CHAIN

SSL Enable Set to "true" to enable SSL ('https').
Set to "false" to disable SSL. (default)
text:  false
SSL Certificate Key The SSL server certificate's private key, in PEM format.

cred:  SSL_CERTIFICATE_KEY

SSL Passphrase If required by an SSL certificate, you must provide the passphrase so Apache can start.

cred:  SSL_PASSPHRASE

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.


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 one of the load balancer servers. HAProxy will then take the request and forward it to one of the application servers in its load balancing pool.

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 provided sample application, you should see the following landing page.

screen-DotNetNuk_Home-v1.png

 

Check HAProxy Status

The easiest way to check the status of the HAProxy load balancing pool is to view the HAProxy Status page. By default, the Status URI input is set to /haproxy-status

If you created DNS A Records for the load balancer servers, you can visit the HAProxy Status page by entering your <FQDN>/haproxy-status in a web browser window. (e.g. josh-www.rightscaleblue.com/haproxy-status)  

If DNS A Records are not used, you can also use the public DNS name or IP of a load balancer server. (e.g. http://192.34.456.77/haproxy-status

 

screen-3tier_haproxy_status-v1.png

Each application server that's successfully added to the load balancing pool will be highlighted in green. In the example screenshot above, two application servers are in the load balancing pool and are able to receive requests from the load balancer servers. Notice that each application server is identified by its universally unique identifier (UUID) that RightScale assigns to each instance. You can find the server's UUID in its machine tags or under its Info tab.

 

Application servers highlighted in red are not included in the load balancing pool and will not receive any client requests. There are several reasons why an application server may be highlighted in red.

  • The application server's firewall permissions are not allowing ingress communication from the load balancers. Check the firewall permissions of the application server (as defined by its security group, if applicable, and/or iptables rules).
  • The application server is not operational. Perhaps the application server is in the booting or decommissioning state.
  • The health check failed. 

Deployment's Servers Tab

Once all of the servers are launched and operational, it's useful to go to the deployment's Servers tab to check the 'cpu-overview' thumbnail graph of each server, as well as view all related server tags. (Click to enlarge)

 

screen-MS_SQL_3tier_Servers-v1.png


Shutting Down

You may find the need to perform some clean up, either to minimize costs, or to perform the tutorial again from a clean slate. Follow these high level steps to do so:

  • Terminate the Load Balancer servers.
  • Terminate the Application servers.
  • Terminate the Database servers. (If you are using volumes, see the Windows Microsoft SQL Runbook for proper instructions.)
  • Delete the Deployment.
  • Delete the two EIPs (if applicable and they no longer need to be preserved)
  • Delete the SSH Key (if applicable)
  • Delete the Security Group(s) (if applicable)
  • Delete all Credentials (unless you are sharing your account or Deployment with others who might still be using them).
  • Delete all four DNS A records (if applicable)
  • Delete the application and database dump files from the ROS containers
  • Delete the ROS containers (e.g. S3 bucket)

You must to post a comment.
Last modified
16:11, 11 Nov 2013

Tags

Classifications

This page has no classifications.

Announcements

None


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