<div dir="ltr">Hi,<div><br></div><div>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. </div><div><br></div><div>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...</div><div><br></div><div>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. </div><div><br></div><div>Regards,</div><div>Viet</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 24 Feb 2022 at 18:22, Jan Friesse <<a href="mailto:jfriesse@redhat.com">jfriesse@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On 24/02/2022 14:19, Viet Nguyen wrote:<br>
> Hi,<br>
> <br>
> Thank you so much! Would you please advise more on this following case:<br>
> <br>
> The cluster I am trying to setup is Postgresql with replication streaming<br>
> with PAF. So, it will decide one node as a master and 3 standby nodes.<br>
> <br>
> So, with this, from what I understand from Postgresql, having 2 independent<br>
> clusters (one in site A, one in site B) is not possible. I have to go with<br>
> one single cluster with 4 notes located in 2 different locations (site A<br>
> and site B).<br>
> <br>
> Then, my question is:<br>
> <br>
>     1. Does the booth ticket work in this setup?<br>
<br>
no, not really. booth basically creates cluster on top of 2+ clusters <br>
and arbitrator.<br>
<br>
>     2. Is Qnetd a better option than booth ticket?<br>
<br>
It's neither better nor worse. Qdevice (qnetd) adds a vote(s) to the <br>
quorum (corosync level). Booth is able to fulfill pacemaker constrain <br>
for ticket given only to one site in automated way.<br>
<br>
<br>
>     3. Is there any better way to manage this?<br>
<br>
If you can really use only one big cluster then probably none of booth <br>
or qdevice is needed.<br>
<br>
>     4. Since we have a distributed site and arbitrator, does fencing make it<br>
>     even more complicated? How I could solve this problem?<br>
<br>
fencing is "must", it doesn't make it more complicated. Probably sbd but <br>
I have virtually no knowledge about that.<br>
<br>
<br>
> <br>
> Sorry if my questions sound silly.... as I am very new to this and thank<br>
> you so much for your help.<br>
<br>
yw<br>
<br>
Regards,<br>
   Honza<br>
<br>
> <br>
> Regards,<br>
> Viet<br>
> <br>
> On Thu, 24 Feb 2022 at 12:17, Jan Friesse <<a href="mailto:jfriesse@redhat.com" target="_blank">jfriesse@redhat.com</a>> wrote:<br>
> <br>
>> On 24/02/2022 10:28, Viet Nguyen wrote:<br>
>>> Hi,<br>
>>><br>
>>> Thank you so so much for your help. May i ask a following up question:<br>
>>><br>
>>> For the option of having one big cluster with 4 nodes without booth,<br>
>> then,<br>
>>> if one site (having 2 nodes) is down, then the other site does not work<br>
>> as<br>
>>> it does not have quorum, am I right? Even if we have a quorum voter in<br>
>><br>
>> Yup, you are right<br>
>><br>
>>> either site A or B, then, if the site with quorum down, then, the other<br>
>>> site does not work.  So, how can we avoid this situation as I want<br>
>>> that if one site is down, the other site still services?<br>
>><br>
>> probably only with qnetd - so basically yet again site C.<br>
>><br>
>> Regards,<br>
>>     Honza<br>
>><br>
>>><br>
>>> Regards,<br>
>>> Viet<br>
>>><br>
>>> On Wed, 23 Feb 2022 at 17:08, Jan Friesse <<a href="mailto:jfriesse@redhat.com" target="_blank">jfriesse@redhat.com</a>> wrote:<br>
>>><br>
>>>> Viet,<br>
>>>><br>
>>>> On 22/02/2022 22:37, Viet Nguyen wrote:<br>
>>>>> Hi,<br>
>>>>><br>
>>>>> Could you please help me out with this question?<br>
>>>>><br>
>>>>> I have 4 nodes cluster running in the same network but in 2 different<br>
>>>> sites<br>
>>>>> (building A - 2 nodes and building B - 2 nodes). My objective is to<br>
>>>>> setup HA for this cluster with pacemaker. The expectation is if a site<br>
>> is<br>
>>>>> down, the other site still services.<br>
>>>>><br>
>>>>>    From what I could understand so far, in order to make it work, it<br>
>> needs<br>
>>>> to<br>
>>>>> have booth ticket manager installed in a different location, let's say<br>
>>>>> building C which connects to both sites A and B.<br>
>>>>><br>
>>>>> With this assumption, i would like to ask few questions:<br>
>>>>><br>
>>>>>       1. Am i right that I need to setup the booth ticket manager as a<br>
>>>> quorum<br>
>>>>>       voter as well?<br>
>>>><br>
>>>> Yes, booth (arbitrator) has to be installed on "site" C if you want to<br>
>>>> use booth. Just keep in mind booth has nothing to do with quorum.<br>
>>>><br>
>>>>>       2. What happens if  the connection between site A and B is down,<br>
>> but<br>
>>>> the<br>
>>>>>       connection between A and C, B and C still up? In this case, both<br>
>>>> site A and<br>
>>>>>       B still have the quorum as it can connect to C, but not between<br>
>> each<br>
>>>> other?<br>
>>>><br>
>>>> If you use booth then it's not required site A to see site B. It's then<br>
>>>> "site" C problem to decide which site gets ticket.<br>
>>>><br>
>>>><br>
>>>>>       3. Or is there any better way to manage 2 sites cluster, each has<br>
>> 2<br>
>>>>>       nodes? And if one site is down like environmental disaster, then,<br>
>>>> the other<br>
>>>>>       site still services.<br>
>>>><br>
>>>> Basically there are (at least) two possible solutions:<br>
>>>> - Have one big cluster without booth and use pcmk constraints<br>
>>>> - Have two 2 node clusters and use booth. Then each of the two node<br>
>>>> clusters is "independent" (have its own quorum) and each of the cluster<br>
>>>> runs booth (site) as a cluster resource + "site" C running booth<br>
>>>> (arbitrator)<br>
>>>><br>
>>>> Regards,<br>
>>>>      Honza<br>
>>>><br>
>>>>><br>
>>>>><br>
>>>>> Thank you so much for your help!<br>
>>>>> Regards,<br>
>>>>> Viet<br>
>>>>><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> Manage your subscription:<br>
>>>>> <a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
>>>>><br>
>>>>> ClusterLabs home: <a href="https://www.clusterlabs.org/" rel="noreferrer" target="_blank">https://www.clusterlabs.org/</a><br>
>>>>><br>
>>>><br>
>>>><br>
>>><br>
>><br>
>><br>
> <br>
<br>
</blockquote></div>