Setup HAProxy as Load Balancer

In my previous post, I have explained about Nginx and HAProxy. We have also seen, where HAProxy wins over Nginx in the field of advanced load balancing. HAProxy ( High Availability Proxy), a fast and lightweight proxy server , and a load balancer is used by many big sites like Github, StackOverflow and others.

The scenario looks somehow like this :

HAProxy working in layer 4 TCP Mode, forwards the RAW TCP Packets from the client to the application server. In the layer 7 HTTP Mode, it parses the HTTP header before forwarding them to the application server.

Layer 4 TCP Layer Load Balancing

Let's start with HAProxy as a layer 4 Load Balancer. A load Balancer checks the information such as application ports & protocol (TCP/UDP) in this configuration. Basically, load balancer forwards this traffic based on this information using various load balancing algoriths such as round-robin.

Load Balancer will forward the user's request to the web-backend based on IP Range port. For example: If a request comes in for http://my-server.com/; the traffic will be forwarded to Application servers in a round-robin fashion or any others on port 80. Normally all the servers in the web-backend should provide the same content. That's why both web servers are connected to the same database. ( see layer 4 image above ).

Layer 7 Application Layer Load Balancing

At Layer-7, a load balancer has information about the application and based on this additional information, it forwards the traffic making more complex load balancing decisions. To determine which group of servers to forward a request to, the load balancer must analyze the HTTP request of each packet coming to match it against rules. With a protocol such as HTTP, a load balancer can detect cookies sessions and deliver to the target server. This server persistence using cookies can be based on the server’s cookie or by active cookie injection where a load balancer cookie is inserted into the connection.

Using layer 7 load balancing, resources are shared based on the content of the user's request. For example, if a user requests http://my-server-name/contacts , they are forwarded to the contacts backend ( as shown in the image above for /blog). Other requests are forwarded to the respective backends. However, all the backends share the same database server.

frontend http
   bind *:80
   mode http

   acl url_blog path_beg /blog
   use_backend blog-backend if url_blog

   default_backend web-backend 

acl url_blog path_beg /blog matches a request if the path of the user's request begins with /blog.

use_backend blog-backend if url_blog uses the ACL to proxy the traffic to blog-backend.

default_backend web-backend specifies that all other traffic will be forwarded to web-backend.

One useful benefit of "L7" like HAProxy is being able to use cookies to keep the same browser hitting the same backend server. This makes debugging client hits much easier. L4 balancing may bounce a single user around on several backend servers. (which in certain cases may be advantageous, but in a debugging/profiling sense, using "L7" is much more valuable.) EDIT: There's also a potential speed advantage of using HTTP balancing. With keep-alives clients can establish a single TCP session to your balancer and then send many HITs without needing to re-establish new TCP sessions (3-way handshake). Similarly many LBs maintain keep-alive sessions to back end systems removing the need to do the same handshake on the back end. Strict TCP load balancing may not accomplish both of these as easily. /* FWIW: I wouldn't say "L7" or "L4", I would say HTTP or TCP. But I'm a stickler for avoiding using the OSI to describe things it doesn't match up with well. */ I think fundamentally if you're not sure what to deploy, go with what feels simple and natural to you. Test it (use apache bench?) and make sure it works for your needs. To me HTTP LB is more natural. - Source: https://bit.ly/2EeMLHb

Note: Some texts/images here are referenced from digitalocean.com and KEMP.