[Pacemaker] Resource capacity limit

[Yan Gao]

Hi Lars,
Thanks for the great suggestions!

Lars Marowsky-Bree wrote:
> On 2009-10-30T19:41:35, Yan Gao <ygao at novell.com> wrote:
>>
>> Configuration example:
>>
>> node yingying \
>> 	attributes capacity="100"
>> primitive dummy0 ocf:heartbeat:Dummy \
>> 	meta weight="90" priority="2"
>> primitive dummy1 ocf:heartbeat:Dummy \
>> 	meta weight="60" priority="1"
>> ..
>> property $id="cib-bootstrap-options" \
>> 	limit-capacity="true"
> 
> First, I would prefer not to contaminate the regular node attribute
> namespace; the word "capacity" might already be used. Second, the
> "weight" is just one dimension, which is somewhat difficult.
> 
> I'd propose to introduce a new XML element, "resource_utilization" (name
> to be decided ;-) containing a "nvset", and which can be used in a node
> element or a resource primitive.
> 
> This creates a new namespace, avoiding clashes, and distinguishes the
> utilization parameters from the other various attributes.
> 
> Further, it trivially allows for several user-defined metrics.
Right, great idea! I'll try to implement it if Andrew is OK with that either:)

> 
> node hex-0 \
> 	utilization memory="4096" cpu="8"
> ...
> primitive dummy0 ocf:heartbeat:Dummy \
> 	meta priority="2"
> 	utilization memory="2048" cpu="2"
> primitive dummy1 ocf:heartbeat:Dummy \
> 	utilization memory="3012"
> primitive dummy2 ocf:heartbeat:Dummy \
> 	utilization cpu="6"
> 
> dummy0 + dummy2 could both be placed on hex-0, or dummy1+dummy2, but not
> dummy0 + dummy1.
> 
> "Placement allowed where none of the utilization parameters would become
> negative." (ie, iterate over the utilization attributes specified for
> the resource.)
> 
>> I also noticed a likely similar planned feature described in
>> http://clusterlabs.org/wiki/Planned_Features
>>
>> "Implement adaptive service placement (based on the RAM, CPU etc.
>> required by the service and made available by the nodes) "
>>
>> Indeed, this try only supports single kind of capacity, and it's not
>> adaptive... Do you already have a thorough consideration about this
>> feature?
> 
> I think this is a two phase feature for the PE: The first phase is what
> you propose - make sure we do not overload any given node, basically
> implementing hard limits.
> 
> The second phase would be for the PE to actually try to "optimize"
> placement, and try to solve the constraints imposed by the utilization
> versus capacity scores to a) place as many resources as possible
> successfully, and b) to either spread them thinly (load distribution) or
> condensed (load concentration, think power savings by being able to put
> some nodes to sleep).
> 
> The first phase should, IMHO, be quite easy to implement. The second one
> is significantly more difficult, and we'd need to pull in an
> optimization library to solve this for us. It's conceivable that for
> this to happen, we'd need to disable the normal "rsc_location" rules
> altogether because they'd interfere badly. (And interesting to note that
> the rsc_collocation constraints can be mapped into this scheme and
> entirely handled by this solver.)
> 
> There is the "adaptive" bit, of course, where the utilization of the
> resources and the nodes is automatically determined and adjusted based
> on utilization monitoring. This is even more challenging and frequently
> considered a research problem.
> 
> 
> In summary, I think phase one is urgently needed; thankfully, it is
> straightforward to solve too, and the admin can influence placement with
> priorities and scoring sufficiently to avoid resources being offlined
> due to resource collisions too frequently.
> 
> Phase two is a "solved problem" from an algorithmic point of view, but
> implementing it is probably not quite as trivial. I'd welcome to see
> this happening too.
> 
Thanks for the information!

Best regards,
  Yan

-- 
ygao at novell.com
Software Engineer
China Server Team, OPS Engineering

Novell, Inc.
Making IT Work As One™