4. Collect Hardware

4.1 minimum setup

You will need a minimum of 3 machines (you can do it with 2, but this doesn't demonstrate how to scale up an LVS farm, read localnode to see how this is done).

You need

• Director: running Linux patched kernel 2.2.x or 2.4.x (VS-NAT is still in development for 2.4.x, in Feb 2001, check on the mailing list for latest info).
• Client: any machine, any OS, with a client for the service (eg netscape, fetch/xterm/...)
• Real-server(s)
  • VS-NAT - any machine, any OS, running some service of interest (eg httpd, ftpd, telnetd, smtp, nntp, dns, daytime ...)
  • VS-Tun - real-server needs to run an OS that can tunnel (only Linux so far).
  • VS-DR - OS known to work are listed in VS-DR

4.2 Gotchas

You need an outside client.

The LVS functions as one machine. You must access the LVS from a client that is NOT a member of the LVS. You cannot access an LVS controlled service (eg http, telnet) from any of the machines in the LVS; access from the director will hang, access from a real-server will connect to the service locally, bypassing the LVS.

Minimum 3 machines: client, director, real-server(s)

4.3 Test with telnet (or netcat)

All testing of your LVS should be done with telnet. Telnet has

• a simple client (available on all OSs)
• a simple protocol (one port)
• exchanges are all ascii (can be watched with tcpdump)
• non-persistent connection (you can test round robin scheduling)
• telnetd usually listens to all IP's on the server (i.e. to 0.0.0.0) at least under inetd
• most importantly, when you get a connection, you'll see an entry in the ActConn column of the output of ipvsadm.

For security reasons, you'll be turning off telnet later, but whenever you're testing your LVS or your new service, always look to see if telnet works if you're having trouble. If telnet is not being LVS'ed then you should go back and fix that first.

Another useful client is netcat. See examples using netcat as a client with ftp.