LVS (Linux Virtual Server) is a set of utilities and patches for the Linux kernel that allows the creation of a single virtual server from multiple nodes, all in load balancing and high availability by eliminating the weaknesses of the infrastructure ( SPOF ) If a node falls, in fact, the service is not interrupted.

With this system the end user will connect to a service (HTTP, FTP, DNS, VoIP, etc …) as if it were hosted on a single server, when in fact there is a whole infrastructure behind the operation of that service, and management of the latter is entrusted to its LVS that deals with requests for it to route to each node and will actually process the request and return the result, all following one of many sorting algorithms implemented in LVS .

The scalability of this system is achieved through the ability to increase or decrease necessary knots, no need to interrupt services, the same thing for high availability when the system detects a malfunction of a demon or a whole, this node is temporarily removed from the nodes available in which it process the requests.

Operation And Forwarding Methods

Let’s see how LVS works in detail. LVS operates through three-layer architecture ( tier-three architecture ) :

The load balancer (obviously redundant) that receives requests from users and redistributes them to various nodes that make up the cluster, also monitors the proper functioning.

All the servers that make up the cluster (nodes) and that process actual requests that are forwarded by the load balancer (for example, can return a web page).

A shared, centralized storage so that data is uniformly available from all nodes at the same time, then without any discrepancies.

The Load Balancer Can Route Requests In Three Different Ways:

Virtual Server via NAT (VS / NAT) : With this method all requests from load balancers (both incoming and outgoing), go to the next chapter to describe in detail all the steps.

When a user accesses a web service managed by cluster, the load balancer receives a packet on the IP of the virtual cluster.

At this point the load balancer examines the destination address and port of the package, if they correspond to a virtual service in the rules of table of the virtual servers ( virtual server rule table ) is selected physical server to which it process the request according to a certain scheduling algorithm and the connection is added to the hash table of connections. At this point, the destination address and port are rewritten by the load balancer to be sent to the physical server selected above.

The request is finally processed by the physical server.

When the response packet is sent back, the load balancer rewrites the source of IP changing from one physical server cluster virtual IP.

The end user receives the result, and once the connection is terminated (or has gone out) is deleted from the respective hash table of connections.

Virtual Server via IP Tunneling (VS / TUN) : Unlike the method VS / NAT in this case, the load balancer sends the package containing the client request to the server via IP tunneling and the physical server, once processed the request, send it directly to the client without going again from the load balancer. This technique is used primarily for geographical clusters.

Virtual Server via Direct Routing (VS / DR) : This method assumes that the load balancer is physically connected with all the physical servers (such as through a network switch). The cluster’s virtual IP address will be shared by the load balancer and all the dedicated server through a network interface (aka, non-arping and loopback) configured with the cluster virtual IP and load balancer will have a standard interface to receive all requests from the outside. Upon receipt of a package, the load balancer will change the MAC address of the destination of choice for physical server data processing and once processed, the physical server will send the response directly to the client.

Balancing Algorithms

Now that we have analyzed the different methods of forwarding the requests, let’s see what are the different algorithms for balancing that we can use with LVS.

Static :

– Round Robin
– Weighted Round Robin
– Destination Hashing
– Source Hashing

Dynamic :

– Least-Connection
– Weighted least-connection
– Never queue
– Locality-based least-connection
– Locality-based least-connection with replication scheduling
– Shortest expected delay

For convenience I will use the description of algorithms, then we will begin with the classic Round Robin and its variation ( Weighted Round Robin ).

This algorithm works by simply changing the physical server to send the request to each of them, gradually . So if you arrive at the required load balancer and 4 had 3 physical servers currently running in cluster, the first request would be forwarded to the first physical server, the second to second, the third to third and fourth again at the first.

The Weighted Round Robin can manage the priority of physical servers, giving a different weight , so if we bought a new server that is supposed to be the most powerful of the old and thus able to process more requests than others, we can give it a chance higher than the requests that are sent to this new server from load balancer. For example if we had three physical servers in the cluster, two of which are less powerful and a more powerful server may assign to the two less powerful than a priority of 30% each, and the more powerful server as a priority by 40%.

The scheduling algorithm least-connection to check which server has the least number of active network connections and forwards the new request to the server that has not, unfortunately, however, is efficient only if all servers have the same power.

The scheduling algorithm shortest expected delay is based on the calculation of how could the server process the request more quickly , this calculation is given by (total connections +1) / (power on the server). Again the power of the server is given the weight that has over the others.

All for now, do not miss the second part of this article that will focus on ‘high availability’.