Novell LINUX ENTERPRISE 11 - HIGH AVAILABILITY, Руководство пользователя, Страница: 96 / 298

Example 8.3 Testing Configuration
A more realistic example (but still only for testing) is the following external/ssh confi-
guration:
configure
primitive st-ssh stonith:external/ssh \
params hostlist="node1 node2"
clone fencing st-ssh
commit
This one can also reset nodes. The configuration is remarkably similar to the first one
which features the null STONITH device. In this example, clones are used. They are a
CRM/Pacemaker feature. A clone is basically a shortcut: instead of defining
n
identical,
yet differently-named resources, a single cloned resource suffices. By far the most
common use of clones is with STONITH resources, as long as the STONITH device
is accessible from all nodes.
Example 8.4 Configuration of an IBM RSA Lights-out Device
The real device configuration is not much different, though some devices may require
more attributes. An IBM RSA lights-out device might be configured like this:
configure
primitive st-ibmrsa-1 stonith:external/ibmrsa-telnet \
params nodename=node1 ipaddr=192.168.0.101 \
userid=USERID passwd=PASSW0RD
primitive st-ibmrsa-2 stonith:external/ibmrsa-telnet \
params nodename=node2 ipaddr=192.168.0.102 \
userid=USERID passwd=PASSW0RD
location l-st-node1 st-ibmrsa-1 -inf: node1
location l-st-node2 st-ibmrsa-2 -inf: node2
commit
In this example, location constraints are used because of the following reason: There
is always a certain probability that the STONITH operation is going to fail. Therefore,
a STONITH operation (on the node which is the executioner, as well) is not reliable.
If the node is reset, then it cannot send the notification about the fencing operation
outcome. The only way to do that is to assume that the operation is going to succeed
and send the notification beforehand. But problems could arise if the operation fails.
Therefore, stonithd refuses to kill its host.
86 High Availability Guide