The LVS' (Linux VIrtual Server) project was launched in 1998 and is meant to eliminate Single Point of Failures (SPOF).

"LVS is a highly scalable and available server built on a cluster of real servers, with the load balancer running on Linux. The architecture of the server cluster is fully transparent to the end user, and the users interact as if it were a single high-performance virtual server. The real servers and the load balancers may be interconnected by either a high speed LAN or by a geographically dispersed WAN."

The load balancer is the Single entry point into the cluster. The client connects to a single known IP address, and then inside the virtual server the load balancer redirects the incoming connections to the server(s) that actually does the work according to the scheduling algorithm chosen. The nodes of the cluster ( real servers) can be transparently added/removed, providing a high level of scalability. The LVS detects node failures on-the-fly and reconfigures the system accordingly, automatically, thus providing high availability. Theoretically, the load balancer
can either run IPVS or KTCPVS techniques for load balancing. but owing to a VEry high stability ofIPVS, it is used in almost all the implementations I have seen. See the sidebar titled "IPVS v / s KTCPVS" for a brief note on the differences between the two. IPVS provides Layer 4 load balancing and KTCPVS provides Layer 7 load balancing (see the sidebar).
There are three load balancing techniques used in IPVS:
•LVS/NAT - VIrtual Server via NAT
•LVS/TUN - Virtual Server via Tunnelling
•LVS/DR - Vrrtual Server via Direct Routing A brief overview of these techniques can be found in the sidebar titled 'IPVS Load Balancing Techniques'.
Since our real servers are located in two different data centres, we will be focusing on LVS/TUN.

Name: Linux virtual server.jpg Views: 597 Size: 40.9 KB

Installing and configuring IPVS
Please note that the set-up explained here should only be used as a guideline and
for an understanding of how IPVS works. Networking scenarios are different for every case and may demand extra reading and experimentation before getting a working set-up. My advice is that before trying this out in the field, make sure enough experiments have been done in the laboratory. Also, it is advisable to read through the documents in the References section at the end of the article.

The kernel module ip _ vs and ipip may need to be loaded. but in my experience. these modules were automatically loaded when I used the ipvsadm command.
To start with. we will consider a scenario that has two data centres. There is one LVS load balancer in each data centre. For the sake of giving them names. we will call them ipvslbll and ipvslb21. Now we will configure the IPIP tunnel between the load balancers and the real servers-rproxyl and rproxy2. where rproxyl is in the first data centre and rproxy2 is in the second.

The various options used with ipvsadm are:
•-A adds a virtual server
•-a adds a real server
•-t specifie that the virtual server is a tcp service
•-s is a scheduling method
•-r represents the real server
•-i is an option which specifies that an IPIP tunnel is to be used. IPVS will generate the IPIP packets on its own
You can view the IPVS configuration using the -L option with the ipvsadm command. The -n option saves some DNS look-up time in case the real servers do not have a DNS or host file entry.