HP Serviceguard manual Single Cluster Lock, Dual Cluster Lock

Page 17

Arbitration for Data Integrity in Serviceguard Clusters

Use of a Lock Disk as the Cluster Lock

Serviceguard periodically checks the health of the lock disk and writes messages to the syslog file when a lock disk fails the health check. This file should be monitored for early detection of lock disk problems.

You can choose between two lock disk options—a single or dual lock disk—based on the kind of high availability configuration you are building. A single lock disk is recommended where possible. With both single and dual locks, however, it is important that the cluster lock be available even if the power circuit to one node fails; thus, the choice of a lock configuration depends partly on the number of power circuits available. Regardless of your choice, all nodes in the cluster must have access to the cluster lock to maintain high availability.

Single Cluster Lock

It is recommended that you use a single lock disk. A single lock disk should be configured on a power circuit separate from that of any node in the cluster. For example, it is highly recommended to use three power circuits for a two-node cluster, with a single, separately powered disk for the cluster lock. For two-node clusters, this single lock disk may not share a power circuit with either node, and it must be an external disk. For three or four node clusters, the disk should not share a power circuit with 50% or more of the nodes.

Dual Cluster Lock

In an extended distance cluster, where the cluster contains nodes running in two separate data centers, a single lock disk would be a single point of failure should the data center it resides in suffer a catastrophic failure. In this case only, a dual cluster lock, with two separately powered disks, should be used to eliminate the lock disk as a single point of failure. The use of the dual cluster lock is further shown in “Use of Dual Lock Disks in Extended Distance Clusters” on page 26.

17

Image 17
Contents Manufacturing Part Number B3936-90078 July Arbitration For Data Integrity Serviceguard ClustersLegal Notices Arbitration for Data Integrity in Serviceguard Clusters Membership Cluster Membership ConceptsCluster Membership Concepts Split-Brain QuorumTie-Breaking Multiple Heartbeat Failures To Arbitrate or Not to ArbitrateNo Arbitration-Multiple Paths Single Node Failure No Arbitration-Multiple MediaAdditional Multiple Paths with Different Media Multiple Paths with Different MediaNo Arbitration-Risks Startup and Re-Formation How Serviceguard Uses ArbitrationCluster Startup Cluster Lock Dynamic Cluster Re-FormationCluster Quorum and Cluster Locking No Cluster Lock Lock Requirements Lock Disk Operation Use of a Lock Disk as the Cluster LockDual Cluster Lock Single Cluster LockUse of a Lock LUN as the Cluster Lock Lock LUN Operation Oot IrrorQuorum Server Operation Use of a Quorum Server as the Cluster LockRunning the Quorum Server Setting up the Quorum ServerQuorum Server Status and State Specifying a Quorum ServerViewing Quorum Server System Data Viewing Quorum Server Status and StateUse of Arbitrator Node Use of Arbitrator NodesMetropolitan Clusters Arbitration in Disaster-Tolerant ClustersExtended Distance Clusters Quorum Server Arbitrator NodesUse of Dual Lock Disks in Extended Distance Clusters Continental ClustersDisk area is not mirrored Arbitration for Data Integrity in Serviceguard Clusters Comparison of Different Arbitration Methods Arbitration Advantages Disadvantages ModeSummary Arbitration for Data Integrity in Serviceguard Clusters Summary
Related manuals
Manual 407 pages 39.81 Kb