[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Linux-cluster] use of delayed power mgmt device for fencing?

I'm setting up a 2-node cluster (CentOS5).  The nodes are connected to a 
Tripplite "8-Outlet Metered PDU with Automatic Transfer Switching"
(Manufacturer Part# : PDUMH15ATNET). I've written an expect script to enable 
each node to power off the other node. This seems like the preferred method for 
cluster fencing, except for a potentially serious defect with the Tripplite PDU:

	upon receipt of the command to power down an outlet, the PDU delays
	powering down the outlet for a variable period of about 15~20 seconds

The manufacturer states that the delay is intentional, unavoidable, cannot be 
configured, and will not be eliminated in future firware releases to the PDU.

My concern is that in case of a loss of cluster communication, each node will 
attempt to power down the other, and the delay will cause both nodes to send 
the power-down command to the PDU, shutting down the entire cluster when the 
PDU acts on the commands.

I am considering a scheme where the nodes would do something like:

	sleep 20 * $nodenumber
	powerdown $othernode

while this is extensible if I add more nodes to the cluster in the future, it 
means that the potential split-brain period could continue for several minutes, 
and that the lower numbered nodes would always have "priority". I'm concerned 
about data corruption during the delay period.

Do you see any reasonable way to use this power management switch for cluster 

The nodes are on a SAN, and could be configured to use a quorum disk or a SAN
switch for fencing as an alternative. The nodes could also be set up to use 
IPMI for power fencing.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]