Note: This is a proposal still and under reasonable heavy discussion. Please read the NodeFencing[1] page in addition to this one; this page only explains the implementation of the STONITH Agents, not the integration into the CRM design.

StonithAgents[2] are essentially a special ResourceAgentClass[3] (in minor extension of the OCF ones), but named differently to avoid any confusion right away. In particular, they are very similar to OpenClusterFramework[4] resource agents[5], with the following differences:

• They are not located under /usr/ocf, but under /usr/lib/heartbeat/stonith.d/.

• For every STONITH method, there is one agent. They likely will all call into the same STONITH backend initially (ie, be a wrapper around the existing heartbeat STONITH plug-ins), but complement them. However, this also means that we have an additional plug-in structure, so that people can chose.

• On start, they start a daemon process to connect to the STONITH device; this is the instantiation of what is called the STONITH Controller in the NodeFencing[1] page. This daemon monitors and controls the STONITH Device, and, if possible/necessary, does what is needed to ensure that we are the only one accessing the device (so that no other task interferes).

• Surprisingly, on stop, said daemon is stopped and thus the ownership of the STONITH Device released.

• monitor does just what it does for regular resources; it verifies whether the daemon is still running and performs a health check request by which the daemon reports whether it can still reach the STONITH Device.

There is two additional commands which the StonithAgents[2] must support:

• The fence operation, which we supply with a comma-separated list of node names to fence (via a OCF_RESKEY_STONITH_NODES environment variable) and report back on stdout for each node name whether the STONITH operation was successful or not. A non-zero exit code on the fence operation shall be interpreted a complete failure to reach the STONITH device, so the CRM can reallocate the STONITH controller resource on another node, if applicable.

• The list-fence-targets which - after the resource has been started - reports the list of nodes which the device controls to stdout (which is already relayed back to us via the LocalResourceManager[6]).

SunJiangDong[7] said: According to the new node fencing architecture, now there is no actual StonithAgent[8] scripts, only function simulation via stonith RA plugin plus the stonith daemon. Moreover, the functions corresponding to the above two operations will be moved to and implemented in node fencing daemon's API library, there will be no these two opertations on virtual StonithAgents[2]. In other word, now these virtual StonithAgents[2] act more like the standard OCF RAs. Please refer to SmartFencingDaemonProposal[9]. Any comment?

Extension under discussion:

• The monitor operation shall not only report back whether or not the STONITH device they control is reachable or not, but will also signal if the list of nodes it could control has changed, so we can dynamically reload it. As the daemon can easily track this, this would be most helpful so that we are notified when this list changes and thus can reload it dynamically. But AlanRobertson[10] really doesn't seem to like this, but LarsMarowskyBree[11] still hopes to convince him

See also

NodeFencing[1], LocalResourceManager/FencingOperations[12]

---

This information provided courtesy of the Linux-HA project at http://linux-ha.org/