Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides resizable compute capacity in the cloud. Amazon Cloud Computing is a good choice if you want to deploy a very large scale network on the cloud that requires high availability, auto scaling and load balancing features.

High availability when deploying applications is crucial.  Newvem Cloud Care has identified that a vast number of users operate an AWS cloud that is highly vulnerable to outages. Many AWS Cloud users do not properly configure Elastic Load Balancers (ELBs) or ensure the backup of their data. In this article I will explain how you can configure High Availability for Microsoft SQL Server 2005/2008 & Web Server (IIS) in Amazon EC2. This article makes the assumption that readers have some basic knowledge of how Amazon EC2 works.

Getting Started with Amazon AWS cloud services

PART 1: Start a new Elastic Load Balancer (ELB) and enable data transfer across multiple availability zones

1. First let’s start with Amazon Load Balancing for Web Servers.

Assuming that you have created two instances for your web server in different availability zones, go to the Load Balancer tab from the EC2 menu, and then click on create a new elastic Load Balancer (ELB).

Learn how to create a new ELB using AWS Console: 

2. In the configure health Check page, set these properties:

• Ping Protocol: http
• Ping Port: 80
• Ping Path: iisstart.htm 

Note: Enter the ping path file. The load balancer will check the iisstart.htm file at 0.5 minute intervals. 

3. On the next page, select your two web server instances and click Continue.

 4. Click the Create button in the Review screen.

5. Make sure that the web servers’ instances are on different Availability Zones. For example, one web server on US-East-1a, and the other web server’s instances on US-East-1d, as shown above.

Different Availability Zones means different Amazon data centers in the same region. Learn more about AWS cloud availability zones and regions.

You can check your Load Balancer’s status, making sure that both instances are in Service mode.

That’s it. Your web server is now configured with the load balancer URL provided by Amazon. You can access your web server from the load balancer’s URL.

PART2: MSSQL Database Mirroring

Let’s configure SQL Server high availability using database mirroring (in this case for SQL Server 2005/2008).

For database mirroring, just take the full backup of the primary database and restore it on a secondary server with no recovery option. You also have to install SQL Server on the witness server to enable automatic failover of the database. SQL Server’s database mirroring uses port 5222, so make sure that port 5222 is open in your Amazon AWS security group (firewall).

After restoring the database on the secondary server go to the primary server and open your SQL console.

1. Right-click on your database and start the Database Mirroring Security Wizard. In the first page of the wizard, click Next.

2. In the Include Witness Server page, select Yes to configure security to include witness server roles wizard.

3. In the Principal Server Instance page, select the primary database instances.

4. In the Mirror Server Instance page, select your mirror server instances.

5. In the Witness Server Instance page, select the Witness Server’s SQL Instances.

6. Click Finish to start the database mirroring.

That’s it. Your SQL server’s high availability setup is complete. If your primary server goes down, the connection automatically switches to the mirror server, and your mirror server becomes active. Neither you nor your clients will have any problems accessing your application!

Newvem Cloud Care continuously analyzes your baseline disaster recovery and identifies if best practices have been implemented. It also  recommends AWS features and best practices that can help you reach optimal availability, increase outage protection and ensure a quick recovery.

PART 3: Additional Considerations

Your SLA

In order to strengthen your SLA, you can deploy cross regions though Amazon cloud does not support ELB configuration between cross regions meaning you can’t select one instance located in Virginia and a second in Ireland and deploy load balancing between them. I have tested this cross AZ architecture in a project with Webserver ELB configuration and SQL Server database mirroring in real time and I felt quite confident with it. If you still want to deploy cross-region load balancing, you can use an open source tool such as HAPROXY, which operates on the same architecture as ELB.

Newvem Cloud Care reviews the status of your instances and identifies unhealthy or overloaded instances that are vulnerable to outages. Having a clear picture of your cloud availability will provide you with the knowledge and tools to protect your cloud from outages and vulnerabilities and make sure you meet your SLA commitments.

Configuration Costs

The ongoing costs depend on the instance type you select for the SQL Server. The witness server is required for the automatic failover configuration. I recommend that you select the option to choose a t1micro instance for the witness server because it only monitors the primary and mirror server; a t1.micro instance can be sufficient for this. You need to choose the primary and secondary servers based on the traffic coming to your application and server.

To calculate the monthly cost, use the Amazon price calculator. With regards to the data transfer costs I invite you to read the article “Control Your Amazon Data Transfer Costs”

More AWS How-to Guides

————————————————————

About the Author

Bhumish Shah

Bhumish is working as Freelancer with 2.5 years of experience in Amazon Cloud Services with EC2,S3,ELB,EBS,AutoScalling,CloudFront,Route53,SES and a total of 5 Years of experience in Linux , Windows Server , CCNA, Firewalls, Email Server , VMware Virtualization , Vmware ESX, Citrix Xen Server , Apache, LAMP Server etc. Read More

Keywords: elastic compute cloud, EC2 Instances, ELB, Elastic load balancer, MSSQL, IIS, AWS, Availability Zones, Amazon Cloud Regions, Amazon AWS console, best practices, high availability, EC2, Costs, SLA