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

Viet Nguyen vietnguyen1254 at gmail.com
Thu Feb 24 08:19:33 EST 2022


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?
   2. Is Qnetd a better option than booth ticket?
   3. Is there any better way to manage this?
   4. Since we have a distributed site and arbitrator, does fencing make it
   even more complicated? How I could solve this problem?

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

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/
> >>>
> >>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20220224/18ef1b6d/attachment.htm>


More information about the Users mailing list