4.6. VIRTUAL SERVERS

Enter a descriptive name to identify the virtual server. This name is not the hostname for the machine, so make it descriptive and easily identifiable. You can even reference the protocol used by the virtual server, such as HTTP.

Enter the port number through which the service application will listen. Since this example is for HTTP services, port 80 is used.

Choose between UDP and TCP in the drop-down menu. Web servers typically communicate via the TCP protocol, so this is selected in the example above.

Enter the virtual server's floating IP address in this text field.

Set the netmask for this virtual server with the drop-down menu.

Do not enter a firewall mark integer value in this field unless you are bundling multi-port protocols or creating a multi-port virtual server for separate, but related protocols. In this example, the above virtual server has a Firewall Mark of 80 because we are bundling connections to HTTP on port 80 and to HTTPS on port 443 using the firewall mark value of 80. When combined with persistence, this technique will ensure users accessing both insecure and secure webpages are routed to the same real server, preserving state.

Enter the name of the network device to which you want the floating IP address defined the Virtual IP Address field to bind.

You should alias the public floating IP address to the Ethernet interface connected to the public network. In this example, the public network is on the eth0 interface, so eth0:1 should be entered as the device name.

Enter an integer value which defines the length of time, in seconds, before the active LVS router attempts to bring a real server back into the pool after a failure.

Enter an integer value which defines the length of time, in seconds, before a real server is considered dead and removed from the pool.

When the Quiesce server radio button is selected, anytime a new real server node comes online, the least-connections table is reset to zero so the active LVS router routes requests as if all the real servers were freshly added to the pool. This option prevents the a new server from becoming bogged down with a high number of connections upon entering the pool.

The LVS router can monitor the load on the various real servers by using either rup or ruptime. If you select rup from the drop-down menu, each real server must run the rstatd service. If you select ruptime, each real server must run the rwhod service.

Select your preferred scheduling algorithm from the drop-down menu. The default is Weighted least-connection. For more information on scheduling algorithms, see Section 1.3.1, “Scheduling Algorithms”.

If an administrator needs persistent connections to the virtual server during client transactions, enter the number of seconds of inactivity allowed to lapse before a connection times out in this text field.

To limit persistence to particular subnet, select the appropriate network mask from the drop-down menu.

A descriptive name for the real server.

The real server's IP address. Since the listening port is already specified for the associated virtual server, do not add a port number.

An integer value indicating this host's capacity relative to that of other hosts in the pool. The value can be arbitrary, but treat it as a ratio in relation to other real servers in the pool. For more on server weight, see Section 1.3.2, “Server Weight and Scheduling”.

For more advanced service verification, you can use this field to specify the path to a service-checking script. This functionality is especially helpful for services that require dynamically changing data, such as HTTPS or SSL.

To use this functionality, you must write a script that returns a textual response, set it to be executable, and type the path to it in the Sending Program field.

The following is a sample script to use as a guide when composing an external service-checking script:

#!/bin/sh

TEST=`dig -t soa example.com @$1 | grep -c dns.example.com

if [ $TEST != "1" ]; then
	echo "OK
else
	echo "FAIL"
fi

Enter a string for the nanny daemon to send to each real server in this field. By default the send field is completed for HTTP. You can alter this value depending on your needs. If you leave this field blank, the nanny daemon attempts to open the port and assume the service is running if it succeeds.

Only one send sequence is allowed in this field, and it can only contain printable, ASCII characters as well as the following escape characters:

Enter a the textual response the server should return if it is functioning properly. If you wrote your own sending program, enter the response you told it to send if it was successful.