[Pacemaker] About influence of resouce-stickiness which used colocation for limitation.

[Andrew Beekhof]

Fixed in:
   http://hg.clusterlabs.org/pacemaker/1.1/rev/4c775a4abc87

2010/4/22  <renayama19661014 at ybb.ne.jp>:
> Hi,
>
> We tested the cluster constitution of four nodes.
>
> srv04 is a standby node, and others are active nodes.
>
> We use INIFINITY for resouce-stickiness well.
>
> But, there was a problem for resource placement when we set INIFINITY in resouce-stickiness.
> (An OVDBgroup02-1 resource did not start in an active srv01 node.)
>
> There was not a problem for resource placement when we set 1000 in resouce-stickiness.
>
>  * resource-stickiness=1000
>
> [root at srv01 ~]# crm_mon -1
> ============
> Last updated: Thu Apr 22 15:34:03 2010
> Stack: openais
> Current DC: srv01 - partition with quorum
> Version: 1.0.8-52c101df29bd1851b2ea6dc13bbba450418d103b
> 4 Nodes configured, 4 expected votes
> 9 Resources configured.
> ============
>
> Online: [ srv01 srv02 srv03 srv04 ]
>
>  Resource Group: UMgroup01
>     UmVIPcheck (ocf::heartbeat:Dummy): Started srv01
>  Resource Group: OVDBgroup02-1
>     prmExPostgreSQLDB1 (ocf::heartbeat:Dummy): Started srv01 ---> not problem
>  Resource Group: OVDBgroup02-2
>     prmExPostgreSQLDB2 (ocf::heartbeat:Dummy): Started srv02
>  Resource Group: OVDBgroup02-3
>     prmExPostgreSQLDB3 (ocf::heartbeat:Dummy): Started srv03
>  Clone Set: clnUMgroup01
>     Started: [ srv01 srv04 ]
>  Clone Set: clnPingd
>     Started: [ srv02 srv03 srv01 srv04 ]
>  Clone Set: clnDiskd1
>     Started: [ srv02 srv03 srv01 srv04 ]
>  Clone Set: clnG3dummy1
>     Started: [ srv01 srv02 srv03 srv04 ]
>  Clone Set: clnG3dummy2
>     Started: [ srv01 srv02 srv03 srv04 ]
>
>
>  * resource-stickiness=INFINITY
>
> [root at srv01 ~]# crm_mon -1
> ============
> Last updated: Thu Apr 22 15:23:43 2010
> Stack: openais
> Current DC: srv01 - partition with quorum
> Version: 1.0.8-52c101df29bd1851b2ea6dc13bbba450418d103b
> 4 Nodes configured, 4 expected votes
> 9 Resources configured.
> ============
>
> Online: [ srv01 srv02 srv03 srv04 ]
>
>  Resource Group: UMgroup01
>     UmVIPcheck (ocf::heartbeat:Dummy): Started srv01
>  Resource Group: OVDBgroup02-1
>     prmExPostgreSQLDB1 (ocf::heartbeat:Dummy): Started srv04 ---> problem
>  Resource Group: OVDBgroup02-2
>     prmExPostgreSQLDB2 (ocf::heartbeat:Dummy): Started srv02
>  Resource Group: OVDBgroup02-3
>     prmExPostgreSQLDB3 (ocf::heartbeat:Dummy): Started srv03
>  Clone Set: clnUMgroup01
>     Started: [ srv01 srv04 ]
>  Clone Set: clnPingd
>     Started: [ srv02 srv03 srv01 srv04 ]
>  Clone Set: clnDiskd1
>     Started: [ srv02 srv03 srv01 srv04 ]
>  Clone Set: clnG3dummy1
>     Started: [ srv01 srv02 srv03 srv04 ]
>  Clone Set: clnG3dummy2
>     Started: [ srv01 srv02 srv03 srv04 ]
>
>
> When we do not use colocation, this problem does not happen.
>
> We think that a difference of resource-stickiness influences it.
>
> When we put colocation and resoucre-stickiness together, will the calculation of the score be right?
>
> Is the movement when we set INIFINITY in resource-stickiness a bug?
>
>  * I read the next document to examine colocation.
>  * http://www.clusterlabs.org/wiki/File:Colocation_Explained_-_White.pdf
>  * However, I was not able to understand the connection with resource-stickiness.
>
> Best Regards,
> Hideo Yamauchi.
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>