We need more information than this. For suggestions look at the information needed to solve problems.
The usual mistake is to have the default gw for the realservers set incorrectly.
Setting up an LVS by hand is tedious. You can use the configure script which will trap most errors in setup.
You have to debug your setup. If you have first setup a simple LVS using the mini-HOWTO and now you have your particular setup which doesn't work then:
First take your realserver offline (pull the network cable) and start the service listening on RIP:port (LVS-NAT) or VIP:port (LVS-DR, LVS-Tun). Note: no matter what service you'll run in production, as a test telnet is a much easier service to debug. I know you want your try out your superduper shockwave webserver with java applets, but you can get that to run later. Try with telnet first OK? It will save you a round of questions on the LVS mailing list.
Check that the service (initially telnet) is running (netstat -an). Connect to the service from a simple client running on the realserver (eg telnet VIP 80, lynx VIP). Then use your usual client (a web browser say). Make sure your service can do all the things that you expect the client on the internet to be able to do.
Then connect the realserver to the LVS network and set its default gw (to the DIP for LVS-NAT, to the router for LVS-DR,LVS-Tun), add the VIP:services to the director with ipvsadm (or the configure script) using rr scheduling. Check that ipvsadm shows your realserver:service.
Make sure you have no firewalls between the client and the LVS, otherwise all bets are off.
Then connect to the VIP:service from a simple client (e.g. telnet VIP port), check that you can get to all the realservers one by one (watch on the director with ipvsadm). Then use your usual client for the service (eg a webbrowser).
Usually you have problems with authd/identd. Simplest thing is to stop your service from calling the identd server on the client (i.e.disconnect your service from identd).
There isn't a simple answer.
The speed of the director is determined by the packet throughput from/to the clients and not by the number of realservers. From the mailing list, 3-500MHz UMP directors running 2.2.x kernels with the ipvs patch can handle 100Mbps throughput. We don't know what is needed for 1Gpbs throughput, but postings on the mailing list show that top end UMP machines (eg 800MHz) can't handle it.
For the complicated answer, see the section on estimating director performance.
Enough for the machine to boot,i.e 486CPU, 8M memory, no disk.
yes. For LVS'ed services, the director handles ICMP redirects and MTU discovery delivering them to the correct realserver. ICMP packets for non-LVS'ed services are delivered locally.
This means that no service is listening for your client's requests and that some machine at the end is replying that it is not listening for that service. Possibly
The LVS is acting like a single machine which doesn't have the service running.
LVS is kernel code. In particular the network code is kernel code. Kernel code is only SMP in 2.4.x kernels. To take advantage of SMP for LVS then you must be running a 2.4.x kernel.
Michael Brown michael_e_brown@dell.com
wrote on 26 Dec 2000
I've seen significant improvements using dual and quad processors with 2.4. Under 2.2 there are improvements but not astonishing ones. Things like 90% saturation of a Gig link using quad processors. 70% using dual processors and 55% using a single processor under 2.4.0test.
I haven't had much of a chance to do a full comparison of 2.2 vs 2.4, but most evidence points to >100% improvement for network intensive tasks.
LVS is all kernel code. It's hard enough to write for one kernel. No-one is contemplating porting LVS to any other OS's.
One person offered to translate the HOWTO into Italian a long time ago and I haven't heard from him since. Another person recently (May 2001) offered to translate it into Japanese. From the number of Japanese HOWTO's I find in google searches, I'd say there is a good chance of having a Japanese HOWTO sometime.