LVS homepage Go to the "software" link. Get the latest patch tarball for the director (available in 2.2.x and 2.4.x flavors). This will contain the kernel patch and source code for various programs and utilities.
You have to patch the standard kernel with the matching ipvs patch.
The director operates in one (or several) forwarding methods; VS-NAT (network address translation); VS-DR (direct routing) and VS-Tun (tunneling). The mode is chosen individually for each real-server/service by ipvsadm.
The director code is well tested on Intel. As well several people
are running on Alpha hardware (Flavio Pescuma
edtfopa@malmen.ericsson.se on a mailserver, and Philip Copeland
copeland@redhat.com who is using it alongside an Intel director
to test director failover).
You have to edit the code to run it on Alpha: from Philip (this has been fixed in recent code).
>remember use socklen_t NOT size_t for network calls (See
>page 27 of R.Stevens UNIX Net. prog. vol1 ed 2) and everything
>suddenly falls into place. Certainly socklen_t is the correct
>type to use for portability between 32/64 machines, you'll
>need to update any other code to use socklen_t thats 64 bit
>eg ia64 sparc64 etc
The real-servers must be configured appropriately for the LVS forwarding method. You must
Here's this list of OS's that have been tested with the forwarding methods. (we expect all OS's can be made to work one way or another.)
ratz@tac.ch)
The arp theory can be skipped on a first read. You'll need to understand this to set up a working LVS. Here's the summary:
IF (
(you are using VS-DR or VS-Tun on the director)
AND
(you are running a Linux 2.2.x, 2.4.x kernel on a real-server)
AND
(
the VIP on the real-server is on an ethernet device eg lo:0, tunl0:0
i.e. is not being accepted by transparent proxy
)
AND
(
the real-servers can answer arp requests from
the client/router (the real-servers are on the same
piece of wire|network as the director)
)
)
THEN
{
YOU MUST HANDLE THE ARP PROBLEM
}
FI
In general you'll have to handle the arp problem.
The most common way to handle the arp problem is to hide the VIP from arp requests
Although not used very much (I don't know why), another simple method is to put an extra NIC into the real-servers for the VIP and not connect it to the network. The NIC doesn't handle any packets, it's just a way of putting the VIP onto the real-server. The NIC can be an old 10Mbps ISA card. The cost of some 100Mbps PCI tulip cards now is less than the salary you'd pay for the time to recompile a 2.4.x kernel with the hidden patch.
All methods of handling the arp problem work, have about the same performance (throughput, latency) and are about equally easy/difficult to setup.
The method of hiding the devices from arp requests is the closest to the standard NOARP unix behaviour and is the method most commonly used on Linux real-servers.
You can set up the LVS by hand with ipvsadm. This is somewhat tedious and error prone. While do-able for a single LVS configuration, this is not the way to go for setting up lots of different LVS configurations. Some configure tools are available.
The configure script was designed to set up LVS's quickly so I could do testing. The current version (0.8) does a wide range of checks, hopefully catching the usual errors. This only sets up a single director and cannot handle director failover. For director failover try Ultra Monkey. The configure script uses mon to handle failure of services on real-servers.