<div dir="ltr">That is what happened here :(. <div>When 2 nodes went down, two resources got scheduled on single node.</div><div>Isn't there any way to stop this from happening. Colocation constraint is not helping.</div><div><br></div><div>-Regards</div><div>Nikhil</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 22, 2016 at 12:57 AM, Vladislav Bogdanov <span dir="ltr"><<a href="mailto:bubble@hoster-ok.com" target="_blank">bubble@hoster-ok.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">21.10.2016 19:34, Andrei Borzenkov wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
14.10.2016 10:39, Vladislav Bogdanov пишет:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
use of utilization (balanced strategy) has one caveat: resources are<br>
not moved just because of utilization of one node is less, when nodes<br>
have the same allocation score for the resource. So, after the<br>
simultaneus outage of two nodes in a 5-node cluster, it may appear<br>
that one node runs two resources and two recovered nodes run<br>
nothing.<br>
<br>
</blockquote>
<br>
I call this a feature. Every resource move potentially means service<br>
outage, so it should not happen without explicit action.<br>
<br>
</blockquote>
<br></span>
In a case I describe that moves could be easily prevented by using stickiness (it increases allocation score on a current node).<br>
The issue is that it is impossible to "re-balance" resources in time-frames when stickiness is zero (over-night maintenance window).<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Original 'utilization' strategy only limits resource placement, it is<br>
not considered when choosing a node for a resource.<br>
<br>
</blockquote>
<br>
<br>
______________________________<wbr>_________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank">Users@clusterlabs.org</a><br>
<a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/mailman<wbr>/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<wbr>/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
<br>
</blockquote>
<br>
<br>
______________________________<wbr>_________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank">Users@clusterlabs.org</a><br>
<a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/mailman<wbr>/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<wbr>/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>