On 2008-09-09T18:37:31, Satomi Taniguchi <[EMAIL PROTECTED]> wrote:
> Hi lists,
>
> I'm posting two patches to realize the function which we have discussed.
> One is for Pacemaker-dev(aba67759589),
> and another one is for Heartbeat-dev(fc047640072c).
>
> The specifications are the following.
> (1) add the following 4 settings.
> "period-length" - Period in seconds to count monitor op's failures.
> "max-failures-per-period" - Maximum times per period a monitor may fail.
> "default-period-length" - default value of period-length for the
> cluster.
> "default-max-failures-per-period" - default value of
> max-failures-per-period for the cluster.
>
> (2) lrmd counts the monitor op's failures of each resource per period-length.
> And it ignores the resource's failure until the number of times of that
> exceeds the threshold (max-failures-per-period).
This means that this policy is enforced by the LRM; I'm not sure that's
perfect. Should this not be handled by the PE?
> (3) If the value of period-length is 0, lrmd calculates the suitable length
> of
> the period for the resource's operation.
>
> NOTE:
> "suitable" means "safe enough".
> In this patch, the expression to calculate "suitable" value is
> (monitor's interval + timeout) * max-failure-per-period.
> If the value of period-length is too short, and the number of times which
> monitor operation has finished in the period is less than the threshold,
> lrmd will never notify its client that the resource is failure.
> To avoid this, period-length requires the value which larger than
> (monitor's interval + timeout) * (max-failures-per-period - 1), at least.
> And allowing for the time of lrmd's internal processing or the margin of
> error of OS's timer and so on, I considered the first expression is
> suitable.
>
> In addition, I add the function to lrmadmin to show the following information.
> i) the time when the period-length started of the specified resource.
> ii) the value of the counter of failures of the specified resource.
> This is the third patch.
This means that the full cluster state is no longer reflected in the
CIB. I don't really like that at all.
> + op_type = ha_msg_value(op->msg, F_LRM_OP);
> +
> + if (STRNCMP_CONST(op_type, "start") == 0) {
> + /* initialize the counter of failures. */
> + rsc->t_failed = 0;
> + rsc->failcnt_per_period = 0;
> + }
What about a resource being promoted to master state, or demoted again?
Should the counter not be reset then too?
(The functions are also getting verrry long; maybe factor some code out
into smaller functions?)
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________
Pacemaker mailing list
[email protected]
http://list.clusterlabs.org/mailman/listinfo/pacemaker
