Load Balancing IIS Web Farm on Amazon EC2

I was recently asked about load balancing IIS web farms in Amazon EC2.  In a traditional web farm (meaning hardware in a datacenter) you would do one of the following:

  • Windows Load Balancing Service (WLBS)
  • Hardware Load Balancer (F5, CoyotePoint, etc)

Windows Load Balancing Service is nice because it does not require any extra equipment to function.  The members of the IIS farm share a virtual IP address and they sort out between themselves where to route the incoming requests to.

Some people prefer a hardware load balancer over WLBS because it provides better performance.  However Microsoft uses WLBS for Microsoft.com so I question how relevant that argument is.

Other Cloud Providers

Before we talk about what to do in EC2 for I wanted to point out how other cloud offerings provide a load balancing solution.

GoGrid provides you access to F5 load balancers.  Through their web based management console you can create a load balancer, list the IP’s of your web servers to load balance, and they handle it all for you.  The best part is that the load balancing offering is 100% free.

Microsoft Azure and Google App Engine abstract away the load balancing issues.  One of the biggest benefits of these types of cloud offerings is that in exchange for giving up some control you get some simplicity.

EC2 and Load Balancing

When talking about EC2 and load balancing the first thing I should mention is that Amazon announced in October of 2008 that they will be offering a load balancing solution built into EC2 (http://aws.typepad.com/aws/2008/10/big-day-for-ec2.html).  I do not know when Amazon will actually release that functionality.  However when you go to the AWS Management Console the “Coming Soon” sidebar lists Tagging and then Monitoring, Load Balancing, and Auto-Scaling.  It seems logical that you’ll need to be able to group your server instances before they can provide load balancing.  So my guess is that load balancing will come after tagging. Assuming Amazon provides a useable and cost effective solution then all of our issues on this subject go away.

Why WLBS Doesn’t Work for EC2

WLBS Diagram

If your looking to use the Windows Load Balancing Service (WLBS) with EC2 you are out of luck.  The easiest way to explain why is to show how WLBS works.

Here you can see that each node of the web farm has it’s own IP address.  These machines are directly accessible via their own address’s.  They also share a virtual IP address (10.0.0.1 in the example).  The DNS entry for the website (www.website.com) points to the shared IP address, so the users incoming requests are received by the virtual IP address, and WLBS directs those TCP packets to one of the web servers.

The problem with EC2 is that the public Elastic IP’s are only able to associate with a single server instance.  As you can see from how WLBS works all of the servers in the farm need to be able to receive packets destined for the virtual IP address.

Alternatives to WLBS

HAProxy Diagram

Alternatives to using WLBS on EC2 involve quite a bit of work and some money, so Amazon providing the service in the future is very attractive.

The most common way to load balance EC2 instances is to have a front-end Linux server running HAProxy.  The problem is you’ll need a separate Linux instance in addition to your web farm.  A small Linux instance is $27/month for a reserved instance or $72/month for on-demand.  Not a deal breaker, but an added expense.  And since you’ll need a second load balancer to monitor the availability of the primary load balancer you’ll need to double those prices.

I’ll post detailed instructions on how to configure this setup in the future.  The basic steps are:

  1. Bring up instance of a Linux server using an ElasticIP
  2. Install haproxy by running: “apt-get install haproxy”
  3. Modify /etc/default/haproxy; change setting ENABLED to 1
  4. Modify /etc/haproxy.cfg to something along the lines of this file.
  5. Restart the haproxy service (service haproxy restart)
  6. Include a file in the root of each webserver called check.txt. If the load balancer can not read this file it will not direct clients to that web server.
  7. Configure your DNS records to point to the ElasticIP address from step 1.

This will get you a non-failover load balancer solution in place.  When I write a detailed post on configuring the load balancer I’ll include instructions on doing the failover steps.

Conclusion

The more I delve into cloud technologies the more I like solutions like Azure or Google App Engine.  We just touched on load balancing, and I barely scratched the surface and it’s already a fairly complicated issue.  You still have to solve the issues of patching, scaling up and down, monitoring, etc, etc.  The Azure/Google App Engine model takes all those issues away from you (or at least greatly simplifies).

However the toolsets and features of Amazon Web Services continues to improve.  For example if Amazon release a good load balancing solution that will be a huge win.  Amazon also gives you a lot more flexibility.  You’re not limited to using programming languages supported by other solutions.  You can treat Amazon almost like a traditional data center, install 3rd party software, etc, etc.  You also can arguably migrate from EC2 to your own hardware more easily than you can from other cloud solutions.

Ultimately where you decide to host your application involves a lot of factors.  Hopefully your load balancing options (as well as seeing the pain involved) on EC2 helps you make the decision that is right for you.

Advertisements

9 thoughts on “Load Balancing IIS Web Farm on Amazon EC2

  1. I have not played with EC2 yet, but I would imagine you could also use Windows Server Routing & Remote Access to provide a router front-end for your load balancer. If you are going to run windows servers in with NLB, you most likely are going to need a domain controller. Your domain controller machine could second as a router and could work as follows:

    Create a Domain Controller

    Install Routing and Remote Access (RAS) with VPN

    Install RAS on all of your Web Servers with VPN and setup a two-way constant VPN between the web servers and the domain controller. This would create a local network and provide each of the Web Servers with an internal IP (ex: 192.168.25.X).

    Add an additional internal IP to the Web Server nic.

    Setup NLB using a shared internal IP across all web servers

    Set you domain names DNS to point to your Domain Controllers Public IP Address

    Set Routing and Remote Access to route all connections on port 80 & 443 to your internal NLB load balancer IP. This would cause all web traffice to get routed to the internal address of the Windows Network Load Balance.

    Again, I have not tried this scenario. However, I believe it would work as long as you can assign multiple IPs to your VMs NIC. Another drawback is that this has a single point of failure (Domain Controller), although that could be adressed.

    Let me know if you get a chance to try it 🙂

    Great Article by the way!

    Like

  2. Excellent post. Curious if you’ve had a chance to get anything documented on more detailed steps to setup HAProxy in EC2?

    Like

  3. Pingback: Shima Root » Balanceamento em uma Cloud EC2 da Amazon
  4. I’ve just come across your site regarding Cloud Computing and Virtualization. There is some good information and we may be interested in including you in our blog. Please feel free to contact. Cheers

    Like

  5. Good Site on Cloud Computing and SaaS – We are periodically looking for good blog information
    related to Rackspace Cloud. Also we are looking for contributors to add value to our blog.

    Keep up the good work!

    Thanks

    Like

Comments are closed.