AWS News Blog
From Our Support Team: Elastic Load Balancing Tips and Tricks
|
A couple of members of the AWS Developer Support team put together the following tips and tricks to help you get the most from the Elastic Load Balancer.
— Jeff;
Are you thinking about using Amazon EC2 with Elastic Load Balancing, but want to make sure you set it up right the first time? Are you already using an ELB but are seeing intermittent problems with your page loads? Well, you’ve come to the right place! Let’s uncover a couple of common pitfalls. They’re easy to avoid, once you know about them.
For those of you who aren’t familiar, Elastic Load Balancing helps you distribute incoming network traffic across multiple Amazon EC2 instances. Your Elastic Load Balancer (ELB) will automatically route traffic to only the EC2 instances it deems to be healthy, so you needn’t worry about manually enforcing which instances handle the traffic. With ELB, it’s all manged for you. Furthermore, your ELB will also scale itself up and down to meet the demands of your traffic load. You can ensure that the EC2 instances themselves do the same by using Amazon Auto Scaling, but that’s beyond the scope of today’s discussion. You can read more about Auto Scaling here.
A key feature of ELB is that it will distribute incoming traffic equally across all of the Availability Zones you’ve configured it to use. This means that if you enabled, say, Availability Zones us-east-1a and us-east-1d, but only registered instances in us-east-1a, half of your traffic will go to us-east-1d, but there will be no EC2 instances there to handle it. The traffic will be redirected back to us-east-1a, but this redirection could increase latency for your users. Thus, you’ll want to keep track of which Availability Zones your ELB is set up to use. You can use the ELB API command line tools to do this:
elb-describe-lbs –show-xml
If you don’t already have the ELB command line API tools, then you can grab them here. Once you know which Availability Zones are enabled for your ELB, you can run this next command to see which instances are currently registered with your ELB:
elb-describe-instance-health Your_ELB_Name_Goes_Here
The command above will return the instance IDs of the registered instances, which you can then use to determine which Availability Zones each is in:
ec2-describe-instances instance_ID_1 instance_ID_2 …
You can glean a lot of potentially useful information at this point regarding each of the instances behind your ELB. Here are some things to check:
1) Does each enabled Availability Zone contain at least one instance registered with your ELB?
If not, you have two approaches to remedy the situation. The quick fix is to simply disable the empty Availability Zones:
elb-disable-zones-for-lb ELB_Name_Goes_Here -z Availability_Zone_Name_Goes_Here
The better fix is to register instances with your ELB in the empty Availability Zones:
elb-register-instances-with-lb ELB_Name_Goes_Here -instances instance_ID_5 instance_ID_6
Great, so at this point you should have at least one instance in each of your ELB’s Availability Zones. But could we still strengthen the setup even further? How about digging into the details of the individual instances behind your ELB? How robust is your configuration? This brings us to a second important item to check:
2) Do you have an equal number of instances in each Availability Zone? And are they the same type?
Since your ELB will distribute incoming traffic equally across your Availability Zones, you really don’t want to have, say, one m1.large instance in us-east-1a and five c1.medium instances in us-east-1d. The single m1.large instance will receive roughly 50% of all of your traffic and, under high traffic volume, may not be able to keep up. Meanwhile, your five c1.medium instances are each under a much lower load. This is definitely a suboptimal arrangement.
The ec2-describe-instances command above returned not only the Availability Zone of each instance but also its instance type. We suggest populating each Availability Zone with an equal number of instances of the same type. You may even want to check if they are all based on the same AMI. Cycling out older instances for replacements based on your most recent AMI will help ensure that your instances remain up-to-date and service requests in a consistent manner, and can simplify debugging in the future.
We hope this helps you understand Elastic Load Balancing. Do you have more questions? Post them to the AWS forums!
Update: George Cook left a good question as a comment. I took it to the leader of the ELB team and here’s what he told me:
Thank you for the feedback. You make some good points. Under certain failure modes, the behavior you described is the right thing to do, and that is on our roadmap. However, in other cases, it is still necessary to bounce traffic between Availability Zones. For example, it is possible that all instances in an Availability Zone become unhealthy (or get deregistered) while there are requests in-flight to that Availability Zone. The load balancer will then bounce these requests to a different Availability Zone in order to minimize any failed requests.