Learn About Remote Virtual Disk Mirroring

The  is used for online, real-time data replication between  over a remote distance. The mirroring is managed by the storage array  and is transparent to  machines and applications. You create one or more mirrored virtual disk pairs that consist of a  at the primary site and a  at a secondary, remote site. After you create the mirror relationship between the two , the  of the primary virtual disk copies all of the data from the primary virtual disk to the secondary virtual disk. This is called a .

Caution:  Risk of application errors - You cannot create a mirror relationship if the primary virtual disk contains unreadable sectors. Furthermore, if an unreadable sector is discovered during a mirroring operation, the mirror relationship will fail.

Note that because replication is managed on a per-virtual disk basis, you can mirror individual virtual disks in a primary storage array to appropriate secondary virtual disks in several different remote storage arrays.

Disaster Recovery

The secondary, remote virtual disk is unavailable to secondary host applications while mirroring is in progress. In the event of a disaster at the primary site, you can fail over to the secondary site by performing a  to promote the secondary virtual disk to a primary virtual disk. Then the recovery host is able to access the newly promoted virtual disk, and business operations can continue.

Data Replication

When the RAID controller module owner of the primary virtual disk receives a write request from a host, the RAID controller module first logs information about the write to a special virtual disk called a  and then writes the data to the primary virtual disk. Next, the RAID controller module initiates a  operation to copy the affected data blocks to the secondary virtual disk at the remote site.

Finally, the RAID controller module sends an I/O completion indication back to the host system to confirm that the data was copied successfully to the secondary storage array. The  you select when first creating a  determines when the I/O completion indication is sent to the host system.

Two write modes are available in this version of the storage management software:

• Synchronous - When this write mode is selected, any host write requests are written to the primary virtual disk and then copied to the secondary storage virtual disk. The RAID controller module sends an I/O completion indication to the host system after the copy has been successfully completed.
• Asynchronous - When this write mode is selected, host write requests are written to the primary virtual disk, and then the RAID controller module sends an I/O completion indication back to the host system before the data has been successfully copied to the secondary storage array.

When  is enabled on either the primary or secondary virtual disk, the I/O completion is sent when data is in the cache on the side (primary or secondary) where write caching is enabled. When write caching is disabled on either the primary or secondary virtual disk, then the I/O completion is not sent until the data has been stored to physical media on that side.

Host write requests received by the RAID controller module are handled normally, and no communication takes place between the primary and secondary storage arrays.

Link Interruptions or Secondary Virtual Disk Errors

When processing write requests, the primary RAID controller module might be able to write to the primary virtual disk, but a link interruption prevents communication with the remote secondary RAID controller module.

In this case, the remote write cannot complete to the secondary virtual disk, and the primary and secondary virtual disks are no longer appropriately mirrored. The primary RAID controller module transitions the mirrored pair into  and sends an I/O completion to the primary host. The primary host can continue to write to the primary virtual disk, but remote writes do not take place.

When connectivity is restored between the RAID controller module owner of the primary virtual disk and the RAID controller module owner of the secondary virtual disk, a  takes place. Only the blocks of data that have changed on the primary virtual disk during the link interruption are copied to the secondary virtual disk. The mirrored pair transitions from an Unsynchronized state to a .

The primary RAID controller module also marks the mirrored pair as Unsynchronized when a virtual disk error on the secondary side prevents the remote write from completing. For example, an offline or a failed secondary virtual disk can cause the Remote Virtual Disk Mirror to become Unsynchronized. When the virtual disk error is corrected (the secondary virtual disk is placed online or recovered to an ) a full synchronization automatically begins, and the mirrored pair transitions to a Synchronization in Progress state.

Connectivity and Virtual Disk Ownership

A primary RAID controller module only attempts to communicate with its matching RAID controller module in the secondary storage array. For example, RAID Controller Module A in the primary storage array only attempts communication with RAID Controller Module A in the secondary storage array. The RAID controller module (A or B) that owns the primary virtual disk determines the RAID controller module owner of the secondary virtual disk. If the primary virtual disk is owned by RAID Controller Module A on the primary side, the secondary virtual disk is owned by RAID Controller Module A on the secondary side. If primary RAID Controller Module A cannot communicate with secondary RAID Controller Module A, no RAID controller module ownership changes take place.

When an I/O path error causes a virtual disk ownership change on the primary side, or if the storage administrator changes the RAID controller module owner of the primary virtual disk, the next remote write processed will automatically trigger a matching ownership change on the secondary side. For example, if a primary virtual disk is owned by RAID Controller Module A, and then you change the RAID controller module owner to RAID Controller Module B, the next remote write changes the RAID controller module owner of the secondary virtual disk from RAID Controller Module A to RAID Controller Module B. Because RAID controller module ownership changes on the secondary side are controlled by the primary side, they do not require any special intervention by the storage administrator.

RAID Controller Module Resets and Storage Array Power Cycles

Sometimes a remote write is interrupted by a RAID controller module reset or a storage array power cycle before it can be written to the secondary virtual disk. The storage array RAID controller module does not need to perform a full synchronization of the mirrored virtual disk pair in this case. A RAID controller module reset causes a RAID controller module ownership change on the primary side from the  to the alternate RAID controller module in the storage array. When a remote write has been interrupted during a RAID controller module reset, the new RAID controller module owner on the primary side reads information stored in a log file in the preferred RAID controller module owners Mirror Repository Virtual Disk. The information is used to copy the affected data blocks from the primary virtual disk to the secondary virtual disk, eliminating the need for a full synchronization of the mirrored virtual disks.

Activating the Remote Virtual Disk Mirroring Feature

Like other premium features, the Remote Virtual Disk Mirroring feature is enabled by purchasing a  from your storage supplier. You must enable the feature on both primary and secondary storage arrays.

Unlike other premium features, you must also activate the feature after you enable it, using the Activate Remote Virtual Disk Mirroring Wizard in the . Each RAID controller module in the storage array must have its own Mirror Repository Virtual Disk for logging write information to recover from RAID controller module resets and other temporary interruptions. The Activate Remote Virtual Disk Mirroring Wizard guides you to specify the placement of the two Mirror Repository Virtual Disks (on newly created or existing free capacity in the storage array).

After you activate the feature, one  host side I/O  on each RAID controller module is solely dedicated to Remote Virtual Disk Mirroring operations. No host-initiated I/O operations are accepted by the dedicated port. I/O requests received on this port are accepted only from remote RAID controller modules that are participating in Remote Virtual Disk Mirroring operations with the RAID controller module.

Connectivity Requirements

Dedicated Remote Virtual Disk Mirroring ports must be attached to a Fibre Channel Fabric environment with support for the Directory Service and Name Service interfaces.

You can use a Fabric configuration that is dedicated solely to the Remote Virtual Disk Mirroring ports on each RAID controller module. In this case, host systems can connect to the storage arrays using Fabric, FC-AL, or Point-to-Point configurations that are totally independent of the dedicated Remote Virtual Disk Mirroring fabric.

Alternatively, you can use a single Fibre Channel Fabric configuration for both the Remote Virtual Disk Mirroring connectivity and for the host I/O paths to the RAID controller modules.

The maximum distance between primary and secondary sites is 10 km, using single-mode fiber and optical long-wave Gigabit Interface Converters (GBICs).

Restrictions

The following restrictions apply to mirrored virtual disk candidates and storage array mirroring:

•   , caching parameters, and  can be different on the two mirrored virtual disks.
• The secondary virtual disk must be at least as large as the primary virtual disk.
• The only type of virtual disk that might participate in a mirroring relationship is a .  cannot participate.
• You can create a snapshot virtual disk by using either a primary virtual disk or a secondary virtual disk as the .
• A primary virtual disk can be a  or  in a . A secondary virtual disk cannot be a source or target virtual disk unless a role reversal was initiated after the copy has completed. If a role reversal is initiated during a , the copy fails and cannot be restarted.
• A given virtual disk might participate in only one mirror relationship.
• On a 5884 or 4884 storage array, up to 64 virtual disks may participate in mirror relationships.
• On a 5884 or 4884 storage array, up to 2048 virtual disks are supported when the Remote Virtual Disk Mirroring Premium Feature is being used.
• On a 2882 storage array, up to 1024 virtual disks are supported when the Remote Virtual Disk Mirroring Premium Feature is being used. Additionally, 32 virtual disks may participate in mirror relationships.