How Does DiskSuite Manage Disksets?

A diskset provides for data redundancy and availability. If one host fails, the other host can take over the failed host's diskset. (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.

Disksets are intended for use with Solstice HA, or another supported third-party HA framework. DiskSuite by itself does not provide all the functionality necessary to implement a failover configuration.

In addition to the shared diskset, each host has a local diskset. This consists of all of the disks on a host not in a shared diskset. A local diskset belongs to a specific host. The local diskset contains the metadevice state database for that specific host's configuration.

Metadevices and hot spare pools in a shared diskset can only consist of drives from within that diskset. Once you have created a metadevice within the diskset, you can use it just as you would a physical slice. However, disksets do not support the mounting of file systems from the /etc/vfstab file.

Similarly, metadevices and hot spare pools in the local diskset can only consist of drives from within the local diskset.

When you add disks to a diskset, DiskSuite automatically creates the state database replicas on the diskset. When a drive is accepted into a diskset, DiskSuite repartitions it so that the state database replica for the diskset can be placed on the drive. Drives are repartitioned when they are added to a diskset only if Slice 7 is not set up correctly. A small portion of each drive is reserved in Slice 7 for use by DiskSuite. 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 diskset, it may be repartitioned as necessary, with the exception that Slice 7 is not altered in any way.

Unlike local diskset administration, you do not need to create or delete diskset metadevice state databases by hand. DiskSuite tries to place a reasonable number of state database replicas (on Slice 7) on across all drives in the diskset. If necessary, however, you can manually administer the replicas. (See Solstice DiskSuite 4.2.1 User's Guide)

Disksets are not intended for "local" (not dual-connected) use.

Diskset Conventions

• What are the diskset naming conventions?

  Disksets use this naming convention:

  /dev/md/setname

  Metadevices within the shared diskset use these naming conventions:

  /dev/md/setname/{dsk | rdsk}/dnumber

  where setname is the name of the diskset, 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 diskset have the standard DiskSuite metadevice naming conventions. (See Table 1-4.)

• What are the maximum number of disksets possible?

  32 (though the default is 4). The actual number of shared disksets is always one less than the number configured, to account for the local diskset.

• What are the hardware requirements for a diskset?

  Currently, disksets are only supported on SPARCstorage Array drives. Disksets 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 diskset 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 diskset. Finally, the shared disks must use the same driver name (ssd). See Solstice DiskSuite 4.2.1 User's Guide for more information on setting up shared disk drives in a diskset.

• Are disksets supported on single-host configurations?

  Disksets are supported in single-host configurations, but the disksets still must be manually "taken" and "released." (See "Administering Disksets".) Usually, this is too much trouble for non-HA use.

• Are disksets supported on the x86 platform?

  No.

• What are the requirements for creating a diskset?

  To create a diskset, 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 diskset be mounted automatically at boot via the /etc/vfstab file?

  No. The necessary diskset RPC daemons (rpc.metad and rpc.metamhd) do not start early enough in the boot process to permit this. Additionally, the ownership of a diskset is lost during a reboot.

Example -- Two Shared Disksets

Figure 5-1 shows an example configuration using two disksets.

Figure 5-1 Disksets Example

In this configuration, Host A and Host B share disksets A and B. They each have their own local diskset, which is not shared. If Host A fails, Host B can take over control of Host A's shared diskset (Diskset A). Likewise, if Host B fails, Host A can take control of Host B's shared diskset (Diskset B).