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

[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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hb_report_inf.tar.bz2
Type: application/octet-stream
Size: 30819 bytes
Desc: 2447912866-hb_report_inf.tar.bz2
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20100422/2eba8d98/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hb_report_1000.tar.bz2
Type: application/octet-stream
Size: 31205 bytes
Desc: 4121839725-hb_report_1000.tar.bz2
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20100422/2eba8d98/attachment-0007.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pe-input_inf.zip
Type: application/x-zip-compressed
Size: 9080 bytes
Desc: 2940549769-pe-input_inf.zip
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20100422/2eba8d98/attachment-0006.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pe-input_1000.zip
Type: application/x-zip-compressed
Size: 9127 bytes
Desc: 424512226-pe-input_1000.zip
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20100422/2eba8d98/attachment-0007.bin>