Support Search
Try RightScale for free
RightScale Cloud Management Support Portal > Clouds > Azure > Tutorials > 3 Tier Deployment with Windows Azure

3 Tier Deployment with Windows Azure

     icon-Beta-v1.png  Service-level response times are the same as for general-release features. For more information, contact sales@rightscale.com.

    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 Windows 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. 1. Objective
    2. 2. Prerequisites
      1. 2.1. Save Application and Database Files to a Cloud Storage Location
      2. 2.2. Create a Deployment
      3. 2.3. Create Load Balancers
    3. 3. Define Inputs
      1. 3.1. LB
        1. 3.1.1. Launch the Load Balancer Servers
      2. 3.2. Configure DNS Records
        1. 3.2.1. Load balancer one
        2. 3.2.2. Load balancer two
        3. 3.2.3. SQL Server - Principal Node
      3. 3.3. Launch the Primary Database Server
      4. 3.4. Define Inputs
        1. 3.4.1. Create the Credentials
      5. 3.5. Finding the Storage credential values within the Windows Azure portal
    4. 4. Required Inputs
      1. 4.1. BACKUP
      2. 4.2. CLOUD
      3. 4.3. DATABASE
      4. 4.4. DNS
      5. 4.5. REMOTE STORAGE
      6. 4.6. SYSTEM
        1. 4.6.1. Launch the Server
        2. 4.6.2. Import the database
          1. 4.6.2.1. Download database backup (.bak) file
      7. 4.7. APPLICATION
          1. 4.7.1.1. Restore from a database backup (.bak)
      8. 4.8. DATABASE
      9. 4.9. REMOTE STORAGE
    5. 5. Set up a SQL Server Mirroring Configuration
      1. 5.1. Generate Principal and Mirror Certificates
      2. 5.2. Modify Deployment Inputs
        1. 5.2.1. DATABASE
      3. 5.3. Change Server from Standalone to Principal Mode
      4. 5.4. Launch the Mirror Database Server
        1. 5.4.1. DATABASE
      5. 5.5. Register the Primary Server with the DNS Provider
    6. 6. Create a SQL Server Login
      1. 6.1. DATABASE
      2. 6.2. Create and configure a scalable Server Array for application tier
    7. 7. Define the Inputs for the Server Array
      1. 7.1. APPLICATION
      2. 7.2. DATABASE
      3. 7.3. SYSTEM
    8. 8. Launching the Server Array
      1. 8.1. Testing the Deployment
      2. 8.2. Shut Down the Deployment

    Prerequisites

    • 'actor' and 'server_login' user role privileges
    • Windows 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 Windows 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.

    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.

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

    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)

    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 Windows 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 Windows Azure Portal
    WAZ_STORAGE_CONTAINER Corresponds to the ‘Container Name’ as found in the Windows Azure portal per the information below
    WAZ_STORAGE_ACCOUNT_SECRET Corresponds to either the primary or secondary access key as found in the Windows 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 Windows Azure portal

    You will need to retrieve 3 pieces of information from your Windows 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.

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

    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.

    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 Windows 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 Windows 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, Windows 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, Windows 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/6435/=

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

    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.

    1. Go to Design > Credentials. Create a credential that contains a valid Windows password for each server in the SQL server setup. Although you can use one certificate for each server, it's less secure. It's recommended that you create a unique certificate for each server. When you run the script, select the matching credential depending on the type of certificate (Principal/Mirror/Witness).
      • PRINCIPAL_PRIVATE_KEY_PASSWORD
      • MIRROR_PRIVATE_KEY_PASSWORD
      • WITNESS_PRIVATE_KEY_PASSWORD
    2. Go to the "current" server's Scripts tab.
    3. Run the 'DB SQLS Generate and Save a Certificate' script to generate a text file that contains an encrypted certificate and private key.
       
    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 recommend 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)
      • Nonalphabetic characters (for example: !, $, #, %)
    • For more information, please see Microsoft SQL Server Strong Password Guidelines
    		 cred: PRINCIPAL_PRIVATE_KEY_PASSWORD

     

    1. Go to your deployments Server tab and RDP into the server.
    2. Go to Start > Computer > Local Disk (C:) and open up the created 'credential.txt' file. 

    screen_RDS-princCert.png

    1. Create a new credential with the contents of the text file and name it accordingly. (e.g. SQL_PRINCIPAL_CERTIFICATE)

    1. Click Save.
    2. Repeat the steps above to create additional (Mirror/Witness) certificates as necessary. When you run the script for a second time, a new certificate will be created ('credential1.txt'), which contains the encrypted credential that the mirror will use for authentication purposes. Note: Each time the script is executed, it creates a newly-incremented credential. For example, if you run the script a third time, a 'credential2.txt' file is created.

    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 containing 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 the Standalone/Principal certificate by running the 'DB SQLS Generate and Save a Certificate' RightScript.

    		 Cred: 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 containing in MIRROR_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 the Mirror certificate by running the 'DB SQLS Generate and Save a Certificate' RightScript. Cred: 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. 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.

      Important!
      Do not wait for the script to be listed as "completed" in the Audit Entries before proceeeding to the next step because you will not see a 'completed: DNS SQLS Init Principal' audit entry until there is a "mirror" server is connected to the principal.

    Launch the Mirror Database Server

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

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

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

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

    		 text:  Mirror
    1. If there are any required inputs that are missing values (highlighted in red), cancel the launch and add the missing values at the deployment level before launching the server again. Refer to the instructions in Launch a Server if you are not familiar with this process.
    2. Click the Launch (not Save and Launch) button at the bottom of the input confirmation page. 
    3. You may notice that the "mirror" server transitions into a "decommissioning" phase before it becomes operational because a reboot is required to complete its configuration. Once the "mirror" server becomes operational, you will need to wait a few more minutes for the mirroring setup to be completed. Wait for the 'DB SQLS Init mirror' script to be completed on the "mirror" server. You'll know that the synchronization process is complete when the principal and mirror server have all of its tags (as seen in the screenshot below). Machine tags are used to clearly identify the "Principal" and "Mirror" servers. Note: You can only have a single mirror server.

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

    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'

     

     

    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:

    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.

     

    Powered by MindTouch