On Tue, May 21, 2013 at 02:20:46PM +0000, Tony Stocker wrote:
> On Tue, 21 May 2013, Ulrich Windl wrote:
> 
> >>>> Tony Stocker <[email protected]> schrieb am 21.05.2013 um 15:21 in
> > Nachricht
> > <alpine.lrh.2.03.1305211310530.10...@tf6102xuryqne.ccf.rbfqvf.anfn.tbi>:
> >> On Tue, 21 May 2013, Ulrich Windl wrote:
> >>
> >>> Hi!
> >>>
> >>> I don't know what you are trying to do, but could "node coloring" do what
> >> you want (run resources on nodes with a specific color (red/green/yellow))?
> >
> > Hi!
> >
> > Maybe that's my fault: "system health" is the term that you should look for 
> > ("info HealthSMART", "node-health-strategy").
> > I don't think the crm can write corresponding rules without using XML.
> >
> > Regards,
> > Ulrich
> 
> 
> Okay, let me back up a bit.  Maybe you can help me answer the following 
> questions which sort of underlie what I'm trying to do:
> 
> 
>       1. Can a location constraint apply to a resource group?  Or must 
> it apply only to resource primitives?
> 
> 
>       2. Can a location constraint rule apply to a node parameter other 
> than #uname?
> 
> 
> 
> I've tried creating one using crmsh but it doesn't seem to be working as I 
> anticipate:
> 
> # crm configure show
> node gpmhac01 \
>          attributes class="A" kernel="2.6.32-358.6.2.el6.x86_64"
> node gpmhac06 \
>          attributes class="A" kernel="2.6.32-358.6.2.el6.x86_64"
> node gpmhac09 \
>          attributes class="B" kernel="2.6.32-358.6.2.el6.x86_64"
> node gpmhac10 \
>          attributes class="B" kernel="2.6.32-358.6.2.el6.x86_64"
> node gpmhac11 \
>          attributes class="B" kernel="2.6.32-358.6.2.el6.x86_64"
> node gpmhac12 \
>          attributes class="B" kernel="2.6.32-358.6.2.el6.x86_64"
> primitive HACMASTER-BAK-IP ocf:heartbeat:IPaddr2 \
>          params ip="192.168.1.179" \
>          op monitor interval="30s"
> primitive HACMASTER-COMM-IP ocf:heartbeat:IPaddr2 \
>          params ip="10.8.1.1" \
>          op monitor interval="30s"
> primitive HACMASTER-EXT-IP ocf:heartbeat:IPaddr2 \
>          params ip="186.106.183.10" \
>          op monitor interval="30s"
> primitive HACMASTER-JAVA ocf:PPS:hacJavaLinks
> primitive HACMASTER-JOBFILE ocf:PPS:hacJobFile \
>          params role="hac" job="hacmaster"
> primitive HACMASTER-PWFILE ocf:PPS:hacPWFile \
>          params role="hac"
> primitive HACMASTER-SSHKEYS ocf:PPS:hacSSHKeys
> primitive HACMASTER-STOR-IP ocf:heartbeat:IPaddr2 \
>          params ip="10.8.3.1" \
>          op monitor interval="30s"
> group HACMASTER HACMASTER-JOBFILE HACMASTER-PWFILE HACMASTER-JAVA 
> HACMASTER-SSHKEYS HACMASTER-EXT-IP HACMASTER-BAK-IP HACMASTER-COMM-IP 
> HACMASTER-STOR-IP \
>          meta target-role="Started"
> location hacmaster_prefer_b HACMASTER \
>          rule $id="hacmaster_prefer_b-rule" 1000: #class eq B

You use "class" above.
So lose the hash mark:
           rule $id="hacmaster_prefer_b-rule" 1000: class eq B

The "#uname" attribute is a special, implicit one...


> property $id="cib-bootstrap-options" \
>          dc-version="1.1.8-7.el6-394e906" \
>          cluster-infrastructure="classic openais (with plugin)" \
>          expected-quorum-votes="6" \
>          stonith-enabled="false"
> rsc_defaults $id="rsc-options" \
>          resource-stickiness="500"
> 
> # crm_mon -1r
> Last updated: Tue May 21 14:15:51 2013
> Last change: Tue May 21 14:04:44 2013 via cibadmin on gpmhac12
> Stack: classic openais (with plugin)
> Current DC: gpmhac10 - partition with quorum
> Version: 1.1.8-7.el6-394e906
> 6 Nodes configured, 6 expected votes
> 8 Resources configured.
> 
> Online: [ gpmhac01 gpmhac06 gpmhac09 gpmhac10 gpmhac11 gpmhac12 ]
> 
> Full list of resources:
> 
>   Resource Group: HACMASTER
>       HACMASTER-JOBFILE  (ocf::PPS:hacJobFile):  Started gpmhac01
>       HACMASTER-PWFILE   (ocf::PPS:hacPWFile):   Started gpmhac01
>       HACMASTER-JAVA     (ocf::PPS:hacJavaLinks):        Started gpmhac01
>       HACMASTER-SSHKEYS  (ocf::PPS:hacSSHKeys):  Started gpmhac01
>       HACMASTER-EXT-IP   (ocf::heartbeat:IPaddr2):       Started gpmhac01
>       HACMASTER-BAK-IP   (ocf::heartbeat:IPaddr2):       Started gpmhac01
>       HACMASTER-COMM-IP  (ocf::heartbeat:IPaddr2):       Started gpmhac01
>       HACMASTER-STOR-IP  (ocf::heartbeat:IPaddr2):       Started gpmhac01
> 
> 
> As you can see even though I have a location rule with a score of 1000 and 
> the default stickiness is 500, the resource group 'HACMASTER' continues to 
> reside on node 'gpmhac01' which is a node that has the node attribute 
> class='A'
> 
> This makes me think that a.) location constraints don't work on resource 
> groups, or b.) location constraints can't handle custom defined node 
> attributes, or c.) I'm not configuring something correctly.
> 
> 
> Thanks,
> Tony
> 
> >
> >>>
> >>> Regards,
> >>> Ulrich
> >>
> >> I can't find any references to "node coloring" in the documentation that I
> >> have, or through a quick search online so I don't know if that applies to
> >> my situation.
> >>
> >>
> >> What I am trying to do is to have a resource group prefer to run on a
> >> specific class of node over other classes of nodes by using a special node
> >> attribute that I define for each node.  I want to do this so that I can
> >> avoid setting a location constraint score for each individual node, and
> >> instead provide a location constraint score for each 'class' of nodes -
> >> based on the node attribute value.  But I do NOT want the resource group
> >> excluded from running on other classes of nodes, I just want it to prefer
> >> a specific class.
> >>
> >> I **think** what I need would look like this in XML, based on Example 8.9
> >> from the document previously mentioned in my original post:
> >>
> >> <rsc_location id="hacmaster-prefers-b" rsc="HACMASTER">
> >>     <rule id="prefer-b-rule" score="1000">
> >>        <expression id="prefer-b-expr" attribute="#class"
> >>         operation="eq" value="B"/>
> >>     </rule>
> >> </rsc_location>
> >>
> >>
> >> However since we are frequently and repeatedly admonished to NOT directly
> >> edit XML code - and I honestly do NOT want to edit XML code -  but rather
> >> to use the tools provided (i.e. crm, pcs, etc.) I am looking for the
> >> syntax for setting such a rule using crm.  Assuming to begin with, of
> >> course, that such a rule is possible in the first place.
> >>
> >> Thanks!
> >>
> >> Tony
> >>
> >>>
> >>>>>> Tony Stocker <[email protected]> schrieb am 21.05.2013 um 14:25 in
> >>> Nachricht
> >>> <alpine.lrh.2.03.1305211212370.10...@tf6102xuryqne.ccf.rbfqvf.anfn.tbi>:
> >>>
> >>>> Version Info:
> >>>> OS:                     CentOS 6.4
> >>>> Kernel (current):       2.6.32-358.6.2.el6.x86_64
> >>>> Pacemaker:              1.1.8-7.el6
> >>>> Corosync:               1.4.1-15.el6_4
> >>>> CRMSH:                  1.2.5-55.4
> >>>>
> >>>> I'm using a number of documents from clusterlabs.org, specific to this
> >>>> question I'm using "Pacemaker-1.1-Pacemaker_Explained-en-US.pdf" and I'm
> >>>> in Chapter 8, section 8.4 regarding the use of node parameters to control
> >>>> resource location.  This particular document appears to rely almost 
> >>>> solely
> >>>> on XML snippets for its examples, and in this case these snippets are the
> >>>> only examples.  In an online archive of the mailing list for Pacemaker I
> >>>> found a similar question from Jan 11, 2010 where the questioner was
> >>>> referred to:
> >>>>          "Or read the crm_cli doc at clusterlabs.org.
> >>>>          Thanks,
> >>>>          Dejan "
> >>>>
> >>>> However the document referred to, "crm_cli doc", no longer appears to be
> >>>> hosted on clusterlabs.org.  Does anyone know of its new location?  Or the
> >>>> location of a similar document which will explain the correct syntax for
> >>>> using 'crm' to configure a rule?
> >>>>
> >>>> I have defined a node parameter called "class", and I want to have a rule
> >>>> which provides a score based on the class value (which is either 'A' or
> >>>> 'B' at the moment, but could increase to other values at a later date.)
> >>>> For example here is a snippet from 'crm configure show' of two nodes in
> >>>> the cluster:
> >>>>
> >>>>          node gpmhac01 \
> >>>>                  attributes class="A" kernel="2.6.32-358.6.2.el6.x86_64"
> >>>>          node gpmhac09 \
> >>>>                  attributes class="B" kernel="2.6.32-358.6.2.el6.x86_64"
> >>>>
> >>>> I have a defined group called 'HACMASTER':
> >>>>
> >>>>   Resource Group: HACMASTER
> >>>>       HACMASTER-JOBFILE  (ocf::PPS:hacJobFile):  Started gpmhac01
> >>>>       HACMASTER-PWFILE   (ocf::PPS:hacPWFile):   Started gpmhac01
> >>>>       HACMASTER-JAVA     (ocf::PPS:hacJavaLinks):        Started gpmhac01
> >>>>       HACMASTER-SSHKEYS  (ocf::PPS:hacSSHKeys):  Started gpmhac01
> >>>>       HACMASTER-EXT-IP   (ocf::heartbeat:IPaddr2):       Started gpmhac01
> >>>>       HACMASTER-BAK-IP   (ocf::heartbeat:IPaddr2):       Started gpmhac01
> >>>>       HACMASTER-COMM-IP  (ocf::heartbeat:IPaddr2):       Started gpmhac01
> >>>>       HACMASTER-STOR-IP  (ocf::heartbeat:IPaddr2):       Started gpmhac01
> >>>>
> >>>> As you can see it got started on 'gpmhac01', which from the snippet above
> >>>> this has a node class of 'A'.  I would like to write a location 
> >>>> constraint
> >>>> rule which basically gives a significantly higher score if the node class
> >>>> is 'B'.  I do not want to prohibit the resource group from running on a
> >>>> class 'A' system, but I want it to run on a class 'B' if at all possible.
> >>>>
> >>>> Can someone either point me to a document which more fully explains the
> >>>> syntax, and hopefully provides examples, of the crm shell for the use of
> >>>> things beyond simple configuration of primitives, to include 
> >>>> configuration
> >>>> examples of rules?  Or at the very least can someone give me an example 
> >>>> of
> >>>> a crm configure rule configuration for a node parameter OTHER THAN then
> >>>> node name?  I have twelve (12) nodes in this cluster, six are class 'A'
> >>>> and six are class 'B', I don't want to have to write twelve location
> >>>> constraints for the same resource group if I can simply use a node
> >>>> parameter to do the same thing -- which I think I should be able to do.
> >>>>
> >>>> Thanks very much,
> >>>>
> >>>> Tony
> >>>>
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> _______________________________________________
> Linux-HA mailing list
> [email protected]
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

Reply via email to