Thanks Dejan - that was very helpful.

Last question :-)

I've modified this setup, taking into account your advice about
removing the ldirectord attributes (where are these things
documented!?).

Everything is running fine and I've got no errors in cluster.log -
only a few WARN's and they seem  harmless.

So when I reboot either node the other takes over just fine.

But - if I disconnect the network cable from either node - nothing
happens at all.
What do I need to do (or am I mis-understanding the concept here) in
order to get the node w/ no network to fail over?

Here is my current 'cibadmin -Ql > local.xml' (with status removed)

   <configuration>
     <crm_config/>
     <nodes>
       <node id="f8e04b68-2b8e-4eac-8b14-eb64ccc5379c"
uname="dmz2.example.com" type="normal"/>
       <node id="d5795fde-df25-451c-a0f2-a8337a8290e3"
uname="dmz1.example.com" type="normal"/>
     </nodes>
     <resources>
       <group id="WEB_IP_TEST">
         <primitive class="ocf" id="IPaddr_212_140_130_37"
provider="heartbeat" type="IPaddr">
           <operations>
             <op id="IPaddr_212_140_130_37_mon" interval="5s"
name="monitor" timeout="5s"/>
           </operations>
           <instance_attributes id="IPaddr_212_140_130_37_inst_attr">
             <attributes>
               <nvpair id="IPaddr_212_140_130_37_attr_0" name="ip"
value="212.140.130.37"/>
             </attributes>
           </instance_attributes>
         </primitive>
         <primitive class="ocf" id="IPaddr_212_140_130_38"
provider="heartbeat" type="IPaddr">
           <operations>
             <op id="IPaddr_212_140_130_38_mon" interval="5s"
name="monitor" timeout="5s"/>
           </operations>
           <instance_attributes id="IPaddr_212_140_130_38_inst_attr">
             <attributes>
               <nvpair id="IPaddr_212_140_130_38_attr_0" name="ip"
value="212.140.130.38"/>
             </attributes>
           </instance_attributes>
         </primitive>
         <primitive class="ocf" id="ldirectord_3" provider="heartbeat"
type="ldirectord">
           <operations>
             <op id="ldirectord_3_mon" interval="120s" name="monitor"
timeout="60s"/>
           </operations>
         </primitive>
       </group>
     </resources>


     <constraints>
       <rsc_location id="rsc_location_group_1" rsc="WEB_IP_TEST">
         <rule id="prefered_location_DMZ1" score="100">
           <expression attribute="#uname"
id="prefered_location_DMZ1_expr" operation="eq"
value="dmz1.example.com"/>
         </rule>
       </rsc_location>
     </constraints>
   </configuration>


-Peter





On 12/09/2007, Dejan Muhamedagic <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Wed, Sep 12, 2007 at 04:24:47PM +0100, Peter Farrell wrote:
> > Andreas -
> >
> > A follow up if you will...
> >
> > 1) RE: finding that /usr/lib/ocf directory - very nice. (Was this in
> > the documentation or am I being thick?)
> >
> > 3) "The ldirectord wrapper is a ocf compliant resource agent which
> > starts, stops and monitors ldirectord."
> >
> > I'm not sure on the use here - I've deleted the symbolic link in
> > /etc/ha.d/haresources.d/ldirectord and copied over the wrapper from
> > /usr/lib/ocf/resource.d/heartbeat/ldirectord along with
> > .ocf-shellfuc.ocf-shellfuncs.
> > I edited the OCF_ROOT path from:
> > ${OCF_ROOT}/resource.d/heartbeat/.ocf-shellfuncs
> > to
> > ${OCF_ROOT}/etc/ha.d/resource.d/.ocf-shellfuncs
> >
> > Is this the correct way to use the wrapper?
> > (because when it starts - the cluster goes straight to hell - so I'm
> > guessing 'no' here - although it could be totally related to the next
> > question!)
>
> No. There are three different kinds of RAs: LSB, heartbeat,
> and OCF. You can't use an OCF RA as a heartbeat one. In short,
> these three are expected to behave in a different manner.
>
> > 2a) you have to create another resource definition for that ldirectord 
> > resource.
> >
> > Would this be the "primitive" "type" from IPaddr to ...?  for the ip
> > address definitions? Or is it that you change ldirectord class from
> > 'heartbeat' to 'ocf'?
>
> Yes, the last one. It seems that the OCF ldirectord does not
> support any parameters, so you should remove the
> "ldirectord_3_attr_1" parameter too.
>
> > Sorry - After looking over the linux-ha site I'm still confused.
> > You create a definition for each resource (ip address 1 and 2)  then
> > one for the ldirectord itself right? I've got those - I'm not clear on
> > the additional definitions I need.
> >
> > 2b) I'm pretty sure you also have to define colocation constraints
> > between the IP resources you want to serve and the ldirectord
> > resource.
> >
> > What would that look like? Do you have an example?
> > I thought (from the website)
> > "This constraint is already implicit because there is a group over
> > these resources."
>
> Yes, you typically put the resources you want to run on the same
> node in a group.
>
> Thanks.
>
> Dejan
>
> > RESOURCES
> > ===========
> >
> > <resources>
> >   <group id="group_1">
> >     <primitive class="ocf" id="IPaddr_212_140_130_37"
> > provider="heartbeat" type="IPaddr">
> >       <operations>
> >         <op id="IPaddr_212_140_130_37_mon" interval="5s"
> > name="monitor" timeout="5s"/>
> >       </operations>
> >         <instance_attributes id="IPaddr_212_140_130_37_inst_attr">
> >           <attributes>
> >             <nvpair id="IPaddr_212_140_130_37_attr_0" name="ip"
> > value="212.140.130.37"/>
> >           </attributes>
> >         </instance_attributes>
> >     </primitive>
> >     <primitive class="ocf" id="IPaddr_212_140_130_38"
> > provider="heartbeat" type="IPaddr">
> >       <operations>
> >         <op id="IPaddr_212_140_130_38_mon" interval="5s"
> > name="monitor" timeout="5s"/>
> >       </operations>
> >         <instance_attributes id="IPaddr_212_140_130_38_inst_attr">
> >           <attributes>
> >             <nvpair id="IPaddr_212_140_130_38_attr_0" name="ip"
> > value="212.140.130.38"/>
> >           </attributes>
> >         </instance_attributes>
> >     </primitive>
> >     <primitive class="heartbeat" id="ldirectord_3"
> > provider="heartbeat" type="ldirectord">
> >       <operations>
> >         <op id="ldirectord_3_mon" interval="120s" name="monitor" 
> > timeout="60s"/>
> >       </operations>
> >         <instance_attributes id="ldirectord_3_inst_attr">
> >           <attributes>
> >             <nvpair id="ldirectord_3_attr_1" name="1" 
> > value="ldirectord.cf"/>
> >           </attributes>
> >         </instance_attributes>
> >     </primitive>
> >   </group>
> > </resources>
> >
> >
> >
> > CONSTRAINTS
> > ===========
> >
> > <constraints>
> >   <rsc_location id="rsc_location_group_1" rsc="group_1">
> >     <rule id="prefered_location_group_1" score="100">
> >       <expression attribute="#uname"
> > id="prefered_location_group_1_expr" operation="eq"
> > value="dmz1.example.com"/>
> >     </rule>
> >   </rsc_location>
> > </constraints>
> >
> >
> > Best Regards;
> > - Peter Farrell
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On 11/09/2007, matilda matilda <[EMAIL PROTECTED]> wrote:
> > > >>> "Peter Farrell" <[EMAIL PROTECTED]> 09/11/07 10:11 PM >>>
> > >
> > > Hi Peter,
> > >
> > > 1) In version 2.1.2 the mentioned script aka ocf-compliant RA should be 
> > > part of the distribution.
> > > You can also use the one posted.
> > > 2) Yes, you have to create another resource definition for that 
> > > ldirectord resource.
> > > I'm pretty sure you also have to define colocation constraints between 
> > > the IP resources you want to serve
> > > and the ldirectord resource.
> > > 3) The ldirectord wrapper is a ocf compliant resource agent which starts, 
> > > stops and monitors
> > > ldirectord.
> > > 4) For me it works.  ;-)
> > >
> > > Hope, it helps.
> > >
> > > Best regards
> > > Andreas Mock
> > >
> > > _______________________________________________
> > > Linux-HA mailing list
> > > Linux-HA@lists.linux-ha.org
> > > http://lists.linux-ha.org/mailman/listinfo/linux-ha
> > > See also: http://linux-ha.org/ReportingProblems
> > >
> > _______________________________________________
> > Linux-HA mailing list
> > Linux-HA@lists.linux-ha.org
> > http://lists.linux-ha.org/mailman/listinfo/linux-ha
> > See also: http://linux-ha.org/ReportingProblems
> _______________________________________________
> Linux-HA mailing list
> Linux-HA@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
>
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

Reply via email to