LVS(Linux Virtual Server) - Different Methods of Load Balancing

With the increasing growth of internet users, the volume of traffic that web based companies deal with has increased dramatically. There are different solutions to cope up with this increasing traffic. One solution is to scale your servers vertically(ie: Simply add more CPU and Memory Resources to your server.), which of course cannot be done after a certain extent.

Another solution is to scale the server horizontally(ie: Add more servers that can deal with the surge in traffic.). This mechanism is generally known as clusters. In a cluster, multiple servers act together as a single component providing the required services to end users.

When traffic/load increases, we can simply add more servers to the cluster, therefore it is more scalable.

In this article, we will be concentrating on different methodologies and schemes that can be used with Linux Virtual Server (LVS).  LVS is an open source project that was started way back in 1998, with the primary focus of building high availability, and load balancing solutions using clusters made up of commodity hardware.

As shown in the above figure, a typical LVS cluster is made up of a load balancer that sits in front and a group of servers sitting in behind (called Real Servers). The end user requests are first sent to the virtual IP address(VIP).

VIP or Virtual IP address is the address that is added as an A record for the service that the virtual cluster provides. The Primary job of the router(the Linux box shown in the Center of the above diagram), is to send the user's requests to the real servers. Hence, it is also sometimes called as a dispatcher.

There are different methods of sending requests from end users to the real servers. LVS has three different modes for servicing the requests. These are mentioned below.

• LVS VIA NAT (Network Address Translation) Related: What is Network Address Translation?
• LVS VIA IP tunneling
• LVS VIA Direct Routing

What is LVS VIA NAT ?

Linux Virtual Server via NAT is the simplest to configure. This is because there is no modification required on the real servers. The real servers can be any operating system that supports TCP IP stack. LVS via NAT is implemented using the IP masquerading technique in Linux. The request from the user first arrives at the virtual IP assigned to the front end Load Balancer. The Load balancer then does an investigation on the packet and modifies it with a destination address of the real server from the pool and forwards it to the real server.

Another important thing to note here is that the virtual IP (The IP accessed by the client, which is generally added as an A record for the domain name providing the service) is only assigned to the Load Balancer. The Real servers can have any Private addressing scheme.

Let's go through the series of events that happens when a request hits the front end Load balancer till the response is delivered back to the client.  To understand this series of events, lets consider an example request from a client to the virtual server and the final response that goes back to the client from the load balancer.  Below are the addresses that we will be using to understand this example.

Client Source Address: 183.83.214.214

Virtual IP (IP that is assigned to Load Balancer): 212.71.233.103

Real Server1: 10.1.10.1

Real Server2: 10.1.10.2

Step 1: User(183.83.214.214) sends a request for the required service to VIP assigned to the Load balancer(212.71.233.103). The request looks something like the below.

SOURCE ADDRESS(183.83.214.214)      ------->    DESTINATION ADDRESS (212.71.233.103)

Step 2: On receiving the request, the load balancer, checks the request destination and the port. If the request matches a particular service defined in the load balancer configuration, a real server from the pool(in our example, we have two real servers) is selected with the help of the selection algorithm. Once the Real Server is selected, the Load balancer notes down the connection information and the selected Real Server into a table and then modifies the packet's destination address and port (to that of the Real Server), and forwards the packet to the Real Server. Let's consider that the Real server that got selected is 10.1.10.1, in which case, the source and destination of the forwarded packet will look like the below.

SOURCE ADDRESS(183.83.214.214)      ------->    DESTINATION ADDRESS (10.1.10.1)

As the load balancer notes down the connection information (in a table) after the selection of the Real server, subsequent packets from the same connection will be simply rewritten with the already selected real server destination address(which can be found from the table)

Step 3: When the Load balancer gets the response packets from the Real Server, it again rewrites the source address and port to that of its own Virtual IP and service port. It then sends that response back to the user.

 SOURCE ADDRESS(212.71.233.103)      ------->    DESTINATION ADDRESS (183.83.214.214)

The end user is never aware of the Real Servers sitting in behind. The user always thinks that actual response is created and delivered by the Virtual IP address of the Load balancer.

The main advantage of LVS via NAT is that the Real Server's can run any operating system and only one single IP address is in use. The Disadvantage of LVS via nat is that the Load balancer does the rewritting of destination address twice to fullfil a single request.  Due to this rewritting, the Load balencer can run out of resources if the number of requests are high. The situation gets even worse, if the number of backend real servers are more in number.

What is LVS VIA IP Tunneling ?

LVS via IP Tunneling is a much better scalable solution compared to LVS via NAT. This is because of two primary reasons.

• The Load Balencer does not do the multiple rewriting of the IP packets.
• The Actual response is never sent via the Load Balancer.

The technique used here to send packets to Real Servers is IP tunneling . In the above shown diagram, an IP tunnel is established between the load balancer and all Real Servers.

Yet another important thing to note about LVS Via IP Tunneling is that, each Real Server must have a tunnel interface that has the Virtual IP address configured. The Real Servers can be either in the same LAN or can even be on a WAN network. This introduces another configuration change(if the Real server is on a complete different network) on the exit routers of the Real server, and it should be configured to accept outgoing packets with the Virtual IP address(this is because routers has a security measure to drop packets with source addresses, which is not part of its accepted list.).

The series of steps involved in fulling a request using LVS via IP tunneling is described below.

Step 1: The client sends the request to the Virtual IP address assigned to the Load Balancer. Here the source address will be of the client, and destination address will be the VIP assigned to the Load Balancer.

Step 2: The Load Balancer inspects the packet and in case it matches with the service rule defined, it encapsulates the packet inside another IP packet, and is then forwarded to a Real Server selected using the selection/scheduling algorithm. Here also the Load Balancer adds the connection information to a table, so that subsequent requests from the same connection can be encapsulated and sent to the same Real Server.

IP Tunneling is very much similar to a VPN(well without encryption). The Real Servers can have any IP address of any different network. But it should also have the Virtual IP address of the Load Balancer configured on a virtual interface. This means all the servers involved in LVS via IP tunneling method, should have the VIP assigned. This imposes another problem of ARP. The problem is if the client, and the LVS cluster's are all in the same LAN, Real server's should never respond back with ARP requests for Virtual IP addresses, else the client can mistakenly reach the Real server directly instead of going through the Load Balancer.

 

Related: Site To Site VPN Tunneling In Linux

This problem is solved by assigning the Virtual IP address in Real servers on non-arp interfaces like lo:0 or tun0 etc. 

The actual request is encapsulated inside another IP packet and is sent to one of the Real servers from the pool.

Step 3: The Real Server decapsulates the packet send by the Load Balancer, and reads the original packet from the client. The Real Server then processes the packet and sends the response directly to the client.

 

As the real server supports IP tunneling protocol, it decapsulates the packet and reads the original packet. On finding the Virtual IP(which is assigned to one of the non-arp interfaces on the Real server) in the destination field of the original packet, the Real server thinks "Yes..this packet is for me..!", and processes it and then sends the response directly to the client.

The main advantage of this tunneling method is the fact that the Load Balancer does not get overloaded with rewriting the packets. And a possible disadvantage can be the essential requirement of IP Tunneling Support on Real Servers.

What is LVS VIA Direct Routing ?

Although we have reduced the overhead of doing multiple packet rewrites using the second method, we still have an overhead of IP tunneling involved there. There is yet another method with LVS, that does not have neither the overhead of tunneling, nor the overhead of rewriting.

This method is called Direct Routing method. Its much similar to the second method in one aspect. Response will go from Real server directly to the user.

In this method also the Virtual IP is assigned and shared by the Load Balancer as well as the real server. As explained in the previous section, Virtual IP addresses are assigned to an interface that does not respond to ARP request(this is very important in this method, as the Load Balancer, and Real servers are all sitting in the same Physical segment.)

Step 1: As usual the client sends the request to the Virtual IP assigned on the Load Balancer. The load Balancer examines the request, and if a similar service configuration is found, it simply forwards the packet to a selected virtual Server. Similar to other methods, the load balancer also makes a not of the connection, so that subsequent packets from the same connection can be forwarded to the same Real server, by simply looking at the table.

Related: Understanding HTTP Request And Response

Well the only thing that load balancer modifies is the mac address. Once the Real Server is selected using the selection/scheduling algorithm, it simply modifies the frame with the mac address of the Real server and is forwards the fram on the LAN. This is the primary reason why Load Balancer and Real servers needs to be on the same LAN segment in this method.

 

Step 2: As the Real server has the same Virtual IP address configured on one of its non-arp interfaces, it accepts the packet and processes it. The response is then directly sent back to the client.

The main advantage of this method is that there is very less overhead involved. The only single disadvantage is the requirement of same LAN segment for Real Servers and Load Balancer.

Summary of Different Load Balancing schemes in Linux Virtual Servers