The High Availability Add-On for Red Hat Enterprise Linux provides high availability of services by eliminating single points of failure. By offering failover services between nodes within a cluster, the High Availability Add-On supports high availability for up to 16 nodes. (Currently this capability is limited to a single LAN or datacenter located within one physical site.)
The High Availability Add-On also enables failover for off-the-shelf applications such as Apache, MySQL, and PostgreSQL, any of which can be coupled with resources like IP addresses and single-node file systems to form highly available services. The High Availability Add-On can also be easily extended to any user-specified application that is controlled by an init script per UNIX System V (SysV) standards.
When using the High Availability Add-On, a highly available service can fail over from one node to another with no apparent interruption to cluster clients. The High Availability Add-On also ensures absolute data integrity when one cluster node takes over control of a service from another cluster node. It achieves this by promptly evicting nodes from the cluster that are deemed to be faulty using a method called "fencing", thus preventing data corruption. The High Availability Add-On supports several types of fencing, including both power and storage area network (SAN) based fencing.
The following sections describe the various components of the High Availability Add-On in the context of this reference architecture.
The High Availability Add-On also enables failover for off-the-shelf applications such as Apache, MySQL, and PostgreSQL, any of which can be coupled with resources like IP addresses and single-node file systems to form highly available services. The High Availability Add-On can also be easily extended to any user-specified application that is controlled by an init script per UNIX System V (SysV) standards.
When using the High Availability Add-On, a highly available service can fail over from one node to another with no apparent interruption to cluster clients. The High Availability Add-On also ensures absolute data integrity when one cluster node takes over control of a service from another cluster node. It achieves this by promptly evicting nodes from the cluster that are deemed to be faulty using a method called "fencing", thus preventing data corruption. The High Availability Add-On supports several types of fencing, including both power and storage area network (SAN) based fencing.
The following sections describe the various components of the High Availability Add-On in the context of this reference architecture.
Quorum
Quorum is a voting algorithm used by the cluster manager (CMAN). CMAN manages cluster quorum and cluster membership. CMAN runs as a service on all the cluster nodes. To maintain quorum, the nodes in the cluster must agree about their status among themselves.
The quorum determines which nodes in the cluster are dominant. For example, if there are three nodes in a cluster and one node loses connectivity, the other two nodes communicate with each other and determine that the third node needs to be fenced. The action of fencing ensures that the node which lost connectivity does not corrupt data.
By default each node in the cluster has one quorum vote, although this is configurable. There are two methods the nodes can communicate with each other to determine quorum. The first method quorum via network consists of a simple majority (50% of the nodes +1 extra). The second method is by adding a quorum disk. The quorum disk allows for user-specified conditions to exist which help determine which node(s) should be dominant.
This reference architecture uses network quorum - a dedicated quorum disk is not required.
Quorum is a voting algorithm used by the cluster manager (CMAN). CMAN manages cluster quorum and cluster membership. CMAN runs as a service on all the cluster nodes. To maintain quorum, the nodes in the cluster must agree about their status among themselves.
The quorum determines which nodes in the cluster are dominant. For example, if there are three nodes in a cluster and one node loses connectivity, the other two nodes communicate with each other and determine that the third node needs to be fenced. The action of fencing ensures that the node which lost connectivity does not corrupt data.
By default each node in the cluster has one quorum vote, although this is configurable. There are two methods the nodes can communicate with each other to determine quorum. The first method quorum via network consists of a simple majority (50% of the nodes +1 extra). The second method is by adding a quorum disk. The quorum disk allows for user-specified conditions to exist which help determine which node(s) should be dominant.
This reference architecture uses network quorum - a dedicated quorum disk is not required.
Resource Group Manager
The resource group manager (rgmanager) provides failover capabilities for collections of cluster resources known as resource groups or resource trees. Rgmanager works by allowing systems administrators to define, configure, and monitor cluster services. In the event of a node failure, rgmanager relocates the clustered service to another node to restore service availability. Services can be restricted to certain nodes, such as restricting httpd to one set of nodes while mysql can be restricted to a separate set of nodes.
The following list summarizes the various processes and agents that constitute rgmanager:
The resource group manager (rgmanager) provides failover capabilities for collections of cluster resources known as resource groups or resource trees. Rgmanager works by allowing systems administrators to define, configure, and monitor cluster services. In the event of a node failure, rgmanager relocates the clustered service to another node to restore service availability. Services can be restricted to certain nodes, such as restricting httpd to one set of nodes while mysql can be restricted to a separate set of nodes.
The following list summarizes the various processes and agents that constitute rgmanager:
- Failover Domains - An ordered subset of members to which a service may be bound
- Service Policies - rgmanager's service startup and recovery policies
- Resource Trees - Representations of resources, their attributes, parent / child and sibling relationships
- Resource Agents
rgmanager runs as a service on all the nodes in a cluster. If the service is not running, the resources are not available to be brought online. Recovery of rgmanager depends on the Distributed Lock Manager (DLM). In the event of a failure, the DLM must recover prior to rgmanager recovering services from a failed host.
Fencing
Fencing is the disconnection of a node from the cluster's shared storage. Fencing prevents the affected node from issuing I/O to shared storage, thus ensuring data integrity. The cluster infrastructure performs fencing through fenced, the fence daemon.
When CMAN determines that a node has failed, it communicates to other clusterinfrastructure components to inform them that the node has failed. The failed node is fenced when fenced is notified. Other cluster-infrastructure components determine what actions to take - that is, they perform any recovery that needs to done. For example, distributed lock manager (DLM) and Global File System version 2 (GFS2), when notified of a node failure, suspend activity until they detect that fenced has completed fencing the failed node. Upon confirmation that the failed node is fenced, DLM and GFS2 perform recovery. DLM releases locks of the failed node; GFS2 recovers the journal of the failed node.
The fencing program (fenced) determines from the cluster configuration file which fencing method to use. Two key elements in the cluster configuration file define a fencing method:
fencing agent and fencing device. The fencing program makes a call to a fencing agent specified in the cluster configuration file. The fencing agent, in turn, fences the node via a fencing device. When fencing is complete, the fencing program notifies the cluster manager.
The High Availability Add-On provides a variety of fencing methods:
Fencing is the disconnection of a node from the cluster's shared storage. Fencing prevents the affected node from issuing I/O to shared storage, thus ensuring data integrity. The cluster infrastructure performs fencing through fenced, the fence daemon.
When CMAN determines that a node has failed, it communicates to other clusterinfrastructure components to inform them that the node has failed. The failed node is fenced when fenced is notified. Other cluster-infrastructure components determine what actions to take - that is, they perform any recovery that needs to done. For example, distributed lock manager (DLM) and Global File System version 2 (GFS2), when notified of a node failure, suspend activity until they detect that fenced has completed fencing the failed node. Upon confirmation that the failed node is fenced, DLM and GFS2 perform recovery. DLM releases locks of the failed node; GFS2 recovers the journal of the failed node.
The fencing program (fenced) determines from the cluster configuration file which fencing method to use. Two key elements in the cluster configuration file define a fencing method:
fencing agent and fencing device. The fencing program makes a call to a fencing agent specified in the cluster configuration file. The fencing agent, in turn, fences the node via a fencing device. When fencing is complete, the fencing program notifies the cluster manager.
The High Availability Add-On provides a variety of fencing methods:
- • Power fencing - A fencing method that uses a power controller to power off an inoperable node
- • Storage fencing - Includes fencing methods that disable the Fibre Channel port that connects storage to an inoperable node. SCSI-3 persistent reservations are another commonly used storage fencing method in which access to a common shared storage device can be revoked to an inoperable node.
- • Systems management fencing - Fencing methods that disable I/O or power to an inoperable node. Examples include IBM® BladeCenter, Dell® DRAC/MC, HP® ILO, IPMI, and IBM RSA II.
Useful Link:
No comments:
Post a Comment