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 ]
>
> 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.
>
> 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 <and...@beekhof.net> wrote:
>
>> 2010/3/17 <renayama19661...@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.
>> >
>> > --- renayama19661...@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@oss.clusterlabs.org
>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>>
>
>
>
> _______________________________________________
> 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
