4 Tier Deployment Setup (HAProxy-IIS-SQL-Witness)

Objective

To create a 4-tiered production-like deployment from scratch using ServerTemplates published by RightScale for an IIS application and a Microsoft SQL database along with a SQL Witness server for automatic failover from a principal to a mirror.

Table of Contents

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

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 4-tier website architecture in the cloud using some of RightScale's ServerTemplates. 

• (HAProxy) Load Balancing servers
• Microsoft IIS Application servers
• Microsoft SQL Database servers (Mirrored Setup)
• Microsoft SQL Server Witness (Uses a v13 Infinity ServerTemplate, because an LTS version is currently unavailable.)

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

SSH Key

If the cloud does not require the use of 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.

• Amazon Web Services - EC2
• OpenStack (Juno)
• 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 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. 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 for the database servers because it's the lowest allowable TTL. Be sure to change the 'DNS_TTL' 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.)
• 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.

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

Common Credentials for a 3-Tier Windows 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.

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. If you do not want to use the 'Administrator' user (default), you can also create a new user with administrative privileges by using the ADMIN_ACCOUNT_NAME input. At a minimum, it's strongly recommended for security reasons that you create a credential for the ADMIN_PASSWORD input in order to use your own password instead of the randomly generated one, which will keep the password private. Only a user with 'admin' privileges or the user who created the credential will be able to view the actual value stored in the credential. Once a server is launched you will use the username and password to start a Remote Desktop Protocol (RDP) connection to the instance.

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

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.
• MASTER_KEY_PASSWORD - The password to encrypt the master key when it's created or decrypt it when opening an existing master key.

DNS

Note: You should have already created the appropriate credentials for your DNS provider in an earlier step.

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

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)

Software Repositories

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.

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

• 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 Windows Azure Blob Container
• Upload Files to a SoftLayer Object Storage Container

If you are setting up a database server for testing purposes, you may use the following sample SQL backup file to complete the tutorial.

• DotNetNuke.bak

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 following ServerTemplate into the RightScale account.
   • Database Manager for Microsoft SQL Server (v13.5.x LTS)
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, then click Continue.
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 the cloud does not support the use of volumes and snapshots for database backups, you must select an instance type with disk space that's at least twice as large as your database because data is stored locally on the instance before it is zipped and saved to the specified ROS location. Also, although these ServerTemplates may work with a variety of instance sizes, 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).

CLOUD

AWS EC2 only
If you are launching your servers in AWS EC2 and using EBS volumes for local data storage, you must provide your AWS credentials for authentication purposes. If you are not using AWS services, set these inputs to 'ignore'.

DATABASE

DNS

REMOTE STORAGE

SYSTEM

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 become a Principal.

DATABASE

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. 
5. (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.  

6. Once the server becomes operational, the DNS Register IP script is automatically executed. 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 the IIS application servers to connect to the database over the private network.
7. If you are using the default setting, the server's private IP address will be used. Check the server's audit entry and/or the DNS record with your DNS provider to view the results.
   

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 (e.g., Amazon S3 bucket).

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 local disk / Remote Storage' script. (Use this script for the provided sample file.)
   • For a database file (.mdf), run the 'DB SQLS Attach database from local disk / Remote Storage' 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 insdstance. Navigate to Start and in "Search programs and files" enter "SQL Server Management Studio" and open the program. When asked to connect to the database, click Connect. You should see the imported database listed under the "Databases" section.

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 snapshots/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. 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 you are not using volumes, a backup file (.bak) will be saved to the specified ROS location (REMOTE_STORAGE_CONTAINER).

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, you will want to create an application specific 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

Set up a SQL Mirroring Configuration

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.

Generate SQL Certificates

1. Go to Design > Credentials > New and create credentials for the private key passwords that will be paired with the certificates you are about to create. Although you can use the same password for each certificate, it's more secure if each certificate has its own unique password.
   • SQL_PRINCIPAL_PRIVATE_KEY_PASSWORD
   • SQL_MIRROR_PRIVATE_KEY_PASSWORD
   • SQL_WITNESS_PRIVATE_KEY_PASSWORD  (Required if you are going to launch a SQL Witness server.) 
2. Go to the "current" server's Scripts tab.
3. Run the 'DB SQLS Generate and Save a Certificate' script two times because you want to generate unique certificates for both the principal and mirror servers. You can technically use one certificate for both servers, but that will be less secure. Select the appropriate password credential (that you just created) for the PRIVATE_KEY_PASSWORD input each time you run the script. First, create a certificate for the principal database server using the principal credential (SQL_PRINCIPAL_PRIVATE_KEY_PASSWORD), then run the script again to create a certificate for the mirror using the other credential (SQL_MIRROR_PRIVATE_KEY_PASSWORD). You will need to run the script a third time if you are going to launch a SQL Witness server.
    

4. Go to your deployments Servers tab and RDP into the server.
5. Go to Start > Computer > Local Disk (C:) and open up credential.txt, which should be the credential for the principal server. The second text file (credential1.txt) was created the second time you ran the script, which should be for the mirror server.
   Note: Each time you run the script, it creates a newly-incremented credential. For example, if you ran the script a third time, there would be a credential2.txt file. 
    

6. Copy the two lines of text from the "credential" file.
7. Go to the RightScale Dashboard and paste in the two lines into a new credential (Design > Credential > New) and name it appropriately. (e.g., SQL_PRINCIPAL_CERTIFICATE)

8. Click Save.
9. If you are going to launch a mirror server, repeat the same steps to create a credential for the mirror certificate. (e.g. SQL_MIRROR_CERTIFICATE). Use the contents of the credential1.txt file to create the credential.
10. If you are going to launch a witness server, repeat the same steps to create a credential for the witness certificate. (e.g. SQL_WITNESS_CERTIFICATE). Use the contents of the credential2.txt file to create the credential.

Modify Deployment Inputs

Note: Because your principal server is already operational, the inputs you modify at the deployment level will not affect the currently running principal server. The purpose of modifying these inputs is so your mirror will be able to interpret these inputs.

Note: If you want to create a witness server to monitor whether or not your principal and mirror servers stay connected, see the Database Manager for Microsoft SQL Server Witness - Beta ST - Tutorial.

Go to your deployment > Inputs. Click Edit and modify the following inputs:

DATABASE

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. Since this server is already operational, the deployment level inputs defined above will not affect this server.

Note: You will need to re-enter the information for the MIRROR_CERTIFICATE, MIRROR_PRIVATE_KEY_PASSWORD, PRINCIPAL_CERTIFICATE, and PRINCIPAL_PRIVATE_KEY_PASSWORD (see Modify Deployment Inputs) because the Deployment Level inputs that were modified in the previous step do not have an influence on operational servers.

Note: You will not see a 'completed: DNS SQLS Init Principal' audit entry on the principal server until there is a "mirror" server connected to it.

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 new server's availability zone by clicking the server's Edit button to promote high availability.
4. Before you launch the server, make sure that the 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.
6. When you view the input confirmation page, change the database server's mode to 'Mirror' mode. 

DATABASE

7. 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.
8. Click the Launch (not Save and Launch) button at the bottom of the input confirmation page because you might not want this server to be launched in "mirror" mode the next time it is launched or relaunched.
9. 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.

10. (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.
    

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 principal 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 DotNetNuke 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.

SQL Witness Tier Setup

Create a Witness Server

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 Witness - Beta v14 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 where your principal and mirror server exists, then click Continue.
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., Witness1). 
   • 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.
6. Click Confirm, review the server's configuration and click Finish to create the server.

Create a Witness Certificate Credential

You will need to create a certificate for the witness server.  

1. Go to Design > Credentials > New and create a new credential for the private key password that will be paired with the SQL certificate for the witness server.
   • SQL_WITNESS_PRIVATE_KEY_PASSWORD
2. Go to the Scripts tab of the SQL database server where you generated the certificates for the principal and mirror database servers. 
3. Run the 'DB SQLS Generate and Save a Certificate' operational script to create a unique certificate for the witness server. Be sure to select the credential (that you just created e.g., SQL_WITNESS_PRIVATE_KEY_PASSWORD) for the PRIVATE_KEY_PASSWORD input.
    

4. RDP into the database server where you ran the script to create the certificate.
5. Go to Start > Computer > Local Disk (C:) and open up the last (highest numbered) credential text file. If you created the principal and mirror certificates on this server, 'credential2.txt' will contain the mirror certificate. 

5. Open the file and copy all of its contents.
6. Go to the RightScale Dashboard and paste in the two lines into a new credential (Design > Credential > New) and name it appropriately. (e.g., SQL_WITNESS_CERTIFICATE) 

7. Click Save.

Modify Deployment Inputs

Go to your Deployment's Inputs tab. Click Edit and modify the following inputs:

DATABASE

Launch the Witness Server

Next, launch the new server that will become a witness for the mirror and principal server.

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.

Add the Witness Server to the Mirroring Session

Once the server becomes operational, you will need to add the witness to the mirroring session by running the 'DB SQLS Init Witness' operational script on each individual server (principal, mirror, and witness).

If the witness server is going to communicate with the principal and mirror database servers over the public network (USE_PUBLIC_IP_WITNESS = True), you must update the firewall permissions on the running principal and mirror database servers to allow ingress requests from the witness server. If the cloud uses security groups (e.g. AWS), you will need to update one of the security groups associated with the principal and mirror database servers appropriately. If the cloud does not use security groups (e.g., Rackspace or Azure) the port will be opened to the IP of the witness server by the 'DB SQLS Init witness' script, when it's executed on the principal and mirror servers. (See steps below.)

1. Verify that the same value for the USE_PUBLIC_IP_WITNESS input is used for all servers. (principal, mirror, and witness) You may need to update the input under the "current" server's Inputs tab on the principal and mirror database servers. The default value for this input is 'False' which means that the servers can communicate with each other over the private network. The input will be applied when you run the operational script in the following step.
2. First run the 'DB SQLS Init witness' operational script on the witness server. 
3. Next, run the same script on the principal and mirror servers. Most likely you created your mirror certificate after you launched the principal and mirror servers. Therefore, when you run the operational script, you may be prompted to select the appropriate credentials for the certificate and private key inputs related to the mirror and witness servers. When you run the script on the principal server you may also have to select the appropriate password and credential for the inputs specific to the mirror server because it was launched before those credentials existed.

4. Once all scripts are completed across all three servers go to the deployment's Servers tab. Each server should now have the appropriate "witness" tags (highlighted below). 

Load Balancer Tier Setup

Important!

If you are going to use RightScale's 'Load Balancer with HAProxy' ServerTemplate for load balancing purposes (and not a cloud load balancing service like Amazon ELB or Rackspace CLB), you must launch the load balancer servers BEFORE launching any IIS application servers.

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 (v13.5.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 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

LB_HAPROXY

WEB_APACHE

If you are not setting up SSL, leave the SSL related inputs set to 'No value/Ignore' (default).

Launch the Servers

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

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

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

• DotNetNuke.zip

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 (v13.5.x LTS) 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.

Add a Server

When you create a server, 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.

1. Go to the imported or cloned ServerTemplate's show page.
2. 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 high availability purposes.
   • The easiest way to create the second server is to clone the first one. Be sure to change the name of the server accordingly (e.g. app2) and its availability zone (if available) under the Info tab.

Configure Inputs

The next step is to define the properties of your IIS 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.
   

CLOUD

(For ELB or CLB only)

If the application server is going to connect to one of the supported cloud load balancing services such as Amazon Elastic Load Balancers (ELB) or Rackspace Cloud Load Balancers (CLB), you must specify the following cloud credentials so that the application servers has the necessary credentials (for authentication purposes) to interact with the cloud services.

DATABASE

LOAD BALANCER

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

REMOTE STORAGE

The SYS Configure IIS logs rotation policy boot script configures a scheduled task (that runs once per day) on the server, which creates a .zip of IIS application server logs (older than one day) and uploads it to a container in a supported ROS service (e.g., Amazon S3, Windows Azure Storage). If you do not want to upload IIS logs to an ROS container, leave the following inputs set to 'no value' (default).

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.

Test the Deployment

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

Next Steps