TruCluster Server Handbook (HP Technologies)

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.

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:

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

Related

Категории