Note: Please go to docs.rightscale.com to access the current RightScale documentation set. Also, feel free to Chat with us!
Home > Clouds > Microsoft Azure > Tutorials > 3 Tier Deployment with Microsoft Azure

3 Tier Deployment with Microsoft Azure

 

logo-Azure_w150-v2.png

Objective

To create a new 3-tier Windows deployment using the RightScale Load Balancer with HAProxy, Microsoft IIS App Server and Database Manager for Microsoft SQL Server ServerTemplates on Microsoft Azure.

This deployment consists of the following three tiers:

  • Tier 1 - Load Balancer (RightScale load balancer with HA Proxy)
  • Tier 2 - Application (Microsoft IIS Application server)
  • Tier 3 - Database (Mirrored Database Manager for Microsoft SQL Server)

Note: This tutorial works with the v13.1 infinity lineage of ServerTemplates. For more information about release terminology, see ServerTemplate Release and Lineage Methodology.

Table of Contents

  1. Objective
  2. Prerequisites
    1. Save Application and Database Files to a Cloud Storage Location
    2. Create a Deployment
    3. Create Load Balancers
  3. Define Inputs
    1. LB
      1. Launch the Load Balancer Servers
    2. Configure DNS Records
      1. Load balancer one
      2. Load balancer two
      3. SQL Server - Principal Node
    3. Launch the Primary Database Server
    4. Define Inputs
      1. Create the Credentials
    5. Finding the Storage credential values within the Microsoft Azure portal
  4. Required Inputs
    1. BACKUP
    2. CLOUD
    3. DATABASE
    4. DNS
    5. REMOTE STORAGE
    6. SYSTEM
      1. Launch the Server
      2. Import the database
        1. Download database backup (.bak) file
    7. APPLICATION
      1. Restore from a database backup (.bak)
    8. DATABASE
    9. REMOTE STORAGE
  5. Set up a SQL Server Mirroring Configuration
    1. Generate Principal and Mirror Certificates
    2. Modify Deployment Inputs
      1. DATABASE
    3. Change Server from Standalone to Principal Mode
    4. Launch the Mirror Database Server
      1. DATABASE
    5. Register the Primary Server with the DNS Provider
  6. Create a SQL Server Login
    1. DATABASE
    2. Create and configure a scalable Server Array for application tier
  7. Define the Inputs for the Server Array
    1. APPLICATION
    2. DATABASE
    3. SYSTEM
  8. Launching the Server Array
    1. Testing the Deployment
    2. Shut Down the Deployment

Prerequisites

  • 'actor' and 'server_login' user role privileges
  • Microsoft Azure registered within the RightScale Dashboard
  • Access to a DNS Made Easy Account
  • If the following ServerTemplates do not exist in your RightScale account (Design > ServerTemplates), you need 'library' user role privileges to import them from the MultiCloud Marketplace:
    • Microsoft IIS App Server (v13.1)
    • Database Manager for Microsoft SQL Server (v13.1)
    • RightScale Load Balancer with HAProxy (v13.0)

Save Application and Database Files to a Cloud Storage Location

Files are provided for both the database backup for SQL Server 2012 as well as the application file package that will be used in this document.  Later in this tutorial you will need to provide the URLs to these files as input values – you can use the links below.

Create a Deployment

Create a new deployment that will contain all of the Windows servers.  Edit section

Go to Manage > Deployments. Click New and provide the following information:

  • Nickname - User-defined name for the deployment.
  • Description - A short, internal-only description of the deployment.

Create Load Balancers

Now that you have a deployment, you can create your servers, starting with the load balancers. 

  1. Go to the new deployment and click the Add Server button. 
  2. Navigate to your deployment (Manage > Deployments > your deployment).
  3. Click Add Server to add a server to your deployment. The Add Server Assistant opens. From the Cloud drop down menu, select the same Microsoft Azure cloud/region as your database servers. 
  4. Select the RightScale Load Balancer with HAProxy ServerTemplate.
  5. Enter a name for the server (e.g. MyApp Load Balancer 1)
  6. Click Confirm and then Finish.
     

Because you want to create two load balancer servers for redundancy purposes, clone the created server and rename it. (e.g. MyApp Load Balancer 2)

You now have two load balancer servers that have identical configurations.

Define Inputs

Go to the deployment's Inputs tab and define values for the following missing inputs:

LB

Input Name Description Example Value
LB: Load Balance Pools Enter the Fully Qualified Domain Name (FQDN) of the application that you will register in DNS for this web app. text:myapp-www.domain.com
Launch the Load Balancer Servers

Go to the deployment's Servers tab and launch both of the load balancer servers.

Configure DNS Records

You must create three DNS A records: One for each load balancer and one for the SQL Server principal node. Log into your DNS account and follow the steps below.



Note: The following steps demonstrate this process using a DNS Made Easy account.

Load balancer one
  1. Create an 'A Record' for your first Load Balancer in your domain.  For example, "myapp-www". 
    Note:  In this basic example, the fully qualified domain name becomes:  myapp-www.example.com.
  2. For the IP address field, use the public IP address that was assigned to your load balancer.
  3. Uncheck Dynamic DNS.  
  4. Leave the Password field blank (if prompted).
  5. Because this is a load balancer, it's OK to use a longer TTL. Set the value to 1800 seconds.

File:09-Clouds/Azure/Tutorials/3_Tier_Deployment_with_Windows_Azure/screen-AzureLoadBalancer1.png

Load balancer two
  1. Create another 'A record' for your second load balancer.
  2. You must use the same name as the first Load Balancer (i.e. myapp-www).  
  3. Use the public IP address assigned to the server.

File:09-Clouds/Azure/Tutorials/3_Tier_Deployment_with_Windows_Azure/screen-AzureLoadBalancer2.png

Important!  The only difference between the two A Records created for the two load balancers is that each load balancer should be using a different IP address.

SQL Server - Principal Node
  1. Create an 'A Record' for the server that will point to the "principal" Microsoft SQL Server.  Name it something simple, for example your app prefix from the web tier dns name appended with "db" (e.g. myapp-db).
  2. Give it any legal, temporary IP address. (e.g. 1.2.3.4)  The actual value does not matter, since it is simply a placeholder IP address that will be replaced at a later time when the DNS script runs.
  3. Set the TTL to 60 seconds.  TTL=60
  4. Be sure to check the Dynamic DNS option so that the DNS A record will be assigned a 7-digit code that will be used to identify and update the record. The DDNSID will be a required input parameter that you will need to provide when you define your deployment's inputs.  This will allow the temporary IP address of 1.2.3.4 (which you created above) to be dynamically replaced by the actual IP address of the cloud server after it boots up.
  5. Leave the Password blank (if prompted).

File:09-Clouds/Azure/Tutorials/3_Tier_Deployment_with_Windows_Azure/screen-AzurePrincipalNode.png

  1. Record the DDNSID of your Master (displayed in a pop-up window when you select the DDNSID link in your DME account). (e.g. 1234123)

File:09-Clouds/Azure/Tutorials/3_Tier_Deployment_with_Windows_Azure/screen-AzureMasterID.png

Launch the Primary Database Server

Now that you have a deployment, you can use the Database Manager for Microsoft SQL Server ServerTemplate to launch a SQL database server. 

  1. Go to your deployment (Manage > Deployments > your deployment).
  2. Click Add Server. The Add Server Assistant opens. From the Cloud drop down menu, select the desired Microsoft Azure cloud/region (the same cloud/region as your load balancers). 
  3. Select the Database Manager for Microsoft SQL Server (v13.1) ServerTemplate.
  4. Under Server Name in the Server Details tab, enter a name for the server (e.g. MyApp-DB1). Do not include "primary" in the server's nickname because the server's role might change in a disaster recovery or failover scenario. To avoid future confusion in the event that you promote a partner server to become the new primary server, you should use generic server nicknames. 
  5. Click Confirm and then Finish.

Define Inputs

The next step is to provide values for any missing inputs at the deployment level. Some input parameters are inherited from the ServerTemplate, whereas some are left undefined because they are user-specific.

Go to the deployment's Inputs tab and click Edit. Although you technically only have to define inputs that are required to launch a database server, you might want to define values for some of the other missing inputs at the deployment level so that you can better manage and keep track of your settings. Also, if you define your inputs now, you will not need to provide any inputs later when you run any of the Operational Scripts.

Create the Credentials

You will need to create credentials for the following values:

Credential Name Description
ADMIN_PASSWORD Holds the password to be assigned to the local administrator account for Windows. The standard windows password complexity requirements apply. This password will be used when accessing the server via RDP.
DNS_USER User name for the DNS provider that you are using (DNS Made Easy, DYNDNS, Route 53, etc.)
DNS_PASSWORD Password for DNS_USER as defined above
WAZ_STORAGE_ACCOUNT_ID Corresponds to the ‘Storage Account Name’ as described below from the Microsoft Azure Portal
WAZ_STORAGE_CONTAINER Corresponds to the ‘Container Name’ as found in the Microsoft Azure portal per the information below
WAZ_STORAGE_ACCOUNT_SECRET Corresponds to either the primary or secondary access key as found in the Microsoft Azure portal per the information below
SQL_SERVER_USER_NAME SQL Authentication user name to be used to authenticate the web application to the SQL server
SQL_SERVER_USER_PASSWORD Password to be used when authenticating the SQL_SERVER_USER_NAME user to the SQL server (See suggestions for password strength)

Finding the Storage credential values within the Microsoft Azure portal

You will need to retrieve 3 pieces of information from your Microsoft Azure account to be able to access your storage account via RightScale: the storage account name associated with the storage account you’re using and either the primary or secondary access key associated with that storage account.

File:09-Clouds/Azure/Tutorials/3_Tier_Deployment_with_Windows_Azure/screen-AzureStorage.png

Within the preview portal, once you navigate to your storage containers, you’ll highlight one of the records and hit the ‘Manage Keys’ button at the bottom of the page—from this page you’ll create credentials for the Storage Account Name as well as one of the access keys (primary or secondary).   

File:09-Clouds/Azure/Tutorials/3_Tier_Deployment_with_Windows_Azure/screen-AzureManageAccessKeys.png

To get the storage container name, go into the detail view of the storage account and look at the ‘Containers’ tab – you’ll see a view that outlines the containers within your storage account. The value you want to use is the item that is not ‘vhds’—this is your default container and should be used for this tutorial.

File:09-Clouds/Azure/Tutorials/3_Tier_Deployment_with_Windows_Azure/screen-AzureVHDS.png

Required Inputs

NOTE: The Example Type/Value column can contain several types of values. 'Text' type entries can either have predefined values or manually entered input. Go to the Inputs tab of your Deployment, click Edit and define these missing inputs:

BACKUP

 

Input Name Description Example Type/Value
BACKUP_METHOD Use this input to specify method of doing continuous database backups. 2 methods are currently supported--uploading backup files to remote storage such as S3/Cloud Files, or performing volume snapshots (on clouds supporting snapshots). Ex: Snapshots
Note: Do not override the predefined values. 		 Text:Remote Storage

CLOUD

Input Name Description Example Type/Value
AWS_ACCESS_KEY_ID Not in use as Microsoft Azure Storage will be used for Mirroring and Backup, but this is a required input—put in any string to validate the input, a valid access key id is not necessary. Text:any string
AWS_SECRET_ACCESS_KEY Not in use as Microsoft Azure Storage will be used for Mirroring and Backup, but this is a required input—put in any string to validate the input, a valid secret access key is not necessary. Text:any string

DATABASE

Input Name Description Example Type/Value
DATA_VOLUME_SIZE Enter the size (in GB) for the volume that will be used to store the database file. By default, drive letter D:\ will be used for the data volume. To override this setting and use a different drive letter you can use the OPT_DATA_VOLUME_LETTER input. Text: 30
DB_LINEAGE_NAME The lineage of the database backups. A string that is used to track all backups in a certain 'set' usually deployment wide. Text: mileagestats
INIT_MIRRORING_METHOD Method of data exchange between principal and mirror server to initialize mirroring session. 2 options are supported--via remote storage such as S3 or Cloud Files or via attaching/detaching volumes. Ex: Volumes Text:Remote Storage
LOGS_VOLUME_SIZE

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

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

 Text:10

DNS

Input Name Description Example Type/Value
DNS_DOMAIN_NAME Enter the Fully Qualified Domain Name (FQDN) of the DNS record. e.g. text: myapp-db.domain.com
DNS_ID Enter the DDNSID of the DNS record you created in a previous step. 1234123
DNS_IP_ADDRESS

Choose whether to use 'public' or 'private' IP addresses for the DNS record.

NOTE: Do not override the predefined values. 		 text:Private IP
DNS_PASSWORD Enter the password of your DNS account or select the appropriate credential. Cred:DNS_PASSWORD
DNS_SERVICE

Select one of the predefined DNS providers: DNS Made Easy or DynDNS.

NOTE: Do not override the predefined values. 		 text: DNS Made Easy
DNS_USER Enter the user name of your DNS account or select the appropriate credential. Cred:DNS_USER
DNS_TTL Enter the TTL of the DNS record. The default value is 60 seconds.  Text:60

REMOTE STORAGE

Inpute Name Description Example Type/Value
REMOTE_STORAGE_ACCOUNT_ID The Storage Account Name which is used to authenticate your requests to Remote Storage services. It's strongly recommended that you use a RightScale Credential (Design > Credentials) to hide the actual key value from non-admin users while still allowing them to pass the appropriate value as an input. Cred:WAZ_STORAGE_ACCOUNT_ID
REMOTE_STORAGE_ACCOUNT_PROVIDER

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

NOTE: Do not override the predefined values.		 Text:Windows_Azure_Storage
REMOTE_STORAGE_ACCOUNT_SECRET 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 RightScale Credential (Design > Credentials) to hide the actual key value from non-admin users while still allowing them to pass the appropriate value as an input.  Cred:WAZ_STORAGE_ACCOUNT_SECRET
REMOTE_STORAGE_CONTAINER Name of Remote Storage container (S3 bucket name, Rackspace Cloud Files, Microsoft Azure Storage or SoftLayer Storage container to be used as storage for database initialization and backups, app server logs.  Cred:WAZ_STORAGE_CONTAINER

SYSTEM

Inpute Name Description Example Type/Value
ADMIN_PASSWORD This holds the password to be assigned to the local administrator account for Windows. The standard windows password complexity requirements apply. This password will be used when accessing the server via RDP. You created a credential for this value earlier in the tutorial. Cred: ADMIN_PASSWORD
SYS_WINDOWS_TZINFO

Set the system time to a specific timezone. Some examples are provided in the dropdown, but can be overridden if the timezone is not listed.

NOTE: Do not override the predefined values—select an existing time zone.  If yours is unavailable, use ‘Pacific Standard Time’ for the purposes of this tutorial.		 Text:Your Local Time Zone

 

Click Save.

Launch the Server
  1. Launch the server. On the Server's page click the Launch action button.  You can also launch the server from the deployment's Servers tab. All of the required inputs should have defined values.  Keep the default values for the remaining inputs. Click the Launch button again to confirm that you want to launch the server with the predefined input values.
  2. Wait for the server instance to become operational before going to the next step.
Import the database

The next step is to import the database onto the instance by first downloading a backup (.bak) file to the server's local disk and then restoring it to the database from the downloaded file. You will need to select and run the appropriate operational script based on the chosen method.

Download database backup (.bak) file

Normally, you would download the .bak file using the PowerShell - Get File HTTP operational script but this script is not published yet. Use the PowerShell - Get File HTTP 'Any Script'—you will find it within the RightScale Open Source publishing account. This will save the .bak file locally, which can then be used to restore the database. The following table provides information for working with the backup file.

APPLICATION

Name Description Input Values
DEST_FOLDER The folder where to save the .bak file text: c:\temp
SRC_FILENAME File name of the .bak file to be downloaded text:mileagestatsdata_sql2012.bak
SRC_FOLDER_URL URL of the folder where the file is located

text:http://support.rightscale.com/@api/deki/files/1109

Click continue.

Restore from a database backup (.bak)

Follow these instructions if you want to load the database by using a backup file (.bak).

Go to the server's Scripts tab and run the DB SQLS Restore database from local disk / Remote Storage (v13.1) operational script. You will need to provide values for the following inputs before running the script:

DATABASE

Input Name Description Example Value
BACKUP_FILE_NAME Enter the filename of the database backup file (.bak) that will be used to load the database. (e.g. mileagestatsdata_sql2012.bak) text: mileagestatsdata_sql2012.bak
BACKUP_LOCAL_DIR This will be the folder where the .bak file was downloaded to. text: c:\temp
DB_NAME The name of the default SQL Server database that will be created. (e.g. MileageStatsData) Note that this name should match the original database name the backup was taken from. text: mileagestatsdata

REMOTE STORAGE

Input Name Description Example Value
REMOTE_STORAGE_ACCOUNT_ID The Storage Account Name which is used to authenticate your requests to Remote Storage services. It's strongly recommended that you use a RightScale Credential (Design > Credentials) to hide the actual key value from non-admin users while still allowing them to pass the appropriate value as an input.  Cred:WAZ_STORAGE_ACCOUNT_ID
REMOTE_STORAGE_ACCOUNT_PROVIDER

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

NOTE: Do not override the predefined values.		 Text:Windows_Azure_Storage
REMOTE_STORAGE_ACCOUNT_SECRET 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 RightScale Credential (Design > Credentials) to hide the actual key value from non-admin users while still allowing them to pass the appropriate value as an input. Cred:WAZ_STORAGE_ACCOUNT_SECRET
REMOTE_STORAGE_BLOCK_SIZE_BYTES Size of upload block in bytes (currently supported by Microsoft Azure Storage only). Default value is 33,554,432 bytes (32MB). Max value: 67,108,864 (64 Mb). Text:33554432
REMOTE_STORAGE_CONTAINER Name of Remote Storage container (S3 bucket name, Rackspace Cloud Files, Microsoft Azure Storage or SoftLayer Storage container to be used as storage for database initialization and backups, app server logs. Cred:WAZ_STORAGE_CONTAINER
REMOTE_STORAGE_THREAD_COUNT Number of parallel threads to be used for file downloads and uploads (currently supported by Microsoft Azure Storage only). Default value is 2. Ex: 4 Text:2

Click Continue.

Set up a SQL Server 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 Principal and Mirror 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
  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).
     
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:

  • 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
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. Repeat the same steps to create a credential for the mirror certificate. (e.g. SQL_MIRROR_CERTIFICATE) from the credential1.txt file

Modify Deployment Inputs

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

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

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

DATABASE
Input Name Description Example Value
PRINCIPAL_CERTIFICATE

This is the certificate to be used for authentication on the mirroring endpoint of the principal server. This input is required when launching a principal, mirror, or witness but not needed if you're launching a standalone SQL server.

 Cred: SQL_PRINCIPAL_CERTIFICATE
PRINCIPAL_PRIVATE_KEY_PASSWORD

Password to decrypt private key contained in PRINCIPAL_CERTIFICATE input. This input is required when launching principal, mirror or witness but not needed for Standalone SQL Server. This should be the same password which was used to generate and encode certificate and private key by 'DB SQLS Generate and Save a Certificate' RightScript.

 Cred: SQL_PRINCIPAL_PRIVATE_KEY_PASSWORD

MIRROR_CERTIFICATE

This is the certificate to be used for authentication on the mirroring endpoint of the mirror server. This input is required when launching a principal, mirror, or witness but not needed if you're launching a standalone SQL server.

 Cred: SQL_MIRROR_CERTIFICATE
MIRROR_PRIVATE_KEY_PASSWORD Password to decrypt private key contained in MIRROR_CERTIFICATE input. This input is required when launching principal, mirror or witness but not needed for Standalone SQL Server. This sshould be the same password which was used to generate and encode certificate and private key by '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). This is 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

Register the Primary Server with the DNS Provider

Go to the "primary" server's Scripts tab and run the DNS Register IP Operational Script.

Note: The inputs required to run this script have already been defined at the deployment level.

Create a SQL Server Login

Create the SQL Server login username/password that will be used by the application servers to connect to the "primary" SQL database server. Run the DB SQLS Create login (v13.1) script and specify the following inputs:

DATABASE

Input Name Description Example Value
DB_NAME Enter the name of the database. text: mileagestatsdata
DB_REMOTE_SQL_LOGIN (Optional) Enter the SQL Server login username with administrative rights to the remote SQL Server database server. No value/Ignore
DB_REMOTE_SQL_PASSWORD (Optional) Enter SQL Server login password. You can enter a text:'password', but for best practices it would be best to create a credential with your password value and name it something like DB_LOGIN_PASSWORD. No value/Ignore
DB_NEW_LOGIN_NAME

Enter the login name for the new SQL Server user. You can enter a text:'password', but for best practices it would be best to create a credential with your password value and name it something like SQL_SERVER_USER_NAME.

Important: This value needs to match the OPT_CONNECTION_STRING_DB_USER_ID defined later in this tutorial. To be properly configured, this DB value needs to match the IIS Server value (OPT).

 cred:SQL_SERVER_USER_NAME
DB_NEW_LOGIN_PASSWORD

Enter the login password for the new SQL Server user. You can enter a text:'password', but for best practices it would be best to create a credential with your password value and name it something like SQL_SERVER_USER_PASSWORD.

Important: This value needs to match the OPT_CONNECTION_STRING_DB_USER_ID defined later in this tutorial. To be properly configured, this DB value needs to match the IIS Server value (OPT).

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

 cred:SQL_SERVER_USER_PASSWORD

Create and configure a scalable Server Array for application tier

The next step is to create and launch a server array consisting of Microsoft IIS Application Servers.  

Go to the Deployment and click Add Array button.

  1. Add the Server Array to the same cloud/region as the other servers. 
  2. Select the Microsoft IIS App Server ServerTemplate.
  3. Enter a name for the server array.
  4. Continue to the Array Details tab. Set the following auto scaling parameters:
    • Min = 2 servers
    • Max = 5 servers
    • Array Type = Alert-based
    • Decision Threshold = 51
    • Choose Voters by Tag = True/Checked for Default to nickname
    • Resize Up by = 3
    • Resize Down by = 1
    • Resize calm time = 8
  5. Make sure that the status is disabled for now and the array type is alert-based.
  6. Click Confirm and then Finish.

 

Note: You may receive a warning that "Some of the Input parameters for boot scripts are missing. Please update them to launch instances successfully." This is OK, you will take care of the remaining inputs soon.

Now that you have created the server array, you need to configure it. 

Under the server array's Next Alerts tab you will be able to add to the existing alert specifications that are being inherited by the array's application ServerTemplate. The next step is to add two new alert specifications that will be used for triggering auto-scaling. When you set up your own custom deployment, you will want to pick appropriate metrics and thresholds that make sense for auto-scaling your own application. But for this tutorial, you can use the suggested parameters below:

  1. Click New to create two new alert specifications. Fill out the fields with the following information.
  2. Name: "Scale Up" 

  3. Condition: if "cpu-0/cpu-idle.value < '30' for 5 min then vote to grow array by setting the tag to be the name of your server array. We used '3tier'.

File:09-Clouds/Azure/Tutorials/3_Tier_Deployment_with_Windows_Azure/screen-Windows3tierScaleUp.png

  1. Click Save.
  2. Create another, by clicking New again. 
  3. Name: "Scale Down"
  4. "Scale Down" - if cpu-0/cpu-idle.value > '80' for 5 min then vote to shrink array by setting the tag '3tier'

 

File:09-Clouds/Azure/Tutorials/3_Tier_Deployment_with_Windows_Azure/screen_-_Array.NextAlerts.png

 

  1. Click Save.

Define the Inputs for the Server Array

Go to the deployment's Inputs tab and edit values for the following missing inputs.

The required inputs will be different depending on whether you are downloading the application code from an URL or SVN repository or Remote Storage. In this tutorial, we are using a ZIP file attached to the tutorial itself (MileageStats.zip).

APPLICATION

Input Name Description Example Type/Value
ZIP_URL In this tutorial, you are using the sample app downloaded above.  MileageStats.zip
(ADVANCED) OPT_APP_POOL_NAME Name of the application pool to be used when hosting the IIS/ASP.net application Text:ASP.NET v4.0

DATABASE

Input Name Description Example Type/Value
OPT_CONNECTION_STRING_DB_NAME Name of the database for the application server to connect to. This is the database served by pair of SQL Server instances you configured earlier in this tutorial. text: mileagestatsdata
OPT_CONNECTION_STRING_DB_SERVER_
NAME 		 Fully qualified domain name of the database server you created earlier in this tutorial. Example text: myapp-db.domain.com
OPT_CONNECTION_STRING_DB_USER_ID

Login name to be used for database connections created earlier in this tutorial.

Important: This value needs to match the DB_NEW_LOGIN_NAME defined earlier in this tutorial. To be properly configured, this IIS Server value needs to match the DB value.		 cred: SQL_SERVER_USER_NAME
OPT_CONNECTION_STRING_DB_USER_
PASSWORD

Login name to be used for database connections created earlier in this tutorial.

Important: This value needs to match the DB_NEW_LOGIN_NAME defined earlier in this tutorial. To be properly configured, this IIS Server value needs to match the DB value.

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

 cred: SQL_SERVER_USER_PASSWORD
OPT_CONNECTION_STRING_NAME Application-specific name of the connection string. For the Mileage Stats application the name is ‘MileageStatsDbContext’. text: MileageStatsDbContext

SYSTEM

Input Name Description Example Type/Value
ADMIN_PASSWORD Set the password for the local Administrator account. This should be at least 7 characters long with at least one uppercase letter, one lowercase letter, and one digit. Cred: ADMIN_PASSWORD
SYS_WINDOWS_TZINFO

Set the system time to a specific timezone. Some examples are provided in the dropdown, but can be overridden if the timezone is not listed.


Note: Do not override the predefined values—select an existing time zone.  If yours is unavailable, use ‘Pacific Standard Time’ for the purposes of this tutorial.		 Text:Your Local Time Zone

 

Note:  SVN_APP_PATH, SVN_PASSWORD, SVN_USERNAME are not required for this tutorial. Set these values to ignore.

You need to set one advanced input  (OPT_APP_POOL_NAME). To see the advanced inputs click on the Show advanced inputs link below the Application category. Next, go to the Inputs tab of the array and set values for this input if you haven't done so already:

File:09-Clouds/Azure/Tutorials/3_Tier_Deployment_with_Windows_Azure/screen-AzureAdvancedCategories.png

Other inputs can be left set to default values.

Click Save.

Launching the Server Array

Now that you have operational load balancers ready to accept requests, and primary/mirror database servers on the backend, you are ready to start up the server array to run your application.

Go to your server array page.

Here you have two alternatives: 

  • Manually launch a single server into the array for testing by navigating to the array and clicking Launch. As a best practice, you should launch a single instance before enabling an array to test if everything has been properly configured.

  • Enable the server array - if you are using this tutorial for learning purposes, just enable the server array by going to the server array's Info tab and clicking the enable link in the Status row.

Note: After being enabled, the array will launch application servers as specified in the Default Min Count auto scaling policy parameters (configured earlier in this tutorial).

Testing the Deployment

To test if your deployment is operational just enter your LB_HOSTNAME in browser address fields. (http://my-www.example.com) 

Shut Down the Deployment

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:

  • Disable the server array.
  • Terminate all servers in the array.
  • Delete the server array.
  • Terminate the load balancers.
  • Terminate the mirror and primary database servers.
  • Delete the deployment.
  • Delete all credentials (unless you are sharing your account or deployment with others who might still be using them).
  • Delete all four DNS Made Easy A records.
  • Delete all snapshots produced by databases servers.

 

You must to post a comment.
Last modified
11:08, 20 Jan 2015

Tags

Classifications

This page has no classifications.

Announcements

None

Powered by MindTouch ®

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