Application Use Cases for the HP Serviceguard Storage Management Suite, November 2009

Performance and scaling with CFS
Another aspect to consider while implementing an application in a CFS cluster is the I/O
performance. If an application uses the CFS only from one node to take advantage of possible
improved failover times and ease of administration, the I/O performance is expected to be equivalent
to the performance on a local VxFS.
For Serviceguard Storage Management Suite, the expectations are different when the CFS data is being
accessed concurrently by multiple nodes. The CFS is a multi-reader/multi-writer file system, which means
that all nodes can read and write user data directly to the file system. For each CFS, one cluster node is
the primary and the other nodes are secondary nodes. The node mounting a CFS first is elected as
primary for that file system. If a primary for a CFS fails, the role moves to another cluster node
automatically. You can also move the primary role manually by executing a command. With Veritas
Storage Foundation 4.1, file system metadata (file size, name, and time stamp) can also be read by all
nodes, but only written by the primary node of that CFS. With Veritas Storage Foundation 5.0, file
system metadata can be read and written by all CFS nodes. Keeping this in mind, the I/O performance
and scaling of multi-instance applications depend on their I/O characteristics:
 Applications that mostly read I/Os are expected to perform and scale very well. No noticeable
degradation in comparison to applications doing I/O to a non-CFS is expected.
 The performance of applications that also do many writes depends on the I/O patterns of the nodes
across the cluster. CFS has implemented a range-locking functionality to allow multiple processes to
write to different regions of the same file at the same time.
 With Veritas Storage Foundation 4.1, applications that perform many file system metadata updates
are not expected to perform as well on a CFS as on a non-CFS. For example, file creation, file
deletion, file size expansion, and file size truncation operations are performed exclusively by the
CFS primary. With Veritas Storage Foundation 5.0, performance is improved, because file system
metadata updates can be performed by all CFS nodes, not just the primary CFS node.
A special mount option (noatime) directs the file system to ignore file access time. This option
reduces file system metadata updates and should be used with applications that do not require file
access time information.
Each mounted file system has its own CFS primary, and by default, the node that mounts the file
system first becomes its primary. One way to mitigate the performance impact is to distribute the CFS
primaries equally across the cluster nodes. For instance, if a four-node cluster shares eight file systems,
each node could be assigned as primary for only two file systems. The fsclustadm command with
the setprimary option can be used to alter the primary node of a CFS.
If an application does many file system metadata updates only on temporary files that are not relevant
to other instances of the application running on other nodes in the cluster, then those files could be
configured to be stored on node-specific storage to avoid performance issues.
Note
With Serviceguard Storage Management Suite 2.0 on HP-UX 11i v3, a
performance
enhancement provides a symmetrical architecture enabling all
nodes in the cluster to process metadata operations simultaneously—so CFS
can handle significantly higher metadata loads.
15