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!
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
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. |
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. |
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