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.
--- renayama19661...@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 <and...@beekhof.net> wrote:
>
> > 2010/3/19 <renayama19661...@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 ]
> > >
> > > \xA0Resource Group: UMgroup01
> > > \xA0 \xA0 UmVIPcheck (ocf::heartbeat:Dummy): Started srv01
> > > \xA0 \xA0 UmIPaddr \xA0 (ocf::heartbeat:Dummy): Started srv01
> > > \xA0 \xA0 UmDummy01 \xA0(ocf::heartbeat:Dummy): Started srv01
> > > \xA0 \xA0 UmDummy02 \xA0(ocf::heartbeat:Dummy): Started srv01
> > > \xA0Resource Group: OVDBgroup02-1
> > > \xA0 \xA0 prmExPostgreSQLDB1 (ocf::heartbeat:Dummy): Started srv01
> > > \xA0 \xA0 prmFsPostgreSQLDB1-1 \xA0 \xA0 \xA0 (ocf::heartbeat:Dummy):
> > > Started srv01
> > > \xA0 \xA0 prmFsPostgreSQLDB1-2 \xA0 \xA0 \xA0 (ocf::heartbeat:Dummy):
> > > Started srv01
> > > \xA0 \xA0 prmFsPostgreSQLDB1-3 \xA0 \xA0 \xA0 (ocf::heartbeat:Dummy):
> > > Started srv01
> > > \xA0 \xA0 prmIpPostgreSQLDB1 (ocf::heartbeat:Dummy): Started srv01
> > > \xA0 \xA0 prmApPostgreSQLDB1 (ocf::heartbeat:Dummy): Started srv01
> > > \xA0Resource Group: OVDBgroup02-2
> > > \xA0 \xA0 prmExPostgreSQLDB2 (ocf::heartbeat:Dummy): Started srv02
> > > \xA0 \xA0 prmFsPostgreSQLDB2-1 \xA0 \xA0 \xA0 (ocf::heartbeat:Dummy):
> > > Started srv02
> > > \xA0 \xA0 prmFsPostgreSQLDB2-2 \xA0 \xA0 \xA0 (ocf::heartbeat:Dummy):
> > > Started srv02
> > > \xA0 \xA0 prmFsPostgreSQLDB2-3 \xA0 \xA0 \xA0 (ocf::heartbeat:Dummy):
> > > Started srv02
> > > \xA0 \xA0 prmIpPostgreSQLDB2 (ocf::heartbeat:Dummy): Started srv02
> > > \xA0 \xA0 prmApPostgreSQLDB2 (ocf::heartbeat:Dummy): Started srv02
> > > \xA0Resource Group: OVDBgroup02-3
> > > \xA0 \xA0 prmExPostgreSQLDB3 (ocf::heartbeat:Dummy): Started srv03
> > > \xA0 \xA0 prmFsPostgreSQLDB3-1 \xA0 \xA0 \xA0 (ocf::heartbeat:Dummy):
> > > Started srv03
> > > \xA0 \xA0 prmFsPostgreSQLDB3-2 \xA0 \xA0 \xA0 (ocf::heartbeat:Dummy):
> > > Started srv03
> > > \xA0 \xA0 prmFsPostgreSQLDB3-3 \xA0 \xA0 \xA0 (ocf::heartbeat:Dummy):
> > > Started srv03
> > > \xA0 \xA0 prmIpPostgreSQLDB3 (ocf::heartbeat:Dummy): Started srv03
> > > \xA0 \xA0 prmApPostgreSQLDB3 (ocf::heartbeat:Dummy): Started srv03
> > > \xA0Resource Group: grpStonith1
> > > \xA0 \xA0 prmStonithN1 \xA0 \xA0 \xA0 (stonith:external/ssh): Started
> > > srv04
> > > \xA0Resource Group: grpStonith2
> > > \xA0 \xA0 prmStonithN2 \xA0 \xA0 \xA0 (stonith:external/ssh): Started
> > > srv01
> > > \xA0Resource Group: grpStonith3
> > > \xA0 \xA0 prmStonithN3 \xA0 \xA0 \xA0 (stonith:external/ssh): Started
> > > srv02
> > > \xA0Resource Group: grpStonith4
> > > \xA0 \xA0 prmStonithN4 \xA0 \xA0 \xA0 (stonith:external/ssh): Started
> > > srv03
> > > \xA0Clone Set: clnUMgroup01
> > > \xA0 \xA0 Started: [ srv01 srv04 ]
> > > \xA0Clone Set: clnPingd
> > > \xA0 \xA0 Started: [ srv01 srv02 srv03 srv04 ]
> > > \xA0Clone Set: clnDiskd1
> > > \xA0 \xA0 Started: [ srv01 srv02 srv03 srv04 ]
> > > \xA0Clone Set: clnG3dummy1
> > > \xA0 \xA0 Started: [ srv01 srv02 srv03 srv04 ]
> > > \xA0Clone Set: clnG3dummy2
> > > \xA0 \xA0 Started: [ srv01 srv02 srv03 srv04 ]
> > >
> > > We encountered the problem that early resource placement did not obey
> > > location by this
> > constitution.
> > > \xA0* I asked next question before...
> > http://www.gossamer-threads.com/lists/linuxha/pacemaker/60342
> > >
> > > This was a mistake of our setting.
> > > \xA0(snip)
> > > \xA0 \xA0 \xA0<rsc_colocation id="rsc_colocation01-1" rsc="UMgroup01"
> > > with-rsc="clnPingd"
> > score="INFINITY"/>
> > > \xA0 \xA0 \xA0<rsc_colocation id="rsc_colocation01-2" rsc="UMgroup01"
> > > with-rsc="clnPingd2"
> > score="INFINITY"/>
> > > \xA0 \xA0 \xA0<rsc_colocation id="rsc_colocation01-3" rsc="UMgroup01"
> > > with-rsc="clnUMgroup01"
> > > score="INFINITY"/>
> > > \xA0 \xA0 \xA0<rsc_colocation id="rsc_colocation02-1-1" rsc="group02-1"
> > > with-rsc="clnPingd"
> > score="INFINITY"/>
> > > \xA0 \xA0 \xA0<rsc_colocation id="rsc_colocation02-1-2" rsc="group02-1"
> > > with-rsc="clnPingd2"
> > > score="INFINITY"/>
> > > \xA0 \xA0 \xA0<rsc_colocation id="rsc_colocation02-2-1" rsc="group02-2"
> > > with-rsc="clnPingd"
> > score="INFINITY"/>
> > > \xA0 \xA0 \xA0<rsc_colocation id="rsc_colocation02-2-2" rsc="group02-2"
> > > with-rsc="clnPingd2"
> > > score="INFINITY"/>
> > > \xA0(snip)
> > >
> > > And we set 1000 in colocation.
> > >
> > > \xA0(snip)
> > > \xA0 \xA0 \xA0<rsc_colocation id="rsc_colocation01-1" rsc="UMgroup01"
> > > with-rsc="clnPingd"
> > score="1000"/>
> > > \xA0 \xA0 \xA0<rsc_colocation id="rsc_colocation01-2" rsc="UMgroup01"
> > > with-rsc="clnPingd2"
> > score="1000"/>
> > > \xA0 \xA0 \xA0<rsc_colocation id="rsc_colocation01-3" rsc="UMgroup01"
> > > with-rsc="clnUMgroup01"
> > score="1000"/>
> > > \xA0 \xA0 \xA0<rsc_colocation id="rsc_colocation02-1-1" rsc="group02-1"
> > > with-rsc="clnPingd"
> > score="1000"/>
> > > \xA0 \xA0 \xA0<rsc_colocation id="rsc_colocation02-1-2" rsc="group02-1"
> > > with-rsc="clnPingd2"
> > score="1000"/>
> > > \xA0 \xA0 \xA0<rsc_colocation id="rsc_colocation02-2-1" rsc="group02-2"
> > > with-rsc="clnPingd"
> > score="1000"/>
> > > \xA0 \xA0 \xA0<rsc_colocation id="rsc_colocation02-2-2" rsc="group02-2"
> > > with-rsc="clnPingd2"
> > score="1000"/>
> > > \xA0(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@oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
_______________________________________________
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
