[Pacemaker] System Health

Mark Hamzy hamzy at us.ibm.com
Fri May 8 20:00:00 UTC 2009


andrew at beekhof.net wrote on 05/08/2009 13:26:16 PM:
> On Thu, May 7, 2009 at 10:24 PM, Mark Hamzy <hamzy at us.ibm.com> wrote:
>
> So what I think we need is the scores:
>  - node-health-score-red (defaults to -INFINITY),
>  - node-health-score-yellow (defaults to 0),
>  - node-health-score-green (defaults to 0),,
>
> These would work like the INFINITY an -INFINITY aliases (see char2score
()).
> So "red", "yellow" and "green" would be allowed anyway a score is
> expected and used in the same way.
> This could go into 1.0.x

Agreed.

> Then I'd add
>  - node-base-score
> Which cuts out half of the rsc_location constraints and seems like a
> generically useful concept.
> (One would probably look up this value and set node-weight during
> unpack_nodes() )
> I still debating whether this is suitable for 1.0

Could you explain more here (and give an example), please?  I am
new to HA and feel that I must be missing something.

All nodes start at zero unless some rule is defined to give them
a weight.  Are you proposing that they would start at some
user-defined value?  For example, 100?

> So now the constraints now look like:
>
> <rsc_location id="other_health" rsc="X">
>   <rule id="health_location_1" score-attribute="#health-ipmi"/>
>   <rule id="health_location_2" score-attribute="#health-smart"/>
> </rsc_location>
>
> Which one would only have to specify once for 1.2 when pattern
> matching gets added (thats definitely not a change for a stable>
> series).
>
> I don't consider this a huge configuration overhead, BUT, I wouldn't
> object to adding
>  - node-health-strategy = (none, custom, migrate-on-red, ...)
>
> * "none" would be the default
> * "custom" would require the admin to configure the rsc_location
> constraints manually
> * "migrate-on-red" would be the one you're proposing and implicitly
> create the relevant rsc_location constraints behind the scenes.
>   I'd not call it "automatic" in order to allow us to add other
> "default" strategies in the future.

Yes.  "migrate-on-red" would automatically all variables that start
with #health.  This would reduce the chance of errors in forgetting
a variable, adding a new monitored variable later on, or mispelling
a variable.

What is the difference between "none" and "custom"?

I image that a sysadmin could set "none" and still define only
the #health variables that they are interested in the other_health
rsc_location list.

This would work the same as "custom".  I imagine that you mean
"custom" to possibly inform HA that these rules exist and are
being used as intended (not to be defaulted in anyway).

> To me this seems like a good compromise between ease-of-use and
> flexibility, with a sane progression from "none", to default
> strategies, to "custom".

Yes.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20090508/601b7979/attachment-0001.htm>


More information about the Pacemaker mailing list