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

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

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.