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