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

renayama19661014 at ybb.ne.jp renayama19661014 at ybb.ne.jp
Tue Mar 23 22:53:27 EDT 2010


Hi Andrew,

I ask you a question one more.

Our real resource constitution is a little more complicated.

We do colocation of the clone(clnG3dummy1, clnG3dummy2) which does not treat the update of the
attribute such as pingd.

(snip)
      <clone id="clnG3dummy1">
        <primitive class="ocf" id="clnG3dummy01" provider="heartbeat" type="Dummy">
          <operations>
            <op id="clnG3dummy01-start" interval="0" name="start" on-fail="restart" timeout="60s"/>
            <op id="clnG3dummy01-monitor" interval="10s" name="monitor" on-fail="restart"
timeout="60s"/>
            <op id="clnG3dummy01-stop" interval="0" name="stop" on-fail="block" timeout="60s"/>
          </operations>
        </primitive>
      </clone>
      <clone id="clnG3dummy2">
        <primitive class="ocf" id="clnG3dummy02" provider="heartbeat" type="Dummy">
          <operations>
            <op id="clnG3dummy02-start" interval="0" name="start" on-fail="restart" timeout="60s"/>
            <op id="clnG3dummy02-monitor" interval="10s" name="monitor" on-fail="restart"
timeout="60s"/>
            <op id="clnG3dummy02-stop" interval="0" name="stop" on-fail="stop" timeout="60s"/>
          </operations>
        </primitive>
      </clone>
(snip)
      <rsc_colocation id="rsc_colocation01-1" rsc="UMgroup01" with-rsc="clnPingd" score="1000"/>
      <rsc_colocation id="rsc_colocation01-3" rsc="UMgroup01" with-rsc="clnG3dummy1" score="1000"/>
      <rsc_colocation id="rsc_colocation01-4" rsc="UMgroup01" with-rsc="clnG3dummy2" score="1000"/>
      <rsc_colocation id="rsc_colocation01-5" rsc="UMgroup01" with-rsc="clnUMgroup01" score="1000"/>
      <rsc_colocation id="rsc_colocation02-1-1" rsc="OVDBgroup02-1" with-rsc="clnPingd" score="1000"/>
      <rsc_colocation id="rsc_colocation02-1-3" rsc="OVDBgroup02-1" with-rsc="clnG3dummy1"
score="1000"/>
      <rsc_colocation id="rsc_colocation02-1-4" rsc="OVDBgroup02-1" with-rsc="clnG3dummy2"
score="1000"/>
(snip)

Can you describe colocation of the clone which does not update these attributes in rule?

We want to realize start in order of the next.
 1) clnPingd, clnG3dummy1, clnG3dummy2, clnUMgroup01 (All resources start) -> UMgroup01 start 
   * And the resource moves if a clone of one stops.
 2) clnPingd, clnG3dummy1, clnG3dummy2 (All resources start) -> OVDBgroup02-1 start
   * And the resource moves if a clone of one stops.

Best Regards,
Hideo Yamauchi.


--- renayama19661014 at ybb.ne.jp wrote:

> Hi Andrew,
> 
> Thank you for comment.
> 
> 
> > I was suggesting:
> > 
> >  <rsc_colocation id="rsc_colocation01-3" rsc="UMgroup01"
> > with-rsc="clnUMgroup01" score="INFINITY"/>
> > 
> > <rsc_location id="no-connectivity-01-1" rsc="UMgroup01">
> >    <rule id="clnPingd-exclude-rule" score="-INFINITY" boolean-op="or">
> >       <expression id="UMgroup01-clnPingd-exclude" attribute="clnPingd"
> > operation="not_defined"/>
> >       <expression id="UMgroup01-clnPingd-only-positive"
> > attribute="clnPingd" operation="lt" type="integer" value="1"/>
> >       <expression id="UMgroup01-clnPingd2-exclude"
> > attribute="clnPingd2" operation="not_defined"/>
> >       <expression id="UMgroup01-clnPingd2-only-positive"
> > attribute="clnPingd2" operation="lt" type="integer" value="1"/>
> >    </rule>
> > </rsc_location>
> > 
> > <rsc_location id="no-connectivity-02-1" rsc="group02-1">
> >    <rule idref="clnPingd-exclude-rule"/>
> > </rsc_location>
> > 
> > <rsc_location id="no-connectivity-02-1" rsc="group02-2">
> >    <rule idref="clnPingd-exclude-rule"/>
> > </rsc_location>
> 
> I understood. 
> With your setting, I test movement.
> 
> Best Regards,
> Hideo Yamauchi.
> 
> 
> --- Andrew Beekhof <andrew at beekhof.net> wrote:
> 
> > 2010/3/19  <renayama19661014 at ybb.ne.jp>:
> > > 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.
> > 
> > Ok, but that wasn't what I was suggesting.
> > 
> > I was suggesting:
> > 
> >  <rsc_colocation id="rsc_colocation01-3" rsc="UMgroup01"
> > with-rsc="clnUMgroup01" score="INFINITY"/>
> > 
> > <rsc_location id="no-connectivity-01-1" rsc="UMgroup01">
> >    <rule id="clnPingd-exclude-rule" score="-INFINITY" boolean-op="or">
> >       <expression id="UMgroup01-clnPingd-exclude" attribute="clnPingd"
> > operation="not_defined"/>
> >       <expression id="UMgroup01-clnPingd-only-positive"
> > attribute="clnPingd" operation="lt" type="integer" value="1"/>
> >       <expression id="UMgroup01-clnPingd2-exclude"
> > attribute="clnPingd2" operation="not_defined"/>
> >       <expression id="UMgroup01-clnPingd2-only-positive"
> > attribute="clnPingd2" operation="lt" type="integer" value="1"/>
> >    </rule>
> > </rsc_location>
> > 
> > <rsc_location id="no-connectivity-02-1" rsc="group02-1">
> >    <rule idref="clnPingd-exclude-rule"/>
> > </rsc_location>
> > 
> > <rsc_location id="no-connectivity-02-1" rsc="group02-2">
> >    <rule idref="clnPingd-exclude-rule"/>
> > </rsc_location>
> > 
> > 
> > 
> > >
> > > 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.
> > >
> 
=== °Ê²¼¤Î¥á¥Ã¥»¡¼¥¸¤Ï¾Êά¤µ¤ì¤Þ¤·¤¿ ===> _______________________________________________
> Pacemaker mailing list
> Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 





More information about the Pacemaker mailing list