> -----Original Message----- > From: linux-cluster-bounces@xxxxxxxxxx > [mailto:linux-cluster-bounces@xxxxxxxxxx] On Behalf Of > isplist@xxxxxxxxxxxx > Sent: Thursday, November 02, 2006 3:51 PM > To: linux-cluster > Subject: RE: 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 -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
