LVS without Persistence

LVS clusters are normally built without using persistence. The general rule for a Linux Enterprise Cluster is that each new connection to the cluster is sent to the least loaded real server (the cluster node with the fewest number of active connections) in order to achieve the best possible distribution of the workload.^[11] To achieve this, you create an IP virtual server table and specify each port separately with commands like these (for LVS-NAT):

 /sbin/ipvsadm -A -t 209.100.100.3:23 -s wrr /sbin/ipvsadm -a -t 209.100.100.3:23 -r 10.1.1.2 -m /sbin/ipvsadm -a -t 209.100.100.3:23 -r 10.1.1.3 -m 

The first command creates the LVS virtual service for port 23 (the telnet port) using VIP 209.100.100.3. The next two lines specify which real servers are available to service requests that come in on port 23 for this VIP. (Recall from Chapter 12 that the -m option tells the Director to use the LVS-NAT forwarding method, though any LVS forwarding method would work.)

As the Director receives each new network connection request, the real server with the fewest connections is selected, using the weighted round robin or wrr scheduling method. As a result, if a client computer opens three telnet sessions to the cluster, it may be assigned to three different real servers.

This may not be desirable, however. If, for example, you are using a licensing scheme such as the Flexlm floating license^[12] (which can cause a single user to use multiple licenses when they run several instances of the same application on multiple real servers), you may want all of the connections from a client computer to go to the same real server regardless of how that affects load balancing.

Keep in mind, however, that using LVS persistence can lead to load-balancing problems when many clients appear to come from a single IP address (they may all be behind a single NAT firewall), or if they are, in fact, all coming from a single IP address (all users may be logged on to one terminal server or one thin client server^[13]). In such a case, all of the client computers will be assigned to a single real server and possibly overwhelm it even though other nodes in the cluster are available to handle the workload. For this reason, you should avoid using LVS persistence if you are using Thin Clients or a terminal server.

In the next few sections, we'll examine LVS persistence more closely and discuss when to consider using it in a Linux Enterprise Cluster.

^[11]Here I am making a general correlation between number of connections and workload.

^[12]Flexlm has other more cluster-friendly license schemes such as a peruser license scheme.

^[13]See the Linux Terminal Server Project at http://www.ltsp.org.