Administering Global Devices and the Global Namespace Overview

Administration of Sun Cluster disk device groups depends on the volume manager that is installed on the cluster. Solstice DiskSuite/Solaris Volume Manager is "cluster-aware," so you add, register, and remove disk device groups by using the Solstice DiskSuite/Solaris Volume Manager metaset(1M) command. If you are using VERITAS Volume Manager (VxVM), you create disk groups by using VxVM commands. You register the disk groups as Sun Cluster disk device groups with the scsetup(1M) utility. When removing VxVM disk device groups, you use both the scsetup command and VxVM commands.

Sun Cluster software automatically creates a rawdisk device group for each disk and tape device in the cluster. However, cluster device groups remain in an offline state until you access the groups as global devices. When administering disk device groups, or volume manager disk groups, you need to be on the cluster node that is the primary node for the group.

Normally, you do not need to administer the global device namespace. The global namespace is automatically set up during installation and automatically updated during Solaris operating environment reboots. However, if the global namespace needs to be updated, you can run the scgdevs(1M) command from any cluster node. This command causes the global namespace to be updated on all other cluster node members, as well as on nodes that might join the cluster in the future.

Global Device Permissions for Solstice DiskSuite/Solaris Volume Manager

Changes made to global device permissions are not automatically propagated to all the nodes in the cluster for Solstice DiskSuite/Solaris Volume Manager and disk devices. If you want to change permissions on global devices, you must manually change the permissions on all the nodes in the cluster. For example, if you want to change permissions on global device /dev/global/dsk/d3s0 to 644, you must execute

# chmod 644 /dev/global/dsk/d3s0

on all nodes in the cluster.

VxVM does not support the chmod command. To change global device permissions in VxVM, consult the VxVM Administrator's Guide.

Dynamic Reconfiguration With Global Devices

Following are issues the you must consider when completing dynamic reconfiguration (DR) operations on disk and tape devices in a cluster.

• All of the requirements, procedures, and restrictions that are documented for the Solaris DR feature also apply to Sun Cluster DR support. The only exception is for the operating environment quiescence operation. Therefore, review the documentation for the Solaris DR feature before using the DR feature with Sun Cluster software. You should review in particular the issues that affect non-network IO devices during a DR detach operation.

• Sun Cluster rejects DR remove-board operations on active devices in the primary node. DR operations can be performed on non-active devices in the primary node and on any devices in the secondary nodes.

• After the DR operation, cluster data access continues as before.

• Sun Cluster rejects DR operations that impact the availability of quorum devices. See Dynamic Reconfiguration With Quorum Devices for more information.

Caution - If the current primary node fails while you are performing the DR operation on a secondary node, cluster availability is impacted. The primary node will have no place to fail over until a new secondary node is provided.

To perform DR operations on global devices, complete the following steps in the order indicated.

Table 4-1 Task Map: Dynamic Reconfiguration with Disk and Tape Devices

SPARC: VERITAS Volume Manager Administration Considerations

• For Sun Cluster to maintain the VxVM namespace, you must register any VxVM disk group or volume changes as Sun Cluster disk device group configuration changes. Registering these changes ensures that the namespace on all cluster nodes is updated. Examples of configuration changes that impact the namespace include adding, removing, or renaming a volume. Changing the volume permissions, owner, or group ID also impacts the namespace.

  ---

  Note - Never import or deport VxVM disk groups by using VxVM commands once the disk group has been registered with the cluster as a Sun Cluster disk device group. The Sun Cluster software handles all cases where disk groups need to be imported or be deported.

  ---

• Each VxVM disk group must have a cluster-wide unique minor number. By default, when a disk group is created, VxVM chooses a random number that is a multiple of 1000 as that disk group's base minor number. For most configurations with only a small number of disk groups, the minor number is sufficient to guarantee uniqueness. The minor number for a newly-created disk group might conflict with the minor number of a pre-existing disk group that was imported on a different node. In this case, attempting to register the Sun Cluster disk device group fails. To fix this problem, the new disk group should be given a new minor number that is a unique value and then registered as a Sun Cluster disk device group.

• If you are setting up a mirrored volume, Dirty Region Logging (DRL) can be used to decrease volume recovery time after a node failure. Use of DRL is strongly recommended, although use of DRL could decrease I/O throughput.

• VxVM does not support the chmod command. To change global device permissions in VxVM, consult the VxVM administrator's guide.

• Sun Cluster 3.1 4/04 software does not support VxVM Dynamic Multipathing (DMP) to manage multiple paths from the same node.

• If you use VxVM to set up shared disk groups for Oracle Parallel Server/Real Application Clusters, use the cluster functionality of VxVM as described in the VERITAS Volume Manager Administrator's Reference Guide. There are differences between creating shared disk groups for Oracle Parallel Server/Real Application Clusters and creating other disk groups. You must import the Oracle Parallel Server/Real Application Clusters shared disk groups by using vxdg -s. You do not register the Oracle Parallel Server/Real Application Clusters shared disk groups with the cluster framework. To create other VxVM disk groups, see SPARC: How to Create a New Disk Group When Initializing Disks (VERITAS Volume Manager).

Administering Cluster File Systems Overview

No special Sun Cluster commands are necessary for cluster file system administration. Administer a cluster file system as you would any other Solaris file system, using standard Solaris file system commands, such as mount, newfs, and so on. Mount cluster file systems by specifying the -g option to the mount command. Cluster file systems can also be automatically mounted at boot.

Note - When the cluster file system reads files, the file system does not update the access time on those files.

SPARC: Guidelines to Support VxFS

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.

The following guidelines for how to use VxFS to create highly available cluster file systems are specific to a Sun Cluster 3.1 4/04 configuration.

• Create a VxFS file system by following procedures in VxFS documentation.

• Mount and unmount a VxFS file system from the primary node. The primary node masters the disk on which the VxFS file system resides. A VxFS file system mount or unmount operation that is performed from a secondary node might fail.

• Perform all VxFS administration commands from the primary node of the VxFS cluster file system.

The following guidelines for how to administer VxFS cluster file systems are not specific to Sun Cluster 3.1 4/04 software. However, the guidelines are different from the way you administer UFS cluster file systems.

• You can administer files on a VxFS cluster file system from any node in the cluster. The exception is ioctls, which you must issue only from the primary node. If you do not know whether an administration command involves ioctls, issue the command from the primary node.

• If a VxFS cluster file system fails over to a secondary node, all standard-system-call operations that were in progress during failover are re-issued transparently on the new primary. However, any ioctl-related operation in progress during the failover will fail. After a VxFS cluster file system failover, check the state of the cluster file system. Administrative commands that were issued on the old primary before failover might require corrective measures. See VxFS documentation for more information.