LocalNode: Using the Director as a Real Server

When you build an enterprise-class cluster, you will need to decide whether you want to dedicate two Linux servers to be the primary and backup LVS Directors. For the moment, however, you can test to make sure the load-balancing function is working properly (regardless of what your final design configuration will be) by configuring and installing Apache on the Director (as described in the "Step 2: Configure and Start Apache on the Real Server" section of this chapter) and then configuring your Director to send client computer requests to this locally running copy of Apache as if the Director were also a node inside the cluster. This configuration is called LocalNode or LocalNode mode.

Note 

A limitation of using a LocalNode configuration is that the Director cannot remap port numbers—whatever port number the client computer used in its request to access the service must also be used on the Director to service the request. The LVS HOWTO describes a workaround for this current limitation in LVS that uses iptables/ipchains redirection.

Assuming you have Apache up and running on the Director, you can modify the /etc/init.d/lvs script on the Director so two cluster nodes are available to client computers (the Director and the real server) as follows:

 # Add an IP virtual service for VIP 209.100.100.3 port 80 /sbin/ipvsadm -A -t 209.100.100.3:80 -s rr # Now direct packets for this VIP to # the real server IP (RIP) inside the cluster /sbin/ipvsadm -a -t 209.100.100.3:80 -r 10.1.1.2 -m # And send requests to the locally running Apache # server on the Director. /sbin/ipvsadm -a -t 209.100.100.3:80 -r 127.0.0.1 -m 

The last two uncommented lines cause the Director to send packets destined for the 209.100.100.3 VIP address to the RIP (10.1.1.2) and to the locally running daemons on the Director (127.0.0.1).

Use ipvsadm to display the newly modified IP virtual server table:

 <DR>#ipvsadm -Ln IP Virtual Server version 1.0.10 (size=4096) Prot LocalAddress:Port Scheduler Flags   -> RemoteAddress:Port             Forward Weight ActiveConn InActConn TCP 209.100.100.3:80 rr   -> 127.0.0.1:80                   Masq    1      0          0   -> 10.1.1.2:80                    Masq    1      0          0 

Now we have two servers capable of responding to requests received on 209.100.100.3—the cluster node and the Director.

Use the Lynx program to make sure you have created a default web page on your Director that is different from the default web page used on your real server. On the Director type this command:

 <DR>#lynx -dump 127.0.0.1 

This should produce output that shows the default web page you have created on your Director.

Note 

For testing purposes you may want to create test pages that display the name of the real server that is displaying the page. See Appendix F for more info on how to configure Apache and how to use virtual hosts.

Now you can watch the IP virtual server round-robin scheduling method in action. From a client computer (outside the cluster) call up the web page the cluster is offering by using the virtual IP address in the URL:

 http://209.100.100.3/ 

This URL specifies the Director's virtual IP address (VIP). Watch for this connection on the Director and make sure it moves from the ActiveConn to the InActConn column and then expires out of the IP virtual server table. Then click the Refresh button^[12] on the client computer's web browser, and the web page should change to the default web page used on the real server.

^[12]You may need to hold down the SHIFT key while clicking the Refresh button to avoid accessing the web page from the cached copy the web browser has stored on the hard drive. Also, be aware of the danger of accessing the same web page stored in a cache proxy server (such as Squid) if you have a proxy server configured in your web browser.