# Maintaining GFS2 Consistency and High Availability

HVM Clusters utilize several open-source technologies to maintain consistency and high availability when GFS2 external storage is utilized. This section lists those technologies and a high level overview of how they work together to prevent data corruption and facilitate smooth failover when a cluster host is lost.

Corosync

- Open-source cluster engine providing a high-performance messaging layer
- Ensures node communication and consistent cluster state in high availability systems
- Tracks active nodes and prevents split-brain scenarios
- Provides are reliable messaging backbone for syncronizing state and data
- Handles node failures and reconfigures the cluster automatically
- Works with Pacemaker as part of a full HA stack providing automatic failover
- Distributes lock information, detects failures, and triggers fencing

Pacemaker

- Open-source HA resource manager
- Ensures services and resources run on correct nodes, even during failures
- Works with Corosync for messaging and membership
- Handles resource management, such as IP addresses, filesystems, and services
- Depects failures and facilitates automatic failover and restart
- Manages GFS2 mounts, distributed lock management, and fencing agents (split-brain prevention)
- Relocates VMs and services automatically on node failure

Distributed Lock Manager (DLM)

- Ensures data integrity in GFS2 clusters by managing file and metadata locks
- Allows just one node to modify a resource at a time, preventing data corruption
- Shares lock info across the cluster
- Utilizes Corosync messaging to synchnonize lock states
- On node failure, fencing releases locks safety before recovery

Fencing

- Ensures data integrity if a node fails
- Isolates failed nodes from shared storage to prevent data corruption
- Uses STONITH fencing method to completely disable nodes considered to be down to ensure they cannot access shared storage
- Releases locks only when unresponsive nodes are safely fenced
