Testing LVS

Once an LVS cluster is running, any attempt to connect to a service's VIP address (via browser or telnet for example), should result in that connection being answered by one of the real servers. Which real server will depend on the scheduling tool being applied.

The following commands are useful for testing or debugging an LVS setup:

• ping — A real server should be able to ping any system on the public network, while only the active LVS router should be able to ping a real server.

• telnet <ipaddress> <port> — Using telnet to connect to a virtual server VIP address should result in a real server responding to that attempt.

• ipchains -l — Lists the currently defined rules for forwarding ip messages.

• ps ax — When done on the active LVS Router, the pulse, lvs, and nanny daemons should all appear in the list. When done on the backup router, only pulse will be shown.

• ipvsadm -l — when done on the active LVS router, will list all the active services running on real servers, along with their scheduling method and weight.

• lynx — lynx is a text-based web browser and can be useful for testing the load balancing of the real server services. For example:

  1. Create or modify a web page on each real server that identifies which real server the page resides on. The best type of page is one that just displays a message like "This is real server #1", with no other content. The page should also include a very large comment section (a few KB worth of comments) that will add bulk to the page loading without affecting the display.

  2. On the active LVS router, execute the following command:

     while true; do lynx -dump nnn.nnn.nnn.nnn; done

     where nnn.nnn.nnn.nnn is the VIP address for the real server's web service.

  3. If load balancing is functioning, you should see the display alternate between "This is real server #1", "This is real server #2", and so on.

     While lynx is running, use the ipvsadm -l command to examine the current status of the services and their scheduling weight.