24.8 Mutual Exclusive Resource

What if you have an application that has to run all the time but cannot run on the same member at the same time as another application?

In this section we will cover one possible solution for handling this type of scenario.

For the application that must run at all times, we will create an application resource named prodAPP. Our other application (that cannot run on the same member as prodAPP) will be called devAPP.

The prodAPP resource will be "favored" to member1 (molari), while the devAPP application will be "restricted" to member2 (sheridan). In this scenario, if both members are up, then both resources will be running on opposite members. The fun begins when member1 becomes unavailable.

If member1 is unavailable, prodAPP will relocate to member2, but prodAPP and devAPP cannot be running on the same member at the same time!

24.8.1 Creating the USR_MUTEX Attribute

In order for prodAPP and devAPP to know which resource is their "anti-resource", we will create a user-defined application resource attribute that will be used for this purpose. The attribute will be a "name_list" type named USR_MUTEX.

Save a copy of the original application.tdf file.

Add the following entry to the application.tdf file.

 #!========================== attribute: USR_MUTEX type: name_list switch: -o mx default: required: no

24.8.2 Creating the prodAPP Application Resource

The prodAPP application resource will be defined with the follow attributes:

•	`-B`	–	Our `prodAPP` application.
•	`-h`	–	The hosting member. In this case, `molari`.
•	`-p`	–	The placement policy. In this case, "`favored`".
•	`-o as`	–	Set `AUTO_START`.
•	`-o mx`	–	The mutual-exclusive resource list. In this case, "`devAPP`".

Create the prodAPP application resource using the caa_profile command.

 # caa_profile -create prodAPP -t application -B /code/caa/prodAPP \ > -o mx=devAPP,as=1 -h molari -p favored

In the "start" entry point of the action script for prodAPP we will need to add logic to check the status and location of devAPP. If devAPP is running on the same member, stop it. If devAPP is not running, and prodAPP is running on one of its favored members, start devAPP.

The following piece of code (written in Korn shell) is one approach to handle stopping and starting devAPP.

 host=$(hostname -s) memb=NO_MEMB for i in $_USR_MUTEX do   caa_stat -a $i -r   if (( $? == 0 )) ; then     memb=$(caa_stat -t $i \          | tail -1 \          | awk '{ print $5 }')     if [[ $memb = $host ]] ; then        caa_stop $i     fi    else     start_mutex=0     for j in $_CAA_HOSTING_MEMBERS     do       if [[ $host = $j ]] ; then           start_mutex=1           break         fi       done       if (( $start_mutex )) ; then            for k in $_USR_MUTEX            do               caa_start $k            done         fi     fi done

← Loop through the list of mutually exclusive resources.
← Check to see if the resource is running.
← If the resource is running…
← Run the caa_stat(8) command.
← Get the last line.
← Return the member name where the resource is running.

← If the member is the same as this member…
← Stop the mutually exclusive resource.

← Loop the list of hosting members.
← If we're running where we're supposed to…
← Set a variable.
← Stop the loop.

← If we're running where we're supposed to…
← Loop through the list mutually exclusive resources.

← Start the mutually exclusive resource.

24.8.3 Creating the devAPP Application Resource

The devAPP application resource will be defined by the follow attributes:

-B – Our devAPP application.
-h – The hosting member. In this case, sheridan.
-p – The placement policy. In this case, "restricted".
-o mx – The mutual-exclusive resource list. In this case, "prodAPP".

Create the devAPP application resource using the caa_profile command.

 # caa_profile -create devAPP -t application -B /code/caa/devAPP \ > -o mx=prodAPP -h sheridan -p restricted

In the "start" entry point of the action script for devAPP, check the status and location of prodAPP. If prodAPP is running on a member where devAPP is restricted, then exit with an error so the CAA will not attempt to restart it.

The following piece of code (written in Korn shell) is one approach to insure that devAPP doesn't start if prodAPP is running on the same member.

  host=$(hostname -s)  memb=NO_MEMB  for i in $_USR_MUTEX   do    caa_stat -a $i -r    if (( $? == 0 )) ; then       memb=$(caa_stat -t $i \            | tail -1 \            | awk '{ print $5 }')       if [[ $memb = $host ]] ; then          exit 1         fi     fi done

← Loop through the list of mutually exclusive resources.

← Check to see if the resource is running.
← If the resource is running…
← Run the caa_stat command.
← Get the last line.
← Return the member name where the resource is running.
← If the member is the same as this member…
← Exit because a mutually exclusive resource is running.

24.8.4 Mutually Exclusive Resources in Action

We've created the devAPP and prodAPP application resources; modified the action scripts for each resource; and tested the action scripts for each resource (always test your action scripts before registering your resources!). So let's register and start the resources.

 # caa_register devAPP prodAPP

 # caa_start devAPP prodAPP Attempting to start 'devAPP' on member 'sheridan' Start of 'devAPP' on member 'sheridan' succeeded. Attempting to start 'prodAPP' on member 'molari' Start of 'prodAPP' on member 'molari' succeeded.

Verify that the resources have started using the caa_stat command.

 # caa_stat -t devAPP prodAPP Name        Type          Target       State      Host ------------------------------------------------------------ devAPP      application   ONLINE       ONLINE     sheridan prodAPP     application   ONLINE       ONLINE     molari

Does the logic work in prodAPP's action script "start" entry point? Let's see by relocating prodAPP to sheridan.

 # caa_relocate prodAPP Attempting to stop 'prodAPP' on member 'molari' Stop of 'prodAPP' on member 'molari' succeeded. Attempting to start 'prodAPP' on member 'sheridan' Start of 'prodAPP' on member 'sheridan' succeeded.

If the logic worked, devAPP should be stopped.

 # caa_stat -t devAPP prodAPP Name               Type             Target          State         Host ------------------------------------------------------------------------- devAPP             application      OFFLINE         OFFLINE prodAPP            application      ONLINE          ONLINE        sheridan

Attempt to start devAPP.

 # caa_start devAPP Attempting to start 'devAPP' on member 'sheridan' Start of 'devAPP' on member 'sheridan' failed. molari : Resource devAPP (application) cannot run on molari Could not start resource devAPP.

The logic in devAPP's action script "start" entry point appears to be working, but we've only tested the first branch of prodAPP's action script "start" entry point when we relocated to sheridan.

Let's complete our test by relocating prodAPP to molari.

 # caa_relocate prodAPP Attempting to stop 'prodAPP' on member 'sheridan' Stop of 'prodAPP' on member 'sheridan' succeeded. Attempting to start 'prodAPP' on member 'molari' Start of 'prodAPP' on member 'molari' succeeded.

If our logic worked, devAPP should have been restarted on sheridan.

 # caa_stat -t devAPP prodAPP  Name           Type          Target       State        Host ----------------------------------------------------------------- devAPP          application   ONLINE       ONLINE       sheridan prodAPP         application   ONLINE       ONLINE       molari