Load balancers work at different networking layers. The load balancer generally are the end point of the network packet. Once the packet reaches the load balancer, they perform SSL termination i.e. they decrypt the packet. The decryption is generally performed at the load balancer level and not at server, because decryption is an processor expensive operation. The content server’s resources are generally avoided for performing this intensive task.

L4 Load balancers

  • L4 load balancer work at the transport layer of the OSI model.
  • The load balancer’s IP is provided to the client through the DNS. It means that when the client does a look up for http://www.something.com, the IP address returned by the DNS is the IP of the load balancer of the webiste.
  • Once the packet from the client is recieved, the load balancer performes a Network Address Translation (NAT). The source IP of the packet is changed to the load balancer’s IP and destination address is changed from the load balancer’s IP to the content server it has chosen on the internal network.

    IP Packet:

    [src:”client address” dest: “load balancer”] \(\rightarrow\) [src: “load balancer”, dest: “webserver”]

  • Similary before forwarding the packets from server to client, it changes the src address from content server to its own.
  • L4 load balancer make routing decision based on the packet headers. They do not inspect the packet content.

L7 Load balancers

  • L7 load balancers work at the application layer of the OSI model. They predominantly work with the HTTP protocol.
  • They terminate the network traffic and read the content of the HTTP packet to make routing decisions based on the packet content like cookies, url etc.

Facebook Load blancers

  1. Initially we can think of a client sending https://facebook.com to DNS sever. DNS server provides the IP of the HHVM server(php Server). The client directly connects to the HHVM server. The Request per Second (RPS) is quite low.
  2. As the clients increase, we put an L7LBs between DNS and HHVM server to increase the RPS. The TCP SSL connection terminates at L7LBs. The L7LBs consistently hash the client request to a HHVM server.
  3. To further increase the RPS, L4LBs are added infront of L7LBs. The L4LBs consistently hash the client’s request to L7LBs. The TCP connection is maintained by the L4LBs.
  4. To further increase the RPS, a router is added in front of L4LBs. The router connects to consistently hashed L4LBs using ECMP. The system now look like

    Cluster: [Router \(\rightarrow\) L4LBs \(\rightarrow\) L7LBs \(\rightarrow\) HHVM]

  5. As router is a single point of failure, the clusters are replicated in different data centers for redundency and avoid single point of failure.

Resources

  1. https://www.nginx.com/resources/glossary/layer-4-load-balancing/
  2. https://www.nginx.com/resources/glossary/layer-7-load-balancing/
  3. https://www.nginx.com/resources/glossary/reverse-proxy-server/
  4. Facebook Load Balancers, Summary
  5. Github Load Balancers: Link 1, Link 2