1. Starting the LVS Cluster Service
There are two ways to manage and use LVS load balancing: one uses the ipvsadm command-line scripts with ldirectord monitoring, and the other uses the Piranha tool. Both are introduced below.
1. Managing LVS with ipvsadm and ldirectord
After all configurations are complete, execute the following steps in order to start the LVS cluster service.
First, start the service on each real server node:
[root@localhost ~]# /etc/init.d/lvsrs start
start LVS of REALServer
Then, start the ldirectord service on the Director Server:
[root@localhost ~]# /etc/init.d/ldirectord start
Starting ldirectord [ OK ]
At this point, viewing the ldirectord log output shows the following:
ldirectord|2561] Invoking ldirectord invoked as: /usr/sbin/ldirectord start
ldirectord|2561] Starting Linux Director v1.186 as daemon
ldirectord|2563] Added virtual server: 192.168.60.200:80
ldirectord|2563] Added fallback server: 127.0.0.1:80 (192.168.60.200:80) (Weight set to 1)
ldirectord|2563] Added real server: 192.168.60.132:80 (192.168.60.200:80) (Weight set to 1)
ldirectord|2563] Deleted fallback server: 127.0.0.1:80 (192.168.60.200:80)
ldirectord|2563] Added real server: 192.168.60.144:80 (192.168.60.200:80) (Weight set to 1)
From the logs, we can see that ldirectord first loaded port 80 for a virtual IP, then loaded port 80 for the two real server nodes and the Director Server’s own port 80, setting the weight of both real servers to 1. Since both nodes were available, it finally deleted the Director Server’s local port 80 from the LVS routing table.
Next, start the main lvsDR service on the Director Server:
[root@xa_web1 ~]# /etc/init.d/lvsDR start
start LVS of DirectorServer
IP Virtual Server version 1.2.0 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.60.200:http rr persistent 600
-> 192.168.60.132:http Route 1 3 22
-> 192.168.60.144:http Route 1 9 22
At this point, the LVS load balancing cluster system is up and running.
2. Managing LVS with the Piranha Tool
With this method, starting the LVS cluster is simple; just execute the following command:
/etc/init.d/pulse start
Checking the system log for the pulse service shows the following:
[root@localhost ~]# tail -f /var/log/messages
Nov 22 15:52:55 lvs lvs[7031]: starting virtual service www.gaojf.com active: 80
Nov 22 15:52:55 lvs lvs[7031]: create_monitor for www.gaojf.com/RS1 running as pid 7039
Nov 22 15:52:55 lvs nanny[7039]: starting LVS client monitor for 192.168.60.200:80
Nov 22 15:52:55 lvs lvs[7031]: create_monitor for www.gaojf.com/RS2 running as pid 7040
Nov 22 15:52:55 lvs nanny[7039]: making 192.168.60.132:80 available
Nov 22 15:52:55 lvs nanny[7040]: starting LVS client monitor for 192.168.60.200:80
Nov 22 15:52:55 lvs nanny[7040]: making 192.168.60.144:80 available
From the logs, it’s clear that the pulse service started a virtual service for www.gaojf.com, loaded the two nodes RS1 and RS2, detected that port 80 on both RS1 and RS2 was available, and finally started port 80 on the virtual IP to serve external traffic.
The identifiers “www.gaojf.com”, “RS1”, “RS2” in the logs are all defined in the Piranha configuration file /etc/sysconfig/ha/lvs.cf.
Once the Pulse service has started, using the “ps –ef” command reveals the following processes running:
[root@localhost ~]# ps -ef|grep nanny
/usr/sbin/nanny -c -h 192.168.60.132 -p 80 -s GET / HTTP/1.0/r/n/r/n -x HTTP -a 15 -I /
/usr/sbin/nanny -c -h 192.168.60.144 -p 80 -s GET / HTTP/1.0/r/n/r/n -x HTTP -a 15 -I /
Here, nanny is the daemon process for the Pulse service, responsible for monitoring the running status of LVS service nodes, similar to the node monitoring functionality of ldirectord.
2. Testing Load Balancing
Here, it is assumed that the web service document root for both real server nodes is the /webdata/www directory. Perform the following steps respectively:
On real server1, execute:
echo "This is real server1" /webdata/www/index.html
On real server2, execute:
echo "This is real server2" /webdata/www/index.html
Then, open a browser and visit http://192.168.60.200. Continuously refresh this page. If you can see “This is real server1” and “This is real server2” alternately, it indicates that LVS is working normally.
3. Testing Failover Functionality
Failover testing checks whether the monitoring module can detect a node failure in time, isolate the faulty node, and transfer services to a healthy node. Below, we detail the failover process under ldirectord monitoring and the failover scenario under nanny monitoring.
1. LVS Failover Monitored by ldirectord
Here, assume we stop the www service on real server1 and observe the log changes from ldirectord. You should see information similar to the following:
ldirectord|2614] Deleted real server: 192.168.60.132:80 (192.168.60.200:80)
This shows that ldirectord detected a service failure on the node 192.168.60.132 and removed this node from the LVS routing table.
If you continue to visit http://192.168.60.200 through the browser, access remains unaffected, but it will only display “This is real server2”. This is because real server1 encountered a problem and was isolated by ldirectord, leaving only real server2 to provide services for the entire LVS cluster.
The log output above is because “quiescent=no” was set in ldirectord.cf. If it is set to “quiescent=yes”, the log output changes to this:
ldirectord|32454] Quiescent real server:192.168.60.132:80 (192.168.60.200:80) (Weight set to 0)
This log entry sets the weight of the faulty node 192.168.60.132 to 0 without deleting this host from the LVS routing table. In this case, existing connected clients will experience access failures, but new connections will not be assigned to this node.
If you restart the service on Real server1, ldirectord will automatically detect that the node is active again and re-add it to the LVS routing table, outputting this information in its logs:
ldirectord|2614] Added real server: 192.168.60.132:80 (192.168.60.200:80) (Weight set to 1)
2. LVS Failover Monitored by nanny
Similarly, assume we stop the www service on real server1 here and observe the log information from the pulse service. The log output is as follows:
Nov 22 15:54:01 lvs nanny[7039]: shutting down 192.168.60.132:80 due to connection failure
It can be seen that after stopping the service on real server1, the nanny daemon detected the node failure and shut down the connection service for this node.
Now restart the service on real server1 and observe the pulse service log output:
Nov 22 16:49:41 lvs nanny[7158]: making 192.168.60.132:80 available
The nanny daemon automatically detected within the configured check interval that the real server1 service was active again, making this node available for connections once more.