In my last post, I described the benefits of a load balancer. This post contains the step-by-step guide for load balancing two EC2 machines using the AWS console. The customer service I am load balancing is a Drupal CMS. I add a load balancer to help make the service operationally ready.
I am not doing anything with DNS. The new load balancer's URL is the exceedingly unattractive http://clb01-1234567890.eu-west-1.elb.amazonaws.com/.
Check the services.
Make sure both VMs are providing my new Drupal service.
- Open a web browser.
- View http://ec2-1-2-3-4.eu-west-1.compute.amazonaws.com/. The factory-fitted Drupal page appears.
- View http://ec2-5-6-7-8.eu-west-1.compute.amazonaws.com/. An identical Drupal page appears.
Both pages display a welcome message saying Welcome to ec2-1-2-3-4.eu-west-1.compute.amazonaws.com. 1-2-3-4? One of the machines should say 5-6-7-8, surely. Has anything gone wrong? Well, no. The page content was copied along with everything else when I cloned my original VM.
If I don't get these results, then I have some bug hunting to do. Is the firewall open? Is Apache running? Is MySQL running? If not, why not?
If I do get these results I am ready to load balance my service.
Create the load balancer.
- Open the AWS console.
- Find the load balancers section by clicking the Amazon EC2 tab, setting your Region in the drop-down list, and clicking on Load Balancers in the left navbar. The Load Balancers pane appears.
- Click the Create Load Balancer button. The load balancer wizard opens.
- On the Define Load Balancer page, I chose the name clb01, similar to my server names cms01 and cms02.
- On the Configure Health Check page replace the Ping Path /index.html with the forward slash character /. The default Ping Path won't work because Drupal doesn't provide an index.html page by default. If it's not good enough for usability guru Jakob Nielsen, it's not good enough for Drupal.
- On the Add EC2 Instances page, I added both my Drupal instances (Figure A).
- I hit the Create button on the Review page. A confirmation page appears.
- Click the View My Load Balancers And Check Their Status link. The Load Balancers pane reappears and now it shows my new LB.
- Find the DNS name of the load balancer. It looks something like clb01-1234567890.eu-west-1.elb.amazonaws.com. This is where all service requests will be sent.
The load balancer is now checking the health of each of my servers by using the Ping Path. Every thirty seconds it gets a copy of the home page. If one server fails to deliver the goods, the load balancer assumes it is sick and doesn't make it work.
Check the load balanced service.
#2 Look at Apache's activity log for each web server.
sudo su -
tail -f access_log
Each log shows many lines, identical except for the timestamp. These are the records of load balancer's health checks.
10.2.3.4 - - [31/Jan/2012:18:33:59 +0000] "GET / HTTP/1.1" 200 7583 "-" "ELB-HealthChecker/1.0"
10.2.3.4 - - [31/Jan/2012:18:34:29 +0000] "GET / HTTP/1.1" 200 7583 "-" "ELB-HealthChecker/1.0"
10.2.3.4 - - [31/Jan/2012:18:34:59 +0000] "GET / HTTP/1.1" 200 7583 "-" "ELB-HealthChecker/1.0"
#3 Go back to the web browser.
#4 Enter the URL http://clb01-1234567890.eu-west-1.elb.amazonaws.com/. The factory-fitted Drupal page appears. One of the logs goes crazy as dozens of extra records are written in it by Apache. That is the server that the load balancer handed your request to.
#5 Reload the page. The other log shows activity.
#6 Reload a third time. Now the action is back in the first log.
#7 Close the CLIs.
Load balancing is working correctly.
If this is a test run only and your credit card is on the line, you probably don't want to pay for resources you are not using. Delete the load balancer.
Nick Hardiman builds and maintains the infrastructure required to run Internet services. Nick deals with the lower layers of the Internet - the machines, networks, operating systems, and applications. Nick's job stops there, and he hands over to the designers and developers who build the top layer that customers use.