Hi all I had said last week I would post these, but it slipped my mind.
I have two stonith scripts here - they may not be complete, but they
work in my circumstances. Feel free to take these and
update/modify/fix/improve.
1. stonith_multi
This is a wrapper around multiple stonith agents to allow the use of
more than one agent. My usecase was that my primary agent was not
reliably connected to the servers for which it needed to act, and the
monitor would often time out (once a week or so). As I did not want to
be constantly cleaning up the failed resource, I wrote this script to
fall back to a backup agent. If at least one of the agents reports
success, the script will be successful. In my case, this meant that the
primary agent times out, but the secondary is successful, the monitor
action does not fail. Ditto for the stonith action as well.
A useful update to this would be a param like mode=all/any which would
change the mode of operation of stonith_multi to require all agents to
succeed (mode=all), or at least one (mode=any)
Configuration is a bit verbose, but is as follows (it supports up to 3
agents, with 7 params each, but that is easily tweakable in the file)
primitive STONITH stonith:external/stonith_multi \
params \
agent1="external/teracopdu" \
agent1_param1name="username" \
agent1_param1val="ch...@mydomain" \
agent1_param2name="password" \
agent1_param2val="mypassword" \
agent1_param3name="proxy" \
agent1_param3val="http://10.1.2.48:3128"; \
agent2="external/ecnipmi" \
agent2_param1name="hostname1" \
agent2_param1val="myhostname1.mydomain" \
agent2_param2name="ipaddr1" \
agent2_param2val="10.24.10.31" \
agent2_param3name="hostname2" \
agent2_param3val="myhostname2.mydomain" \
agent2_param4name="ipaddr2" \
agent2_param4val="10.24.10.32" \
agent2_param5name="userid" \
agent2_param5val="root" \
agent2_param6name="passwd" \
agent2_param6val="myipmipassword" \
op monitor interval="3m" timeout="60s"
The second one (multipdu) is an agent which can connect to multiple PDUs
and control all outlets associated with the required action/host
It is actually in two parts - the first is the agent itself, which is a
simple wrapper around a perl script which does the actual work. While
writing this I have noticed a bug/feature? which only allows the agent
to control nodes specified in /etc/ha.d/ha.cf, but if there are no node
specifications in /etc/ha.d/ha.cf, then it returns the full outlet list
from the pdu
As most pdus don't allow arbitrary length outlet names, the agent
accepts a domain parameter, so that you can use short hostnames on the
pdu, but map these to long hostnames in pacemaker:
primitive STONITH stonith:external/ecnpdu \
params \
pduip="10.12.3.190,10.12.3.191" \
community="privatestring" \
domain="ecntelecoms.za.net" \
op monitor interval="3m" timeout="15s"
The control script (/sbin/pdu-control) can manage multiple pdu types,
based on their sysObjectID
multipdu
Description: application/shellscript
pdu-control
Description: Perl program
stonith_multi
Description: Perl program
_______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
