Browse Prior Art Database

Synchronous Mirror Failover in a Cascaded Configuration

IP.com Disclosure Number: IPCOM000236297D
Publication Date: 2014-Apr-17
Document File: 3 page(s) / 77K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method to enable a high-capacity storage system to operate in the manner that is expected by the current controlling software when a synchronous mirror failover command is received in a cascaded environment.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 3

Synchronous Mirror Failover in a Cascaded Configuration

A storage replication failover command normally causes the secondary volume to convert to a primary volume. In the case of a synchronous mirroring pair A->B, a failover B->A command causes the B volume to become a suspended primary volume to A. (The A volume remains as a primary volume to B.)

In a cascaded storage replication configuration of A->B->C, the intermediate volume B is a secondary from A and a primary to C. Typically, the A->B pair is synchronously mirrored and the B->C pair is asynchronously mirrored.

In this configuration, a storage replication failover command B->A may be expected to cause B to become a suspended primary

volume to A. However, since the current storage replication design does not allow a volume to be a primary to more than one secondary, and B is already a primary to C, the B volume cannot also be made a primary to A. Instead, the B volume is placed into what is known as a "cascaded failover" state, by performing the following actions:

1. A special indication is set on the B volume to allow it to accept host read/write input/output (I/O), even though it remains a secondary volume from B. (Normally, a secondary volume is not allowed to receive host read/write I/O.)

2. Change Recording is started on B. This creates a record of which tracks have been updated by a host write that have not been transferred to A.

Resuming synchronous mirroring from B->A requires suspending the B->C asynchronous pairs, manipulating the structure to ensure that all updates made to B are transferred back to A, and keeping track of which data has been updated by the host write to B that have not been transferred to C.

The asynchronous mirroring suspension and the complexity of the process are drawbacks that are alleviated by using multi-target mirroring. With multi-target, a volume can be a primary to more than one secondary volume; thus, a failover BA may simply operate as a "normal" storage replication failover and make B a suspended primary of A.

The problem remains, however, that existing controlling software (i.e. host or replication manager) that has not been updated with multi-target support expects a storage replication failover command in a cascaded configuration to operate in the previous manner and create the cascaded failover state. This is the problem addressed here.

A high-capacity storage system must be able to operate in the manner that is expected by the current controlling software when a storage replication failover command is received in a cascaded environment. If the controlling software has not been upgraded to the level that understands multi-target replication, then the storage system has to still put the B volume into the cascaded failover state. However, if the controlling software has been upgraded to support multi-target replication, then it is much preferred to use the simplified multi-target capability.

1


Page 02 of 3

Two possible methods of...