Hi, Thank you so much for the answer. It seems to me that the one option I am having is one big cluster with 4 nodes.
However, i still can not understand how i could solve the issue when one site with 2 nodes is down, then the other site along does not have quorum so it does not work... Can you please explain more on the approach for one big cluster? I am opened to another other solutions either commercial or open-source if available. Regards, Viet On Thu, 24 Feb 2022 at 18:22, Jan Friesse <jfrie...@redhat.com> wrote: > 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 <jfrie...@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 <jfrie...@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/ > >>>>> > >>>> > >>>> > >>> > >> > >> > > > >
_______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/