STONITH: Difference between revisions
Created page with " {{Draft}} {{IT}}" |
Ollama: improve existing draft article |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
[[STONITH]] (Shoot The Other Node In The Head) is a critical mechanism in cluster computing designed to ensure data consistency and system reliability by preventing split-brain scenarios. It is a fencing technique used to isolate and disable nodes that have failed or are otherwise unreachable, thereby maintaining the integrity of distributed systems. This article provides an overview of [[STONITH]], its technical implementation, and its role in high-availability environments. |
|||
{{H2|Technical Overview}} |
|||
[[STONITH]] operates on the principle of "quorum" in distributed systems, where a majority of nodes must agree on the state of the cluster to maintain consistency. When a node becomes unresponsive, [[STONITH]] triggers a mechanism to forcibly shut it down or disconnect it from the network. This prevents the node from simultaneously accessing shared resources, which could lead to data corruption or conflicting operations. |
|||
The term "Shoot The Other Node In The Head" is a metaphor for the aggressive action taken by [[STONITH]] to eliminate potential points of failure. It is often implemented through hardware-based solutions, such as power switches or network isolation devices, or software-based methods like IPMI (Intelligent Platform Management Interface) or external fencing agents. |
|||
{{Draft}} |
|||
{{IT}} |
|||
{{H2|Implementation}} |
|||
Implementing [[STONITH]] requires careful configuration to balance reliability and safety. Key considerations include: |
|||
- **Hardware fencing**: Uses dedicated hardware to power off or isolate nodes. |
|||
- **Software fencing**: Relies on software protocols to detect failures and initiate shutdowns. |
|||
- **Quorum configuration**: Ensures that a majority of nodes remain operational to avoid split-brain scenarios. |
|||
In practice, [[STONITH]] is commonly integrated with cluster management tools such as Pacemaker or Corosync. These tools monitor node health and trigger [[STONITH]] actions when failures are detected. Proper configuration is essential to avoid unintended shutdowns of healthy nodes. |
|||
{{H2|Examples and Use Cases}} |
|||
[[STONITH]] is widely used in high-availability databases, cloud computing infrastructures, and mission-critical applications. For example: |
|||
- In a two-node cluster, [[STONITH]] ensures that only one node can access shared storage at a time. |
|||
- In large-scale distributed systems, it prevents partial failures from causing cascading outages. |
|||
A notable implementation is the use of [[STONITH]] with Red Hat's High Availability Add-On, which employs IPMI for hardware-level fencing. This approach minimizes the risk of data inconsistency during node failures. |
|||
{{H2|References}} |
|||
- [ClusterLabs documentation on fencing](https://clusterlabs.org/): Provides detailed information on [[STONITH]] implementation in Pacemaker clusters. |
|||
- [Red Hat High Availability Add-On](https://www.redhat.com/en/technologies/linux-platforms/high-availability): Describes hardware and software fencing techniques. |
|||
- [IPMI specification](https://www.intel.com/content/www/us/en/silicon-solutions/ipmi.html): Explains the role of IPMI in [[STONITH]]-based fencing. |
|||
[[Category:Cluster computing]] |
|||
[[Category:Computer security]] |
|||
[[Category:High-availability systems]] |
|||
{{Ollama}} |
|||
{{Pending Human Review}} |
|||
Latest revision as of 19:52, 30 October 2026
STONITH (Shoot The Other Node In The Head) is a critical mechanism in cluster computing designed to ensure data consistency and system reliability by preventing split-brain scenarios. It is a fencing technique used to isolate and disable nodes that have failed or are otherwise unreachable, thereby maintaining the integrity of distributed systems. This article provides an overview of STONITH, its technical implementation, and its role in high-availability environments.
Technical Overview
STONITH operates on the principle of "quorum" in distributed systems, where a majority of nodes must agree on the state of the cluster to maintain consistency. When a node becomes unresponsive, STONITH triggers a mechanism to forcibly shut it down or disconnect it from the network. This prevents the node from simultaneously accessing shared resources, which could lead to data corruption or conflicting operations.
The term "Shoot The Other Node In The Head" is a metaphor for the aggressive action taken by STONITH to eliminate potential points of failure. It is often implemented through hardware-based solutions, such as power switches or network isolation devices, or software-based methods like IPMI (Intelligent Platform Management Interface) or external fencing agents.
Implementation
Implementing STONITH requires careful configuration to balance reliability and safety. Key considerations include: - **Hardware fencing**: Uses dedicated hardware to power off or isolate nodes. - **Software fencing**: Relies on software protocols to detect failures and initiate shutdowns. - **Quorum configuration**: Ensures that a majority of nodes remain operational to avoid split-brain scenarios.
In practice, STONITH is commonly integrated with cluster management tools such as Pacemaker or Corosync. These tools monitor node health and trigger STONITH actions when failures are detected. Proper configuration is essential to avoid unintended shutdowns of healthy nodes.
Examples and Use Cases
STONITH is widely used in high-availability databases, cloud computing infrastructures, and mission-critical applications. For example: - In a two-node cluster, STONITH ensures that only one node can access shared storage at a time. - In large-scale distributed systems, it prevents partial failures from causing cascading outages.
A notable implementation is the use of STONITH with Red Hat's High Availability Add-On, which employs IPMI for hardware-level fencing. This approach minimizes the risk of data inconsistency during node failures.
References
- [ClusterLabs documentation on fencing](https://clusterlabs.org/): Provides detailed information on STONITH implementation in Pacemaker clusters. - [Red Hat High Availability Add-On](https://www.redhat.com/en/technologies/linux-platforms/high-availability): Describes hardware and software fencing techniques. - [IPMI specification](https://www.intel.com/content/www/us/en/silicon-solutions/ipmi.html): Explains the role of IPMI in STONITH-based fencing.
This page contains information generated by Ollama. The information was reviewed, and may have been altered, by a human editor before being added to the Featured category. As of July 2026 information generated by AI is not subject to copyright and is thus in the public domain. This page is pending human review.