Mount Information for Cluster File Systems
Consider the following points when you plan mount points for cluster file systems.
Mount-point location - Create mount points for cluster file systems in the /global directory, unless you are prohibited by other software products. By using the /global directory, you can more easily distinguish cluster file systems, which are globally available, from local file systems.
The following VxFS features are not supported in a Sun Cluster 3.1 configuration.
Quick I/O
Snapshots
Storage checkpoints
VxFS-specific mount options:
convosync (Convert O_SYNC)
mincache
qlog, delaylog, tmplog
VERITAS CFS requires VERITAS cluster feature & VCS
Cache advisories can be used, but the effect is observed on the given node only.
All other VxFS features and options that are supported in a cluster configuration are supported by Sun Cluster 3.1 software. See VxFS documentation for details about VxFS options that are supported in a cluster configuration.
VxFS mount requirement - Globally mount and unmount a VxFS file system from the primary node. The primary node is the node that masters the disk on which the VxFS file system resides. This method ensures that the mount or unmount operation succeeds. A VxFS file-system mount or unmount operation that is performed from a secondary node might fail.
Nesting mount points - Normally, you should not nest the mount points for cluster file systems. For example, do not set up one file system that is mounted on /global/a and another file system that is mounted on /global/a/b. To ignore this rule can cause availability and node boot-order problems. These problems would occur if the parent mount point is not present when the system attempts to mount a child of that file system. The only exception to this rule is if the devices for the two file systems have the same physical node connectivity. An example is different slices on the same disk.
Planning Volume Management
Add this planning information to the Disk Device Group Configurations Worksheet and the Volume Manager Configurations Worksheet. For Solstice DiskSuite/Solaris Volume Manager, also add this planning information to the Metadevices Worksheet (Solstice DiskSuite/Solaris Volume Manager).
This section provides the following guidelines for planning volume management of your cluster configuration:
Sun Cluster software uses volume-manager software to group disks into disk device groups which can then be administered as one unit. Sun Cluster software supports Solstice DiskSuite/Solaris Volume Manager software and VERITAS Volume Manager (VxVM) software that you install or use in the following ways.
Table 1-4 Supported Use of Volume Managers with Sun Cluster Software
Volume-Manager Software | Requirements |
|---|---|
Solstice DiskSuite/Solaris Volume Manager | You must install Solstice DiskSuite/Solaris Volume Manager software on all nodes of the cluster, regardless of whether you use VxVM on some nodes to manage disks. |
VxVM with the cluster feature | You must install and license VxVM with the cluster feature on all nodes of the cluster. |
VxVM without the cluster feature | You are only required to install and license VxVM on those nodes that are attached to storage devices which VxVM manages. |
Both Solstice DiskSuite/Solaris Volume Manager and VxVM | If you install both volume managers on the same node, you must use Solstice DiskSuite/Solaris Volume Manager software to manage disks that are local to each node. Local disks include the root disk. Use VxVM to manage all shared disks. |
See your volume-manager documentation and Installing and Configuring Solstice DiskSuite/Solaris Volume Manager Software or Installing and Configuring VxVM Software for instructions on how to install and configure the volume-manager software. For more information about volume management in a cluster configuration, see the Sun Cluster 3.1 10/03 Concepts Guide.
Guidelines for Volume-Manager Software
Consider the following general guidelines when you configure your disks with volume-manager software:
Mirrored multihost disks - You must mirror all multihost disks across disk expansion units. See Guidelines for Mirroring Multihost Disks for guidelines on mirroring multihost disks. You do not need to use software mirroring if the storage device provides hardware RAID as well as redundant paths to disks.
Mirrored root - Mirroring the root disk ensures high availability, but such mirroring is not required. See Mirroring Guidelines for guidelines about deciding whether to mirror the root disk.
Unique naming - You might have local Solstice DiskSuite metadevices, local Solaris Volume Manager volumes, or VxVM volumes that are used as devices on which the /global/.devices/node@nodeid file systems are mounted. If so, the name of each local metadevice or local volume must be unique throughout the cluster.
Node lists - To ensure high availability of a disk device group, make its node lists of potential masters and its failback policy identical to any associated resource group. Or, if a scalable resource group uses more nodes than its associated disk device group, make the scalable resource group's node list a superset of the disk device group's node list. See the resource group planning information in the Sun Cluster 3.1 Data Service Planning and Administration Guide for information about node lists.
Multiported disks - You must connect, or port, all disks used to construct a device group within the cluster to all of the nodes that are configured in the node list for that device group. Solstice DiskSuite/Solaris Volume Manager software can automatically check for this connection at the time that disks are added to a diskset. However, configured VxVM disk groups do not have an association to any particular set of nodes.
Hot spare disks - You can use hot spare disks to increase availability, but hot spare disks are not required.
See your volume-manager documentation for disk layout recommendations and any additional restrictions.