Huawei Storage HyperMirror Technical White Paper.pdf

Doc. code

HyperMirror Technical White Paper

Issue 01

Date 2012-04-20

HUAWEI TECHNOLOGIES CO., LTD.

HyperMirror Technical White Paper CONFIDENTIAL

2013-07-26 Copyright Huawei Technologies Co., Ltd. 2012. All rights reserved Page2, Total25

Copyright Huawei Technologies Co., Ltd. 2012. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means

without prior written consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.

All other trademarks and trade names mentioned in this document are the property of their

respective holders.

Notice

The purchased products, services and features are stipulated by the contract made between

Huawei and the customer. All or part of the products, services and features described in this

document may not be within the purchase scope or the usage scope. Unless otherwise

specified in the contract, all statements, information, and recommendations in this document

are provided "AS IS" without warranties, guarantees or representations of any kind, either

express or implied.

The information in this document is subject to change without notice. Every effort has been

made in the preparation of this document to ensure accuracy of the contents, but all

statements, information, and recommendations in this document do not constitute the

warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base

Bantian, Longgang

Shenzhen 518129

People's Republic of China

Website: http://www.huawei.com

Email: [email protected]



Content

Chapter 1 ........................................................................................................................................... 3

Chapter 2 Overview .......................................................................................................................... 5

Chapter 3 Design Method of the HyperMirror ................................................................................ 6

Chapter 4 Synchronous HyperMirror ............................................................................................. 7

4.1 Work Principle of the Synchronous HyperMirror................................................................... 7

4.2 Main Functions of the Synchronous HyperMirror ................................................................. 8

4.2.1 Zero Data Loss ........................................................................................................... 8

4.2.2 Double Backups for Key Data .................................................................................... 8

4.2.3 Supporting the Split Mode .......................................................................................... 9

4.2.4 Quick Response to Faults and Fault Resilience ...................................................... 10

4.2.5 Supporting Master/Slave Switchovers ..................................................................... 10

4.2.6 Functions Related to a Consistent Group ................................................................ 12

4.3 Disaster Recovery Process for the Synchronous HyperMirror ........................................... 13

Chapter 5 Asynchronous HyperMirror ......................................................................................... 14

5.1 Work Principle of the Asynchronous HyperMirror ............................................................... 14

5.2 Main Functions of the Asynchronous HyperMirror ............................................................. 15

5.2.1 Quick Response to Write Requests from the Host................................................... 15

5.2.2 Supporting Splitting, the Master/Slave Switchover, and Quick Fault Resilience ..... 15

5.2.3 Full Protection for Data on the Slave LUN ............................................................... 17

5.2.4 Supporting Functions Related to a Consistent Group .............................................. 17

5.3 Disaster Recovery Process for the Asynchronous HyperMirror ......................................... 17

Chapter 6 Technical Features of the HyperMirror ....................................................................... 18

6.1 Flexible Networking ............................................................................................................. 18

6.2 Flexible Setting of Member LUNs ....................................................................................... 19

6.3 Interconnection with Multiple Arrays ................................................................................... 19

6.4 Mutual Mirroring .................................................................................................................. 20

6.5 Changeable Network Connection ....................................................................................... 20

Chapter 7 Application Scenarios of the HyperMirror .................................................................. 21

7.1 Building a Central Backup Site ........................................................................................... 22

7.2 Building Active-Active Service Sites ................................................................................... 23

7.3 Building Double-Backup Sites............................................................................................. 24



Chapter 1 Overview

With the digitalization in various industries, data has become the core of the

operation of enterprises and institutions. Users' requirements on the stability of

storage systems become higher and higher. Although many vendors can produce

storage devices with high stability, irrecoverable damage to production systems

caused by various natural disasters is still inevitable. To ensure the consistency,

recoverability, and high reliability of data access, remote disaster recovery

solutions emerge. The remote mirror technology is one of the key technologies in

a remote disaster recovery solution.

Also called remote copy, the remote mirror technology is one of the data mirror

technologies. It can maintain several data copies on two or more sites and

prevent data loss caused by disasters by making use of the long distance. Figure

1-1 shows a typical topology of a remote mirror system.

Figure 1-1 Topology of a remote mirror system

Many technologies can be used to implement the remote mirror function. The

most widely used two technologies are the synchronous remote mirror technology



and asynchronous remote mirror technology. Huawei OceanStor storage array

supports both the synchronous HyperMirror (Huawei's remote mirror technology)

and asynchronous HyperMirror to provide users with multiple methods of data

recovery. This document describes the work principles, main functions,

application scenarios, and technology features of the synchronous HyperMirror

and asynchronous HyperMirror respectively.

Chapter 2 Design Method of the HyperMirror

During the design of the HyperMirror, the following requirements were

considered.

1) Ensuring close synchronization between different copies to reduce the

amount of lost data in the case of a disaster.

2) Reducing the write latency of foreground applications in the system to

reduce the system response time and to improve data throughput and

performance.

3) Ensuring data availability and service continuity of the main site and the

mirror site in the case of an abnormity or a disaster.

Due to the inevitable latency on the communication link, the first two requirements

cannot be simultaneously met. When the first requirement is met, the main site

sends a local I/O write request to the mirror site immediately after it receives the

request, and notifies the foreground application of completing the write

application after the I/O is written to the master LUN and slave LUN

simultaneously. This method is called the synchronous HyperMirror. When the

second requirement is met, the main site records the difference caused by the I/O

it receives, and then it notifies the foreground application that the write operation

is complete. When the accumulated to a certain degree (or after a certain period

of time), the differences are written to the slave LUN of the mirror site. This

method is called the asynchronous HyperMirror. Both the synchronous

HyperMirror and asynchronous HyperMirror must meet the third requirement:

data availability under any circumstance.

The synchronous HyperMirror and asynchronous HyperMirror are respectively

described as follows.



Chapter 3 Synchronous HyperMirror

3.1 Work Principle of the Synchronous HyperMirror

The synchronous remote mirror of the OceanStor storage array is called the

synchronous HyperMirror that implements data consistency between the master

LUN and slave LUN through logs. The work principle of the synchronous

HyperMirror is as follows:

1) When a synchronous HyperMirror is created between the master LUN of the

main site and the slave LUN of the remote mirror site, the initial

synchronization will be carried out, that is, all data on the master LUN will be

copied onto the slave LUN.

2) If the master LUN receives a write request from the production host during

the initial synchronization, the system checks the progress on the initial

synchronization. If the data block to which the new data will be written has

not been copied onto the slave LUN, the production host will be notified that

the write operation is complete after the new data is written onto the master

LUN, and new data written onto the master LUN will be copied onto the slave

LUN during the initial synchronization. If the data block to which the new data

will be written to has been copied onto the slave LUN, the new data will be

written to the master LUN and slave LUN respectively. If the data block to

which the new data will be written to is being copied, the new data will be

written to the master LUN and slave LUN respectively after the data block is

fully copied onto the slave LUN.

3) After the initial synchronization, data on the master LUN is consistent with

that on the slave LUN. If the master LUN receives a write request from the

production host after the initial synchronization is complete, the I/O will be

processed according to the following process. (Figure 3-1 shows the work

principle.)

Figure 3-1 Work principle of I/O processing of the synchronous HyperMirror



Step1 The master LUN receives a write request from the production host, and record

"different" in the difference log of the corresponding data block of the I/O.

Step2 Meanwhile, data in the write request is written onto the master LUN and slave

LUN. When written onto the slave LUN, data is sent to the remote mirror site

through the pre-configured link.

Step3 The system checks the result of writing data to the master LUN and the slave

LUN. If data is successfully written onto the master LUN the slave LUN, the

"different" in the difference log is changed to "same"; otherwise, the difference log

still reads "different", and this data block will be copied again in the next

synchronization process.

Step4 The master LUN notifies the production host that the write operation is complete.

3.2 Main Functions of the Synchronous HyperMirror

3.2.1 Zero Data Loss

The synchronous HyperMirror frequently updates data on the master LUN and

slave LUN to keep the recovery point objective (RPO, the time point when data is

recovered to recover services, representing the tolerable data loss) at zero. That

is to say, a remote disaster recovery system based on the synchronous remote

mirror technology can implement disaster recovery on a comparatively high level

the data level (tier 6 zero data loss).

3.2.2 Double Backups for Key Data

The Synchronous HyperMirror supports the mode that a master LUN corresponds

to two slave LUNs (one-to-two mode), thus implementing double backups for key

data, as shown in Figure 3-2. That is to say, the LUN-level fan-out (to be

differentiated from the array-level fan-out) of the HyperMirror is two.

Figure 3-2 One-to-two mode of the synchronous HyperMirror



In one-to-two mode, when data is written to the master LUN, it is simultaneously

written to the two slave LUNs. The two slave LUNs must be on different mirror

sites. In one-to-two mode of the synchronous HyperMirror, a piece of data has

three copies stored in three places. Synchronous HyperMirror in one-to-two mode

is a solution for disaster recovery of highly important data.

3.2.3 Supporting the Split Mode

The synchronous HyperMirror supports the split mode. In split mode, data is only

written onto the master LUN when the production host sends a write request to

the master LUN. The split mode meets users' some requirements, such as

temporary link maintenance, network bandwidth expansion, storing data of a

certain time point on a slave LUN, and so on.

When the synchronous HyperMirror is in split mode, data is only written to the

master LUN when the production host sends a write request, thus data on the

master LUN is different from that on the slave LUN. The differences are recorded

in the difference log. The user can perform the synchronization operation again, if

the user wants to keep data on the slave LUNs consistent with that on the master

LUN. In the synchronization of the synchronous HyperMirror, data blocks that are

marked "different" in the difference log are copied incrementally onto the slave

LUN. The I/O processing principle of the synchronization is similar to that of the

initial synchronization.

Figure 3-3 Splitting and synchronization of the synchronous HyperMirror



3.2.4 Quick Response to Faults and Fault Resilience

The synchronous HyperMirror enters the disconnected status immediately after it

detects a system fault (such as link disconnection, a failure of the master LUN or

the slave LUN). The I/O processing in the disconnected status is similar to that in

split mode. I/Os are written onto the master LUN and the differences are recorded

(note: if the master LUN is faulty, the master LUN cannot receive any I/O request

before the fault is removed). After the fault is removed, the synchronous

HyperMirror performs corresponding operations within a very short time

according to the recovery policy. If the recovery policy is automatic recovery, the

synchronous HyperMirror automatically enters the synchronous status, and

copies data that is marked "different" onto the slave LUN. If the recovery policy is

manually recovery, the synchronous HyperMirror will enter the To Be Recovered

status. Since incremental synchronization is adopted after the synchronous

HyperMirror is disconnected, the time needed by the disaster recovery of the

synchronous HyperMirror is greatly reduced.

3.2.5 Supporting Master/Slave Switchovers

The synchronous HyperMirror supports master/slave switchovers (see Figure

3-4).

Figure 3-4 Master/slave switchover of the synchronous HyperMirror



Before the master/slave switchover, the concept of slave LUN data status is

introduced first. Slave LUN Data Status specifies the availability of the slave LUN.

Slave LUN Data Status can be any of the following four values:

Consistent: Data on the slave LUN is a copy of the data on the master LUN

of the previous time point. Data on the slave LUN is available but perhaps

not completely the same as that on the master LUN now.

Synchronizing: Data on the slave LUN is in the Synchronizing status when

the HyperMirror is in the Synchronizing status. Data on the slave LUN is

unavailable.

Inconsistent: Data on the slave LUN is not a copy of the data on the master

LUN of the previous time point. Data on the slave LUN is unavailable.

Synchronized: Data on the slave LUN now is the same as that on the

master LUN. Data on the slave LUN is of high availability.

As shown in Figure 3-4, the master LUN of the main site becomes the new slave

LUN after the switchover, and the slave LUN of the mirror site becomes the new

master LUN after the switchover. After some simple operations (including LUN

mapping and I/O redirection) are performed on the host, the standby production

host of the mirror site takes over services and sends I/O requests to the new

master LUN. The master/slave switchover cannot be performed on a slave LUN

whose data status is Inconsistent or Synchronizing, since data on the slave

LUN is unavailable and the switchover is meaningless. For a slave LUN whose

data status is Consistent, full synchronization is needed after the master/slave

switchover. For a slave LUN whose data status is Synchronized, full

synchronization is not needed after the master/slave switchover, since data on

the new master LUN is the same as that on the new slave LUN (see Table 3-1).



Table 3-1 Relationship between the master/slave switchover and the slave LUN data status

Relationship with the

Master/Slave Switchover

Slave LUN Data Status

Consistent Synchronizing Inconsistent Synchronized

Whether a master/slave

switchover is allowed Yes No No Yes

Whether full

synchronization is required

after the switchover

Yes - - No

In addition, the synchronous HyperMirror supports the user to perform a

mandatory master/slave switchover on the slave LUN of the mirror site, so that

the user can use data on the new master LUN of the mirror site. The new master

LUN after the mandatory master/slave switchover does not have a slave LUN. To

implement disaster recovery for the new master LUN, a slave LUN must be

specified.

The master/slave switchover can be complete within several seconds. It enables

services at two places that are far apart to be switched casually and ensures data

consistency, thus meeting users' requirement for service switchover.

3.2.6 Functions Related to a Consistent Group

In large and medium-sized database applications, data, logs, and modification

information are stored on different LUNs in the storage array. Loss of data on any

of the LUNs will make data on the other LUNs invalid and unavailable. How to

keep time consistency between multiple remote mirrors must be considered if

remote disaster recovery is required to be implemented upon these LUNs

simultaneously. The synchronous HyperMirror provides the consistent group

function to ensure time consistency between mirror data of multiple LUNs.

After creating a consistent group, the user can add eight HyperMirrors to the

consistent group, as shown in Figure 3-5. The operation of splitting,

synchronization, and master/slave switchover can be performed on a consistent

group. When performed on a consistent group, these operations are effective on

all member HyperMirrors in the consistent group. In addition, all member

HyperMirrors in a consistent group are disconnected when encountering a fault.

The OceanStor storage array does not pose any limit on the working controller of

the master LUNs and slave LUNs in a consistent group, that is, master LUNs in a

consistent group might have different working controllers (the same applies to



slave LUNs), thus the OceanStor storage array provides more flexible

configurations for users.

Figure 3-5 Consistent group of the synchronous HyperMirror

3.3 Disaster Recovery Process for the Synchronous HyperMirror

The disaster recovery process for the synchronous HyperMirror is described as

follows:

1) Normally, the main site provides services. Data on the master LUN of the

main site is copied onto the slave LUN of the mirror site during the

synchronization.

2) When a disaster occurs to the main site, the remote mirroring is

disconnected. A master/slave switchover is performed at this time to change

the slave LUN of the mirror site to the new master LUN.

3) The mirror site takes over services of the main site and ensures that the

services are not interrupted. (The synchronous HyperMirror reserves

interfaces for the main site. If a piece of failover software is installed on the

host, services will be automatically switched in the case of a disaster. So,

disaster recovery of the OceanStor storage array reaches the highest level.)

4) After the disaster recovery, data on the new master LUN will be copied onto

the new slave LUN of the main site during the synchronization.

5) A master/slave switchover is performed again after services on the mirror

site stops. The initial mirroring of the synchronous HyperMirror is recovered.

6) Finally, services on the main site recover. The disaster recovery process is

complete.



Chapter 4 Asynchronous HyperMirror

4.1 Work Principle of the Asynchronous HyperMirror

The asynchronous remote mirror of the OceanStor storage array is called the

asynchronous HyperMirror. The work principle of the asynchronous HyperMirror

is as follows:

1) Similar to the synchronous HyperMirror, initial synchronization is performed

when an asynchronous remote mirroring is established between the master

LUN of the main site and the slave LUN of the remote mirror site.

2) If the master LUN receives a write request from the production host during

the initial synchronization, new data is only written onto the master LUN.

3) After the initial synchronization, Slave LUN Data Status is Synchronized or

Consistent. (If the host sends no write request during the initial

synchronization, Slave LUN Data Status is Synchronized; otherwise,

Slave LUN Data Status is Consistent.). Then, I/Os are processed

according to the following process (for the work principle, see Figure 4-1).

Step1 The master LUN receives the write request from the production host.

Step2 After data in the write request is written onto the master LUN, the host is informed

that the write operation is complete.

Step3 After every synchronization period (set by the user; value range: 1 to 1440

minutes), a synchronization process in which incremental data on the master LUN

is copied onto the slave LUN is automatically performed. (If Sync Type is Manual,

the user has to start the synchronization.) Before the synchronization, snapshots

are created respectively for the master LUN and slave LUN. The snapshot of the

master LUN ensures that data read from the master LUN during the

synchronization is consistent. The snapshot of the slave LUN is used to copy data

on the salve LUN before the synchronization to prevent data on the slave LUN

from becoming unavailable due to an abnormity during the synchronization.

Step4 During the synchronization of data from the master LUN to the slave LUN, data is

read from the snapshot of the master LUN and then copied onto the slave LUN.

Step5 After the synchronization is complete, the snapshot of the master LUN and that of

the slave LUN are cancelled respectively.

Figure 4-1 Work principle of I/O processing of the asynchronous HyperMirror



4.2 Main Functions of the Asynchronous HyperMirror

4.2.1 Quick Response to Write Requests from the Host

The asynchronous HyperMirror responds quickly to write requests from

application servers. The host is informed that the write operation is complete after

data in the write request is written onto the master LUN instead of the slave LUN.

That is to say, the latency of the master LUN of the asynchronous HyperMirror to

the host is the same as that of an ordinary LUN. In addition, synchronization of

data from the master LUN to the slave LUN is performed in the background, thus

having no impact on the access of the host to the master LUN.

Since updates on the master LUN of the asynchronous HyperMirror is not copied

onto the slave LUN immediately, data loss amount is determined by the

synchronization period set by the user. The user can set the synchronization

period according to the application scenario (value range: 1 to 1440 minutes).

4.2.2 Supporting Splitting, the Master/Slave Switchover, and Quick Fault

Resilience

Similar to the synchronous HyperMirror, the asynchronous HyperMirror has the

functions of splitting, synchronization, the master/slave switchover, and recovery

after disconnection.

The split asynchronous HyperMirror does not perform periodic synchronization

until the user manually starts synchronization.

The user can set Sync Type of the asynchronous HyperMirror to Manual or Auto.

When Sync Type is Manual, the HyperMirror does not start synchronization after

a synchronization period but waits for the user to start synchronization. Choosing

Manual, the user can copy updates on the master LUN onto the slave LUN

according to his or her own need, that is, the user determines at which time point

updates on the master LUN are copied onto the slave LUN. There are two types



of automatic synchronization. If the first type Timing wait when sync begins is

chosen, the system starts synchronization and timing and repeats after a

synchronization period. If the second type Timing wait when sync ends is

chosen, the system starts timing when a synchronization process ends until the

next synchronization process starts. The three synchronization types are applied

in different scenarios. Users can choose one according to the actual situation.

Different from the synchronization process of the synchronous HyperMirror, the

synchronization process of the asynchronous HyperMirror uses the difference log

and the progress log to ensure data consistency. The work principle of the

synchronization of the asynchronous HyperMirror is described as follows (see

Figure 4-2):

Figure 4-2 Work principle of the synchronization of the asynchronous

HyperMirror

1) Updates to data on the master LUN between the time points of two

consecutive synchronization processes are recorded in the difference log.

2) When the synchronization starts, the difference log changes to the progress

log. Incremental synchronization is performed according to the records in the

progress log. Meanwhile, a new difference log starts to record data updates

to the master LUN, preparing for the next synchronization process.

3) Synchronization of the asynchronous HyperMirror is started by the user

manually or by the system automatically (after timing is set).

4) The synchronization speed can be adjusted dynamically.

5) An initial synchronization process (full synchronization) is performed by

default when an asynchronous HyperMirror is created. The user can choose

to skip the initial synchronization to save time if data on the slave LUN is the

same as that on the master LUN (for example, a LUN that is newly created

and formatted).



The asynchronous HyperMirror also supports the master/salve switchover,

mandatory master/slave switchover, and quick recovery after disconnection. The

work principle is similar to that of the synchronous HyperMirror.

4.2.3 Full Protection for Data on the Slave LUN

The asynchronous HyperMirror provides full protection for data on the slave LUN.

When data on the slave LUN is unavailable, the snapshot of the mirror site can be

used to roll the slave LUN back, that is, data on the slave LUN is recovered to the

usable data before the time point of the last synchronization process.

After a master/slave switchover is performed on the asynchronous HyperMirror,

the availability of the original slave LUN determines whether the original slave

LUN needs data recovery. If data on the original slave LUN is available, the

original slave LUN does not need to be rolled back; otherwise, a rollback for the

original slave LUN starts, that is, data recovery starts. The rollback for the original

slave LUN is performed in the background. The user is informed that data

recovery is complete after the rollback is complete.

Data recovery for data on the slave LUN is not only applied to the process of a

master/slave switchover. The user can immediately access data on the slave

LUN through data recovery to minimize the recovery time objective (RTO). That is

to say, data recovery starts automatically when the user cancels the remote

mirroring of the slave LUN and data on the slave LUN becomes unavailable.

4.2.4 Supporting Functions Related to a Consistent Group

Same with the synchronous HyperMirror, the asynchronous HyperMirror also

supports functions related to the consistent group, including creating a consistent

group, deleting a consistent group, adding a member to a consistent group,

deleting a member of a consistent group, splitting a consistent group,

synchronization, the master/slave switchover, the mandatory master/slave

switchover, and so on.

4.3 Disaster Recovery Process for the Asynchronous HyperMirror

The disaster recovery process for the asynchronous HyperMirror is described as

follows:

1) Normally, the main site provides services. Data on the master LUN of the

storage device on the main site is copied onto the slave LUN of the mirror

site in asynchronous mode.



2) When a disaster occurs to the main site, the remote mirroring is

disconnected. A master/slave switchover is performed at this time to change

the slave LUN of the mirror site to the new master LUN.

3) The mirror site takes over services of the main site and ensures that the

services are not interrupted. (If a piece of failover software is installed on the

host, the asynchronous HyperMirror can also have the failover function.)

4) After the disaster recovery, the main site starts a synchronization process to

copy data updates on the new master LUN onto the new slave LUN to

reduce lagged write operations between the new master LUN and the new

slave LUN.

5) Services on the mirror site stop.

6) Another synchronization process starts to make data on the new master

LUN the same as that on the new slave LUN. (This synchronization process

eliminates differences caused by write operations during the previous

synchronization process. Due to the multiple synchronization processes

before, this synchronization process is finished quickly.)

7) Another master/slave switchover is performed to recover the initial mirroring

of the asynchronous HyperMirror.

8) Finally, services on the main site recover. The whole disaster recovery

process is complete.

Chapter 5 Technical Features of the

HyperMirror

5.1 Flexible Networking

The HyperMirror supports two networking modes: the parallel networking and

cross networking, as shown in Figure 5-1. Due to the double-link redundancy,

disconnection of either link does not affect services.

Figure 5-1 Networking of the HyperMirror



5.2 Flexible Setting of Member LUNs

The HyperMirror has no limit on the working controllers its member LUNs. The

user can set the working controller of a LUN flexibly, as shown in Figure 5-2. A

fault of any controller does not interrupt services, for services of LUNs that are in

charge of the faulty LUN are automatically taken over by another controller.

Figure 5-2 Flexible setting of working controllers

5.3 Interconnection with Multiple Arrays

The HyperMirror of an OceanStor storage array supports interconnection with a

maximum of eight arrays, as shown in Figure 5-3. The array-level fan-out and

fan-in of the HyperMirror are both eight.

Figure 5-3 Interconnection with multiple arrays



5.4 Mutual Mirroring

The HyperMirror supports mutual mirroring between two OceanStor storage

arrays.

Figure 5-4 Mutual mirroring

5.5 Changeable Network Connection

The HyperMirror supports FC network connections and iSCSI network

connections, as shown in Figure 5-5. In addition, according to the application

scenario, the HyperMirror adapts itself to complicated network connections, such



as array direct connections, connections through FC switches, connections

through IP switches, and connections through an IP-WAN.

Figure 5-5 Supporting FC and iSCSI connections

Chapter 6 Application Scenarios of the

HyperMirror

The HyperMirror is mainly applied to data disaster recovery and backup.

For the synchronous HyperMirror, data in each write request is simultaneously

written onto the main site and the mirror site, and then the production host is

informed that the write operation is complete. If the main site is far from the mirror

site, the write latency of the storage system to the foreground applications is

comparatively high, affecting the user's services. Therefore, the synchronous

HyperMirror is mainly applied to a disaster recovery application in which the main

site is comparatively near to the mirror site, for example disaster recovery within a

city.

For the asynchronous HyperMirror, the write latency of the storage system to

foreground applications is not related to the distance between the main site and

mirror site. So, the asynchronous HyperMirror is applied to a disaster recovery

application in which the distance between the two sites is long or the network

bandwidth is limited.

Table 6-1 lists the maximum transfer distance supported by the HyperMirror in

different networking modes.



Table 6-1 Maximum transfer distance supported by the HyperMirror in different

networking modes

Networking Mode

Maximum Mirroring Distance

Remarks

Synchronous Asynchronous

Direct connection

(iSCSI) 100 m to 150 m

Not

related to

the

transfer

medium

Direct connection

(multiple-mode FC ) 500 m

Through long-distance

transmission equipment

(switches, relay

devices, DWDM, and

FC/IP gateways)

200 km No limit

Related to

the

networking

mode

Note : Multi-mode FC transmission distance

Transmission

Speed

Fiber Type

OM1 OM2 OM3

2Gbps 150m 300m 500m

4Gbps 70m 150m 380m

8Gbps 21m 50m 150m

Several typical application scenarios of the HyperMirror are described as follows.

To most application scenarios, both the synchronous HyperMirror and

asynchronous HyperMirror are applicable.

6.1 Building a Central Backup Site

I. Scenario description:

Services of the customer are scattered in different places.

Remote disaster recovery is required by each site.

Centralized management is required for all backup data.

II. Figure of the application scenario

See Figure 6-2.

Figure 6-1 Central data backup site



III. Features of the scenario:

Centralized backup data management enables the user to analyze and mine

data without interruption to services.

If a disaster occurs to any of the sites, the central backup site takes over the

services of the site; therefore, switchovers of services are managed

centrally.

The HyperMirror supports a central backup site to have a maximum of eight

sites (determined by the maximum fan-in).

According to the distance between each site and the central backup site, the

user can flexibly use the synchronous HyperMirror or asynchronous

HyperMirror.

6.2 Building Active-Active Service Sites


Services of the customer are scattered in two places.

Remote disaster recovery is required by both service sites.

II. Figure of the application scenario

See Figure 6-2.

Figure 6-2 Active-active service sites




The two service sites run their services independently, that is, do not

interfere with each other's services.

Each of the two service sites serves as the backup site of the other.

Dedicated backup sites are unnecessary. Therefore, the cost of the entire

disaster recovery system is reduced.

When one site encounters a disaster, the other site immediately takes over

services of the site that encounters the disaster.

The number of sites can be expanded. Mutual mirroring is also applicable to

three or more sites.

Using the synchronous HyperMirror or asynchronous HyperMirror is

determined by the service features and the distance between the sites.

6.3 Building Double-Backup Sites


The user needs to have three copies of highly important data in three places.

The level of the disaster recovery system is required to be above the zero

data loss level.

II. Figure of the application scenario:

See Figure 6-3.

Figure 6-3 Double-backup sites




Double-backup sites are suitable for disaster recovery for key data and

prevent data loss caused by the second disaster.

When the service site encounters a disaster, either of the mirror sites takes

over the services.

Now, the OceanStor storage array supports double-backup sites using the

synchronous HyperMirror.

Huawei Storage HyperMirror Technical White Paper.pdf

Documents

Transcript of Huawei Storage HyperMirror Technical White Paper.pdf