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/
