Chapter 1. Introduction to Red Hat Cluster Manager
The Red Hat Cluster Manager is a collection of technologies working together to provide data integrity and the ability to maintain application availability in the event of a failure. Using redundant hardware, shared disk storage, power management, and robust cluster communication and application failover mechanisms, a cluster can meet the needs of the enterprise market.
Specially suited for database applications, network file servers, and World Wide Web (Web) servers with dynamic content, a cluster can also be used in conjunction with the Piranha load balancing cluster software, based on the Linux Virtual Server (LVS) project, to deploy a highly available e-commerce site that has complete data integrity and application availability, in addition to load balancing capabilities. See the Section called Using Red Hat Cluster Manager with Piranha in Appendix B for more information.
Cluster Overview
To set up a cluster, an administrator must connect the cluster systems (often referred to as member systems) to the cluster hardware, and configure the systems into the cluster environment. The foundation of a cluster is an advanced host membership algorithm. This algorithm ensures that the cluster maintains complete data integrity at all times by using the following methods of inter-node communication:
Quorum partitions on shared disk storage to hold system status
Ethernet and serial connections between the cluster systems for heartbeat channels
To make an application and data highly available in a cluster, the administrator must configure a cluster service — a discrete group of service properties and resources, such as an application and shared disk storage. A service can be assigned an IP address to provide transparent client access to the service. For example, an administrator can set up a cluster service that provides clients with access to highly-available database application data.
Both cluster systems can run any service and access the service data on shared disk storage. However, each service can run on only one cluster system at a time, in order to maintain data integrity. Administrators can set up an active-active configuration in which both cluster systems run different services, or a hot-standby configuration in which a primary cluster system runs all the services, and a backup cluster system takes over only if the primary system fails.
Figure 1-1 shows an example of a cluster in an active-active configuration.
If a hardware or software failure occurs, the cluster will automatically restart the failed system's services on the functional cluster system. This service failover capability ensures that no data is lost, and there is little disruption to users. When the failed system recovers, the cluster can re-balance the services across the two systems.
In addition, a cluster administrator can cleanly stop the services running on a cluster system and then restart them on the other system. This service relocation capability enables the administrator to maintain application and data availability when a cluster system requires maintenance.