SFHA Solutions 6.0.1: About GAB seeding and its role in VCS and other SFHA products
Group Membership and Atomic Broadcast (GAB) is a kernel component of Veritas Cluster Server (VCS) that provides globally-ordered messages that keep nodes synchronized. GAB maintains the cluster state information and the correct membership on the cluster. However, GAB needs another kernel component, Low Latency Transport (LLT), to send messages to the nodes and keep the cluster nodes connected.
How GAB and LLT function together in a VCS cluster?
VCS uses GAB and LLT to share data among nodes over private networks. LLT is the transport protocol responsible for fast kernel-to-kernel communications. GAB carries the state of the cluster and the cluster configuration to all the nodes on the cluster. These components provide the performance and reliability that VCS requires.
In a cluster, nodes must share the groups, resources and the resource states. LLT and GAB help the nodes communicate.
For information on LLT, GAB, and private networks, see:
The GAB seeding function ensures that a new cluster starts with an accurate membership count of the number of nodes in the cluster. It prevents your cluster from a preexisting network partition upon initial start-up. A preexisting network partition refers to the failure in the communication channels that occurs while the nodes are down and VCS cannot respond. When the nodes start, GAB seeding reduces the vulnerability to network partitioning, regardless of the cause of the failure. GAB services are used by all Veritas Storage Foundation and High Availability (SFHA) products.
For information about preexisting network partitions, and how seeding functions in VCS, see:
Enabling automatic seeding of GAB
If I/O fencing is configured in the enabled mode, you can edit the /etc/vxfenmode file to enable automatic seeding of GAB. If the cluster is stuck with a preexisting split-brain condition, I/O fencing allows automatic seeding of GAB.
You can set the minimum number of nodes to form a cluster for GAB to seed by configuring the Control port seed and Quorum flag parameters in the /etc/gabtab file. Quorum is the number of nodes that need to join a cluster for GAB to complete seeding.
For information on configuring the autoseed_gab_timeout parameter in the /etc/vxfenmode file, see:
For information on configuring the control port seed and the Quorum flag parameters in GAB, see:
For information on split-brain conditions, see:
- About the Steward process: Split-brain in two-cluster global clusters
- How I/O fencing works in different event scenarios
- Example of a preexisting network partition (split-brain)
Role of GAB seeding in cluster membership
For information on how the nodes gain cluster membership, seeding a cluster, and manual seeding of a cluster, see:
- About cluster membership
- Initial joining of systems to cluster membership
- Seeding a new cluster
- Seeding a cluster using the GAB auto-seed parameter through I/O fencing
- Manual seeding of a cluster
Troubleshooting issues that are related to GAB seeding and preexisting network partitions
For information on the issues that you may encounter when GAB seeds a cluster and preexisting network partitions, see:
- Examining GAB seed membership
- Manual GAB membership seeding
- Waiting for cluster membership after VCS start-up
- Summary of best practices for cluster communications
- System panics to prevent potential data corruption
- Fencing startup reports preexisting split-brain
- Clearing preexisting split-brain condition
- Recovering from a preexisting network partition (split-brain)
- Example Scenario I – Recovering from a preexisting network partition
- Example Scenario II – Recovering from a preexisting network partition
- Example Scenario III – Recovering from a preexisting network partition
gabconfig (1M) 6.0.1 manual pages:
For more information on seeding clusters to prevent preexisting network partitions, see:
Veritas Cluster Server documentation for other releases and platforms can be found on the SORT website.