3 Tier Deployment for Windows (Infinity)

Create an EC2 SSH Key

Determine which AWS region the Windows servers will be launched into and create an EC2 SSH Key in that region.  See Create a New SSH Key.

Create Elastic IPs

You will need two EIPs for both of the front end Load Balancers.  Name them appropriately. (e.g. myapp-lb1 and myapp-lb2) (Those in a classroom environment should preface their EIP names with their initials for easy identification later.)  See Create Elastic IPs (EIP).

Tip:

• Write down your EIP names and their IP addresses.
• Reminder:  There is an attached Deployment Worksheet (at the bottom of this page) you can print out to record IP addresses, bucket names, credentials, etc.

Create an EC2 Security Group

Create an EC2 Security Group with the following port permissions in the selected AWS region.  For development and test purposes you can simply create a single security group that will be used by all Windows servers. However, if you are building a production environment, you should consider creating separate security groups for each tier. Use 0.0.0.0/0 CIDR notation to open the ports to any IP address. See Create a New EC2 Security Group.

• 22 for SSH access (Linux)   (The load balancers in this example will be Linux instances.)
• 3389 for RDP access (Windows)
• 80 (HTTP)
• 443 for (HTTPS) -- Ignore if you are not using SSL.
• 1433 for SQL Server database connections
• 5022 for SQL Server mirroring connections

The created security group should have permissions that look like the following:

Save Application and Database Files in an S3 Bucket

Create an S3 bucket with a properly formatted name (see Create a New S3 Bucket) and upload an archive file of the application code (.zip) and a valid database file.  You can either restore the database using a SQL backup file (.bak) or attach an existing database file (.mdf). Upload the files to the S3 bucket.  Later in this tutorial you will need to provide the URLs to these files as input values. If you do not have your own files that you would like to use, you can download and use the following example files to complete the tutorial.

• DotNetNuke.zip

• DotNetNuke.bak

Note regarding file permissions: When you upload a file to an S3 bucket, its access permissions will automatically be set to "private" which means it can only be accessed with the AWS account credentials.  Our scripts will be able to access the database dump file if it's located inside one of your account's S3 buckets even if it's "private" because the AWS account credentials can be used for authentication.  However, if you're using an application or dump file that's in an S3 bucket that doesn't belong to this account, you will need to make sure the file is set to "public-read" by updating its permissions with the drop down menu. 

Configure DNS Records

The Database Manager for Microsoft SQL Server (v13.1) ServerTemplate supports the following DNS Providers:

• DNS Made Easy
• DynDNS
• Rackspace Cloud DNS (US and UK regions)
• Route53

You will need to create three DNS A records: two for both of the load balancers and one for the SQL Server principal node. Log into your DNS account and follow the steps below.

Note: The following steps were created using a DNS Made Easy account.

Create a Deployment

Create a new deployment that will be used to contain all of the Windows servers.  See Create a New Deployment.

Launch the Primary Server

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

Go to the new Deployment and click Add Server button.  See Add a Server to a Deployment.

1. Add the Server to the AWS region into which you will later launch your database servers.
2. Select the Database Manager for Microsoft SQL Server (v13.1) ServerTemplate.
3. 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. 
4. Select the SSH Key that you created earlier in this tutorial.
5. Select the Security Group that you created earlier in this tutorial
6. Ignore all other values.
7. 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.

Launch the Partner (Mirror) Server

1. Clone the existing (primary) database server. (e.g. MyApp-DB1)
2. Click Edit and rename the cloned server appropriately.  (e.g. MyApp-DB2)
3. Set the Availability Zone field of the cloned server to place it in another availability zone than your primary database server (you might need to check the current availability zone of the principal server on the Info tab of the Server page).
4. Launch the cloned server.
5. When viewing the inputs confirmation page, set the SERVER_MODE to Text:Mirror.
6. Click the Launch button.  Do not click the "Save and Launch" button because you do not want to save this setting for future launches of this server because its role may change over time.  You only want to launch this current server as a "mirror" server because you earlier launched a "primary" server.
7. Go to the principal server's Scripts tab and execute DB SQLS Init principal Operational Script. You do not need to wait until your mirror server is operational to run this script. DB SQLS Init principal waits for the mirror server automatically. Note that DB SQLS Init principal automatically completes the DB SQLS Init mirror script so this script does not need to be ran on the partner server.
8. Wait for your mirror server to become operational and mirroring initialization to complete. (That takes approximately 20-25 minutes).

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 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 script and specify the following inputs:

Note: You may not need to perform this step if your SQL Server configuration already contains all necessary logins/users for database access.

Create Load Balancers

Go to the new Deployment and click Add Server button. See Add a Server to a Deployment.

1. Add the Server to the AWS region into the same cloud/region as your database servers. 
2. Select the Load Balancer with HAProxy (v13.0) ServerTemplate.
3. Enter a name for the server (e.g. MyApp Load Balancer 1) and select the SSH Key and Security Group that you created earlier in this tutorial.
4. Select one of the Elastic IPs that you created in a previous step (e.g. MyApp-LB1).
5. Ignore all other values.
6. Click Confirm and then Finish.
7. Since you want to create two load balancer servers for redundancy purposes, clone the created server and rename it. (e.g. MyApp Load Balancer 2)

8. You now have two load balancer servers that have identical configurations.  Under the second load balancer server Info tab, click Edit and select the second Elastic IP you created in previous step.

Note: For high availability purposes, you might want to launch the load balancers into different zones from each other. Typically, you will want to use the same zones as the database servers so that each zone will contain a load balancer and database server. To change availability zone of the server you can go to Info tab of that server and click Edit.

Create and configure a scalable Server Array for application tier

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

Go to the Deployment and click Add Array button.

1. Add the Server Array to the AWS region into the same cloud/region as the other servers. 
2. Select the Microsoft IIS App Server (13.1) ServerTemplate.
3. Enter a name for the server array and select the SSH Key and Security Group that you created earlier in this tutorial.
4. Continue to the Array Details tab. Set the following autoscaling parameters:
   • Minimum = 2 servers
   • Maximum = 5 servers
   • Resize Up by = 3
   • Resize Down by = 1
   • Resize calm time = 8
5. Make sure that the status is disabled for now and array type is alert-based.
6. Click Confirm and then Finish.

Note: You may receive a warning ‘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 shortly.

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. Next, you will need 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:

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

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

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

• 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 launches application servers as specified in the Default Min Count autoscaling 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 the two EIPs.
• Delete the SSH key.
• Delete the security group.
• 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 the application and database dump file from the two S3 buckets.
• Delete the S3 buckets for your application and database.
• Delete all snapshots produced by databases servers.