Cluster File Systems

For information about the purpose and function of cluster file systems, see Cluster File Systems in Sun Cluster Overview for Solaris OS and Cluster File Systems in Sun Cluster Concepts Guide for Solaris OS.

You can alternatively configure highly available local file systems. This can provide better performance to support a data service with high I/O, or to permit use of certain file-system features that are not supported in a cluster file system. For more information, see Enabling Highly Available Local File Systems in Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

Consider the following points when you plan cluster file systems.

• Quotas – Quotas are not supported on cluster file systems. However, quotas are supported on highly available local file systems.

• Non-global zones – If a cluster file system is to be accessed from a non-global zone, it must first be mounted in the global zone. The cluster file system is then mounted in the non-global zone by using a loopback mount. Therefore, the loopback file system (LOFS) must be enabled in a cluster that contains non-global zones.

• Zone clusters – You cannot configure cluster file systems that use UFS or VxFS for use in a zone cluster. Use highly available local file systems instead. You can use a QFS shared file system in a zone cluster, but only to support Oracle RAC.

• Loopback file system (LOFS) – During cluster creation with the Solaris 9 version of Sun Cluster software, LOFS is disabled by default. During cluster creation with the Solaris 10 version of Sun Cluster software, LOFS is enabled by default.

  You must manually disable LOFS on each voting cluster node if the cluster meets both of the following conditions:

  • Sun Cluster HA for NFS is configured on a highly available local file system.

  • The automountd daemon is running.

  If the cluster meets both of these conditions, you must disable LOFS to avoid switchover problems or other failures. If the cluster meets only one of these conditions, you can safely enable LOFS.

  If you require both LOFS and the automountd daemon to be enabled, exclude from the automounter map all files that are part of the highly available local file system that is exported by Sun Cluster HA for NFS.

• Process accounting log files – Do not locate process accounting log files on a cluster file system or on a highly available local file system. A switchover would be blocked by writes to the log file, which would cause the node to hang. Use only a local file system to contain process accounting log files.

• Communication endpoints – The cluster file system does not support any of the file-system features of Solaris software by which one would put a communication endpoint in the file-system namespace.

  • Although you can create a UNIX domain socket whose name is a path name into the cluster file system, the socket would not survive a node failover.

  • Any FIFOs or named pipes that you create on a cluster file system would not be globally accessible.

  Therefore, do not attempt to use the fattach command from any node other than the local node.

• Device special files – Neither block special files nor character special files are supported in a cluster file system. To specify a path name to a device node in a cluster file system, create a symbolic link to the device name in the /dev directory. Do not use the mknod command for this purpose.

• atime – Cluster file systems do not maintain atime.

• ctime – When a file on a cluster file system is accessed, the update of the file's ctime might be delayed.

• Installing applications - If you want the binaries of a highly available application to reside on a cluster file system, wait to install the application until after the cluster file system is configured. Also, if the application is installed by using the Sun Java System installer program and the application depends on any shared components, install those shared components on all nodes in the cluster that are not installed with the application.