<div dir="ltr">Hmm. I will then work towards bringing this in. Thanks for your input.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 22, 2016 at 10:44 AM, Digimer <span dir="ltr"><<a href="mailto:lists@alteeve.ca" target="_blank">lists@alteeve.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 22/06/16 01:07 AM, Nikhil Utane wrote:<br>
> I don't get it.  Pacemaker + Corosync is providing me so much of<br>
> functionality.<br>
> For e.g. if we leave out the condition of split-brain for a while, then<br>
> it provides:<br>
> 1) Discovery and cluster formation<br>
> 2) Synchronization of data<br>
> 3) Heartbeat mechanism<br>
> 4) Swift failover of the resource<br>
> 5) Guarantee that one resource will be started on only 1 node<br>
><br>
> So in case of normal fail-over we need the basic functionality of<br>
> resource being migrated to a standby node.<br>
> And it is giving me all that.<br>
> So I don't agree that it needs to be as black and white as you say. Our<br>
> solution has different requirements than a typical HA solution. But that<br>
> is only now. In the future we might have to implement all the things. So<br>
> in that sense Pacemaker gives us a good framework that we can extend.<br>
><br>
> BTW, we are not even using a virtual IP resource which again I believe<br>
> is something that everyone employs.<br>
> Because of the nature of the service a small glitch is going to happen.<br>
> Using virtual IPs is not giving any real benefit for us.<br>
> And with regard to the question, why even have a standby and let it be<br>
> active all the time, two-node cluster is one of the possible<br>
> configuration, but main requirement is to support N + 1. So standby node<br>
> doesn't know which active it has to take over until a failover occurs.<br>
><br>
> Your comments however has made me re-consider using fencing. It was not<br>
> that we didn't want to do it.<br>
> Just that I felt it may not be needed. So I'll definitely explore this<br>
> further.<br>
<br>
</div></div>It is needed, and it is that black and white. Ask yourself, for your<br>
particular installation; Can I run X in two places at the same time<br>
without coordination?<br>
<br>
If the answer is "yes", then just do that and be done with it.<br>
<br>
If the answer is "no", then you need fencing to allow pacemaker to know<br>
the state of all nodes (otherwise, the ability to coordinate is lost).<br>
<br>
I've never once seen a valid HA setup where fencing was not needed. I<br>
don't claim to be the best by any means, but I've been around long<br>
enough to say this with some confidence.<br>
<br>
digimer<br>
<span class=""><br>
> Thanks everyone for the comments.<br>
><br>
> -Regards<br>
> Nikhil<br>
><br>
> On Tue, Jun 21, 2016 at 10:17 PM, Digimer <<a href="mailto:lists@alteeve.ca">lists@alteeve.ca</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:lists@alteeve.ca">lists@alteeve.ca</a>>> wrote:<br>
><br>
>     On 21/06/16 10:57 AM, Dmitri Maziuk wrote:<br>
>     > On 2016-06-20 17:19, Digimer wrote:<br>
>     ><br>
>     >> Nikhil indicated that they could switch where traffic went up-stream<br>
>     >> without issue, if I understood properly.<br>
>     ><br>
>     > They have some interesting setup, but that notwithstanding: if split<br>
>     > brain happens some clients will connect to "old master" and some: to<br>
>     > "new master", dep. on arp update. If there's a shared resource<br>
>     > unavailable on one node, clients going there will error out. The other<br>
>     > ones will not. It will work for some clients.<br>
>     ><br>
>     > Cf. both nodes going into stonith deathmatch and killing each other: the<br>
>     > service now is not available for all clients. What I don't get is the<br>
>     > blanket assertion that this "more highly" available that option #1.<br>
>     ><br>
>     > Dimitri<br>
><br>
>     As I've explained many times (here and on IRC);<br>
><br>
>     If you don't need to coordinate services/access, you don't need HA.<br>
><br>
>     If you do need to coordinate services/access, you need fencing.<br>
><br>
>     So if Nikhil really believes s/he doesn't need fencing and that<br>
>     split-brains are OK, then drop HA. If that is not the case, then s/he<br>
>     needs to implement fencing in pacemaker. It's pretty much that simple.<br>
><br>
>     --<br>
>     Digimer<br>
>     Papers and Projects: <a href="https://alteeve.ca/w/" rel="noreferrer" target="_blank">https://alteeve.ca/w/</a><br>
>     What if the cure for cancer is trapped in the mind of a person without<br>
>     access to education?<br>
><br>
>     _______________________________________________<br>
</div></div>>     Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a> <mailto:<a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a>><br>
<div class="HOEnZb"><div class="h5">>     <a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/mailman/listinfo/users</a><br>
><br>
>     Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
>     Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
>     Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
> <a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/mailman/listinfo/users</a><br>
><br>
> Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
> Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
> Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
><br>
<br>
<br>
--<br>
Digimer<br>
Papers and Projects: <a href="https://alteeve.ca/w/" rel="noreferrer" target="_blank">https://alteeve.ca/w/</a><br>
What if the cure for cancer is trapped in the mind of a person without<br>
access to education?<br>
<br>
_______________________________________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
<a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/mailman/listinfo/users</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
</div></div></blockquote></div><br></div>