[ClusterLabs] qnetd and booth arbitrator running together in a 3rd geo site

[Rohit Saini]

Thanks Honza. I guess qnetd+booth will be best in my case as you also
suggested.

Regards,
Rohit

On Tue, Jul 14, 2020 at 5:19 PM Jan Friesse <jfriesse at redhat.com> wrote:

> Rohit,
>
> > I dont think my question was very clear. I am strictly NO for STONITH.
> > STONITH is limited only for kvm or HP machines. That's the reason I don't
>
> Nope, stonith is not limited only for KVM or HP machine. There is huge
> amount of fence agents for various HW and VMs
> (https://github.com/ClusterLabs/fence-agents/tree/master/agents). Also
> there is SBD.
>
>
> > want to use STONITH.
> > What my question is can I use booth with nodes of a single cluster also
> > (similar to qdevice)? So idea is to use booth arbitrator for cluster of
>
> Standard way to use booth is to have 2 clusters with N nodes. On each
> cluster, there is clustered booth, which is running in active-passive
> fashion (so only on one of the nodes of the cluster). And this booth
> gives ticket depending on booth arbitrator decision. And final piece of
> puzzle is pacemaker resource which depends on ownership of ticket.
>
>
> > clusters AS WELL AS for a single cluster.
>
> So something like a booth resource in one cluster depending on booth
> ticket given by some locally running booth? I would say in theory it is
> possible, but I would say original idea of using both qnetd and booth
> looked a bit more "standard".
>
> Honza
>
> >
> >
> > On Tue, Jul 14, 2020 at 4:42 PM Jan Friesse <jfriesse at redhat.com> wrote:
> >
> >> Rohit,
> >>
> >>> Thanks Honja. That's helpful.
> >>> Let's say I don't use qnetd, can I achieve same with booth arbitrator?
> >>
> >> That means to have two two-node clusters. Two-node cluster without
> >> fencing is strictly no.
> >>
> >>> Booth arbitrator works for geo-clusters, can the same arbitrator be
> >> reused
> >>> for local clusters as well?
> >>
> >> I'm not sure that I understand question. Booth just gives ticket to
> >> (maximally) one of booth-sites.
> >>
> >>
> >>> Is it even possible technically?
> >>
> >> The question is, what you are trying to achieve. If geo-cluster then
> >> stonith for sites + booth is probably best solution. If the cluster is
> >> more like a stretch cluster, then qnetd + stonith is enough.
> >>
> >> And of course your idea (original one) should work too.
> >>
> >> Honza
> >>
> >>
> >>>
> >>> Regards,
> >>> Rohit
> >>>
> >>> On Tue, Jul 14, 2020 at 3:32 PM Jan Friesse <jfriesse at redhat.com>
> wrote:
> >>>
> >>>> Rohit,
> >>>>
> >>>>> Hi Team,
> >>>>> Can I execute corosync-qnetd and booth-arbitrator on the same VM in a
> >>>>> different geo site? What's the recommendation? Will it have any
> >>>> limitations
> >>>>> in a production deployment?
> >>>>
> >>>> There is no technical limitation. Both qnetd and booth are very
> >>>> lightweight and work just fine with high latency links.
> >>>>
> >>>> But I don't really have any real-life experiences with deployment
> where
> >>>> both booth and qnetd are used. It should work, but I would recommend
> >>>> proper testing - especially what happens when arbitrator node
> >> disappears.
> >>>>
> >>>>> Due to my architecture limitation, I have only one arbitrator
> available
> >>>>> which is on a 3rd site. To handle cluster split-brain errors, I am
> >>>> thinking
> >>>>> to use same arbitrator for local cluster as well.
> >>>>> STONITH is not useful in my case as it is limited only to ILO and
> VIRT.
> >>>>
> >>>> Keep in mind that neither qdevice nor booth is "replacement" for
> >> stonith.
> >>>>
> >>>> Regards,
> >>>>      Honza
> >>>>
> >>>>>
> >>>>> [image: image.png]
> >>>>>
> >>>>> Thanks,
> >>>>> Rohit
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Manage your subscription:
> >>>>> https://lists.clusterlabs.org/mailman/listinfo/users
> >>>>>
> >>>>> ClusterLabs home: https://www.clusterlabs.org/
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clusterlabs.org/pipermail/users/attachments/20200714/e3756fc3/attachment-0001.htm>