[Linux-cluster] LVS: Not as a gateway?

[Christopher Hawkins]

> -----Original Message-----
> From: linux-cluster-bounces at redhat.com 
> [mailto:linux-cluster-bounces at redhat.com] On Behalf Of 
> isplist at logicore.net
> Sent: Thursday, November 02, 2006 3:51 PM
> To: linux-cluster
> Subject: RE: [Linux-cluster] LVS: Not as a gateway?
> 
> Maybe someone who's running DIRECT and all of the same 
> internap IP's. can send me their lvs.cfg? I'm stumped.

>Yes, it's how I've got it set up. Only problem is, the web servers need to
see the LVS as their gateways no?

No. I'm not familiar with the redhat way of doing this, but I know LVS. So
if I trample on accepted redhat wisdom someone please correct me.... But
straight, cross-platform LVS works like this: The real servers do not even
need to know they are part of an LVS cluster. They can be setup like any
typical server providing a service, like httpd or whatever, and then they
get the virtual IP bound to their loopback interface so that they will
accept packets with that address. However, they do not respond to ARP
requests, therefore that IP can exist on all servers in this cluster and not
cause communication problems. Ie., if you were to ping that address, only
the director would respond. I have configured real servers before with just
these three lines of code:
ifconfig lo:1 $VIP netmask 255.255.255.255 up
echo 1 > /proc/sys/net/ipv4/conf/all/hidden
echo 1 > /proc/sys/net/ipv4/conf/lo/hidden

That's it. If a real server can accept packets addressed to the virtual IP
and does not respond to ARP on that IP, it's done, all set up. If nanny
requires more, then maybe there is more, but that's the guts of the LVS
stuff on real servers. 

The LVS director (and it's partner if there are two directors) accept all
packets that are sent to the floating IP, whether they get there by NAT
through a firewall, or directly from a machine on the same network, or
anywhere else. Say I want a web page from this cluster. I send an http
request to your floating IP. The director gets it, chooses a real server,
and then forwards the packet there. The real server serves the request and
replies directly to the client, using the virtual IP as the source in the
packet header, such that client never realizes that it dealt with more than
one machine. From the client side, it sent an http request to your virtual
IP (hypothetically) 10.10.10.9 which got accepted by the director and it got
a packet back from 10.10.10.9 (which is bound to the loopback on the real
server, so it can use that address as its source). And voila, a transparent
load balanced cluster. I can't answer a redhat specific question because I
don't know the answer, but maybe this will help you diagnose what is not
working. 

Chris