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.
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)
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 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.
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)