Re: Tripp Lite switched PDU fence agent; exists?

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

 



On 3/18/2011 5:29 PM, Digimer wrote:
> On 03/18/2011 06:36 AM, Rajagopal Swaminathan wrote:
>> Greetings,
>>
>> On 3/17/11, bergman@xxxxxxxxxxxx <bergman@xxxxxxxxxxxx> wrote:
>>> The pithy ruminations from Digimer <linux@xxxxxxxxxxx> on "
>>> Tripp Lite switched PDU fence agent; exists?" were:
>>>
>>>
>>>
>>> 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.
>>>
>>
>> This "powerfence" should come nowhere near a production cluster.
>>
>> Such randomness can play havoc in the predictability of availability:
>> Just think two of those strips (A,B) used for each of the redundant
>> power inputs and they not being switched off together. can get _very_
>> messy.
>>
>> Just my 2paise
>>
>> Regards,
>>
>> Rajagopal
> 
> At the end of the day, I think the argument for or against a device's
> use should be secondary to it being supported. It's difficult to predict
> why a user may want to use a given piece of hardware. I'm hoping that
> adequate warnings in the docs to potential drawbacks will suffice.
> 
> As for this specific device, I'd not seen a review of it when I ordered
> it. I plan to write an amateur review and I will specifically test for
> these issues. If I can not find a safe way around queued fence calls,
> then I will certainly include that in the review. That should hopefully
> help steer people away from using this device, should the delay be a
> show-stopper for them.

Wouldn´t it be possible for the agent to:

1) issue OFF command
2) either poll for OFF status or wait > $known_random_max_delay
3) issue ON command
4) profit?

even if it takes time to fence, it would make it usable.

Not all fence devices are millisecond fast either...

Fabio

--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster



[Index of Archives]     [Corosync Cluster Engine]     [GFS]     [Linux Virtualization]     [Centos Virtualization]     [Centos]     [Linux RAID]     [Fedora Users]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Camping]

  Powered by Linux