RAID–1 (Mirror) Volumes in Multi-Owner Disk Sets

A RAID–1 volume, or mirror, created in a multi-owner disk set functions identically to a RAID-1 volume in a Solaris Volume Manager shared disk set. However, RAID-1 volumes in multi-owner disk sets have some additional features.

Mirror Ownership With Multi-Owner Disk Sets

The concept of mirror ownership is unique to multi-owner disk sets. Unlike a RAID-1 volume in a Solaris Volume Manager shared disk set, a RAID-1 volume in a multi-owner disk set usually has an owner associated with it. The ownership of the mirror volume is chosen by the volume manager. The owner of the volume is one of the nodes designated in the node list for the disk set. Only the owner of the RAID-1 volume can write to the volume. If a non-owner node wants to write to the volume, the ownership switches to the node doing the write operation. The following output from the metastat -s diskset-name command shows nodeone as the owner of the RAID-1 volume, d24.

# metastat -s red
red/d24: Mirror
    Submirror 0: red/d20
      State: Okay
    Submirror 1: red/d21
      State: Okay
    Pass: 1
    Read option: roundrobin (default)
    Write option: parallel (default)
    Resync option: optimizedresync
    Owner: nodeone
    Size: 825930 blocks (403 MB)

Data Management and Recovery Processes

As with RAID-1 volumes in Solaris Volume Manager, RAID-1 volumes in Solaris Volume Manager for Sun Cluster perform operations to ensure consistent data. Solaris Volume Manager for Sun Cluster provides RAID-1 volumes with two options for data management and recovery.

Optimized Resynchronization for Solaris Volume Manager for Sun Cluster

Optimized resynchronization in Solaris Volume Manager for Sun Cluster functions identically to optimized resynchronization in Solaris Volume Manager. However, in a multi-owner disk set, a RAID-1 volume with the resynchronization option set to optimized resynchronization always has a mirror owner. The following output from the metastat -s diskset-name command shows the resynchronization option set to optimizedresync (for optimized resynchronization).

# metastat -s red
red/d24: Mirror
    Submirror 0: red/d20
      State: Okay
    Submirror 1: red/d21
      State: Okay
    Pass: 1
    Read option: roundrobin (default)
    Write option: parallel (default)
    Resync option: optimizedresync
    Owner: nodeone
    Size: 825930 blocks (403 MB)

For more information on optimized resynchronization, see Optimized Resynchronization.

Application-Based Recovery and Directed Mirror Reads

To optimize data recovery in Solaris Volume Manager for Sun Cluster, applications such as Oracle Real Application Clusters require the ability to manage and control the recovery of data. Enabling an application to control the recovery improves the performance of the recovery. The ioctls DKIOGETVOLCAP, DKIOSETVOLCAP, and DKIODMR provide support for an application's data management recovery in a cluster environment. These ioctls provide an application with the following capabilities:

• Application Based Recovery (ABR)—Allows the application to control the recovery of data on mirrored volumes

• Directed Mirror Reads—Allows the application to direct reads to specific submirrors and to determine the state of the data

For more information on the ioctls used with application-based data management recovery, see the dkio(7I) man page.

A RAID-1 volume with the resynchronization option set to application-based recovery only has a mirror owner during the application-based recovery process. The following output from the metastat -s diskset-name command shows a RAID-1 volume in a normal state. The resynchronization option is set to application-based recovery. There is no mirror owner.

# metastat -s red
red/d24: Mirror
    Submirror 0: red/d20
      State: Okay
    Submirror 1: red/d21
      State: Okay
    Pass: 1
    Read option: roundrobin (default)
    Write option: parallel (default)
    Resync option: application based
    Owner: None
    Size: 825930 blocks (403 MB)