White Paper

CFS primary placement for failover applications

For failover applications that only run on one node at the time, the location of the CFS primary is also

important. The best performance is expected if the CFS primaries of all file systems used by an

application is using are co-located with the application package on the same node and not evenly

distributed among all cluster nodes.

Shutdown for single-instance failover applications in C

FS clusters

Single-instance failover applications might benefit from a CFS cluster due to reduced failover times

because some of the tasks necessary during the failover process in an VxVM/VxFS environment are

not needed with CVM/CFS (for example: importing disk groups, mounting file systems). The

concurrent availability of the CFS on all cluster nodes can also introduce new challenges.

In a non-CFS cluster, the data of single-instance failover applications is moving with the application

package from node to node. The volumes are exclusively activated only on the node that currently

runs the package, which prevents the application data from being altered concurrently by multiple

nodes. The Serviceguard package control scripts enable that on package failure or shutdown, the

storage is made inaccessible on the node the package failed or was halted.

This behavior changes with CFS. The application data is accessible on multiple nodes at the same

time even if an application package is not running on a specific node or not running on any node in

the cluster. If an application does not shut down completely on one node before it is started on

another node, it can result in data corruption. To address this potential issue, the start and stop

functions of single-instance failover applications require special attention in a CFS cluster.

Application shutdown procedures require an analysis of their robustness when CFS is used to store the

application data. HP provides the following recommendations for robust application shutdown within

the cluster:

 Before the application shutdown procedure returns the control back to the Serviceguard control

script, it should verify the success, or report a failure if some of the application processes had not

died. A failure code directs Serviceguard to disable the global AUTO_RUN flag of this application

package and prevents it from starting up on any other node without operator intervention.

 Serviceguard package control scripts use the fuser command to terminate all processes having a

mount point open before they unmount exclusively mounted file systems and deactivates the

exclusively activated volume groups. The same fuser command can be used in the application-specific

shutdown function.

 You can make CFS volumes temporarily unavailable on application shutdown by specifying the

mount point and disk group within the same cmhaltpkg command as the application package.

However, this process might not be suitable in all cases because the file system may require

operator intervention to be made available again on the node where the package was halted.

 As a last resort, the NODE_FAIL_FAST_ENABLED flag can be set to YES to trigger Serviceguard to halt

the node on a package failure. This process works when a package fails or when it fails to shut down.

Serviceguard package management provides interfaces and mechanisms to integrate robust

application shutdown procedures. It is up to the application integrator to choose and utilize them to

prevent unwanted concurrent access to the application data.

The following pseudo code lists the major components of a robust shutdown procedure that should be

added to the customer_defined_run_cmds/customer_defined_halt_cmds functions of the

package control script.