No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

OceanStor BCManager 6.5.0 eReplication User Guide 02

Rate and give feedback :
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Geo-Redundant DR Solution

Geo-Redundant DR Solution

This section describes the characteristics, DR technologies, and principles of the geo-redundant DR solution.

Solution Introduction

This solution establishes a same-city DR center and a remote DR center. It uses the remote DR center to recover services if the production center fails due to a disaster or misoperation, ensuring business continuity.

Context

As IT services being increasingly used, continuous and secure running of IT systems becomes critical for normal enterprise operation. In production environments, many factors pose threats to proper running of enterprise IT systems. These factors include the device breakdown, network failure, power failure, and human-made and natural disasters. To eliminate those threats, enterprises often establish DR solutions for critical service systems or data centers.

Solution Description
This solution belongs to Huawei Business Continuity and Disaster Recovery Solution. In the Disaster Recovery Data Center Solution (Geo-Redundant Mode), three data centers coexist. The continuity of core services can be ensured when two data centers are damaged, remarkably improving availability of the DR solution. The production center, same-city DR center, and remote DR center are the three data centers in the solution.
  • Production center

    Provides external services.

  • Same-city DR center

    locates at a place dozens of kilometers away from the production center. Fibre Channel network-based direct connection is recommended. Synchronous or Asynchronous replication is implemented and level-1 DR protection is provided in the data center.

  • Remote DR center

    locates at a place hundreds or thousands of kilometers away from the production center. The data center is used to respond to major regional disasters. Periodic asynchronous replication is implemented and level-2 DR protection is provided in the data center.

This solution is applicable to scenarios where data and services at the production center need to be protected in multiple levels.

Service DR: If the production center fails in a disaster, services are quickly switched to the same-city DR center. If both the production center and the local DR center fail in a disaster, data copies stored in the remote DR center can be used to recover production services, protecting business continuity.

The following lists the supported DR technologies:
  • Cascading replication (synchronous and asynchronous)
  • Parallel replication (synchronous and asynchronous)
  • Cascading replication (asynchronous and asynchronous)
  • Parallel replication (asynchronous and asynchronous)
  • Active-active (VIS) and asynchronous replication (SAN)
  • HyperMetro (SAN) and asynchronous replication (SAN)
  • HyperMetro (SAN) and synchronous replication (SAN)
  • HyperMetro (NAS) and asynchronous replication (NAS)
NOTE:

This solution is developed based on the HyperMetro data center solution. The production and same-city DR centers correspond to the two production centers of the solution in two data center mode. For details about the HyperMetro data center solution, see HyperMetro DC Solution.

Deployment Modes
Centralized and distributed deployment modes are supported:
  • Centralized deployment: The eReplication Server is deployed on the server of the DR center with service restoration priority and manages resources of the three centers. The eReplication Server must communicate with other two centers properly over networks.
  • Distributed deployment: The eReplication Servers are deployed on servers of same-city and remote DR centers. The eReplication Servers in the same-city DR center manage local resources and those of the production center. And the others manage resources of the remote DR center. The network between the two eReplication Servers must be properly connected.
NOTE:

Compared with centralized deployment, distributed deployment is more secure and provides shorter latency during daily production center maintenance. Up to two eReplication Servers can be deployed.

Cascading Replication (Synchronous and Asynchronous or Asynchronous and Asynchronous) DR

The cascading replication relationship is established between storage systems used by services to implement same-city and remote DR at the same time, minimizing impact on production center performance.

Figure 1-13 shows the network of cascading replication (synchronous and asynchronous or asynchronous and asynchronous) DR in distributed mode.

Figure 1-13  Cascading replication (synchronous and asynchronous or asynchronous and asynchronous) DR in distributed mode
  • Replication network: Communication network used by the production site to replicate service data to the DR site.
  • Management network: The management network includes DR management network and production management network. The two networks may reside on a same network or be separated.
    • DR management network

      Communication network used by eReplication to provide external services. The maintenance terminal and third-party systems access this network using the management IP address of the DR server.

    • Production management network

      Communication network used by eReplication storage devices, hosts, FusionManagerFusionCompute, VRGs, and vCenter servers to provide external services. The maintenance terminal and third-party systems access this network using their management IP addresses.

  • Service network: Communication network that transfers the read and write I/Os between hosts (or VMs) and storage resources.
Parallel Replication (Synchronous and Asynchronous or Asynchronous and Asynchronous) DR

If a regional disaster occurs, the parallel replication network can effectively avoid the drawbacks of the cascading network.

Figure 1-14 shows the network of parallel replication (synchronous and asynchronous or asynchronous and asynchronous) DR in distributed mode.

Figure 1-14  Parallel replication (synchronous and asynchronous or asynchronous and asynchronous) DR in distributed mode
  • Replication network: Communication network used by the production site to replicate service data to the DR site.
  • Management network: The management network includes DR management network and production management network. The two networks may reside on a same network or be separated.
    • DR management network

      Communication network used by eReplication to provide external services. The maintenance terminal and third-party systems access this network using the management IP address of the DR server.

    • Production management network

      Communication network used by eReplication storage devices, hosts, FusionManagerFusionCompute, VRGs, and vCenter servers to provide external services. The maintenance terminal and third-party systems access this network using their management IP addresses.

  • Service network: Communication network that transfers the read and write I/Os between hosts (or VMs) and storage resources.
Active-Active (VIS) and Asynchronous Replication (SAN) DR

The VIS6600T is deployed both in the production and same-city DR centers to implement HyperMetro DR. The asynchronous remote replication is adopted between the two centers to protect data upon regional disasters.

Figure 1-15 shows the network of active-active (VIS) and asynchronous replication (SAN) DR in distributed mode.

Figure 1-15  Active-active (VIS) and asynchronous replication (SAN) DR in distributed mode
  • Replication network: Communication network used by the production site to replicate service data to the DR site.
  • Management network: The management network includes DR management network and production management network. The two networks may reside on a same network or be separated.
    • DR management network

      Communication network used by eReplication to provide external services. The maintenance terminal and third-party systems access this network using the management IP address of the DR server.

    • Production management network

      Communication network used by eReplication storage devices, hosts, FusionManagerFusionCompute, VRGs, and vCenter servers to provide external services. The maintenance terminal and third-party systems access this network using their management IP addresses.

  • Service network: Communication network that transfers the read and write I/Os between hosts (or VMs) and storage resources.
HyperMetro (SAN) and Asynchronous or Synchronous Replication (SAN) DR

The production and same-city DR centers are deployed in storage HyperMetro mode. Asynchronous or synchronous remote replication is enabled between the same-city and remote DR centers.

Figure 1-16 shows the network of cascading HyperMetro (SAN) and asynchronous or synchronous replication (SAN) DR in distributed mode.

Figure 1-16  HyperMetro (SAN) and asynchronous or synchronous replication (SAN) DR in distributed mode
  • Replication network: Communication network used by the production site to replicate service data to the DR site.
  • Management network: The management network includes DR management network and production management network. The two networks may reside on a same network or be separated.
    • DR management network

      Communication network used by eReplication to provide external services. The maintenance terminal and third-party systems access this network using the management IP address of the DR server.

    • Production management network

      Communication network used by eReplication storage devices, hosts, FusionManagerFusionCompute, VRGs, and vCenter servers to provide external services. The maintenance terminal and third-party systems access this network using their management IP addresses.

  • Service network: Communication network that transfers the read and write I/Os between hosts (or VMs) and storage resources.
  • HyperMetro replication network: It is the heartbeat network between the storage arrays in the production site and same-city DR site. It enables the storage arrays to concurrently provide services for hosts and ensures data synchronization between the storage arrays in the two sites.
  • Same-city data center network: The storage arrays in both production site and same-city DR site provide services for hosts and can carry the same services. A mutual backup relationship is set up between the storage arrays in the two sites. If the storage array in one data center malfunctions, the storage array in the other data center automatically takes over services without data loss or service interruption.
  • Quorum network: The HyperMetro quorum server is deployed on the network. If communication between the storage arrays in production site and same-city DR site interrupted or a storage array malfunctions, the quorum server determines which storage array can be accessed.
HyperMetro (NAS) + Asynchronous Replication (NAS) DR

The production and same-city DR centers are deployed in storage active-active mode. Synchronous or asynchronous remote replication is enabled between the same-city and remote DR centers.

Figure 1-17 shows the network in distributed mode.

Figure 1-17  HyperMetro (NAS) + asynchronous replication (NAS) DR in distributed mode
  • Replication network: Communication network used by the production site to replicate service data to the DR site.
  • Management network: The management network includes DR management network and production management network. The two networks may reside on a same network or be separated.
    • DR management network

      Communication network used by eReplication to provide external services. The maintenance terminal and third-party systems access this network using the management IP address of the DR server.

    • Production management network

      Communication network used by eReplication storage devices, hosts, FusionManagerFusionCompute, VRGs, and vCenter servers to provide external services. The maintenance terminal and third-party systems access this network using their management IP addresses.

  • Service network: Communication network that transfers the read and write I/Os between hosts (or VMs) and storage resources.
  • HyperMetro replication network: It is the heartbeat network between the storage arrays in the production site and same-city DR site. It enables the storage arrays to concurrently provide services for hosts and ensures data synchronization between the storage arrays in the two sites.
  • Same-city data center network: The storage arrays in both production site and same-city DR site provide services for hosts and can carry the same services. A mutual backup relationship is set up between the storage arrays in the two sites. If the storage array in one data center malfunctions, the storage array in the other data center automatically takes over services without data loss or service interruption.
  • Quorum network: The HyperMetro quorum server is deployed on the network. If communication between the storage arrays in production site and same-city DR site interrupted or a storage array malfunctions, the quorum server determines which storage array can be accessed.
DR Management
eReplication provides the following functions:
  • Automatically identify the storage LUN and remote replication relationship by detecting applications on hosts and the storage system of applications.
  • Automatically aware VMs running virtualization infrastructure (FusionManager or FusionCompute) being added.
  • Protect service hosts and VMs based on preset DR policies.
  • If a planned disaster (such as an outage or system maintenance) is to happen:

    Migrate services from the production center to the remote DR center through one-click scheduled migration.

  • If an unplanned disaster (such as an earthquake, fire, or flood) occurs:

    Restore services by using backup data in the remote DR center by one click.

Cascaded Replication DR Principles

A cascaded replication relationship is established between storage systems used by services to implement same-city and remote DR.

Synchronous or asynchronous remote replication is used between a production data center and a same-city DR center for same-city DR. Asynchronous remote replication is used between the same-city DR center and remote DR center for remote DR.

For details about storage configuration and scheme principle of the DR Star networking, see About DR Star in the storage device online help.

Synchronous Replication (SAN)
Synchronous replication (SAN) is implemented as follows:
  1. After a synchronous remote replication relationship is set up between a primary LUN at a production site and a secondary LUN at a DR site, an initial synchronization is implemented to replicate all the data from the primary LUN to the secondary LUN.
  2. If the primary LUN receives a write request from a production host during the initial synchronization, the storage system checks the synchronization progress.
    • If the original data block to be replaced is not synchronized to the secondary LUN, the new data block is written to the primary LUN and the storage system returns a write success response to the host. Then, the synchronization task will synchronize the new data block to the secondary LUN.
    • If the original data block to be replaced has been synchronized, the new data block must be written to both the primary LUN and secondary LUN.
    • If the original data block to be replaced is being synchronized, the storage system waits until the data block is copied. Then, the storage system writes the new data block to both the primary LUN and secondary LUN.
  3. After the initial synchronization is complete, data on the primary and secondary LUNs is the same. If the primary LUN receives a write request from the production host, I/O requests are processed according to the procedure in Figure 1-18.
    Figure 1-18  I/O processing procedure in synchronous replication
    1. The primary LUN receives a write request from a production host and sets the differential log value to Differential for the data block corresponding to the I/O.
    2. The data of the write request is written to both the primary and secondary LUNs. When data is written to the secondary LUN, the secondary LUN sends the data to the DR site over a preset link.
    3. If data is successfully written to both the primary and secondary LUNs, the corresponding differential log value is changed to Non-differential. Otherwise, the value remains Differential, and the data block will be copied again in the next synchronization.
    4. The primary LUN returns a write completion acknowledgement to the production host.
Asynchronous Replication (SAN)
Asynchronous replication (SAN) is implemented as follows:
  1. After an asynchronous remote replication relationship is set up between a primary LUN at a production site and a secondary LUN at a DR site, an initial synchronization is implemented.
  2. If the primary LUN receives a write request from a production host during the initial synchronization, data is written only to the primary LUN.
  3. After the initial synchronization is complete, 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/O requests are processed according to the procedure in Figure 1-19.
    Figure 1-19  I/O processing procedure in asynchronous replication
    1. The primary LUN receives a write request from a production host.
    2. After data is written to the primary LUN, a write completion response is immediately returned to the host.
    3. Incremental data is automatically synchronized from the primary LUN to the secondary LUN based on the user-defined synchronization period. (If the synchronization type is Manual, users need to trigger the synchronization manually.) Before the synchronization, the storage system creates snapshots for the primary LUN and secondary LUN.
      • The snapshot generated for the primary LUN ensures data consistency between the primary LUN and the secondary LUN during data synchronization.
      • The snapshot for the secondary LUN provides backup for the data on the secondary LUN before synchronization. This ensures that data on the secondary LUN is usable even when an exception occurs during synchronization.
    4. During the synchronization, data is read from the snapshot of the primary LUN and copied to the secondary LUN.
    5. After the synchronization is complete, the snapshots of the primary and secondary LUNs are canceled, and the next synchronization period starts.

Parallel Replication DR Principles

A parallel replication relationship is established between storage systems used by services to implement same-city and remote DR.

Synchronous or asynchronous remote replication is used between a production data center and a same-city DR center for same-city DR. Asynchronous remote replication is used between the production data center and a remote DR center for remote DR.

parallel replication (synchronous + asynchronous) supports the DR Star networking. For details about storage configuration and scheme principle of the DR Star networking, see About DR Star in the storage device online help.

For principles of synchronous replication (SAN) and asynchronous replication (SAN), see Cascaded Replication DR Principles.

Active-Active (VIS) and Asynchronous Replication (SAN) DR Principles

The HyperMetro technology provided by VIS devices is used for same-city DR. Remote replication functions provided by storage devices are used to replicate application data from a production data center to a DR center for remote DR.

  • VIS6600Ts are deployed for a production data center and a same-city DR center to implement HyperMetro DR. For details about the HyperMetro DC Solution, see Active-Active (VIS) DR Principles.
  • Asynchronous remote replication is used between a same-city DR center and a remote DR center. The principles for asynchronous remote replication are as follows:
    1. After an asynchronous remote replication relationship is set up between a primary LUN in a same-city DR center and a secondary LUN in a remote DR center, an initial synchronization is implemented.
    2. If the primary LUN receives a write request from a production host during the initial synchronization, data is written only to the primary LUN.
    3. After the initial synchronization is complete, 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/O requests are processed according to the procedure in Figure 1-20.
      Figure 1-20  I/O processing procedure in asynchronous replication
      1. The primary LUN receives a write request from a production host.
      2. After data is written to the primary LUN, a write completion response is immediately returned to the host.
      3. Incremental data is automatically synchronized from the primary LUN to the secondary LUN based on the user-defined synchronization period. (If the synchronization type is Manual, users need to trigger the synchronization manually.) Before the synchronization, the storage system creates snapshots for the primary LUN and secondary LUN.
        • The snapshot generated for the primary LUN ensures data consistency between the primary LUN and the secondary LUN during data synchronization.
        • The snapshot for the secondary LUN provides backup for the data on the secondary LUN before synchronization. This ensures that data on the secondary LUN is usable even when an exception occurs during synchronization.
      4. During the synchronization, data is read from the snapshot of the primary LUN and copied to the secondary LUN.
      5. After the synchronization is complete, the snapshots of the primary and secondary LUNs are canceled, and the next synchronization period starts.

HyperMetro (SAN) and Asynchronous or Synchronous Replication (SAN) DR Principles

The HyperMetro technology provided by storage devices is used for same-city DR. Remote replication functions provided by storage devices are used to replicate application data from a production data center to a DR center for remote DR.

  • Storage devices are deployed for a production data center and a same-city DR center to implement HyperMetro DR. For details about the HyperMetro DC Solution, see HyperMetro (SAN) DR Principles.
  • Asynchronous remote replication is used between a same-city DR center and a remote DR center. The principles for asynchronous remote replication are as follows:
    1. After an asynchronous remote replication relationship is set up between a primary LUN at a production site and a secondary LUN at a DR site, an initial synchronization is implemented.
    2. If the primary LUN receives a write request from a production host during the initial synchronization, data is written only to the primary LUN.
    3. After the initial synchronization is complete, 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/O requests are processed according to the procedure in Figure 1-21.
      Figure 1-21  I/O processing procedure in asynchronous replication
      1. The primary LUN receives a write request from a production host.
      2. After data is written to the primary LUN, a write completion response is immediately returned to the host.
      3. Incremental data is automatically synchronized from the primary LUN to the secondary LUN based on the user-defined synchronization period. (If the synchronization type is Manual, users need to trigger the synchronization manually.) Before the synchronization, the storage system creates snapshots for the primary LUN and secondary LUN.
        • The snapshot generated for the primary LUN ensures data consistency between the primary LUN and the secondary LUN during data synchronization.
        • The snapshot for the secondary LUN provides backup for the data on the secondary LUN before synchronization. This ensures that data on the secondary LUN is usable even when an exception occurs during synchronization.
      4. During the synchronization, data is read from the snapshot of the primary LUN and copied to the secondary LUN.
      5. After the synchronization is complete, the snapshots of the primary and secondary LUNs are canceled, and the next synchronization period starts.
  • Asynchronous remote replication is used between a same-city DR center and a remote DR center. The principles for synchronous remote replication are as follows:
    1. After a synchronous remote replication relationship is set up between a primary LUN at a production site and a secondary LUN at a DR site, an initial synchronization is implemented to replicate all the data from the primary LUN to the secondary LUN.
    2. If the primary LUN receives a write request from a production host during the initial synchronization, the storage system checks the synchronization progress.
      • If the original data block to be replaced is not synchronized to the secondary LUN, the new data block is written to the primary LUN and the storage system returns a write success response to the host. Then, the synchronization task will synchronize the new data block to the secondary LUN.
      • If the original data block to be replaced has been synchronized, the new data block must be written to both the primary LUN and secondary LUN.
      • If the original data block to be replaced is being synchronized, the storage system waits until the data block is copied. Then, the storage system writes the new data block to both the primary LUN and secondary LUN.
    3. After the initial synchronization is complete, data on the primary and secondary LUNs is the same. If the primary LUN receives a write request from the production host, I/O requests are processed according to the procedure in Figure 1-22.
      Figure 1-22  I/O processing procedure in synchronous replication
      1. The primary LUN receives a write request from a production host and sets the differential log value to Differential for the data block corresponding to the I/O.
      2. The data of the write request is written to both the primary and secondary LUNs. When data is written to the secondary LUN, the secondary LUN sends the data to the DR site over a preset link.
      3. If data is successfully written to both the primary and secondary LUNs, the corresponding differential log value is changed to Non-differential. Otherwise, the value remains Differential, and the data block will be copied again in the next synchronization.
      4. The primary LUN returns a write completion acknowledgement to the production host.
  • HyperMetro (SAN) + synchronous replication (SAN) supports the establishment of the DR Star networking. For details about specific configurations and principles, see XXXX Storage technical documentation.

DR Principles (HyperMetro (NAS) + Asynchronous Replication (NAS))

The Geo-Redundant solution uses the active-active technology provided by storage devices for same-city active-active DR. Remote replication functions provided by storage devices are used to replicate application data from a production data center to a DR center for remote DR.

  • The VIS6600T is deployed both in the production and same-city DR centers to implement active-active DR. For details about principles, see HyperMetro (NAS) DR Principles.
  • Asynchronous remote replication for storage file systems is enabled between the same-city and remote DR centers. The principles are as follows:
    • Object layer–based replication

      HyperReplication/A for File System implements data replication based on the object layer. The files, directories, and file properties of file systems consist of objects. Object layer–based replication copies objects from the primary file system to the secondary file system without considering complex file level information, such as dependency between files and directories and file operations, simplifying replication operations.

    • Periodic replication based on redirect-on-write (ROW) snapshots

      HyperReplication/A for File System implements data replication based on ROW snapshots.

    In asynchronous replication, a write success acknowledgement is returned immediately after host data is written to the primary file system. Then the data is periodically replicated to the secondary file system in the background. Replication periods are defined by users. The addresses instead of content of incremental data blocks in each period are recorded. When a replication period starts, HyperReplication/A for File System creates a snapshot for the primary file system, reads and replicates snapshot data to the secondary file system based on the incremental information since the last synchronization. After the incremental replication is complete, the content of the secondary file system is the same as the snapshot of the primary file system. The secondary file system becomes the data consistency point. In each replication period, the secondary file system is incomplete before all incremental data is completely transferred to the secondary file system. After the replication period ends and the secondary file system becomes a data consistency point, a snapshot is created for the secondary file system. If the next periodic replication is interrupted because the production center malfunctions or the link is down, HyperReplication/A for File System can restore the secondary file system data to the last snapshot point to obtain consistent data.
    Figure 1-23  HyperMetro (NAS) + Asynchronous Replication (NAS) DR

    Periodic replication can improve the replication efficiency and bandwidth utilization. In a replication period, if the host repeatedly writes data with the same address, for example, the data in the same location of a file is repeatedly modified, the data written last is replicated.

    File systems and their snapshots employ ROW to process data write operations. For details, see the file system technical white paper and snapshot technical white paper. No matter whether a file system has a snapshot, data is written to the new address space. The service performance will not decrease even though snapshots are created. Therefore, HyperReplication/A for File System imposes a slight impact on production service performance.

Translation
Download
Updated: 2019-05-21

Document ID: EDOC1100075861

Views: 10333

Downloads: 55

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next