[ClusterLabs] Antw: Re: spread out resources

[Alexandre]

This is true for opt-out clusters. Opt-in cluster only rely on location
constraints.

Regards
Le 4 avr. 2016 08:46, "Ulrich Windl" <Ulrich.Windl at rz.uni-regensburg.de> a
écrit :

> Hi!
>
> Actually form my SLES11 SP[1-4] experience, the cluster always distributes
> resources across all available nodes, and only if don't want that, I'll
> have to
> add constraints. I wonder why that does not seem to work for you.
>
> Regards,
> Ulrich
>
> >>> Ferenc Wágner <wferi at niif.hu> schrieb am 02.04.2016 um 10:28 in
> Nachricht
> <87egao9zyc.fsf at lant.ki.iif.hu>:
> > Ken Gaillot <kgaillot at redhat.com> writes:
> >
> >> On 03/30/2016 08:37 PM, Ferenc Wágner wrote:
> >>
> >>> I've got a couple of resources (A, B, C, D, ... more than cluster
> nodes)
> >>> that I want to spread out to different nodes as much as possible.  They
> >>> are all the same, there's no distinguished one amongst them.  I tried
> >>>
> >>> <rsc_colocation id="cl-test-spread" score="-50">
> >>>   <resource_set id="cl-test-spread-set" sequential="false">
> >>>     <resource_ref id="A"/>
> >>>     <resource_ref id="B"/>
> >>>     <resource_ref id="C"/>
> >>>     <resource_ref id="D"/>
> >>>   </resource_set>
> >>>   <resource_set id-ref="cl-test-spread-set"/>
> >>> </rsc_colocation>
> >>>
> >>> But crm_simulate did not finish with the above in the CIB.
> >>> What's a good way to get this working?
> >>
> >> Per the docs, "A colocated set with sequential=false makes sense only if
> >> there is another set in the constraint. Otherwise, the constraint has no
> >> effect." Using sequential=false would allow another set to depend on all
> >> these resources, without them depending on each other.
> >
> > That was the very idea behind the above colocation constraint: it
> > contains the same group twice.  Yeah, it's somewhat contrived, but I had
> > no other idea with any chance of success.  And this one failed as well.
> >
> >> I haven't actually tried resource sets with negative scores, so I'm not
> >> sure what happens there. With sequential=true, I'd guess that each
> >> resource would avoid the resource listed before it, but not necessarily
> >> any of the others.
> >
> > Probably, but that isn't what I'm after.
> >
> >> By default, pacemaker does spread things out as evenly as possible, so I
> >> don't think anything special is needed.
> >
> > Yes, but only on the scale of all resources.  And I've also got a
> > hundred independent ones, which wash out this global spreading effect if
> > you consider only a select handful.
> >
> >> If you want more control over the assignment, you can look into
> >> placement strategies:
> >
> > We use balanced placement to account for the different memory
> > requirements of the various resources globally.  It would be possible to
> > introduce a new, artifical utilization "dimension" for each resource
> > group we want to spread independently, but this doesn't sound very
> > compelling.  For sets of two resources, a simple negative colocation
> > constraint works very well; it'd be a pity if it wasn't possible to
> > extend this concept to larger sets.
> > --
> > Thanks,
> > Feri
> >
> > _______________________________________________
> > Users mailing list: Users at clusterlabs.org
> > http://clusterlabs.org/mailman/listinfo/users
> >
> > Project Home: http://www.clusterlabs.org
> > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> > Bugs: http://bugs.clusterlabs.org
>
>
>
>
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://clusterlabs.org/pipermail/users/attachments/20160404/4bc3be7c/attachment.html>