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

Mon Apr 19 00:49:57 UTC 2010

Hi Andrew, 

Are you busy?
Please give my question an answer. 

Best Regards, 
Hideo Yamauchi.

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

> 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 ]
> > > >
> > > > &#65533;Resource Group: UMgroup01
> > > > &#65533; &#65533; UmVIPcheck (ocf::heartbeat:Dummy): Started srv01
> > > > &#65533; &#65533; UmIPaddr &#65533; (ocf::heartbeat:Dummy): Started srv01
> > > > &#65533; &#65533; UmDummy01 &#65533;(ocf::heartbeat:Dummy): Started srv01
> > > > &#65533; &#65533; UmDummy02 &#65533;(ocf::heartbeat:Dummy): Started srv01
> > > > &#65533;Resource Group: OVDBgroup02-1
> > > > &#65533; &#65533; prmExPostgreSQLDB1 (ocf::heartbeat:Dummy): Started srv01
> > > > &#65533; &#65533; prmFsPostgreSQLDB1-1 &#65533; &#65533; &#65533; (ocf::heartbeat:Dummy):
Started srv01
> > > > &#65533; &#65533; prmFsPostgreSQLDB1-2 &#65533; &#65533; &#65533; (ocf::heartbeat:Dummy):
Started srv01
> > > > &#65533; &#65533; prmFsPostgreSQLDB1-3 &#65533; &#65533; &#65533; (ocf::heartbeat:Dummy):
Started srv01
> > > > &#65533; &#65533; prmIpPostgreSQLDB1 (ocf::heartbeat:Dummy): Started srv01
> > > > &#65533; &#65533; prmApPostgreSQLDB1 (ocf::heartbeat:Dummy): Started srv01
> > > > &#65533;Resource Group: OVDBgroup02-2
> > > > &#65533; &#65533; prmExPostgreSQLDB2 (ocf::heartbeat:Dummy): Started srv02
> > > > &#65533; &#65533; prmFsPostgreSQLDB2-1 &#65533; &#65533; &#65533; (ocf::heartbeat:Dummy):
Started srv02
> > > > &#65533; &#65533; prmFsPostgreSQLDB2-2 &#65533; &#65533; &#65533; (ocf::heartbeat:Dummy):
Started srv02
> > > > &#65533; &#65533; prmFsPostgreSQLDB2-3 &#65533; &#65533; &#65533; (ocf::heartbeat:Dummy):
Started srv02
> > > > &#65533; &#65533; prmIpPostgreSQLDB2 (ocf::heartbeat:Dummy): Started srv02
> > > > &#65533; &#65533; prmApPostgreSQLDB2 (ocf::heartbeat:Dummy): Started srv02
> > > > &#65533;Resource Group: OVDBgroup02-3
> > > > &#65533; &#65533; prmExPostgreSQLDB3 (ocf::heartbeat:Dummy): Started srv03
> > > > &#65533; &#65533; prmFsPostgreSQLDB3-1 &#65533; &#65533; &#65533; (ocf::heartbeat:Dummy):
Started srv03
> > > > &#65533; &#65533; prmFsPostgreSQLDB3-2 &#65533; &#65533; &#65533; (ocf::heartbeat:Dummy):
Started srv03
> > > > &#65533; &#65533; prmFsPostgreSQLDB3-3 &#65533; &#65533; &#65533; (ocf::heartbeat:Dummy):
Started srv03
> > > > &#65533; &#65533; prmIpPostgreSQLDB3 (ocf::heartbeat:Dummy): Started srv03
> > > > &#65533; &#65533; prmApPostgreSQLDB3 (ocf::heartbeat:Dummy): Started srv03
> > > > &#65533;Resource Group: grpStonith1
> > > > &#65533; &#65533; prmStonithN1 &#65533; &#65533; &#65533; (stonith:external/ssh): Started
srv04
> > > > &#65533;Resource Group: grpStonith2
> > > > &#65533; &#65533; prmStonithN2 &#65533; &#65533; &#65533; (stonith:external/ssh): Started
srv01
> > > > &#65533;Resource Group: grpStonith3
> > > > &#65533; &#65533; prmStonithN3 &#65533; &#65533; &#65533; (stonith:external/ssh): Started
srv02
> > > > &#65533;Resource Group: grpStonith4
> > > > &#65533; &#65533; prmStonithN4 &#65533; &#65533; &#65533; (stonith:external/ssh): Started
srv03
> > > > &#65533;Clone Set: clnUMgroup01
> > > > &#65533; &#65533; Started: [ srv01 srv04 ]
> > > > &#65533;Clone Set: clnPingd
> > > > &#65533; &#65533; Started: [ srv01 srv02 srv03 srv04 ]
> > > > &#65533;Clone Set: clnDiskd1
> > > > &#65533; &#65533; Started: [ srv01 srv02 srv03 srv04 ]
> > > > &#65533;Clone Set: clnG3dummy1
> > > > &#65533; &#65533; Started: [ srv01 srv02 srv03 srv04 ]
> > > > &#65533;Clone Set: clnG3dummy2
> > > > &#65533; &#65533; Started: [ srv01 srv02 srv03 srv04 ]
> > > >
> > > > We encountered the problem that early resource placement did not obey location by this
> > > constitution.
> > > > &#65533;* I asked next question before...
> > > http://www.gossamer-threads.com/lists/linuxha/pacemaker/60342
> > > >
> > > > This was a mistake of our setting.
> > > > &#65533;(snip)
> > > > &#65533; &#65533; &#65533;<rsc_colocation id="rsc_colocation01-1" rsc="UMgroup01"
with-rsc="clnPingd"
> > > score="INFINITY"/>
> > > > &#65533; &#65533; &#65533;<rsc_colocation id="rsc_colocation01-2" rsc="UMgroup01"
with-rsc="clnPingd2"
> > > score="INFINITY"/>
> > > > &#65533; &#65533; &#65533;<rsc_colocation id="rsc_colocation01-3" rsc="UMgroup01"
with-rsc="clnUMgroup01"
> > > > score="INFINITY"/>
> > > > &#65533; &#65533; &#65533;<rsc_colocation id="rsc_colocation02-1-1" rsc="group02-1"
with-rsc="clnPingd"
> > > score="INFINITY"/>
> > > > &#65533; &#65533; &#65533;<rsc_colocation id="rsc_colocation02-1-2" rsc="group02-1"
with-rsc="clnPingd2"
> > > > score="INFINITY"/>
> > > > &#65533; &#65533; &#65533;<rsc_colocation id="rsc_colocation02-2-1" rsc="group02-2"
with-rsc="clnPingd"
> > > score="INFINITY"/>
> > > > &#65533; &#65533; &#65533;<rsc_colocation id="rsc_colocation02-2-2" rsc="group02-2"
with-rsc="clnPingd2"
> > > > score="INFINITY"/>
> > > > &#65533;(snip)
> > > >
> > > > And we set 1000 in colocation.
> > > >
> > > > &#65533;(snip)
> > > > &#65533; &#65533; &#65533;<rsc_colocation id="rsc_colocation01-1" rsc="UMgroup01"
with-rsc="clnPingd"
> > > score="1000"/>
> > > > &#65533; &#65533; &#65533;<rsc_colocation id="rsc_colocation01-2" rsc="UMgroup01"
with-rsc="clnPingd2"
> > > score="1000"/>
> > > > &#65533; &#65533; &#65533;<rsc_colocation id="rsc_colocation01-3" rsc="UMgroup01"
with-rsc="clnUMgroup01"
> > > score="1000"/>
> > > > &#65533; &#65533; &#65533;<rsc_colocation id="rsc_colocation02-1-1" rsc="group02-1"
with-rsc="clnPingd"
> > > score="1000"/>
> 
=== 以下のメッセージは省略されました ===