LVS Cluster Management - Revision history

Wensong: /* Cluster Management Software */

2010-02-22T13:15:00Z

‎Cluster Management Software

Wensong: /* Cluster Management Software */

2007-07-03T15:23:30Z

‎Cluster Management Software

Wensong: /* Cluster Management Software */

2007-03-31T03:38:25Z

‎Cluster Management Software

Wensong at 04:03, 11 November 2006

2006-11-11T04:03:58Z

Wensong: /* Cluster Monitoring */

2006-07-06T15:04:27Z

‎Cluster Monitoring

Wensong: add more internal links

2006-05-27T03:30:43Z

add more internal links

Wensong: /* Cluster Monitoring */

2005-10-02T11:19:07Z

‎Cluster Monitoring

Wensong: /* Cluster Management Software */

2005-09-03T01:18:55Z

‎Cluster Management Software

Awebb: /* Cluster Management Software */

2005-09-01T22:07:30Z

‎Cluster Management Software

Openssi: /* Cluster Management Software */

2005-08-30T01:34:54Z

‎Cluster Management Software

@@ Line 34: / Line 34: @@
 * [[Keepalived]]
 * [[UltraMonkey]]
 * [[heartbeat plus ldirectord]]
 * [[heartbeat plus mon]]

@@ Line 37: / Line 37: @@
 * [[heartbeat plus mon]]
 * [[feedbackd]]
 * [[LVSM]]
 * [[lvs-kiss]]

@@ Line 39: / Line 39: @@
 * [[LVSM]]
 * [[lvs-kiss]]
 * [[OpenSSI Cluster integrated HA-LVS]]

← Older revision		Revision as of 04:03, 11 November 2006
Line 47:		Line 47:
	* [http://en.wikipedia.org/wiki/Computer_cluster Computer Cluster]		* [http://en.wikipedia.org/wiki/Computer_cluster Computer Cluster]

−	[[Category:~~Cluster Management~~]]	+	[[Category:LVS Handbook]]

@@ Line 11: / Line 11: @@
 === Cluster Monitoring ===
-The major work of cluster monitoring in [[LVS]] is to monitor the availability of real servers and [[load balancer]]s, and reconfigure the system if any partial failure happens, so that the whole cluster system can still serve requests. Note that monitoring the availability of database, network file system or distributed file system is not addressed here.
+The major work of cluster monitoring in [[LVS]] is to monitor the availability of [[real server]]s and [[load balancer]]s, and reconfigure the system if any partial failure happens, so that the whole cluster system can still serve requests. Note that monitoring the availability of database, network file system or distributed file system is not addressed here.
-To monitor the availability of real servers, there are two approaches, one is to run service monitoring daemons at the load balancer to check server health periodically, the other is to run monitoring agents at real servers to collect information and report to the load balancer. The service monitor usually sends service requests and/or ICMP ECHO_REQUEST to real servers periodically, and remove/disable a real server in server list at the load balancer if there is no response in a specified time or error response, thus no new requests will be sent to this dead server. When the service monitor detects the dead server has recovered to work, the service monitor will add the server back to the available server list at the load balancer. Therefore, the load balancer can mask the failure of service daemons or servers automatically.
+To monitor the availability of [[real server]]s, there are two approaches, one is to run service monitoring daemons at the load balancer to check server health periodically, the other is to run monitoring agents at real servers to collect information and report to the load balancer. The service monitor usually sends service requests and/or ICMP ECHO_REQUEST to real servers periodically, and remove/disable a real server in server list at the load balancer if there is no response in a specified time or error response, thus no new requests will be sent to this dead server. When the service monitor detects the dead server has recovered to work, the service monitor will add the server back to the available server list at the load balancer. Therefore, the load balancer can mask the failure of service daemons or servers automatically.
 In the monitoring agent approach, there is also a monitoring master running at the load balancer to receive information from the agents. The monitoring master will add/remove servers at the load balancer based on the availability of agents, can also adjust server weight based on server load information. However, there is more efforts to make the monitoring agents running at all kinds of server operating systems, such as Linux, FreeBSD, and Windows.

@@ Line 17: / Line 17: @@
 In the monitoring agent approach, there is also a monitoring master running at the load balancer to receive information from the agents. The monitoring master will add/remove servers at the load balancer based on the availability of agents, can also adjust server weight based on server load information. However, there is more efforts to make the monitoring agents running at all kinds of server operating systems, such as Linux, FreeBSD, and Windows.
-The [[load balancer]] is the core of a server cluster system, and it cannot be a single failure point of the whole system. In order to prevent the whole system from being out of service because of the load balancer failure, we need setup a backup (or several backups) of the load balancer, which are connected by [[heartbeat]] or [[VRRP]]. Two heartbeat daemons run on the primary and the backup respectively, they heartbeat the message like "I'm alive" each other through serial lines and/or network interfaces periodically. When the heartbeat daemon of the backup cannot hear the heartbeat message from the primary in the specified time, it will take over the virtual IP address to provide the load-balancing service. When the failed load balancer comes back to work, there are two solutions, one is that it becomes the backup load balancer automatically, the other is the active load balancer releases the VIP address, and the recover one takes over the VIP address and becomes the primary load balancer again.
+The [[load balancer]] is the core of a server cluster system, and it cannot be a single failure point of the whole system. In order to prevent the whole system from being out of service because of the load balancer failure, we need setup a backup (or several backups) of the load balancer, which are connected by [[heartbeat]] or [[VRRP]]. Two heartbeat daemons run on the primary and the backup respectively, they heartbeat the message like "I'm alive" each other through serial lines and/or network interfaces periodically. When the heartbeat daemon of the backup cannot hear the heartbeat message from the primary in the specified time, it will take over the virtual IP address to provide the load-balancing service. When the failed load balancer comes back to work, there are two solutions, one is that it becomes the backup load balancer automatically, the other is the active load balancer releases the [[VIP]] address, and the recover one takes over the [[VIP]] address and becomes the primary load balancer again.
-The primary [[load balancer]] has state of connections, i.e. which server the connection is forwarded to. If the backup load balancer takes over without those connections information, the clients have to send their requests again to access service. In order to make load balancer failover transparent to client applications, we implement connection synchronization in [[IPVS]], the primary [[IPVS]] load balancer synchronizes connection information to the backup load balancers through UDP multicast. When the backup load balancer takes over after the primary one fails, the backup load balancer will have the state of most connections, so that almost all connections can continue to access the service through the backup load balancer.
+The primary [[load balancer]] has state of connections, i.e. which server the connection is forwarded to. If the backup load balancer takes over without those connections information, the clients have to send their requests again to access service. In order to make load balancer failover transparent to client applications, we implement connection synchronization in [[IPVS]], the primary [[IPVS]] [[load balancer]] synchronizes connection information to the backup load balancers through UDP multicast. When the backup load balancer takes over after the primary one fails, the backup load balancer will have the state of most connections, so that almost all connections can continue to access the service through the backup load balancer.
 === Administration Interface ===
-The administration interface of LVS cluster management should enable administrators to do the following things:
+The administration interface of [[LVS]] cluster management should enable administrators to do the following things:
 * add new servers to increase the system throughput or remove servers for system maintenance, without bringing down the whole system service
 * monitor the traffic of LVS cluster and provide statistics

@@ Line 31: / Line 31: @@
 There are many cluster management software in conjuction with LVS to provide high availability and management of the whole system.
 * [[Piranha]]
 * [[Keepalived]]
@@ Line 42: / Line 40: @@
 * [[lvs-kiss]]
 * [[OpenSSI Cluster integrated HA-LVS]]
 == External Links ==