Amazon Elastic Load Balancers (ELB)

Setting up  Load Balancers inside the Amazon Cloud is deceptively easy but there are a number of 'gotchas'. First, they are called 'elastic load balancers or ELB'. They are also software load balancers of an unknown capacity.There's been some talk on how scalable they really are though I have lost track of the news item that stated this.

Like trying out anything new, I decided to have a delve around for the documentation, just to be sure that what I had in mind would work and oddly, I found this time round that the normally excellent Amazon Web Services documentation was a wee bit sparse. However, the GUI to set up a load balancer looks easy so I decided it probably wasn't too difficult. I also discovered that the GUI tool as provided in the AWS console was not available when this service first came out and all of the work had to be done by command line. I love command line so I read up on it too. So can you here in a nice blog post by Steve Evans.

As ever, I sketched out what I am trying to achieve: a simple website running on two (or more) instances behind a load balancer supporting HTTPS. I will also need to attach a much more memorable name (e.g. loadbalancer.esriuk.com)  to the DNS of the load balancer (currently something like: mytestloadbalancer123-678076149.eu-west-1.elb.amazonaws.com ) in order to make the site easier to use. This is the CNAME as explained in a previous post.

Creating the servers or instances

First step is to create the two instances and I opted to go for the small instances. They're cheaper and for my testing, perfectly adequate for the work in mind. I created one instance (server-01), installed IIS7 on it, patched and slapped on an anti-virus software on it and then took a snap-shot of it. This snap-shot creates an AMI file which I then used to create a second instance, indeed an almost identical copy of the server-01. Very useful. 

Once I had two instances running, I made sure that each one was functioning properly. Tests were done to see that IIS on both of the instances were working. I subtly changed the default landing page on one of the IIS instances to help me differentiate between the two. 

 

The 'secure 2' was part of the HTTPS test and also helped me to remember that we were on a new page.

Creating the Elastic Load Balancer

IMPORTANT!

Now before you even start the creation of the ELB, one needs to decide what protocols are to be used. Obviously, one would want HTTP (80) to be allowed through the load balancer and this is the default but if you want to load balance HTTPS (443) or some other protocol / port - these have to be defined during the creation of the ELB. One cannot add extra protocols / ports once the ELB has been created. It is a one-step process. 

The ELB I need must support HTTP and HTTPS so these had to be defined during the ELB creation stage. HTTPS is called ' Secure HTTP server'. When this is option is selected, the other options are automatically filled in though don't worry that the protocol drop-down still says 'HTTP'; the port changes to '443' - the well-known port for HTTPS so all is well. Am sure that the protocol drop-down error is a bug and a minor one at that. One can also see that you can also re-direct incoming traffic on a particular port (e.g. 80) to a specific one on the EC2 instances. This makes the 

The rest of the process is quite straight forward; though one should spend a bit of time understanding the instance health checks that the ELB will employ to ensure that it does not redirect traffic to a 'dead' or unresponsive instance. 
 

Instance Health Checks

The ELB is quite smart in that it needs a way to check that the instances it is redirecting traffic to are online and valid traffic should still be routed to them.  Otherwise if an instance died (or was accidentally switched off) the load balancer would still continue to route traffic to it, oblivious to the instance's 'dead' state and this would cause partial downtime. What's worse, it could be quite intermittent with one out of every two pages (for example) returning with a '404' error message. 


So how does the ELB work? It does it simply by checking a specific file, usually a web-page file on a set schedule to ensure that the instance is healthy.

There are six parameters that one needs to be configure: 

'Protocol' - you can use either HTTP or TCP as the protocol of choice. 
'Target' - this is the file that the ELB checks to ensure it is all OKAY, usually it will be a simple web-page such as the default.htm file.
'Interval' - this is how often the ELB will perform the above health check.

'Timeout' - this is how long to allow the instance to respond to the health check before a failure is recorded.
'Unhealthy threshold' - is the number of *consecutive* failures before the ELB marks the instance as 'failed' and 'OutOfService'.

'Health threshold' is the number of successful checks before the ELB marks the instance as 'working' and 'InService' 

Create CNAME Record for ELB Instance 

When an ELB instance is first created, AWS provides you a public DNS name. It is unique but quite long and difficult to remember. Much better to have something a bit friendly for it. To do this, you will need to create a CNAME record in DNS to redirect the friendly URL to this DNS name. I blogged about this in my previous post.