Making applications scalable with Load Balancing
Why this articleAs the author of the HAProxy Load Balancer, I'm often questionned about Load Balancing architectures or choices between load balancers. Since there is no obvious response, it's worth enumerating the pros and cons of several solutions, as well as a few traps to avoid. I hope to complete this article soon with a deeper HTTP analysis and with architecture examples. You can contact me for further information. This document is now available as a PDF file :
IntroductionOriginally, the Web was mostly static contents, quickly delivered to a few users which spent most of their time reading between rare clicks. Now, we see real applications which hold users for tens of minutes or hours, with little content to read between clicks and a lot of work performed on the servers. The users often visit the same sites, which they know perfectly and don't spend much time reading. They expect immediate delivery while they inconsciously inflict huge loads on the servers at every single click. This new dynamics has developped a new need for high performance and permanent availability.
What is load balancing ?Since the power of any server is finite, a web application must be able to run on multiple servers to accept an ever increasing number of users. This is called scaling. Scalability is not really a problem for intranet applications since the number of users has little chances to increase. However, on internet portals, the load continuously increases with the availability of broadband Internet accesses. The site's maintainer has to find ways to spread the load on several servers, either via internal mechanisms included in the application server, via external components, or via architectural redesign. Load balancing is the ability to make several servers participate in the same service and do the same work. As the number of servers grows, the risk of a failure anywhere increases and must be addressed. The ability to maintain unaffected service during any predefined number of simultaneous failures is called high availability. It is often mandatory with load balancing, which is the reason why people often confuse those two concepts. However, certain load balancing techniques do not provide high availability and are dangerous.
Load balancing techniques
1. DNSThe easiest way to perform load balancing is to dedicate servers to predefined groups of users. This is easy on Intranet servers, but not really on internet servers. On common approach relies on DNS roundrobin. If a DNS server has several entries for a given hostname, it will return all of them in a rotating order. This way, various users will see different addresses for the same name and will be able to reach different servers. This is very commonly used for multi-site load balancing, but it requires that the application is not impacted to the lack of server context. For this reason, this is generally used to by search engines, POP servers, or to deliver static contents. This method does not provide any means of availability. It requires additional measures to permanently check the servers status and switch a failed server's IP to another server. For this reason, it is generally used as a complementary solution, not as a primary one.
$ host -t a google.com google.com. has address 184.108.40.206 google.com. has address 220.127.116.11 google.com. has address 18.104.22.168 $ host -t a google.com google.com. has address 22.214.171.124 google.com. has address 126.96.36.199 google.com. has address 188.8.131.52 $ host -t a mail.aol.com mail.aol.com. has address 184.108.40.206 mail.aol.com. has address 220.127.116.11 mail.aol.com. has address 18.104.22.168 mail.aol.com. has address 22.214.171.124 mail.aol.com. has address 126.96.36.199 mail.aol.com. has address 188.8.131.52 mail.aol.com. has address 184.108.40.206 mail.aol.com. has address 220.127.116.11 mail.aol.com. has address 18.104.22.168 mail.aol.com. has address 22.214.171.124 mail.aol.com. has address 126.96.36.199
[ 1/10 ] >>>