1. Getting Started With Solaris Volume Manager
2. Storage Management Concepts
3. Solaris Volume Manager Overview
4. Solaris Volume Manager for Sun Cluster (Overview)
Introduction to Solaris Volume Manager for Sun Cluster
Prerequisite: Required Software Components for Multi-Owner Disk Set Functionality
Tasks Associated With Multi-Owner Disk Sets
Solaris Volume Manager for Sun Cluster Configuration
RAID-1 (Mirror) Volumes in Multi-Owner Disk Sets
Mirror Ownership With Multi-Owner Disk Sets
Data Management and Recovery Processes
Optimized Resynchronization for Solaris Volume Manager for Sun Cluster
5. Configuring and Using Solaris Volume Manager (Scenario)
8. RAID-0 (Stripe and Concatenation) Volumes (Overview)
9. RAID-0 (Stripe and Concatenation) Volumes (Tasks)
10. RAID-1 (Mirror) Volumes (Overview)
11. RAID-1 (Mirror) Volumes (Tasks)
12. Soft Partitions (Overview)
16. Hot Spare Pools (Overview)
20. Maintaining Solaris Volume Manager (Tasks)
21. Best Practices for Solaris Volume Manager
22. Top-Down Volume Creation (Overview)
23. Top-Down Volume Creation (Tasks)
24. Monitoring and Error Reporting (Tasks)
25. Troubleshooting Solaris Volume Manager (Tasks)
A. Important Solaris Volume Manager Files
B. Solaris Volume Manager Quick Reference
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)