[Linux-ha-dev] To avoid STONITH for a node which is doing kdump
beekhof at gmail.com
Fri Sep 19 03:17:34 MDT 2008
On Fri, Sep 19, 2008 at 09:00, Satomi TANIGUCHI
<taniguchis at intellilink.co.jp> wrote:
>>> I implemented a prototype, and it seems to work well.
>>> I would like to hear your opinions.
>> Personally I think this is unnecessarily complicated.
>> I'm sure what you have works well, but would favor a single
>> stonith-timeout configuration option which it is up to the admin to
>> set appropriately (passed to the TE in the same way as cluster-delay).
> Is "stonith-timeout" a configuration option per cluster?
> (In other words, is it written in <cluster_property_set>?)
Not yet, because it doesn't exist.
But yes, that is the intention.
> I consider it is better to be able to set timeout value for each STONITH
> as if we can set the value for each resource.
> Because each STONITH device has its own characteristic.
Right, but by far the most common scenario is to only have one type of plugin.
>> In my opinion, this would be sufficient for most scenarios^ and the
>> chance of it being configured correctly is much higher.
>> It also requires a whole lot less CPU to figure out what value to use ;-)
> less CPU is one of the most important matters for customers!
Well you can't have both :)
>> ^ Clusters with multiple types of devices can simply pick the highest
>> timeout and clusters with cascaded stonith setups (is that even
>> possible at the moment?) just add all the timeouts all together.
> I'm confused.
> With this sentence, it seems that "stonith-timeout" is an option per
What I meant was that the admin should determine what timeout all the
plugins need and use those values to set the global stonith-timeout
appropriately. I've amended my reply below:
>> ^ [For] Clusters with multiple types of devices [, admins] can simply pick the highest
>> timeout and [for] clusters with cascaded stonith setups (is that even
>> possible at the moment?) [admins should] just add all the timeouts all together.
Actually, looking again at your proposal, you have the core of an
acceptable idea but its the implementation I really dislike.
If the admin is configuring timeouts, then there is really no need to
get the CRM involved at all (step 3).
And combining everything into a single CRM_meta_stonith_plugin_dataset
field is unnecessary and ugly.
If you _really_ want to have a per-plugin value, I suggest making it
an extra resource parameter (ie. like hostlist) and teach stonithd to
look for and use it _instead_of_ the CRM-supplied value.
Dejan: Any objections to something like this?
Btw. if NTT wants this in for 1.0, then you guys need to be _very_
quick writing the patch.
> Cascaded stonith setup can be realized by setting two or more plugins in a
> at the moment.
> As far as I confirm, if the first plugin in a group is failed,
> the second one is executed.
> And if the first one succeeds, the second one is _not_ executed.
> If it is an unexpected behavior, please let me know the correct one.
Cool. I had no idea. I, like the CRM, am blissfully ignorant of how
STONITHd works :-)
More information about the Linux-HA-Dev