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

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

Table of Contents
  1. Objective
  2. Prerequisites
  3. Overview
  4. Deployment Setup
    1. Create a Deployment
    2. Create Cloud-specific Resources
      1. SSH Key
      2. Security Groups
      3. Remappable Public IP Addresses
    3. Create DNS Records
    4. Create Credentials
      1. Common Credentials for a 3-Tier Windows Architecture
      2. Remote Object Storage (ROS)
      3. Software Repositories
        1. Source Control Management (SVN, GitHub)
      4. Secure Sockets Layer (SSL)
        1. Load Balancer
  5. Database Tier Setup
    1. Upload the Database Dump File
    2. Create a Database Server
    3. Configure Inputs
      1. Set Inputs at the Deployment Level
      2. BACKUP
      3. CLOUD
      4. DATABASE
      5. DNS
      6. REMOTE STORAGE
      7. SYSTEM
    4. Launch a Standalone Database Server
      1. DATABASE
    5. Load the Database
    6. Create a Database Backup
    7. Create a SQL User
      1. DATABASE
    8. Set up a SQL Mirroring Configuration
      1. Generate SQL Certificates
      2. Modify Deployment Inputs
        1. DATABASE
      3. Change Server from Standalone to Principal Mode
      4. Launch the Mirror Database Server
        1. DATABASE
    9. Optimize Tempdb System Database (Recommended)
  6. SQL Witness Tier Setup
    1. Create a Witness Server
    2. Create a Witness Certificate Credential
    3. Modify Deployment Inputs
      1. DATABASE
    4. Launch the Witness Server
    5. Add the Witness Server to the Mirroring Session
  7. Load Balancer Tier Setup
    1. Add a Server
    2. Create another Load Balancer Server
    3. Configure Inputs
      1. LB
      2. LB_HAPROXY
      3. WEB_APACHE
    4. Launch the Servers
    5. Configure DNS Records
  8. Application Tier Setup
    1. Upload the Application
    2. Import the ServerTemplate
    3. Customize the ServerTemplate
    4. Add a Server
    5. Configure Inputs
      1. Set Inputs at the Deployment Level
      2. APPLICATION
      3. CLOUD
      4. DATABASE
      5. LOAD BALANCER
      6. REMOTE STORAGE
    6. Launch the Application Server
  9. Test the Deployment
    1. Check the Landing Page
    2. Check HAProxy Status
    3. Deployment's Servers Tab
  10. Next Steps
    1. Add a Microsoft SQL Mirror for Automatic Database Failover
    2. Shutting Down

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

diag-System_Architecture-19.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

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.

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.

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.

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.

diag-3tier_ga_Win-v1.png

 

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.

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.

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.


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 following ServerTemplate into the RightScale account.
  2. From the imported ServerTemplate's show page, click the Add Server button.
  3. Select the cloud for which you will configure a server. 
  4. Select the deployment for the new server, 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).

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. If the cloud supports volumes and snapshots, you should use 'Snapshots' for this option.

  • Snapshots - Volume snapshots such as Amazon's Elastic Block Store (EBS), Microsoft Azure Volume Snapshots, etc.
  • Remote Storage - Remote Object Store (ROS) location such as an Amazon S3 bucket, Azure Blob Storage container, Rackspace Cloud Files container, etc.
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. 

Inputs are ignored if you are using 'Remote Storage' for BACKUP_METHOD.

See Archiving of EBS Snapshots for more details.

 
MDF_FILE_NAME

The name of the database file that you previously uploaded to the 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

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

Input Name Description Example Value

AWS_ACCESS_KEY_ID

AWS_SECRET_ACCESS_KEY

Specify valid AWS cloud credentials.

cred:  AWS_ACCESS_KEY_ID

cred:  AWS_SECRET_ACCESS_KEY

DATABASE

Input Name Description Example Value
DATA_VOLUME_SIZE

The size of each volume that will be used to 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 read/write performance.

Warning! If 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.

For the provided sample file use:
text:  10

 

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

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 define 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. It's recommended that you launch your principal and mirror servers in different availability zones for high availability and disaster recovery reasons. You can either use a snapshot or an ROS container depending on the cloud volume support. 

  • Snapshots (default) - A snapshot is used to transport the database backup file between the principal and mirror servers. The snapshot is used to create a volume in the same availability zone as the mirror server. Once the created volume (from the snapshot) has delivered the database file, it's unmounted, detached, and deleted.
  • Remote Storage - An ROS container is used to store and transfer the database backup file between the principal and mirror servers. You must use this option if the cloud in which the SQL servers are running does not support volumes and snapshots.
text:  Snapshots
MASTER_KEY_PASSWORD

This password is used for the encryption of the master database key, which is used to protect other certificate keys in the database. This input allows you to set a master key password so that you are later able to decrypt and use the master key, if necessary.

Note: It's strongly recommended that you use a credential to hide the actual key value from non-admin users while still allowing them to pass the appropriate value as an input.

cred: MY_MASTER_KEY_PASSWORD
LOGS_VOLUME_SIZE

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

To Configure 'tempdb' this should be 1GB or greater than your instance core count.

For the provided sample file use:
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 volume stripe, keep the default setting which uses a single volume with no striping. (Default: 1)

Warning! You 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 (DynDNS, Rackspace Cloud DNS, and Amazon Route 53) instead of a string ID, use this input to specify the fully qualified domain name that points to the standalone or principal database server. 

  • Example:  my-principal.example.com  (FQDN)

For other DNS services, you can leave this field blank/unset.

text:  my-principal.example.com
DNS_ID

Use this input to provide the appropriate identification number of the standalone or principal database server's DNS record. See below for details.

Examples:

  • DNS Made Easy - Dynamic DNS ID
    (e.g. 1234567)
  • DynDNS: n/a; ignore
  • Rackspace Cloud DNS: ID of the Rackspace DNS zone of the DNS record to be updated  (e.g. a9300699)
  • Amazon Route 53 - Hosted Zone ID
    (e.g. Z3DSDFSDFX)
text: 1234567
DNS_PASSWORD

The account or record level password used to log into your DNS provider. For security reasons you may want to create and use a credential to pass this value to the script.

  • DNS Made Easy - User Password
  • DynDNS - User Password
  • Rackspace Cloud DNS - User Password
  • Amazon Route 53 - AWS Secret Access Key
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. For security reasons you may want to create and use a credential to pass this value to the script.

  • DNS Made Easy - Username
  • DynDNS - Username
  • Rackspace CloudDNS - Username
  • Amazon Route 53 - AWS Access Key ID

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 (default)
text:  False
USE_PUBLIC_IP_WITNESS

If you are going to launch a MSSQL Witness server, use this input to specify whether or not the witness will use the public network to connect to the principal and mirror database servers on TCP port 5022. If you launch the witness server in a cloud/region where it cannot communicate with the principal and mirror database servers over the private network, you must set this input to 'True' and set appropriate firewall permissions on both the pricipal and mirror servers to allow ingress communication from the witness server.

  • True (default) - Use the public network for the witness connection
  • False - Use private network for the witness connection

Note: Later when you launch the witness server, make sure the same value is used for this input.

text: False

REMOTE STORAGE

Input Name Description Example Value
REMOTE_STORAGE_ACCOUNT_ID

The Account ID or Name of the Remote Storage account which is used to authenticate your requests to Remote Storage services. It's strongly recommended that you use a credential to hide the actual key value from non-admin users while still allowing them to pass the appropriate value as an input.

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

The remote object storage provider where your database file is stored, select appropriate provider from the dropdown list.

  • Amazon_S3 - Amazon S3
  • Rackspace_Cloud_Files_US - Rackspace Cloud Files (United States)
  • Rackspace_Cloud_Files_UK - Rackspace Cloud Files (United Kingdom)
  • Windows_Azure_Storage - Microsoft Azure Blob Storage
  • SoftLayer_Object_Storage_Dallas - SoftLayer's Dallas (USA) cloud
  • SoftLayer_Object_Storage_Singapore - SoftLayer's Singapore cloud
  • SoftLayer_Object_Storage_Amsterdam - SoftLayer's Amsterdam cloud
  • Openstack_Swift - Openstack Swift Object Storage
text: Amazon_S3
REMOTE_STORAGE_ACCOUNT_SECRET

The Secret Key or Password of the Remote Storage account which is used to authenticate your requests to Remote Storage services. It's strongly recommended that you use a credential to hide the actual key value from non-admin users while still allowing them to pass the appropriate value as an input.

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

If retrieving from a Remote Storage container, specify its name here. If retrieving from an ROS container from another cloud account, the specified file must be publicly accessible (e.g. set to "public-read" at a minimum).

Warning! If BACKUP_METHOD is set to 'Remote Storage' and the ROS container used for backups differs from the one where your database file is stored, ensure that you change this value back to your backup container, if needed, after running this script.
text:  my-bucket

SYSTEM

Input Name Description Example Value
ADMIN_PASSWORD

Set the new password for the local Administrator account.

NoteThe password must meet the Microsoft SQL Server Strong Password requirements, 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 must satisfy the following requirements:

  • Does not contain all or part of the user's account name. 
  • Is more than eight characters in length.
  • Contains characters from at least three of the following categories:
    • English uppercase characters (A through Z)
    • English lowercase characters (a through z)
    • Base 10 digits (0 through 9)
    • Nonalphabetic characters (for example: !, $, #, %)
  • For more information, please see Microsoft SQL Server Strong Password Guidelines.

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

Note: 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 "UTC"

text: UTC

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

Input Name Description Example Value
SERVER_MODE
Select the database 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

  1. 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.
  2. 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.
    screen-DNS_Update-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 (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.

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

User created with database privileges. 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 used by 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/2012 server password complexity requirements. It should be at least 7 characters long with at least one uppercase letter, one lowercase letter, and one digit. 

text:  4MicroSoft!

cred: SQL_SERVER_PASSWORD

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.
     
Input Name Description Example Value
PRIVATE_KEY_PASSWORD

This is the password used to encrypt the certificate's private key.

Although you can input this value as text, it's recommended that you create a credential for each certificate password. Although you can use the same password for each certificate, it's more secure if each certificate has its own unique password.

NoteThe password must meet the Microsoft SQL Server Strong Password requirements:

  • Does not contain all or part of the user's account name. 
  • Is more than eight characters in length.
  • Contains characters from at least three of the following categories:
    • English uppercase characters (A through Z)
    • English lowercase characters (a through z)
    • Base 10 digits (0 through 9)
    • Non-alphabetic characters (for example: !, $, #, %)
  • For more information, please see Microsoft SQL Server Strong Password Guidelines

For the Principal Certificate

cred: SQL_PRINCIPAL_PRIVATE_KEY_PASSWORD

 

For the Mirror Certificate

cred: SQL_MIRROR_PRIVATE_KEY_PASSWORD

 

For the Witness Certificate

cred: SQL_WITNESS_PRIVATE_KEY_PASSWORD

MASTER_KEY_PASSWORD

This password is used for the encryption of the master database key, which is used to protect other certificate keys in the database. This input allows you to set a master key password so that you are later able to decrypt and use the master key, if necessary.

Note: It's strongly recommended that you use a credential to hide the actual key value from non-admin users while still allowing them to pass the appropriate value as an input.

cred: MY_MASTER_KEY_PASSWORD

 

  1. Go to your deployments Servers tab and RDP into the server.
  2. 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. 
     

screen_RDS-princCert.png

  1. Copy the two lines of text from the "credential" file.
  2. 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)

screen-SQL_Principal_Certificate-v1.png

  1. Click Save.
  2. 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.
  3. 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 > InputsClick Edit and modify the following inputs:

DATABASE
Input Name Description Example Value

PRINCIPAL_CERTIFICATE

(Required for Principle)

This is the certificate to be used for authentication on the mirroring endpoint of the principal server. This input is required for a principal server.

Cred: SQL_PRINCIPAL_CERTIFICATE

PRINCIPAL_PRIVATE_KEY_PASSWORD

(Required for Principle)

Password to decrypt private key contained in PRINCIPAL_CERTIFICATE input. This input is required for a principal server. This should be the same password which was used to generate and encode certificate and private key by the 'DB SQLS Generate and Save a Certificate' RightScript.

Cred: SQL_PRINCIPAL_PRIVATE_KEY_PASSWORD

MIRROR_CERTIFICATE

(Required for Mirror)

This is the certificate to be used for authentication on the mirroring endpoint of the mirror server. This input is required for a mirror server. 

Cred: SQL_MIRROR_CERTIFICATE

MIRROR_PRIVATE_KEY_PASSWORD

(Required for Mirror)
Password to decrypt private key contained in MIRROR_CERTIFICATE input. This input is required if you are going to launch a mirror server. when launching mirror server but not needed for a Standalone SQL Server. This should be the same password which was used to generate and encode certificate and private key by the 'DB SQLS Generate and Save a Certificate' RightScript. Cred: SQL_MIRROR_PRIVATE_KEY_PASSWORD

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
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 because you might not want this server to be launched in "mirror" mode the next time it is launched or relaunched.
  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_Tags-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

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.
  1. From the imported ServerTemplate's show page, click the Add Server button.
  2. Select the cloud for which you will configure a server. 
  3. Select the deployment where your principal and mirror server exists, then click Continue.
  4. 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.
  5. 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.
     
Input Name Description Example Value
PRIVATE_KEY_PASSWORD

This is the password used to encrypt the certificate's private key.

Although you can input this value as a text, it's recommended that you create a credential for each certificate password. Although you can use the same password for each certificate, it's more secure if each certificate has its own unique password.

NoteThe password must meet the Microsoft SQL Server Strong Password requirements:

  • Does not contain all or part of the user's account name. 
  • Is more than eight characters in length.
  • Contains characters from at least three of the following categories:
    • English uppercase characters (A through Z)
    • English lowercase characters (a through z)
    • Base 10 digits (0 through 9)
    • Nonalphabetic characters (for example: !, $, #, %)
  • For more information, please see Microsoft SQL Server Strong Password Guidelines

cred: SQL_WITNESS_PRIVATE_KEY_PASSWORD

 

MASTER_KEY_PASSWORD

This password is used for encryption of the master database key, which is a key that is used to protect other certificate keys and other various keys in the database. This input allows you to set a master key password so that you are later able to decrypt and use the master key if needed. The same value used on your Principal and Mirror servers should be used here.

 

Note: It's strongly recommended that you use a credential to hide the actual key value from non-admin users while still allowing them to pass the appropriate value as an input.

cred: MY_MASTER_KEY_PASSWORD

 

  1. RDP into the database server where you ran the script to create the certificate.
  2. 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. 

screen_WitnessCertificate.png

  1. Open the file and copy all of its contents.
  2. 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) 

File:ServerTemplates/Infinity/ST/Database_Manager_for_Microsoft_SQL_Server_Witness_Beta_(v13_Infinity)/Database_Manager_for_Microsoft_SQL_Server_Witness_-_Beta_ST_-_Tutorial/screen_witnessCred.png

  1. Click Save.

Modify Deployment Inputs

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

DATABASE

Input Name Description Example Value
SQL_EXPRESS_VERSION

This is the version of SQL Server Express that will be used for the witness. Currently SQL Server Express 2008R2 and SQL Server Express 2012 are supported. Please select appropriate version from dropdown.

  • 2008R2 (default)
  • 2012

Important! The version of SQL Server Express on the witness server needs to match versions of SQL Server on the principal and mirror servers. Go to the principal database server's Info tab, under the MultiCloud Image or Image sections to verify which SQL version is being used.

text: 2008R2
USE_PUBLIC_IP_WITNESS

Defines whether or not the witness will use the public network to connect to the principal and mirror database servers on TCP port 5022. If you launch the witness server in a cloud/region where it cannot communicate with the principal and mirror database servers over the private network, you must set this input to 'True' and set appropriate firewall permissions on both the pricipal and mirror servers to allow ingress communication from the witness server.

  • True (default) - Use the public network for the witness connection
  • False - Use private network for the witness connection
     

Important: If set to 'True,' and there are operational principal and mirror database servers, you must first set up any necessary firewall permissions so that it will accept incoming requests over the public network on TCP port 5022.

text: False
WITNESS_CERTIFICATE

This is the certificate to be used for authentication on the mirroring endpoint of the witness server. This input is required for a witness server.

Cred: SQL_WITNESS_CERTIFICATE
WITNESS_PRIVATE_KEY_PASSWORD

Password to decrypt private key contained in WITNESS_CERTIFICATE input. This input is required if you are going to launch a mirror server. This should be the same password which was used to generate and encode certificate and private key by the 'DB SQLS Generate and Save a Certificate' RightScript.

Cred: SQL_WITNESS_PRIVATE_KEY_PASSWORD

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.
Input Name Description Example Value
WITNESS_PRIVATE_KEY_PASSWORD

Password to decrypt the private key of the generated witness certificate. (SQL_WITNESS_CERTIFICATE)

cred: SQL_WITNESS_PRIVATE_KEY_PASSWORD
WITNESS_CERTIFICATE

Certificate to be used for authentication on mirrroring endpoint of Witness server. 

cred: SQL_WITNESS_CERTIFICATE
  1. 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). 

screen-MS_SQL_4tier_Servers-v1.png


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

Input Name Description Example Value
Load Balance Pools

Comma-separated list of URIs or FQDNs for which the load balancer will create server pools to answer website requests. The last entry will be the default backend and will answer for all URIs and FQDNs not listed here. A single entry of any name (for example, default) will mimic basic behavior of one load balancer with one pool of application servers. This will be used for naming server pool backends.

Note: Application servers can provide any number of URIs or FQDNs to join corresponding server pool backends (for example,  www.mysite.com, api.mysite.com, /serverid, default).


text:  www.mysite.com, api.mysite.com

 

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

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.

text:  /

For the DotNetNuke Windows 3 tier example, use:

text: /Default.aspx

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

LB_HAPROXY

Input Name Description Example Value
Load Balancing Algorithm

Defines which load balancing algorithm is used to establish  connections with application servers in the load balancing pool.

  • roundrobin (default) - Incoming requests are distributed in a round-robin fashion. (a-b-c-a-b-...)
  • leastconn - Incoming requests are sent to the server with the fewest number of active connections.
  • source - Incoming requests from the same client IP address will be sent to the same application server.
text: roundrobin

 

WEB_APACHE

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

Input Name Description Example Value
Allow Override Directive Set to All to allow the use of .htaccess files in the project web root directory. Set to None (default) to disallow the use of .htaccess files. text: None
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.

No value/Ignore

 

cred:  SSL_CERTIFICATE

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

No value/Ignore

 

cred:  SSL_CERTIFICATE_CHAIN

SSL Enable Set to "true" to enable SSL ('https').
Set to "false" to disable SSL. (default)

No value/Ignore

 

text:  false

SSL Certificate Key

The SSL server certificate's private key, in PEM format.

No value/Ignore

 

cred:  SSL_CERTIFICATE_KEY

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

No value/Ignore

 

cred:  SSL_PASSPHRASE

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 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 (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.
     
Input Name Description Example Value
APPLICATION_LISTENER_PORT The TCP port that the application service will listen on to receive requests from the load balancing servers/service. Ex: 8000 text: 8000
REMOTE_STORAGE_ACCOUNT_ID_APP
(For ROS only)

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

Specify the Account ID or name of the Remote Storage account. 

  • Amazon S3 - Amazon Access Key ID (e.g. cred: AWS_ACCESS_KEY_ID)
  • Rackspace Cloud Files - Rackspace login username (e.g. cred: RACKSPACE_USERNAME)
  • Microsoft Azure Blob Storage - Azure Storage Account Name (e.g. cred: AZURE_ACCOUNT_NAME)
  • SoftLayer Object Storage - SoftLayer Account ID (e.g. cred: SOFTLAYER_USER_ID)
  • OpenStack Object Storage (Swift) - OpenStack Object Storage (Swift) Account Password (e.g. SWIFT_ACCOUNT_PASSWORD)
cred: AWS_ACCESS_KEY_ID
REMOTE_STORAGE_ACCOUNT_PROVIDER_APP
(For ROS only)

Name of Remote Storage provider. Amazon S3, Rackspace Cloud Files, Windows Azure Storage, Softlayer Object Storage and OpenStack Swift are currently supported. Please select appropriate value from the dropdown. 

  • Amazon_S3 - Amazon S3 
  • Rackspace_Cloud_Files_US - Rackspace Cloud Files (United States)
  • Rackspace_Cloud_Files_UK - Rackspace Cloud Files (United Kingdom)
  • Windows_Azure_Storage - Microsoft Azure Blob Storage
  • SoftLayer_Object_Storage_Dallas - SoftLayer's Dallas (USA) cloud
  • SoftLayer_Object_Storage_Singapore - SoftLayer's Singapore cloud
  • SoftLayer_Object_Storage_Amsterdam - SoftLayer's Amsterdam cloud
  • OpenStack_Swift - OpenStack Object Storage (Swift)
text: Amazon_S3
REMOTE_STORAGE_ACCOUNT_SECRET_APP
(For ROS only)

The Secret Key or Password of the Remote Storage account which is used to authenticate your requests to Remote Storage services. For security reasons, it's recommended that you create and use credentials for these values instead of entering the text value.

Specify the Secret Key or password of the Remote Storage account. 

  • Amazon_S3 - AWS Secret Access Key (e.g. cred: AWS_SECRET_ACCESS_KEY)
  • Rackspace_Cloud_Files_US - Rackspace Account API Key US (e.g. cred: RACKSPACE_AUTH_KEY)
  • Rackspace_Cloud_Files_UK - Rackspace Account API Key UK (e.g. cred: RACKSPACE_AUTH_KEY)
  • Windows_Azure_Storage - Microsoft Primary Access Key (e.g. cred: AZURE_PRIMARY_ACCESS_KEY)
  • SoftLayer_Object_Storage - SoftLayer API Access Key (e.g. cred: SOFTLAYER_API_KEY)
  • OpenStack_Swift - OpenStack Object Storage (Swift) Account Password (e.g. SWIFT_ACCOUNT_PASSWORD)
cred: AWS_SECRET_ACCESS_KEY
REMOTE_STORAGE_CONTAINER_APP
(For ROS only)
Name of Remote Storage container (S3 bucket name, Rackspace Cloud Files, Windows Azure Storage or SoftLayer Storage container to be used as storage web application code. Ex: mycontainer text: my_app
SVN_APP_PATH
(For SVN only)

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
(For SVN only)
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
(For SVN only)

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
(For ROS only)
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
(For URL only)

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

REMOTE_STORAGE_BLOCK_SIZE_APP

(For Amazon S3 and Windows Azure Storage only)
Size of upload block in megabytes (currently supported by Amazon S3 and Windows Azure Storage only). Default and recommended value is 10 (10MB). Supported ranges are 1..5024 for S3 and 1..64 for Windows Azure Storage. text: 10

REMOTE_STORAGE_ENDPOINT_URL_APP

(For Swift storage only)
The endpoint URL for the Remote Storage provider. Currently this is used to specify an endpoint for OpenStack Swift.  text: http://myswift.com:5000/v2.0/tokens

REMOTE_STORAGE_THREAD_COUNT_APP

(For Windows Azure Storage only)
Number of parallel threads to be used for file downloads and uploads.  text: 2

REMOTE_STORAGE_USE_INTERNAL_NETWORK_APP

(For Swift storage only)
Set this input to True to force network connection to remote storage service using private interface (if the server is located in the same cloud/datacenter as remote storage service). This input is supported for Rackspace Open cloud, SoftLayer and OpenStack. Default is False (uses public network interface).  text: False

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.

 

Input Name Description Example Value

AWS_ACCESS_KEY_ID

AWS_SECRET_ACCESS_KEY

(For ELB only)

Specify the following Amazon EC2 cloud credentials to interact with an ELB.

cred:  AWS_ACCESS_KEY_ID

cred:  AWS_SECRET_ACCESS_KEY

RACKSPACE_USERNAME
RACKSPACE_AUTH_KEY
(For CLB only)

Specify the following Rackspace cloud credentials to interact with a CLB.

cred:  RACKSPACE_USERNAME
cred:  RACKSPACE_AUTH_KEY

RACKSPACE_REGION
(For CLB only)

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, this input is ignored.

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

DATABASE

Input Name Description Example Value
OPT_CONNECTION_STRING_DB_NAME The name of the target Microsoft SQL database that the IIS application will connect to. Ex: MyDB

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

If the database server uses a TCP communications port other than TCP 1433 (default), specify the desired 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_APPLICATION_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_APPLICATION_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_POOLS

(For HAProxy only)

The name of the load balancing pool that the application server will connect to. If you are connecting to a load balancer launched with RightScale's 'Load Balancer with HAProxy' ServerTemplate, this value should match one or more values in the 'Load Balance Pools' 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' pool 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

 

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

Input Name Description Example Value
REMOTE_STORAGE_ACCOUNT_ID

In order to upload IIS log files to an ROS location, you must provide proper cloud authentication credentials. For security reasons, it's recommended that you create and use credentials for these values instead of entering the text value. This input is also used for specifying the ROS container for database initialization and ROS-based backups.

Specify the Account ID or name of the Remote Storage account. 

  • Amazon S3 - Amazon Access Key ID (e.g. cred: AWS_ACCESS_KEY_ID)
  • Rackspace Cloud Files - Rackspace login username (e.g. cred: RACKSPACE_USERNAME)
  • Microsoft Azure Blob Storage - Azure Storage Account Name (e.g. cred: AZURE_ACCOUNT_NAME)
  • SoftLayer Object Storage - SoftLayer Account ID (e.g. cred: SOFTLAYER_USER_ID)
  • OpenStack Object Storage (Swift) - OpenStack Object Storage (Swift) Account Password (e.g. SWIFT_ACCOUNT_PASSWORD)
cred: AWS_ACCESS_KEY_ID
REMOTE_STORAGE_ACCOUNT_PROVIDER

Name of Remote Storage provider. Amazon S3, Rackspace Cloud Files, Windows Azure Storage, Softlayer Object Storage and OpenStack Swift are currently supported. Please select appropriate value from the dropdown. 

  • Amazon_S3 - Amazon S3 
  • Rackspace_Cloud_Files_US - Rackspace Cloud Files (United States)
  • Rackspace_Cloud_Files_UK - Rackspace Cloud Files (United Kingdom)
  • Windows_Azure_Storage - Microsoft Azure Blob Storage
  • SoftLayer_Object_Storage_Dallas - SoftLayer's Dallas (USA) cloud
  • SoftLayer_Object_Storage_Singapore - SoftLayer's Singapore cloud
  • SoftLayer_Object_Storage_Amsterdam - SoftLayer's Amsterdam cloud
  • OpenStack_Swift - OpenStack Object Storage (Swift)
text: Amazon_S3
REMOTE_STORAGE_ACCOUNT_SECRET

The Secret Key or Password of the Remote Storage account which is used to authenticate your requests to Remote Storage services. For security reasons, it's recommended that you create and use credentials for these values instead of entering the text value.

Specify the Secret Key or password of the Remote Storage account. 

  • Amazon_S3 - AWS Secret Access Key (e.g. cred: AWS_SECRET_ACCESS_KEY)
  • Rackspace_Cloud_Files_US - Rackspace Account API Key US (e.g. cred: RACKSPACE_AUTH_KEY)
  • Rackspace_Cloud_Files_UK - Rackspace Account API Key UK (e.g. cred: RACKSPACE_AUTH_KEY)
  • Windows_Azure_Storage - Microsoft Primary Access Key (e.g. cred: AZURE_PRIMARY_ACCESS_KEY)
  • SoftLayer_Object_Storage - SoftLayer API Access Key (e.g. cred: SOFTLAYER_API_KEY)
  • OpenStack_Swift - OpenStack Object Storage (Swift) Account Password (e.g. SWIFT_ACCOUNT_PASSWORD)
cred: AWS_SECRET_ACCESS_KEY
REMOTE_STORAGE_CONTAINER

The name of the container in the specified Remote Storage provider where the IIS log files will be stored. This input is also used for specifying the ROS container for database initialization and ROS-based backups.

text: my_iis_logs

REMOTE_STORAGE_BLOCK_SIZE

(For Amazon S3 and Windows Azure Storage only)
Size of upload block in megabytes (currently supported by Amazon S3 and Windows Azure Storage only). Default and recommended value is 10 (10MB). Supported ranges are 1..5024 for S3 and 1..64 for Azure. text: 10

REMOTE_STORAGE_ENDPOINT_URL

(For Swift storage only)
The endpoint URL for the Remote Storage provider. Currently this is used to specify an endpoint for OpenStack Swift.  text: http://myswift.com:5000/v2.0/tokens

REMOTE_STORAGE_THREAD_COUNT

(For Windows Azure Storage only)

Number of parallel threads to be used for file downloads and uploads. text: 2

REMOTE_STORAGE_USE_INTERNAL_NETWORK

(For Swift storage only)
Set this input to True to force network connection to remote storage service using private interface (if the server is located in the same cloud/datacenter as remote storage service). This input is supported for Rackspace Open cloud, SoftLayer and OpenStack. Default is False (uses public network interface).  text: False

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.

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_4tier_Servers-v2.png


Next Steps

Add a Microsoft SQL Mirror for Automatic Database Failover

See Database Manager for Microsoft SQL Server Witness Beta (v13 Infinity).

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 Microsoft IIS App Server (v13.5 LTS) - 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
11:19, 6 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.