[Linux-HA] R1 to R2 testing: cib.xml & ldirectord questions for 2
node cluster
Andrew Beekhof
beekhof at gmail.com
Thu Sep 13 05:58:58 MDT 2007
On 9/13/07, Peter Farrell <peter.d.farrell at gmail.com> wrote:
> 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!?).
http://linux-ha.org/ResourceAgents
> 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.
how many communication paths?
> 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)
which is the important part :-(
that and supplying logs (as attachments)
>
> <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 <dejanmm at fastmail.fm> 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 <matilda at grandel.de> wrote:
> > > > >>> "Peter Farrell" <peter.d.farrell at gmail.com> 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 at 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 at 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 at 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 at lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
>
More information about the Linux-HA
mailing list