Guidelines for Solstice DiskSuite/Solaris Volume Manager Software
Consider the following points when you plan Solstice DiskSuite/Solaris Volume Manager configurations:
Local metadevice names or volume names - The name of each local Solstice DiskSuite metadevice or Solaris Volume Manager volume must be unique throughout the cluster. Also, the name cannot be the same as any device-ID name.
Mediators - Each diskset configured with exactly two disk strings and mastered by exactly two nodes must have Solstice DiskSuite/Solaris Volume Manager mediators configured for the diskset. A disk string consists of a disk enclosure, its physical disks, cables from the enclosure to the node(s), and the interface adapter cards. Observe the following rules to configure mediators:
You must configure each diskset with exactly two nodes that act as mediator hosts.
You must use the same two nodes for all disksets that require mediators. Those two nodes must master those disksets.
Mediators cannot be configured for disksets that do not meet the two-string and two-host requirements.
See the mediator(7D) man page for details.
/kernel/drv/md.conf settings - All Solstice DiskSuite metadevices or Solaris Volume Manager volumes used by each diskset are created in advance, at reconfiguration boot time. This reconfiguration is based on the configuration parameters that exist in the /kernel/drv/md.conf file.
Caution - All cluster nodes must have identical /kernel/drv/md.conf files, regardless of the number of disksets that are served
by each node. Failure to follow this guideline can result in serious Solstice DiskSuite/Solaris Volume Manager errors and possible loss of data.You must modify the nmd and md_nsets fields as follows to support a Sun Cluster configuration:
md_nsets - The md_nsets field defines the total number of disksets that can be created for a system to meet the needs of the entire cluster. Set the value of md_nsets to the expected number of disksets in the cluster plus one additional diskset. Solstice DiskSuite/Solaris Volume Manager software uses the additional diskset to manage the private disks on the local host. The private disks are those metadevices or volumes that are not in the local diskset.
The maximum number of disksets that are allowed per cluster is 32. This number allows for 31 disksets for general use plus one diskset for private disk management. The default value of md_nsets is 4.
nmd - The nmd field defines the number of metadevices or volumes that are created for each diskset. Set the value of nmd to the predicted highest value of metadevice or volume name that is used by any one of the disksets in the cluster. For example, if a cluster uses 10 metadevices or volumes in its first 15 disksets, but 1000 metadevices or volumes in the 16th diskset, set the value of nmd to at least 1000. Also, the value of nmd must be large enough to ensure that enough numbers exist for each device-ID name. The number must also be large enough to ensure that each local metadevice name or local volume name can be unique throughout the cluster.
The highest allowed value of a metadevice or volume name per diskset is 8192. The default value of nmd is 128.
Set these fields at installation time to allow for all predicted future expansion of the cluster. To increase the value of these fields after the cluster is in production is time consuming. The value change requires a reconfiguration reboot for each node. To raise these values later also increases the possibility of inadequate space allocation in the root (/) file system to create all of the requested devices.
At the same time, keep the value of the nmdfield and the md_nsets field as low as possible. Memory structures exist for all possible devices as determined by nmdand md_nsets, even if you have not created those devices. For optimal performance, keep the value of nmd and md_nsets only slightly higher than the number of metadevices or volumes you plan to use.
See "System and Startup Files" in Solstice DiskSuite 4.2.1 Reference Guide or "System Files and Startup Files" in Solaris Volume Manager Administration Guide for more information about the md.conf file.
Guidelines for VERITAS Volume Manager Software
Consider the following points when you plan VERITAS Volume Manager (VxVM) configurations.
Enclosure-Based Naming - Enclosure-Based Naming is a feature that was introduced in VxVM version 3.2. If you use Enclosure-Based Naming of devices, ensure that you use consistent device names on all cluster nodes that share the same storage. VxVM does not coordinate these names, so the administrator must ensure that VxVM assigns the same names to the same devices from different nodes. Failure to assign consistent names does not interfere with correct cluster behavior. However, inconsistent names greatly complicate cluster administration and greatly increase the possibility of configuration errors, potentially leading to loss of data.
Root-disk group - You must create a default root-disk group (rootdg) on each node. The rootdg disk group can be created on the following disks:
The root disk, which must be encapsulated
One or more local nonroot disks, which you can encapsulate or initialize
A combination of root and local nonroot disks
The rootdg disk group must be local to the node.
Encapsulation - Disks to be encapsulated must have two disk-slice table entries free.
Number of volumes - Estimate the maximum number of volumes any given disk device group can use at the time the disk device group is created.
If the number of volumes is less than 1000, you can use default minor numbering.
If the number of volumes is 1000 or greater, you must carefully plan the way in which minor numbers are assigned to disk device group volumes. No two disk device groups can have overlapping minor number assignments.
Dirty Region Logging - Using Dirty Region Logging (DRL) decreases volume recovery time after a node failure. Using DRL might decrease I/O throughput.
Dynamic Multipathing (DMP) - DMP is not supported on Sun Cluster configurations. If you use VxVM in a configuration with multiple paths per node, then you must use another multipathing solution, such as Sun StorEdge Traffic Manager or EMC PowerPath. However, having DMP enabled on systems with only a single path per node poses no problems.
File-System Logging
Logging is required for cluster file systems. Sun Cluster software supports the following choices of file-system logging:
Solaris UFS logging - See the mount_ufs(1M) man page for more information.
Solstice DiskSuite trans-metadevice logging or Solaris Volume Manager transactional-volume logging - See "Creating DiskSuite Objects" in Solstice DiskSuite 4.2.1 User's Guide or "Transactional Volumes (Overview)" in Solaris Volume Manager Administration Guide for more information.
VERITAS File System (VxFS) logging - See the mount_vxfs man page provided with VxFS software for more information.
The following table lists the file-system logging supported by each volume manager.
Table 1-5 Supported File System Logging Matrix
Volume Manager | Supported File System Logging |
|---|---|
Solstice DiskSuite/Solaris Volume Manager | Solaris UFS logging, Solstice DiskSuite trans-metadevice logging or Solaris Volume Manager transactional-volume logging, VxFS logging |
VERITAS Volume Manager | Solaris UFS logging, VxFS logging |
Consider the following points when you choose between Solaris UFS logging and Solstice DiskSuite trans-metadevice logging/Solaris Volume Manager transactional-volume logging:
Solaris Volume Managertransactional-volume logging (formerly Solstice DiskSuite trans-metadevice logging) is scheduled to be removed from the Solaris operating environment in an upcoming Solaris release. Solaris UFS logging provides the same capabilities but superior performance, as well as lower system administration requirements and overhead.
Solaris UFS log size - Solaris UFS logging always allocates the log by using free space on the UFS file system, and depending on the size of the file system.
On file systems less than 1 Gbyte, the log occupies 1 Mbyte.
On file systems 1 Gbyte or greater, the log occupies 1 Mbyte per Gbyte on the file system, to a maximum of 64 Mbytes.
Log metadevice/transactional volume - A Solstice DiskSuite trans metadevice or Solaris Volume Manager transactional volume manages UFS logging. The logging device component of a trans metadevice or transactional volume is a metadevice or volume that you can mirror and stripe. You can create a maximum 1-Gbyte log size, although 64 Mbytes is sufficient for most file systems. The minimum log size is 1 Mbyte.