I've written a perl script, modeled after the fence_drac script, to control
outlets on a TrippLite PDUMH15ATNET PDU, and I'd like to contribute it to the
community.
What do I need to do to make the cluster software (RHCS 5.2, under
CentOS 5.2, cman version 2.0.84) aware of the new agent so that I can
complete testing?
I've tried adding fencing methods and new fencedevice entries to
my cluster configuration, and there are no typos ("xmllint --noout
/etc/cluster/cluster.conf" runs cleanly).
There are no errors on the command-line or in log files when I use
"ccs_tool update /etc/cluster/cluster.conf" and "cman_tool version"
to update and propagate the new cluster configuration.
However, when I run "xmllint --relaxng /usr/share/system-config-cluster/misc/cluster.ng /etc/cluster/cluster.conf 1> /dev/null" I get the following errors:
Relax-NG validity error : Extra element fencedevices in interleave
/etc/cluster/cluster.conf:2: element cluster: Relax-NG validity error : Element cluster failed to validate content
/etc/cluster/cluster.conf:15: element device: validity error : IDREF attribute name references an unknown ID "sbia-infr2-tripplite"
/etc/cluster/cluster.conf fails to validate
Here's an subset of /etc/cluster.conf:
=================================================================
<?xml version="1.0"?>
<cluster alias="cluster" config_version="108" name="cluster>
<fence_daemon clean_start="1" post_fail_delay="0" post_join_delay="30"/>
<clusternodes>
<clusternode name="infr2" nodeid="1" votes="1">
<fence>
<method name="1">
<device modulename="" name="infr2-drac"/>
</method>
<method name="2">
<device name="sphereon" port="2"/>
<device name="sphereon" port="6"/>
</method>
<method name="3">
<device name="infr2-tripplite"/>
</method>
</fence>
</clusternode>
<clusternode name="infr1" nodeid="2" votes="1">
<fence>
<method name="1">
<device modulename="" name="infr1-drac"/>
</method>
<method name="2">
<device name="sphereon" port="0"/>
<device name="sphereon" port="4"/>
</method>
<method name="3">
<device name="infr1-tripplite"/>
</method>
</fence>
</clusternode>
</clusternodes>
<cman expected_votes="2" two_node="0"/>
<fencedevices>
<fencedevice agent="fence_mcdata" ipaddr="192.168.110.11" login="Administrator" name="sphereon" passwd_script="getpw_sphereon"/>
<fencedevice agent="fence_drac" ipaddr="192.168.110.202" login="root" name="infr1-drac" passwd_script="getpw_infr1-drac"/>
<fencedevice agent="fence_drac" ipaddr="192.168.110.203" login="root" name="infr2-drac" passwd_script="getpw_infr2-drac"/>
<fencedevice agent="fence_tripplite" name="infr1-tripplite" ipaddr="pdu1" passwd_script="getpw_infr2-drac" operation="off" receptacle1="1" receptacle2="3"/>
<fencedevice agent="fence_tripplite" name="infr2-tripplite" ipaddr="pdu1" passwd_script="getpw_infr2-drac" operation="off" receptacle1="2" receptacle2="4"/>
</fencedevices>
=================================================================
Finally, I'd like to warn people away from using the TrippLite PDU model
PDUMH15ATNET as a fencing device. While it seems to have nice features, it
has a design choice that is a serious problem with fencing--when a command
is given to power down an outlet, there is a "random" delay (observed
to be about 17 to 35 seconds) before that command is executed. This has
been acknowledged by TrippLite support as a design choice, with no option
or setting to override this behavior.
Thanks,
Mark
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
