[ClusterLabs] Booth ticket multi-site and quorum /Pacemaker

[Jan Friesse]

Hi,

On 24/02/2022 14:19, Viet Nguyen wrote:
> Hi,
> 
> Thank you so much! Would you please advise more on this following case:
> 
> The cluster I am trying to setup is Postgresql with replication streaming
> with PAF. So, it will decide one node as a master and 3 standby nodes.
> 
> So, with this, from what I understand from Postgresql, having 2 independent
> clusters (one in site A, one in site B) is not possible. I have to go with
> one single cluster with 4 notes located in 2 different locations (site A
> and site B).
> 
> Then, my question is:
> 
>     1. Does the booth ticket work in this setup?

no, not really. booth basically creates cluster on top of 2+ clusters 
and arbitrator.

>     2. Is Qnetd a better option than booth ticket?

It's neither better nor worse. Qdevice (qnetd) adds a vote(s) to the 
quorum (corosync level). Booth is able to fulfill pacemaker constrain 
for ticket given only to one site in automated way.


>     3. Is there any better way to manage this?

If you can really use only one big cluster then probably none of booth 
or qdevice is needed.

>     4. Since we have a distributed site and arbitrator, does fencing make it
>     even more complicated? How I could solve this problem?

fencing is "must", it doesn't make it more complicated. Probably sbd but 
I have virtually no knowledge about that.


> 
> Sorry if my questions sound silly.... as I am very new to this and thank
> you so much for your help.

yw

Regards,
   Honza

> 
> Regards,
> Viet
> 
> On Thu, 24 Feb 2022 at 12:17, Jan Friesse <jfriesse at redhat.com> wrote:
> 
>> On 24/02/2022 10:28, Viet Nguyen wrote:
>>> Hi,
>>>
>>> Thank you so so much for your help. May i ask a following up question:
>>>
>>> For the option of having one big cluster with 4 nodes without booth,
>> then,
>>> if one site (having 2 nodes) is down, then the other site does not work
>> as
>>> it does not have quorum, am I right? Even if we have a quorum voter in
>>
>> Yup, you are right
>>
>>> either site A or B, then, if the site with quorum down, then, the other
>>> site does not work.  So, how can we avoid this situation as I want
>>> that if one site is down, the other site still services?
>>
>> probably only with qnetd - so basically yet again site C.
>>
>> Regards,
>>     Honza
>>
>>>
>>> Regards,
>>> Viet
>>>
>>> On Wed, 23 Feb 2022 at 17:08, Jan Friesse <jfriesse at redhat.com> wrote:
>>>
>>>> Viet,
>>>>
>>>> On 22/02/2022 22:37, Viet Nguyen wrote:
>>>>> Hi,
>>>>>
>>>>> Could you please help me out with this question?
>>>>>
>>>>> I have 4 nodes cluster running in the same network but in 2 different
>>>> sites
>>>>> (building A - 2 nodes and building B - 2 nodes). My objective is to
>>>>> setup HA for this cluster with pacemaker. The expectation is if a site
>> is
>>>>> down, the other site still services.
>>>>>
>>>>>    From what I could understand so far, in order to make it work, it
>> needs
>>>> to
>>>>> have booth ticket manager installed in a different location, let's say
>>>>> building C which connects to both sites A and B.
>>>>>
>>>>> With this assumption, i would like to ask few questions:
>>>>>
>>>>>       1. Am i right that I need to setup the booth ticket manager as a
>>>> quorum
>>>>>       voter as well?
>>>>
>>>> Yes, booth (arbitrator) has to be installed on "site" C if you want to
>>>> use booth. Just keep in mind booth has nothing to do with quorum.
>>>>
>>>>>       2. What happens if  the connection between site A and B is down,
>> but
>>>> the
>>>>>       connection between A and C, B and C still up? In this case, both
>>>> site A and
>>>>>       B still have the quorum as it can connect to C, but not between
>> each
>>>> other?
>>>>
>>>> If you use booth then it's not required site A to see site B. It's then
>>>> "site" C problem to decide which site gets ticket.
>>>>
>>>>
>>>>>       3. Or is there any better way to manage 2 sites cluster, each has
>> 2
>>>>>       nodes? And if one site is down like environmental disaster, then,
>>>> the other
>>>>>       site still services.
>>>>
>>>> Basically there are (at least) two possible solutions:
>>>> - Have one big cluster without booth and use pcmk constraints
>>>> - Have two 2 node clusters and use booth. Then each of the two node
>>>> clusters is "independent" (have its own quorum) and each of the cluster
>>>> runs booth (site) as a cluster resource + "site" C running booth
>>>> (arbitrator)
>>>>
>>>> Regards,
>>>>      Honza
>>>>
>>>>>
>>>>>
>>>>> Thank you so much for your help!
>>>>> Regards,
>>>>> Viet
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Manage your subscription:
>>>>> https://lists.clusterlabs.org/mailman/listinfo/users
>>>>>
>>>>> ClusterLabs home: https://www.clusterlabs.org/
>>>>>
>>>>
>>>>
>>>
>>
>>
>