Andrew Beekhof wrote:
On Oct 30, 2007, at 5:30 PM, Alan Robertson wrote:
Andrew Beekhof wrote:
On Oct 30, 2007, at 2:44 AM, Alan Robertson wrote:
Hi,
I've been working with a customer - trying to get them up and
running on version 2.1.2. I got everything to work except for one
thing: They require that their web server fail over on the 3rd
failure. I read the documentation on the failcount stuff on the web
site here: http://www.linux-ha.org/v2/faq/forced_failover
I think I understood it, and I created a CIB to match. In the CIB I
created, I believe it should fail over on the 3rd failure. In
practice it fails over reliably on the 9th iteration instead. We
had been doing a "killall httpd" to fail the web server.
9th is correct.
As has been explained here on the list a number of times, the group's
stickiness is N * default-resource-stickiness, where N is the number
of resources in the group.
Including the rsc_location constraint, the group stickiness is
therefor: 4 * 20 + 1 = 81
So clearly apache is going to need to fail 9 times (9 *
default-resource-failure-stickiness = -90) before the group is moved.
Of course it all starts getting even more complicated when one starts
creating rsc_colocation constraints with other groups and primitives.
Can I specify the resource-failure-stickiness of a group either
explicitly or implicitly?
no, because groups, being meta-objects, don't fail - resources do
you can set a 'special' value for all members in the group by setting it
in the group object, but its still applied at the resource level.
OK. So, the usual inheritance rules apply? I assume you can inherit
from the default, from the meta-object, or specify explicitly in the
resource?
And, when you apply it to the group, and it is then inherited by the
individual primitive resources in the group, then you get this
multiplier of 'n' put in again?
one thing I would like to do is make it so that the resource-stickiness
of a group is not the sum of its components.
however due to a feature someone asked for 2 years or so ago, I'm not
sure if I can.
I'm not sure that this idea of having the resources stickiness battle
the resource-failure stickiness and the locational preferences is what's
wanted in most cases. Although I didn't understand the group part
(which makes it even more complicated), just explaining the basic
resource semantics is pretty daunting - especially if you add in the
fact that you have dynamic attributes like 'pingd' to complicate the
whole thing.
I've been thinking about a suggested alternative approach that's easier
to understand and configure which wouldn't require breaking things for
existing configurations. I'd be happy to discuss it on the list if
you'd be interested in hearing it.
Please let me know yes or no on this.
I was really surprised how hard this was to explain and justify the
current behavior (even discounting groups) to the customer. Although
the customer isn't always right, in this case I agree with them.
Since I'm writing this up for the web site, I want to make sure I have
this absolutely clear so I can write it up correctly:
Do you mean that you sum up the stickiness values for each resource in
the group,
yes, the sum
or did you really mean that you it always uses n*default stickiness?
(I'm asking for both for failure stickiness and resource stickiness).
If I have a locational constraints for a group of 'p' points, does
that then distribute across the group of 'n' nodes so that we get a
group preference of 'p' * 'n' points? Or is it just just a total of
'p' points for the group as a whole?
this part i actually got right, just 'p' and not n*p
Just trying to document this clearly and accurately as best as I am
able. I appreciate your help in doing this.
My current attempt to document this can be found here:
http://linux-ha.org/v2/faq/forced_failover
Please take a minute and review what I've written here and make sure
that I got it right. I fixed some errors in the text as well as adding
the stuff on groups at the end. As soon as I work out all the details,
and the customer sees them work right on their site, I'll put an example
at the end.
The (now-corrected) errors in the text made it hard to find this page,
since the attributes for stickiness were all spelled the old (incorrect)
way (e.g., resource_failure_stickiness).
--
Alan Robertson <[EMAIL PROTECTED]>
"Openness is the foundation and preservative of friendship... Let me
claim from you at all times your undisguised opinions." - William
Wilberforce
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
