AW: [Linux-HA] Shared Resource across groups

[Oliver.Jansen at t-systems.com]

Hi,

I have a similar setup and I use a "watch" resource (LSB script) which is grouped with the IP addresses. The services (your databases) are not grouped and stuck to their server. The watch script only implements the status command; start and stop always return fine. 
To make the watch resource dependent on the base resource I use a rsc_order directive. The watch script may check fail-counts of the local base resource or the result of the base resource LSB status command.


Check this out:
(The stickiness values are still being worked on.)

Base resources:

        <primitive class="lsb" id="gw_adexp_a" provider="heartbeat" type="gw_adexp" resource_failure_stickiness="0">
          <operations>
            <op id="gw_adexp_a_mon" interval="20s" name="monitor" timeout="15s"/>
          </operations>
          <instance_attributes id="gw_adexp_a_attr">
            <attributes>
              <nvpair name="target_role" id="gw_adexp_a_target_role" value="default"/>
            </attributes>
          </instance_attributes>
        </primitive>
        <primitive class="lsb" id="gw_adexp_b" provider="heartbeat" type="gw_adexp" resource_failure_stickiness="0">
          <operations>
            <op id="gw_adexp_b_mon" interval="20s" name="monitor" timeout="15s"/>
          </operations>
          <instance_attributes id="gw_adexp_b_attr">
            <attributes>
              <nvpair name="target_role" id="gw_adexp_b_target_role" value="default"/>
            </attributes>
          </instance_attributes>
        </primitive>

Watch resource group:

        <group id="group_adexp_ip">
        <primitive class="lsb" id="gw_adexp" provider="heartbeat" type="gw_adexp_watch" resource_stickiness="0" resource_failure_stickiness="-1000">
          <operations>
            <op id="gw_adexp_mon" interval="20s" name="monitor" timeout="15s"/>
          </operations>
          <instance_attributes id="gw_adexp_attr">
            <attributes>
              <nvpair name="target_role" id="gw_adexp_target_role" value="default"/>
            </attributes>
          </instance_attributes>
        </primitive>
          <primitive class="ocf" id="IPaddr_10_32_5_26" provider="heartbeat" type="IPaddr">
            <operations>
              <op id="IPaddr_10_32_5_26_mon" interval="5s" name="monitor" timeout="5s"/>
            </operations>
            <instance_attributes id="IPaddr_10_32_5_26_inst_attr">
              <attributes>
                <nvpair id="IPaddr_10_32_5_26_attr_0" name="ip" value="10.32.5.26"/>
              </attributes>
            </instance_attributes>
          </primitive>
        </group>

Resource constraints:
(To make a resource stick on a node A, make it -INF on B. Making it INF on A and 0 on B, still leaves HA with the option to move it to B when A fails.)

      <rsc_location id="rsc_location_gw_adexp_a" rsc="gw_adexp_a">
        <rule id="rsc_gw_adexp_a2" score="-INFINITY">
          <expression attribute="#uname" id="id_gw_adexp_a2" operation="eq" value="sxfaim2"/>
        </rule>
      </rsc_location>

      <rsc_location id="rsc_location_gw_adexp_b" rsc="gw_adexp_b">
        <rule id="rsc_gw_adexp_b1" score="-INFINITY">
          <expression attribute="#uname" id="id_adexp_b1" operation="eq" value="sxfaim1"/>
        </rule>
      </rsc_location>

      <rsc_location id="rsc_location_group_adexp_ip" rsc="group_adexp_ip">
        <rule id="rsc_group_adexp_ip" score="200">
          <expression attribute="#uname" id="id_group_adexp_ip" operation="eq" value="sxfaim1_"/>
        </rule>
      </rsc_location>

      <rsc_location id="gateway_access_adexp" rsc="group_adexp_ip">
        <rule id="gateway_access_rule_adexp" score="300">
          <expression id="gateway_access_rule_adexp_positive" attribute="pingdval" operation="gt" value="300"/>
        </rule>
      </rsc_location>

      <rsc_order id="order_gw_adexp_a" from="group_adexp_ip" to="gw_adexp_a"/>
      <rsc_order id="order_gw_adexp_b" from="group_adexp_ip" to="gw_adexp_b"/>


I hope this helps. Regards,
Oliver

> -----Ursprüngliche Nachricht-----
> Von: linux-ha-bounces at lists.linux-ha.org 
> [mailto:linux-ha-bounces at lists.linux-ha.org] Im Auftrag von 
> Thurston Nabe
> Gesendet: Mittwoch, 2. August 2006 20:21
> An: linux-ha at lists.linux-ha.org
> Betreff: [Linux-HA] Shared Resource across groups
> 
> Hello,
>  
> After carefully reading the DTD and the wiki, I'm still not 
> clear as to how to do what I want to do.
>  
> This is the scenario I would like to configure
>  
> Assume two groups: (pseudo-configuration) <group id="A">
>    <resource type="ip" value="ip-1"/>
>   <resource type="database" />
> </group>
> <group id="B">
>    <resource type="ip" value="ip-2"/>
>   <resource type="database" />
> </group>
>  
> In the nominal case, group A runs on node A and group B runs 
> on node B.
> So far so good.
>  
> If group A fails for any reason (and I'm running monitor 
> actions on both the ip resource and the database), I want 
> heartbeat to migrate ip-A over to node B (and this doesn't 
> present a problem).  But I don't need the "database" resource 
> to migrate to node B per se, because the database resource is 
> already up and running as part of group B (I don't want 
> multiple instances (processes) of the database to ever be 
> running on the SAME node).  My applications will still work 
> with one database instance
> (process) running on one node and serving two ips.
>  
> This probably wouldn't present a problem as far as heartbeat 
> calling "start" on the database resource--I can just return 
> OCF_SUCCESS if it's already running.  
> But there are two issues:
> 1.  I'd prefer not to have the monitor action be called twice 
> as often in this case--it's calling the exact same resource 
> script which is testing to see whether the same database 
> instance is up and functioning.
> 2.  The real problem is on action "stop" (let's say because 
> node A's problems have been fixed and it's ready to go, and I 
> want heartbeat to always choose running only one group per 
> node if at all possible)--so heartbeat would first call stop 
> on the group A running on node B because it wants to migrate 
> group A back to node A).  As far as the ip-1 resource no 
> problem, but I don't want to honor the call to stop on the 
> database resource, because that same database process is 
> serving group B.
>  
> I'm assuming this is possible with a set of resource 
> constraints and rules, but I couldn't figure out how.  I had 
> thought about just not implementing the stop action in the 
> database resource script (returning OCF_SUCCESS but not 
> actually shutting down the database process), but I worry 
> that heartbeat (perhaps via "just-checking" monitor calls 
> will detect a false "split-brained" condition) and it's a bit 
> of a hack.
> If someone has encountered a similar scenario and could post 
> a cib.xml or offer other help, I'd appreciate it.
>  
> Thanks.
>  
>  
> _______________________________________________
> 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
>