[ClusterLabs] Antw: [EXT] Re: Stonith

Ulrich Windl Ulrich.Windl at rz.uni-regensburg.de
Tue Dec 20 02:07:11 EST 2022


>>> Andrei Borzenkov <arvidjaar at gmail.com> schrieb am 19.12.2022 um 14:17 in
Nachricht
<CAA91j0WC10f9h1MGPEs7R8VT2eaWtWtBHiwidgPGmEjZOWdXtw at mail.gmail.com>:
> On Mon, Dec 19, 2022 at 4:01 PM Antony Stone
> <Antony.Stone at ha.open.source.it> wrote:
>>
>> On Monday 19 December 2022 at 13:55:45, Andrei Borzenkov wrote:
>>
>> > On Mon, Dec 19, 2022 at 3:44 PM Antony Stone
>> >
>> > <Antony.Stone at ha.open.source.it> wrote:
>> > > So, do I simply create one stonith resource for each server, and rely on
>> > > some other random server to invoke it when needed?
>> >
>> > Yes, this is the most simple approach. You need to restrict this
>> > stonith resource to only one cluster node (set pcmk_host_list).
>>
>> So, just to be clear, I create one stonith resource for each machine which
>> needs to be able to be shut down by some other server?
>>
> 
> Correct.
> 
>> I ask simply because the acronym stonith refers to "the other node", so it
>> sounds to me more like something I need to define so that a working machine 
> can
>> kill another one.
>>
> 
> Yes, you define a stonith resource that can kill node A and nodes B,
> C, D, ... will use this resource to kill A when needed. As long as
> your stonith resource can actually work on any node it does not matter
> which one will do the killing. You can restrict which nodes can use
> this stonith agent using usual location constraints if necessary.
> 
> But keep in mind that if the whole site is down (or unaccessible) you
> will not have access to IPMI/PDU/whatever on this site so your stonith
> agents will fail ...

But, considering the design, such site won't have a quorum and should commit suicide, right?

> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users 
> 
> ClusterLabs home: https://www.clusterlabs.org/ 






More information about the Users mailing list