Bart Coninckx wrote:
The scoring calculation is described here:
http://www.linux-ha.org/ScoreCalculation
Fiew. Rocket-science. I kinda start to miss the old version 1 days ;-)
You're not the only one. :-)
The essence of it that is particularly germane is:
score = (constraint-score) + (num_group_resources * resource_stickiness)
+ (failcount * (resource_failure_stickiness) )
(for a resource group).
Without a group:
score = (constraint-score) + (resource_stickiness) + (failcount *
(resource_failure_stickiness) )
I didn't use any resource_stickyness for the resources, so it should look at
the default resource stickyness. Which it doesn't actually, but that probably
has to do with the drbd resource I have (master-slave thing). I'll try to
manipulate the scores but in order to do so, I first need to understand the
scoring-theory and that seems to me like a hell of a job. It's putting me off
already as a matter of fact...
I can definitely understand that. It can be quite complicated; it took
me quite some time to get it right on my first setup recently (I'm a
newbie too).
Don't give up or abandon it, though - just slog through it and learn it.
The reason is that once you do figure it out, the advantages of
v2-style cluster resource management are considerable due to the
granularity they afford you in customising the failover desiderata. V1
didn't have the ability to meaningfully fail over based on the failure
of a particular resource or to tweak all this on such a level. It's
worth figuring out.
There is a reason why v2 was created apart from someone's fetish for
inordinate complexity, and the reason is fundamentally a good one.
Although, I am definitely put off by the notion that XML is somehow a
decent format for a configuration file.
And you can see the values currently assigned to all resources using:
ptest -Ls
the "s" parameter is not supported on my ptest (SLES 10 SP1), but ptest -LV
gives:
node1:/usr/lib64/heartbeat # ./ptest -LV
<transition_graph cluster-delay="60s" transition_id="0"/>
Huh. That's strange.
When I run it on my (32-bit, Debian) system running CRM/heartbeat 2.1.4
I get:
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: group_color:
grp_1 allocation score on gma-2: 0
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: group_color:
grp_1 allocation score on gma-1: 0
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: group_color:
ip_addr allocation score on gma-2: 50
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: group_color:
ip_addr allocation score on gma-1: 100
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: group_color:
drbd_disk allocation score on gma-2: 0
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: group_color:
drbd_disk allocation score on gma-1: 0
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: group_color:
fs allocation score on gma-2: 0
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: group_color:
fs allocation score on gma-1: 0
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: group_color:
pgsql allocation score on gma-2: 0
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: group_color:
pgsql allocation score on gma-1: 0
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: group_color:
kamailio allocation score on gma-2: 0
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: group_color:
kamailio allocation score on gma-1: 0
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: native_color:
ip_addr allocation score on gma-2: 50
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: native_color:
ip_addr allocation score on gma-1: 100
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: native_color:
drbd_disk allocation score on gma-2: -1000000
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: native_color:
drbd_disk allocation score on gma-1: 0
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: native_color:
fs allocation score on gma-2: -1000000
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: native_color:
fs allocation score on gma-1: 0
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: native_color:
pgsql allocation score on gma-2: -1000000
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: native_color:
pgsql allocation score on gma-1: 0
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: native_color:
kamailio allocation score on gma-2: -1000000
ptest[25013]: 2008/11/28_13:12:00 ALERT: dump_node_scores: native_color:
kamailio allocation score on gma-1: 0
Notice the peculiar fact that only the group and the first resource in
the group actually gets a score based on the rules in the CIB. This is
accounted for in a subtle note on the ScoreCalculation page:
("If you look at the scores for resources within a colocated group
(colocated is the default for groups, meaning all resources shall run on
the same node), you will find only the first resource of the group to
have the score you configured. All subsequent resources will have a
score of INFINITY for the node the first resource was started on and
-INFINITY for any other node(s).")
-- Alex
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
