24.4 CFS Server Relocation

An application is often only as useful as its ability to access application data successfully. If the application data were on a file system (and not on a raw device), it would certainly be more efficient to have the application resource and the CFS server located on the same server. Since there is currently no "CFS server" resource type that can be used to monitor the location of the CFS server for a file system and that your application resource can have as a dependency, here are a couple of possible solutions:

Create an application resource that monitors and relocates a CFS server.
Add CFS server resource and monitoring capability to your existing application resource.

IMPORTANT

If you plan to relocate a file system in a multi-fileset domain, remember that the CFS server serves AdvFS file systems on a per-domain basis.

In other words, do not create a resource that relocates know#ledge to member1 and another resource that relocates know#where to member2.

For more information, see Chapter 13.

24.4.1 CFS Server Application Resource

A CFS server application resource can also be implemented to create a simple, highly available application resource (see section 24.2) with the following considerations:

Modify the application.tdf type definition file to add two user-defined attributes to file systems and mount points. Each of these attributes should be defined as a "name_list" type.
Modify the "start" and "check" entry points in the action script to perform the CFS server relocation tasks.

24.4.1.1 Add USR_CFS and USR_MNT_PT User-defined Attributes

The USR_CFS attribute will be used to define the file system list, whereas the USR_MNT_PT attribute will be used for a list of mount points that should match up with the file system list (in fact the action script should check that this is the case).

      USR_CFS = cluster_root#root cluster_usr#usr cluster#var USR_MNT_PT = / /usr /var

Save a copy of the original application.tdf^[2] file.

 # cd /var/cluster/caa/template

 # cp application.tdf application.tdf.orig

Modify the application.tdf file.

The following entries should be added to the file.

 #!========================== attribute: USR_CFS type: name_list switch: -o cfs default: required: no

 #!========================== attribute: USR_MNT_PT type: name_list switch: -o mp default: required: no

24.4.1.2 Creating a CFS Server Action Script

As mentioned in section 24.4.1, the "start" and "check" entry points to the action script should be modified to check the location of the CFS server for the list of file systems and relocate the CFS server if the member running the application resource is not the CFS server.

The following tasks will need to be added to the action script:

Check to see if the file system is mounted.

If the file system is not mounted, either mount it or post a message and exit.
If the file system is mounted privately, exit because either the member mounted it so it is the CFS server, or the member did not mount it in which case it cannot be unmounted or relocated by the member.

The following piece of code (written in Korn shell) is one approach to checking the file system status.

 ic=0 jc=0 for i in $_USR_CFS do   (( ic += 1 ))   for j in $_USR_MNT_PT   do     (( jc += 1 ))     if (( $ic != $jc ))     then       continue     fi     fs="$(mount | grep $i)" ; stat=$?

← Loop through the list of file systems.

← Loop through the list of mount points.

← Make sure the file system and mount point is the same place in the list.

← See if the file system is mounted.

    if (( $stat != 0 ))    then      not_mounted $i $j      jc=0      break    else      if [[ $fs != *server_only* ]]      then        cfs_relocate $i $j        jc=0        break      else         priv_mount $i $j         jc=0         break        fi      fi    done done

← The file system is not mounted.
← Call the not_mounted function.

← Check to see if the file system is privately mounted.
← Call the cfs_relocate function.

← Call the priv_mount function.

Check the location of the CFS server.

If the CFS server is not the member running the application resource, relocate the CFS server.

 function cfs_relocate {   cfs="$(cfsmgr -F raw $2 \   | awk '$0 ~ ss { print $5 }' ss=$1 \   | cut -d. -f1)"  member="$(hostname -s)"  if [[ $cfs != $member ]]   then     cfsmgr -r -a server=$member -s $2     stat=$?     if (( $stat != 0 )) ; then          return $stat        fi     fi     return 0   }

← Get information from cfsmgr.
← Search for the file system, get the CFS server, and
← return only the base CFS server hostname.

← Get this member's base hostname.
← If this is not the CFS server…

← Relocate it.

← If the relocation was unsuccessful…
← Return an error.

There are some additional questions you may wish to consider (and even answer):

What if the relocation fails? Is this acceptable or should you exit the script with a failure status?
If there is a relocation failure, what was the error? Should you address and attempt to handle specific errors, or is any error fatal?
- If the error is "Not Served", should you attempt to forcibly unmount the file system with the "cfsmgr -u" command and then attempt to mount the file system?
If the relocation fails, should another attempt be made? If so, how many? When should you give up and return an error?

There is not just one answer to each of these questions. Use your best judgment and try a few options to see what works best for your configuration.

24.4.1.3 Creating a CFS Server Application Resource

In this section, we will create a CFS Server application resource that we'll name cfs_common. The cfs_common resource will be a "favored" resource and used to relocate the CFS server duties for cluster_root, cluster_usr, and cluster_var to member1 (molari). Of course this resource (or a similar one) can be used as a dependency for another application resource.

We will use the caa_profile command with the following options:

`-a`	– Our customized CFS server script.
`-o cfs`	– Used to set the `USR_CFS` attribute variable.
`-o mp`	– Used to set the `USR_MNT_PT` attribute variable.
`-o as`	– Set `AUTO_START`.
`-o ap`	– Set `ACTIVE_PLACEMENT`.
`-p`	– Set the `PLACEMENT` to "`favored`".
`-h`	– Set the `HOSTING_MEMBER`.

 # caa_profile -create cfs_common -t application -a cfs_relo.scr \ > -o cfs="cluster_root#root cluster_usr#usr cluster_var#var",\ > mp="/ /usr /var",as=1,ap=1 -p favored -h molari

Verify the resource profile with the caa_profile command with the "-print" option.

 # caa_profile -print cfs_common NAME=cfs_common TYPE=application ACTION_SCRIPT=cfs_relo.scr ACTIVE_PLACEMENT=1 AUTO_START=1 CHECK_INTERVAL=60 DESCRIPTION=cfs_common FAILOVER_DELAY=0 FAILURE_INTERVAL=0 FAILURE_THRESHOLD=0 HOSTING_MEMBERS=molari OPTIONAL_RESOURCES= PLACEMENT=favored REQUIRED_RESOURCES= RESTART_ATTEMPTS=1 SCRIPT_TIMEOUT=60 USR_CFS=cluster_root#root cluster_usr#usr cluster_var#var USR_MNT_PT=/ /usr /var

24.4.2 Relocating a CFS Server from an Application Resource

Instead of having a separate resource for relocating file systems to a different CFS server, you can add logic to your application resource's action script to do the relocation(s).

You will need to modify your "start" and "check" entry points.

Verify that the file system is mounted. If it is unmounted, should you mount it or fail to start the resource?
Locate the CFS server for the file system.
- If the member is the CFS server, no relocation is necessary.
- If the CFS server is not the member, then relocate the CFS server.
If the relocation was successful, start the application.
If the relocation was unsuccessful, do you try again?
- If so, you must determine how many times to attempt to relocate the domain.
- You must also decide what action to take if you cannot relocate the domain.
Should the resource start anyway? Probably. Your users will still be more efficient using an application that is accessing its data across the cluster interconnect than not being able to use the application at all.

^[2]The application.tdf file is in the /var/cluster/caa/template directory beginning V5.1A/PK1.