diff --git a/doc/Pacemaker_Explained/en-US/Ch-Stonith.xml b/doc/Pacemaker_Explained/en-US/Ch-Stonith.xml index c5ef7570e5..f0e511d061 100644 --- a/doc/Pacemaker_Explained/en-US/Ch-Stonith.xml +++ b/doc/Pacemaker_Explained/en-US/Ch-Stonith.xml @@ -1,84 +1,84 @@ Protecting Your Data - STONITH
Why You Need STONITH STONITH is an acronym for Shoot-The-Other-Node-In-The-Head and it protects your data from being corrupted by rouge nodes or concurrent access. Just because a node is unresponsive, this doesn't mean it isn't accessing your data. The only way to be 100% sure that your data is safe, is to use STONITH so we can be certain that the node is truly offline, before allowing the data to be accessed from another node. STONITH also has a role to play in the event that a clustered service cannot be stopped. In this case, the cluster uses STONITH to force the whole node offline, thereby making it safe to start the service elsewhere.
What STONITH Device Should You Use It is crucial that the STONITH device can allow the cluster to differentiate between a node failure and a network one. The biggest mistake people make in choosing a STONITH device is to use remote power switch (such as many on-board IMPI controllers) that shares power with the node it controls. In such cases, the cluster cannot be sure if the node is really offline, or active and suffering from a network fault. Likewise, any device that relies on the machine being active (such as SSH-based "devices" used during testing) are inappropriate.
Configuring STONITH Find the correct driver: stonith -L Since every device is different, the parameters needed to configure it will vary. To find out the parameters required by the device: stonith -t type -n Hopefully the developers chose names that make sense, if not you can query for some additional information by finding an active cluster node and running: lrmadmin -M stonith type pacemaker The output should be XML formatted text containing additional parameter descriptions Create a file called stonith.xml containing a primitive resource with a class of stonith, a type of type and a parameter for each of the values returned in step 2 Create a clone from the primitive resource if the device can shoot more than one node and supports multiple simultaneous connections. Upload it into the CIB using cibadmin: cibadmin -C -o resources --xml-file stonith.xml
Example Assuming we have an IBM BladeCenter consisting of four nodes and the management interface is active on 10.0.0.1, then we would chose the external/ibmrsa driver in step 2 and obtain the following list of parameters
Obtaining a list of STONITH Parameters stonith -t external/ibmrsa -n hostname ipaddr userid passwd type
from which we would create a STONITH resource fragment that might look like this Sample STONITH Resource - + ]]>