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

Re: [Linux-cluster] Tripp Lite switched PDU fence agent; exists?



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 merctech com <bergman merctech com> wrote:
>>> The pithy ruminations from Digimer <linux alteeve com> on "[Linux-cluster]
>>> 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


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