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, which is based on the Linux Virtual Server (LVS) project. Using Red Hat Enterprise Linux with Piranha, you can deploy a highly available e-commerce site that has complete data integrity and application availability, in addition to load balancing capabilities. Refer to Chapter 9 Linux Virtual Server Overview through Chapter 12 Configuring the LVS Routers with Piranha Configuration Tool for more information.
This guide assumes that the user has an advanced working knowledge of Red Hat Enterprise Linux and understands the concepts of server computing. For more information about using Red Hat Enterprise Linux, refer to the following resources:
Red Hat Enterprise Linux Installation Guide for information regarding installation.
Red Hat Enterprise Linux Introduction to System Administration for introductory information for new Red Hat Enterprise Linux system administrators.
Red Hat Enterprise Linux System Administration Guide for more detailed information about configuring Red Hat Enterprise Linux to suit your particular needs as a user.
Red Hat Enterprise Linux Reference Guide provides detailed information suited for more experienced users to refer to when needed, as opposed to step-by-step instructions.
Red Hat Enterprise Linux Security Guide details the planning and the tools involved in creating a secured computing environment for the data center, workplace, and home.
HTML, PDF, and RPM versions of the manuals are available on the Red Hat Enterprise Linux Documentation CD and online at http://www.redhat.com/docs/.
![]() | Note |
---|---|
Although this manual reflects the most current information possible, read the Red Hat Enterprise Linux Release Notes for information that may not have been available prior to our documentation being finalized. They can be found on the Red Hat Enterprise Linux CD #1 and online at http://www.redhat.com/docs/. |
To set up a cluster, you must connect the member systems (often referred to simply as members) to the cluster hardware, and configure the members 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-member communication:
Network connections between the cluster systems for heartbeat
Shared state on shared disk storage to hold cluster status
To make an application and data highly available in a cluster, you must configure a service (such as an application and shared disk storage) as a discrete, named group of properties and resources to which you can assign an IP address to provide transparent client access. For example, you can set up a service that provides clients with access to highly-available database application data.
You can associate a service with a failover domain, a subset of cluster members that are eligible to run the service. In general, any eligible member can run the service and access the service data on shared disk storage. However, each service can run on only one cluster member at a time, in order to maintain data integrity. You can specify whether or not the members in a failover domain are ordered by preference. You can also specify whether or not a service is restricted to run only on members of its associated failover domain. (When associated with an unrestricted failover domain, a service can be started on any cluster member in the event no member of the failover domain is available.)
You can set up an active-active configuration in which the members run different services, or a hot-standby configuration in which a primary member runs all the services, and a backup cluster system takes over only if the primary system fails.
Figure 1 shows an example of a cluster in an active-active configuration.
If a hardware or software failure occurs, the cluster automatically restarts the failed member's services on the functional member. This service failover capability ensures that no data is lost, and there is little disruption to users. When the failed member recovers, the cluster can re-balance the services across the members.
In addition, you can cleanly stop the services running on a cluster system and then restart them on another system. This service relocation capability allows you to maintain application and data availability when a cluster member requires maintenance.