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
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.
Disclaimers
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.
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.
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.
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.
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.
In a typical 3-tier architecture setup, DNS A records are used to create fully qualified domain names (FQDNs) that map to a particular server or tier of servers. The digram below shows a typical example of a 3-tier website architecture.
For example, the application servers locate the standalone or principal SQL database server by using the database server's FQDN (e.g., db-principal.example.com), which points to the server's private IP address. Similarly, front-end web traffic can be routed to a FQDN (e.g. www.example.com) where each load balancer server has a DNS record for that FQDN so that incoming requests are routed to one of the load balancer servers. Since the IP address of an instance in the cloud is often dynamically assigned at launch time, you are required to use a DNS provider that supports dynamic DNS (i.e. the ability to dynamically update the IP address of an A record) for the standalone/principal server (at a minimum). You can also use the same DNS provider for creating FQDNs for the load balancer servers. However, since they do not require the use of dynamic DNS, any DNS provider can be used.
TTLs
When you create the DNS records, it's important to set appropriate TTLs to ensure that servers will not stay connected to an old IP address that is no longer assigned to a functional server. For example, the DNS record that points to the standalone/principal database server should have a low TTL to ensure that the application servers will connect to the correct server within a reasonable amount of time. It's strongly recommended that you use a TTL of 60 seconds for the DNS record that points to the standalone/principal database server. If you are also creating DNS records for the front-end load balancer servers, you can use a more conservative TTL than the database tier. (e.g. 1800 seconds)
Note: If you are using Rackspace's Cloud DNS service, you must use a TTL of 300 seconds for the database servers because it's the lowest allowable TTL. Be sure to change the 'DNS_TTL' input from 60 (default) to 300.
You will need to create DNS records for the following servers:
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.
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.
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.
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.
DNS
Note: You should have already created the appropriate credentials for your DNS provider in an earlier step.
* 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.
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.
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.
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?
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.
Follow these steps to add a database server to the deployment.
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.
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.
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.
| 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 |
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 |
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:
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.
| 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 |
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.
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:
| 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.
| cred: DNS_PASSWORD |
DNS_SERVICE | Select the DNS provider that will be used to update the DNS record of the principal database server.
| 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.
| 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.
| 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.
Note: Later when you launch the witness server, make sure the same value is used for this input. | text: False |
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.
| 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.
| 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.
| 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 |
Input Name | Description | Example Value |
ADMIN_PASSWORD | Set the new password for the local Administrator account. Note: The 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:
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 |
After configuring your inputs, launch the database server that will serve as either the standalone or principal server.
Input Name | Description | Example Value |
SERVER_MODE | Select the database server's role/mode.
| text: Standalone |
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).
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.
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.
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 |
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.
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. Note: The password must meet the Microsoft SQL Server Strong Password requirements:
| 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 |
Note: Because your principal server is already operational, the inputs you modify at the deployment level will not affect the currently running principal server. The purpose of modifying these inputs is so your mirror will be able to interpret these inputs.
Note: If you want to create a witness server to monitor whether or not your principal and mirror servers stay connected, see the Database Manager for Microsoft SQL Server Witness - Beta ST - Tutorial.
Go to your deployment > Inputs. Click Edit and modify the following inputs:
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 |
The first step is to change the existing database server from "standalone" to "principal" mode.
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.
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.
Input Name | Description | Example Value |
SERVER_MODE | Since you already have a 'Principal' server running, set this input to 'Mirror'. | text: Mirror |
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:
Note: Make sure that this value multiplied by the number of instance cores does not exceed your value for LOGS_VOLUME_SIZE.
You will need to create a certificate for the 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 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. Note: The password must meet the Microsoft SQL Server Strong Password requirements:
| 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 |
Go to your Deployment's Inputs tab. Click Edit and modify the following inputs:
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.
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.
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 |
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.
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.)
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 |
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.
Follow these steps to add a load balancer server to the deployment.
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.
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.
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). |
For the 3-tier tutorial, use: |
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: |
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 |
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.
| text: roundrobin |
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 |
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.
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.
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
For CLB
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.
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.
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.
The application code can be retrieved from several different location. You must specify the appropriate inputs depending on the option.
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.
| 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.
| 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.
| 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 |
(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 | Specify the following Rackspace cloud credentials to interact with a CLB. | cred: RACKSPACE_USERNAME |
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.
| text: us |
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 |
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.
| text: ord |
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.
| 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.
| 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.
| 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 |
After configuring your inputs, launch the application server.
Once all of the servers are operational you can perform the following tests.
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.
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)
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.
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)
See Database Manager for Microsoft SQL Server Witness Beta (v13 Infinity).
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:
© 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.