[Pacemaker] Location based on resource utilization

Andreas Kurz andreas at hastexo.com
Tue Oct 25 18:12:03 EDT 2011


hello,

On 10/25/2011 05:41 PM, agutxi Agustin wrote:
> Thank you Andreas!
> that's exactly what I was looking for :)
> I guess I was stuck with the documents from the older release.
> 
> however, if you know the answer, I still would like to know (once I
> posed myself the question, I'm curious) if it's a good practice to
> mess with the CRM from the resource agents script code or not.

There is no need to change any code of resource agents to get
utilization based resource location to work ... so: no, it is not good
practice ;-) ... if that was your question ....

Regards,
Andreas

-- 
Need help with Pacemaker?
http://www.hastexo.com/now


> 
> Regards,
> agutxi
> 
> 2011/10/25 Andreas Kurz <andreas at hastexo.com>:
>> On 10/25/2011 01:36 AM, agutxi Agustin wrote:
>>> Hi list,
>>> I'm new to pacemaker (though I've fought my battles with former
>>> heartbeat), so please don't go harsh on me ;D
>>> I have read through all the documentation I found in the internet for
>>> corosync/pacemaker/ras and have done and tested a few lab scenarios to
>>> build up my knowledge, but in this case, I couldn't figure it out and
>>> Google sent me over and over to the same posts, so I decided to ask
>>> for some clues
>>
>> then you asked google the wrong questions ;-)
>>
>> http://theclusterguy.clusterlabs.org/post/570381880/feature-spotlight-utilization
>>
>> ... might be the feature you are looking for.
>>
>> Regards,
>> Andreas
>>
>> --
>> Need help with Pacemaker?
>> http://www.hastexo.com/now
>>
>>
>>>
>>> Im planning a pacemaker design based on resource utilization.
>>> I want to have a number of light VMs running on top of a few phisical
>>> machines (PMs from now on).
>>> Ideally, every PM will be able to run n VMs, but will be running n-1,
>>> so the load will be distributed among the nodes instead of overloading
>>> one if all are available, and fall back to other nodes if one PM
>>> fails,
>>>
>>> I have found no way to find the number of resources (same type, or
>>> even global) running on a node and use that in a rule for location
>>> constraint.
>>> Is this possible?
>>> another way to do this would be to update some cluster nodes
>>> properties in the Resource Agents operations code. Is this an accepted
>>> and proper behaviour or is there a reason to avoid it?
>>>
>>> Thank you for your time,
>>> agutxi @
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> "Human beings make life so interesting. Do you know, that in a
>>> universe so full of wonders, they have managed to invent boredom."
>>> Terry Pratchet - Hogfather
>>>
>>> _______________________________________________
>>> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>>>
>>> Project Home: http://www.clusterlabs.org
>>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>> Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
>>
>>
>>
>>
>> _______________________________________________
>> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>>
>> Project Home: http://www.clusterlabs.org
>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>> Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
>>
>>
> 
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 286 bytes
Desc: OpenPGP digital signature
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20111026/05b8cb5b/attachment-0003.sig>


More information about the Pacemaker mailing list