User manual REDHAT CLUSTER SUITE FOR ENTERPRISE LINUX 5.0 OVERVIEW

[. . . ] Red Hat Cluster Suite Overview Red Hat Cluster Suite for Red Hat Enterprise Linux 5. 0 5. 0 ISBN: N/A Publication date: Red Hat Cluster Suite Overview Red Hat Cluster Suite Overview provides an overview of Red Hat Cluster Suite for Red Hat Enterprise Linux 5. 0. Red Hat Cluster Suite Overview: Red Hat Cluster Suite for Red Hat Enterprise Linux 5. 0 Copyright © You need to override the YEAR enity in your local ent file Red Hat, Inc. Copyright © You need to override the YEAR enity in your local ent file Red Hat Inc. . This material may only be distributed subject to the terms and conditions set forth in the Open Publication License, V1. 0 or later with the restrictions noted below (the latest version of the OPL is presently available at http://www. opencontent. org/openpub/). Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. Distribution of the work or derivative of the work in any standard (paper) book form for commercial purposes is prohibited unless prior permission is obtained from the copyright holder. [. . . ] Capacity is indicated by a user-assigned weight, which is then adjusted up or down by dynamic load information. The addition of weighting makes this algorithm ideal when the real server pool contains hardware of varying capacity. · Locality-Based Least-Connection Scheduling -- Distributes more requests to servers with fewer active connections relative to their destination IPs. This algorithm is for use in a proxy-cache server cluster. It routes the packets for an IP address to the server for that address unless that server is above its capacity and has a server in its half load, in which case it assigns the IP address to the least loaded real server. · Locality-Based Least-Connection Scheduling with Replication Scheduling -- Distributes more requests to servers with fewer active connections relative to their destination IPs. This algorithm is also for use in a proxy-cache server cluster. It differs from Locality-Based Least-Connection Scheduling by mapping the target IP address to a subset of real server nodes. Requests are then routed to the server in this subset with the lowest number of connections. If all the nodes for the destination IP are above capacity, it replicates a new server for that destination IP address by adding the real server with the least connections from the overall pool of real servers to the subset of real servers for that destination IP. The most-loaded node is then dropped from the real server subset to prevent over-replication. · Source Hash Scheduling -- Distributes requests to the pool of real servers by looking up the source IP in a static hash table. This algorithm is for LVS routers with multiple firewalls. Also, the active LVS router dynamically monitors the overall health of the specific services on the real servers through simple send/expect scripts. To aid in detecting the health of services that require dynamic data, such as HTTPS or SSL, you can also call external executables. If a service on a real server malfunctions, the active LVS router stops sending jobs to that server until it returns to normal operation. 29 Chapter 1. Red Hat Cluster Suite Overview The backup LVS router performs the role of a standby system. Periodically, the LVS routers exchange heartbeat messages through the primary external public interface and, in a failover situation, the private interface. Should the backup LVS router fail to receive a heartbeat message within an expected interval, it initiates a failover and assumes the role of the active LVS router. During failover, the backup LVS router takes over the VIP addresses serviced by the failed router using a technique known as ARP spoofing -- where the backup LVS router announces itself as the destination for IP packets addressed to the failed node. When the failed node returns to active service, the backup LVS router assumes its backup role again. The simple, two-tier configuration in Figure 1. 20, "Two-Tier LVS Topology" is suited best for clusters serving data that does not change very frequently -- such as static web pages -- because the individual real servers do not automatically synchronize data among themselves. 8. 2. [. . . ] On the backup router, pulse determines the health of the active router by executing a simple heartbeat at a user-configurable interval. If the active LVS router fails to respond after a user-configurable interval, it initiates failover. During failover, pulse on the backup LVS router instructs the pulse daemon on the active LVS router to shut down all LVS services, starts the send_arp program to reassign the floating IP addresses to the backup LVS router's MAC address, and starts the lvs daemon. The lvs daemon runs on the active LVS router once called by pulse. [. . . ]