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: support@huawei.com


Page3, Total25

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


Page4, Total25


Page5, Total25

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


Page6, Total25

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.


Page7, Total25

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


Page8, Total25

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


Page9, Total25

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


Page10, Total25

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


Page11, Total25

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).


Page12, Total25

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


Page13, Total25

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.


Page14, Total25

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


Page15, Total25

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


Page16, Total25

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).


Page17, Total25

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.


Page18, Total25

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


Page19, Total25

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


Page20, Total25

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


Page21, Total25

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.


Page22, Total25

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


Page23, Total25

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


Page24, Total25

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


Page25, Total25

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

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Huawei Storage HyperMirror Technical White Paper PDF

Загружено:

Авторское право:

Доступные форматы

Doc.

Вам также может понравиться