[Pacemaker] rsc_location does not work.

[renayama19661014 at ybb.ne.jp]

Hi Andrew,

Thank you for comment.

> > You would be better off with a constraint like example 9.3 which will
> > exclude any unconnected node and leave the previous location scores
> > unchanged:
> >
> >  
>
 http://www.clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/ch09s03s03s02.html#id2079508

I try it by the method that you showed at once.

Best Regards,
Hideo Yamauchi.

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

> Minor correction to the reply
> 
> On Tue, Jan 5, 2010 at 12:32 PM, Andrew Beekhof <andrew at beekhof.net> wrote:
> > 2009/12/22  <renayama19661014 at ybb.ne.jp>:
> >> Hi,
> >>
> >> We constituted the complicated cluster of three nodes.(2ACT+1STB)
> >>
> >> We built a cluster by the next combination.
> >>
> >>  * corosync-1.1.2
> >>  * Reusable-Cluster-Components-fa44a169d55f
> >>  * Cluster-Resource-Agents-6f02f8ad7fd4
> >>  * Pacemaker-1-0-d990c453b999
> >>
> >> The resource of group02-1 hoped that it started in an active node.(srv01)
> >> But, against rsc_location which I appointed, the resource is started in a standby
> node.(srv03)
> >>
> >> ------ output crm_mon -------------------------
> >>  Resource Group: UMgroup01
> >>     UmDummy01  (ocf::heartbeat:Dummy01):       Started srv01
> >>     UmDummy02  (ocf::heartbeat:Dummy): Started srv01
> >>     UmIPaddr   (ocf::heartbeat:IPaddr):        Started srv01
> >>  Resource Group: group02-1
> >>     Dummy01-1  (ocf::heartbeat:Dummy): Started srv03
> >>     Dummy01-2  (ocf::heartbeat:Dummy): Started srv03
> >>  Resource Group: group02-2
> >>     Dummy02-1  (ocf::heartbeat:Dummy): Started srv02
> >>     Dummy02-2  (ocf::heartbeat:Dummy): Started srv02
> >>  Resource Group: grpStonith1
> >>     prmStonithN1-1     (stonith:external/ssh): Started srv03
> >>  Resource Group: grpStonith2
> >>     prmStonithN2-1     (stonith:external/ssh): Started srv01
> >>  Resource Group: grpStonith3
> >>     prmStonithN3-1     (stonith:external/ssh): Started srv02
> >>  Clone Set: clnUMgroup01
> >>     Started: [ srv01 srv03 ]
> >>  Clone Set: clnPingd
> >>     Started: [ srv01 srv02 srv03 ]
> >>  Clone Set: clnPingd2
> >>     Started: [ srv01 srv02 srv03 ]
> >> ----------------------------------------------------
> >>
> >> ------ cib.xml group02-1 rsc_location --------------
> >>      <rsc_location id="grp02-1-1-location" rsc="group02-1" node="srv01" score="200"/>
> >>      <rsc_location id="grp02-1-2-location" rsc="group02-1" node="srv03" score="100"/>
> >>      <rsc_location id="grp02-1-3-location" rsc="group02-1" node="srv02" score="-INFINITY"/>
> >> ----------------------------------------------------
> >>
> >> Will my cib.xml be a mistake?
> >> Or will it be a bug?
> >
> > Your location constraints are working (run ptest on pe-input-4.bz2 and
> > you'll see that we originally intend to start the group on srv01).
> >
> > The problem is that their preference is being saturated by these two
> > colocation constraints:
> >      <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"/>
> >
> > Run ptest -s with pe-input-4.bz2 and you'll see the scores for
> 
> Sorry, that should have been pe-input-5.bz2
> 
> > Dummy01-1 are now:
> > native_color: Dummy01-1 allocation score on srv01: 1000000
> > native_color: Dummy01-1 allocation score on srv02: -1000000
> > native_color: Dummy01-1 allocation score on srv03: 1000000
> >
> > In the PE, 1000000 == INFINITY
> >
> > You would be better off with a constraint like example 9.3 which will
> > exclude any unconnected node and leave the previous location scores
> > unchanged:
> >
> >  
>
 http://www.clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/ch09s03s03s02.html#id2079508
> >
> 
> _______________________________________________
> Pacemaker mailing list
> Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>