A disk set provides for data redundancy and availability. If one host fails, the other host can take over the failed host's disk set. (This type of configuration is known as a failover configuration.)
Though each host can control the set of disks, neither host has access to the set of disks at the same time that the other host controls the set of disks.
Note - Disk sets are intended for use with Solaris HA, or another supported third-party HA framework. Enhanced Storage by itself does not provide all the functionality necessary to implement a failover configuration.
In addition to the shared disk set, each host has a local disk set. This disk set consists of all of the disks on a host not in a shared disk set. A local disk set belongs to a specific host. The local disk set contains the volume state database for that specific host's configuration.
Volumes and hot spare pools in a shared disk set can only consist of drives from within that disk set. Once you have created a metadevice within the disk set, you can use it just as you would a physical slice. However, disk sets do not support the mounting of file systems from the /etc/vfstab file.
Similarly, metadevices and hot spare pools in the local disk set can only consist of drives from within the local disk set.
When you add disks to a disk set, Enhanced Storage automatically creates the state database replicas on the disk set. When a drive is accepted into a disk set, Enhanced Storage repartitions it so that the state database replica for the disk set can be placed on the drive. Drives are repartitioned when they are added to a disk set only if Slice 7 is not set up correctly. A small portion of each drive is reserved in Slice 7 for use by Enhanced Storage. The remainder of the space on each drive is placed into Slice 0. Any existing data on the disks is lost by repartitioning. After adding a drive to a disk set, it may be repartitioned as necessary, with the exception that Slice 7 is not altered in any way.
Unlike local disk set administration, you do not need to create or delete disk set metadevice state databases by hand. Enhanced Storage tries to place a reasonable number of state database replicas (on Slice 7) on across all drives in the disk set. If necessary, however, you can manually administer the replicas. (SeeSolaris Volume Manager Administration Guide)
Note - Disk sets are not intended for "local" (not dual-connected) use.
What are the disk set naming conventions?
Disksets use this naming convention:
/dev/md/setname
Metadevices within the shared disk set use these naming conventions:
/dev/md/setname/{dsk | rdsk}/dnumber
where setname is the name of the disk set, and number is the metadevice number (usually between 0-127).
Hot spare pools use setname/hspxxx, where xxx is in the range 000-999.
Metadevices within the local disk set have the standard Enhanced Storage metadevice naming conventions.
What are the maximum number of disk sets possible?
32 (though the default is 4). The actual number of shared disk sets is always one less than the number configured, to account for the local disk set.
What are the hardware requirements for a disk set?
Currently, disk sets are only supported on SPARCstorage Array drives. Disk sets do not support SCSI disks.
Three or more SPARCstorage Arrays are recommended to avoid losing one-half of the configuration, which would result in the disk set being inaccessible.
The two hosts connected to the shared disks must be "symmetric." The shared disk drives must be the same. (Refer to the next question for specifics.)
What are the requirements for shared disk drive device names?
A shared disk drive must be seen on both hosts at the same device number (c#t#d#). The disk drive must also have the same major/minor number. If the minor numbers are not the same on both hosts, typically you see the message "drive c#t#d# is not common with host xxxx" when adding drives to the disk set. Finally, the shared disks must use the same driver name (ssd). SeeSolaris Volume Manager Administration Guidefor more information on setting up shared disk drives in a disk set.
Are disk sets supported on single-host configurations?
Disk sets are supported in single-host configurations, but the disk sets still must be manually "taken" and "released." (See Administering Disk Sets.) Usually, this is too much trouble for non-HA use.
Are disk sets supported on the x86 platform?
No.
What are the requirements for creating a disk set?
To create a disk set, you need root in group 14, or you need a /.rhosts file entry containing the other hostname (on each host).
Can a file system that resides on a metadevice in a disk set be mounted automatically at boot via the /etc/vfstab file?
No. The necessary disk set RPC daemons (rpc.metad and rpc.metamhd) do not start early enough in the boot process to permit this. Additionally, the ownership of a disk set is lost during a reboot.
shows an example configuration using two disk sets.
In this configuration, Host A and Host B share disk sets A and B. They each have their own local disk set, which is not shared. If Host A fails, Host B can take over control of Host A's shared disk set (Disk set A). Likewise, if Host B fails, Host A can take control of Host B's shared disk set (Disk set B).