Go Linux load Balancer software LVS Four (test article-end)

First, start the LVS Cluster service
LVS load balancing management and use in two ways, one is the Ipvsadm command line footstep and Ldirectord monitoring mode, one is the Piranha tool for management and use. The following are described separately.

1, using Ipvsadm command line footsteps and Ldirectord monitoring method to manage LVS
After everything has been configured, start the LVS Cluster service by performing the following operations in turn.
First, start the service for each real server node:
[[email protected] ~]#/etc/init.d/lvsrs start
Start LVS of Realserver
Then, start the Ldirectord service on the Director server:
[[email protected] ~]#/etc/init.d/ldirectord start
Starting Ldirectord [OK]
Now look at the Ldirectord output log information as follows:
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)
As can be seen from the log, Ldirectord first loaded a virtual IP 80 port, then loaded two real server node 80 port and the Director server Native 80 port, while the real server two node weight is set to 1, Since two nodes are available, the 80 port of the director server native is finally removed from the LVS routing table.
Next, start the LVSDR Master service on the director server:
[[Email protected]_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
So far, the LVS load Balancer cluster system has started running.

2. Using Piranha tools to manage LVS
In this way, starting the LVS cluster is simple, just execute the following command:
/etc/init.d/pulse start
At this point, the system log information for the Pulse service is read as follows:
[Email protected] ~]# tail-f/var/log/messages
Nov 15:52:55 LVs lvs[7031]: Starting virtual service www.gaojf.com active:80
Nov 15:52:55 LVs lvs[7031]: Create_monitor for www.gaojf.com/RS1 running as PID 7039
Nov 15:52:55 LVs nanny[7039]: Starting LVS client Monitor for 192.168.60.200:80
Nov 15:52:55 LVs lvs[7031]: Create_monitor for www.gaojf.com/RS2 running as PID 7040
Nov 15:52:55 LVs nanny[7039]: making 192.168.60.132:80 available
Nov 15:52:55 LVs nanny[7040]: Starting LVS client Monitor for 192.168.60.200:80
Nov 15:52:55 LVs nanny[7040]: making 192.168.60.144:80 available
As can be seen from the log, the Pulse service initiates a www.gaojf.com virtual service, loads both RS1 and RS2 two nodes, then detects 80 ports available for RS1 and RS2 two nodes, and finally starts the 80 port of the virtual IP and provides services externally.
Log in “www.gaojf.com”, “ rs1”, “ Identifiers such as rs2” are defined in the Piranha configuration file/ETC/SYSCONFIG/HA/LVS.CF.
After the Pulse service is started, you can see that the following processes are running through the “ps –ef” command:
[Email protected] ~]# 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/
Among them, nanny is the Pulse service daemon, used to monitor the operation State of the LVS service node, similar to the Ldirectord node monitoring function.

Second, test load balancing
This assumes that the Web page file root directory of the two real server nodes configuration WWW service is the/webdata/www directory, and then performs the following actions, respectively:
In real server1 execution:
echo "Real Server1 OK" >/webdata/www/index.html
In real Server2 execution:
echo "Real server2 OK" >/webdata/www/index.html
Then open the browser, access to http://192.168.60.200 this address, and then constantly refresh this page, if you can see the real server1 OK, and real server2 OK to indicate that LVS is working properly.

Third, test failover function
Failover is to test when a node fails, the monitoring module can be found in time, and then block the failure node, while the service is transferred to the normal node to execute, the following respectively, the use of ldirectord monitoring of the failover process and the use of nanny monitoring the failover situation.

1. Monitoring LVs with Ldirectord failover
It is assumed that the WWW service of the real Server1 node is stopped, and then the Ldirectord log changes are observed, you should see a message similar to the following:
ldirectord|2614] Deleted Real server:192.168.60.132:80 (192.168.60.200:80)
Ldirectord monitored the service to the 192.168.60.132 node, and then removed the node from the LVS routing table. The
continues to access http://192.168.60.200 through the browser at this point, access is unaffected, but only the real server2 OK message is displayed because of a problem with real server1. Blocked by Ldirectord, the entire LVS cluster is only real server2 in service.
The above log output information is due to the quiescent=no set in LDIRECTORD.CF, if set to Quiescent=yes, the log output information becomes as follows:
ldirectord|32454] quiescent Real server:192.168.60.132:80 (192.168.60.200:80) (Weight set to 0)
This log output is to set the weight of the failed node 192.168.60.132 to 0 without removing the host from the LVS routing table, at which point the connected client will become unreachable, but the new connection will not be assigned to this node.
If you restart the real Server1 service, Ldirectord will be able to automatically detect that the node has been activated, re-join the node to the LVS routing table, and Ldirectord will output the information in the log:
ldirectord|2614] Added Real Server:192.168.60.132:80 (192.168.60.200:80) (Weight set to 1)

2. Using nanny to monitor the failure switch of LVS
Again, it is assumed that the WWW service of the real Server1 node is stopped and then the log information of the Pluse service is observed, and the log output is as follows:
Nov 15:54:01 LVs nanny[7039]: Shutting down 192.168.60.132:80 due to connection failure
As you can see, when the real Server1 service is stopped, the nanny daemon monitors this node for failure and then shuts down the connection service for this node.
Now restart the service that starts the real Server1 node, and then observe the log output of the Pluse service:
Nov 16:49:41 LVs nanny[7158]: making 192.168.60.132:80 available
The nanny daemon automatically detects that the real Server1 service has been activated and re-makes the node available for connection within the set detection time.

This article originates from http://ixdba.blog.51cto.com/2895551/555738

Go Linux load Balancer software LVS Four (test article-end)