[Pacemaker] Problem : By colocations limitation, the resource appointment of the combination does not become effective.

Fri Mar 19 01:22:54 UTC 2010

Hi Andrew,

> I've been extremely busy.
> Sometimes I defer more complex questions until I have time to give
> them my full attention.

I understand that you are busy.
Thank you for comment.

> I don't really understand the question here.

Sorry..
I made a mistake in the link of the former problem.
I explain a problem sequentially once again.

We constituted the next cluster.

Online: [ srv01 srv02 srv03 srv04 ]

 Resource Group: UMgroup01
     UmVIPcheck (ocf::heartbeat:Dummy): Started srv01
     UmIPaddr   (ocf::heartbeat:Dummy): Started srv01
     UmDummy01  (ocf::heartbeat:Dummy): Started srv01
     UmDummy02  (ocf::heartbeat:Dummy): Started srv01
 Resource Group: OVDBgroup02-1
     prmExPostgreSQLDB1 (ocf::heartbeat:Dummy): Started srv01
     prmFsPostgreSQLDB1-1       (ocf::heartbeat:Dummy): Started srv01
     prmFsPostgreSQLDB1-2       (ocf::heartbeat:Dummy): Started srv01
     prmFsPostgreSQLDB1-3       (ocf::heartbeat:Dummy): Started srv01
     prmIpPostgreSQLDB1 (ocf::heartbeat:Dummy): Started srv01
     prmApPostgreSQLDB1 (ocf::heartbeat:Dummy): Started srv01
 Resource Group: OVDBgroup02-2
     prmExPostgreSQLDB2 (ocf::heartbeat:Dummy): Started srv02
     prmFsPostgreSQLDB2-1       (ocf::heartbeat:Dummy): Started srv02
     prmFsPostgreSQLDB2-2       (ocf::heartbeat:Dummy): Started srv02
     prmFsPostgreSQLDB2-3       (ocf::heartbeat:Dummy): Started srv02
     prmIpPostgreSQLDB2 (ocf::heartbeat:Dummy): Started srv02
     prmApPostgreSQLDB2 (ocf::heartbeat:Dummy): Started srv02
 Resource Group: OVDBgroup02-3
     prmExPostgreSQLDB3 (ocf::heartbeat:Dummy): Started srv03
     prmFsPostgreSQLDB3-1       (ocf::heartbeat:Dummy): Started srv03
     prmFsPostgreSQLDB3-2       (ocf::heartbeat:Dummy): Started srv03
     prmFsPostgreSQLDB3-3       (ocf::heartbeat:Dummy): Started srv03
     prmIpPostgreSQLDB3 (ocf::heartbeat:Dummy): Started srv03
     prmApPostgreSQLDB3 (ocf::heartbeat:Dummy): Started srv03
 Resource Group: grpStonith1
     prmStonithN1       (stonith:external/ssh): Started srv04
 Resource Group: grpStonith2
     prmStonithN2       (stonith:external/ssh): Started srv01
 Resource Group: grpStonith3
     prmStonithN3       (stonith:external/ssh): Started srv02
 Resource Group: grpStonith4
     prmStonithN4       (stonith:external/ssh): Started srv03
 Clone Set: clnUMgroup01
     Started: [ srv01 srv04 ]
 Clone Set: clnPingd
     Started: [ srv01 srv02 srv03 srv04 ]
 Clone Set: clnDiskd1
     Started: [ srv01 srv02 srv03 srv04 ]
 Clone Set: clnG3dummy1
     Started: [ srv01 srv02 srv03 srv04 ]
 Clone Set: clnG3dummy2
     Started: [ srv01 srv02 srv03 srv04 ]

We encountered the problem that early resource placement did not obey location by this constitution.
 * I asked next question before... http://www.gossamer-threads.com/lists/linuxha/pacemaker/60342

This was a mistake of our setting. 
 (snip)
      <rsc_colocation id="rsc_colocation01-1" rsc="UMgroup01" with-rsc="clnPingd" score="INFINITY"/>
      <rsc_colocation id="rsc_colocation01-2" rsc="UMgroup01" with-rsc="clnPingd2" score="INFINITY"/>
      <rsc_colocation id="rsc_colocation01-3" rsc="UMgroup01" with-rsc="clnUMgroup01"
score="INFINITY"/>
      <rsc_colocation id="rsc_colocation02-1-1" rsc="group02-1" with-rsc="clnPingd" score="INFINITY"/>
      <rsc_colocation id="rsc_colocation02-1-2" rsc="group02-1" with-rsc="clnPingd2"
score="INFINITY"/>
      <rsc_colocation id="rsc_colocation02-2-1" rsc="group02-2" with-rsc="clnPingd" score="INFINITY"/>
      <rsc_colocation id="rsc_colocation02-2-2" rsc="group02-2" with-rsc="clnPingd2"
score="INFINITY"/>
 (snip)

And we set 1000 in colocation.

 (snip)
      <rsc_colocation id="rsc_colocation01-1" rsc="UMgroup01" with-rsc="clnPingd" score="1000"/>
      <rsc_colocation id="rsc_colocation01-2" rsc="UMgroup01" with-rsc="clnPingd2" score="1000"/>
      <rsc_colocation id="rsc_colocation01-3" rsc="UMgroup01" with-rsc="clnUMgroup01" score="1000"/>
      <rsc_colocation id="rsc_colocation02-1-1" rsc="group02-1" with-rsc="clnPingd" score="1000"/>
      <rsc_colocation id="rsc_colocation02-1-2" rsc="group02-1" with-rsc="clnPingd2" score="1000"/>
      <rsc_colocation id="rsc_colocation02-2-1" rsc="group02-2" with-rsc="clnPingd" score="1000"/>
      <rsc_colocation id="rsc_colocation02-2-2" rsc="group02-2" with-rsc="clnPingd2" score="1000"/>
 (snip)

Because we set 1000 in colocation, the resource was arranged in a node definitely.

We confirmed movement after the trouble of clnPingd by cluster constitution of this setting more.
(The detailed procedure is an email of the beginnings of this matter.)

But clnPingd does not start in srv01, but UMgroup01 starts after this. 
* Because there was colocation limitation, we did not expect start of UMgroup01. 

Your answer to solve this problem was to set INFINITY in colocation.

> Only if you change: 
> <rsc_colocation id="rsc_colocation01-1" rsc="UMgroup01" 
> with-rsc="clnPingd" score="1000"/> 
> 
> to 
> <rsc_colocation id="rsc_colocation01-1" rsc="UMgroup01" 
> with-rsc="clnPingd" score="INFINITY"/> 

However, the early resource placement that we solved becomes invalid when I set colocation in
INFINITY.

By our cluster constitution, can you satisfy two next demands?

1)The resource placement of a right early cluster.
2)The start control of the resource of the combination by the colocation limitation.

Is there setting of cib.xml to realize a demand?

#I am not good at English. 
#Give me comment if you do not understand contents of my comment.

Best Regards,
Hideo Yamauchi.

--- Andrew Beekhof <andrew at beekhof.net> wrote:

> 2010/3/17  <renayama19661014 at ybb.ne.jp>:
> > Hi Andrew,
> >
> > Please give my question an answer.
> 
> I've been extremely busy.
> Sometimes I defer more complex questions until I have time to give
> them my full attention.
> 
> >
> > Best Regards,
> > Hideo Yamauchi.
> >
> > --- renayama19661014 at ybb.ne.jp wrote:
> >
> >> Hi Andrew,
> >>
> >> Thank you for comment.
> >>
> >> I asked next question before.
> >>
> >>   http://www.gossamer-threads.com/lists/linuxha/pacemaker/61484
> >>
> >> I guessed from your this answer.
> >> When I use cib.xml of the answer of before, is the limitation that it combined a start of
> >> clnPingd
> >> with after a node rebooted unrealizable?
> 
> I don't really understand the question here.
> 
> >>
> >> Limitation of before :
> >> >  <rsc_colocation id="rsc_colocation01-1" rsc="UMgroup01"
> >> > with-rsc="clnPingd" score="1000"/>
> >>
> >> This limitation :
> >> >  <rsc_colocation id="rsc_colocation01-1" rsc="UMgroup01"
> >> > with-rsc="clnPingd" score="INFINITY"/>
> >>
> >> Is there a description method of cib.xml letting both limitation function at the same time?
> 
> What would that achieve?
> 
> _______________________________________________
> Pacemaker mailing list
> Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 