Browse Prior Art Database

Building mutual volume mirror with storage virtualization engines between two sites Disclosure Number: IPCOM000227683D
Publication Date: 2013-May-13
Document File: 5 page(s) / 111K

Publishing Venue

The Prior Art Database


With storage virtualization engines deployed, usually there are 2 ways to achieve data high-availability between the 2 virtualization clusters of 2 sites: disaster recovery and active-active solution. Either way has its disadvantages on recovery time or performance. In this article, a new method is proposed to realize data high-availability with storage virtualization engines between two sites. This method uses a new mirroring architecture called "Mutual Volume Mirror". With this technology, data availability and performance are both assured, and the data is accessed at both sites simultaneously.

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

Page 01 of 5

Building mutual volume mirror with storage virtualization engines between two sites

More and more customers today would like to use storage virtualization technology to manage their heterogeneous storage subsystems. In the IT environment

with storage virtualization engines, there are usually 2 ways to achieve data high-availability between 2 remote sites:

1) Disaster recovery: one site acts as the production site and it uses the virtualization engines' remote mirroring function to replicate data to the standby site;

2) active-active solution: the storage virtualization engines of two sites work together to maintain 2 data copies across 2 underlying storage subsystems from 2 sites.

However, either above method has its disadvantages: if disaster recovery is used, the failover of storage, server, network and application usually cost a long time before the production could resume; if active-active solution is used, the IO performance is often impacted especially when the server and storage are in different sites.

Our invention provides a new active-active solution with the storage virtualization engines, while enhancing both the availability and performance. We call it " Mutual Volume Mirror".

The theory of the solution is depicted as below. Note that the write IO flow sample from Site B is just reversed and is not drawn in the chart in order to save space.


Page 02 of 5

In the "Mutual Volume Mirror" solution, two clusters of storage virtualization engines are deployed at 2 sites. In the follow contents, "LUN" is used to represent the logical disks mapped from the underlying storage subsystems to the virtualization engines, and "volume" is used to represent the logical volume mapped from the virtualization engines to the host.

Here is the description of how to setup "Mutual Volume Mirror":

LUN_A and LUN_B are LUNs represented from the storage subsystems at site A and site B, respectively.

Volume_A and Volume_B are volumes that are created based on LUN_A and LUN_B, respectively.

Additionally, Volume_A is mapped to Cluster_B as a backend LUN and Volume_B is also mapped to Cluster_A as a backend LUN.

Moreover, Volume_A is treated as a secondary LUN (LUN_B') copy of Volume_B. Meanwhile, Volume_B is treated as a secondary LUN (LUN_A') copy of


A special rule of write IO mirror will be created...