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).
HyperMetro DC Solution

HyperMetro DC Solution

This section describes the characteristics, DR technologies, and principles of the HyperMetro DC solution.

Solution Introduction

In this solution, both data centers run concurrently to share service loads, improving data center performance and system resource utilization.

Context

With the rapid development of the information technology (IT), information systems are becoming ever important for critical services in a variety of industries. Service interruptions in information systems may lead to severe economic loss, damaged brand images, or critical data loss, especially in the fields of communications, finance, medical care, e-commerce, logistics, and government. Therefore, service continuity is critical to the construction of information systems.

Many enterprises protect production data and ensure service continuity of critical applications by constructing remote DR centers. In this deployment mode, a production center corresponds to a DR center. The DR center does not provide services for external applications if the production center works properly. Once the production center encounters a disaster and its services are interrupted and cannot be quickly recovered, the DR is started to provide services. Such DR systems are facing the following challenges:
  • If the production center encounters a disaster such as a power failure, fire, flood, or earthquake, you must manually switch services from the production center to the DR center. Professional recovery measures and time-consuming debugging may be required. Services are interrupted for a long time.
  • The DR center does not provide services and remains idle for most of the time, lowering resource utilization.

To address these challenges, Huawei launched the HyperMetro DR solution to help customers resolve pain points.

Solution Description

This solution adopts Huawei virtualization intelligent storage (VIS) systems to mirror host services from the production center to the remote DR center. In addition, its HyperMetro arrays enable real-time data writes into two data centers simultaneously to ensure data consistency between two centers. Once a device or data center fails, a service failover starts, ensuring data integrity and service continuity, as well as DR of zero RPO and RTO. In addition, this solution can protect snapshots of protected objects for rolling back data, preventing data loss and data corruption caused by viruses.

Application scenarios:
  • Service loads need to be shared across data centers without interrupting services.
  • Partial or all services (including network, storage, and host services) in a center fail and need to be restored.
  • Links between two data centers of a DR system is of high speed and low latency.
The following lists the supported DR technologies:
  • Active-active (VIS)
  • HyperMetro (SAN)
  • HyperMetro (SAN) and snapshot (SAN)
  • HyperMetro (NAS)
  • HyperMetro (NAS) and HyperVault
Deployment Modes

Deploy one eReplication Server on an independent server of the DR center to protect data of the production center against disasters. On the production center, ensure that service systems can interconnect with the storage management network.

Active-Active (VIS) DR

The mirror function provided by VIS6600T can mirror service data of the production center to the DR center.

Figure 1-26 shows the network of active-active (VIS) DR.

Figure 1-26  Active-active (VIS) DR
HyperMetro (SAN) / HyperMetro (NAS) DR

If the storage devices are deployed in HyperMetro mode, data can be written into both data centers simultaneously and in real time.

Figure 1-27 shows the network of HyperMetro (SAN) / HyperMetro (NAS) DR.

Figure 1-27  HyperMetro (SAN) / HyperMetro (NAS) DR
  • 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: a network that keeps the data and heartbeat information synchronized between two storage systems.
  • Same-city data center network: The storage arrays in both production site 1 and production site 2 provide services for hosts and can carry the same services. A mutual backup relationship is set up between the storage arrays in the two data centers. 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 two data centers interrupted or a storage array malfunctions, the quorum server determines which storage array can be accessed.
HyperMetro (SAN) and Snapshot (SAN) DR

In addition to functions provided HyperMetro (SAN) DR, HyperMetro (SAN) and snapshot (SAN) DR allows real-time multiple data writes by VM services and periodic generation of virtual service data duplicates, to implement one-to-many DR based on the storage layer.

Figure 1-28 shows the network of HyperMetro (SAN) and snapshot (SAN) DR.

Figure 1-28  HyperMetro (SAN) and snapshot (SAN) DR
  • 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: a network that keeps the data and heartbeat information synchronized between two storage systems.
  • Same-city data center network: The storage arrays in both production site 1 and production site 2 provide services for hosts and can carry the same services. A mutual backup relationship is set up between the storage arrays in the two data centers. 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 two data centers interrupted or a storage array malfunctions, the quorum server determines which storage array can be accessed.
HyperMetro (NAS) and HyperVault DR

In addition to functions provided HyperMetro (NAS) DR, HyperMetro (NAS) and HyperVault DR allows real-time multiple data writes by VM services and periodic generation of virtual service data duplicates, to implement one-to-many DR based on the storage layer.

Figure 1-29 shows the network of HyperMetro (NAS) and HyperVault DR.

Figure 1-29  HyperMetro (NAS) and HyperVault DR
  • 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: a network that keeps the data and heartbeat information synchronized between two storage systems.
  • Same-city data center network: The storage arrays in both production site 1 and production site 2 provide services for hosts and can carry the same services. A mutual backup relationship is set up between the storage arrays in the two data centers. 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 two data centers 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.
  • Modify snapshot quantity or time tables of the policy by snapshot configuration.
  • Perform the recovery plan to roll back snapshots by one click.

Active-Active (VIS) DR Principles

The Huawei storage active-active DC solution uses the active-active disaster recovery (DR) technology provided by Huawei VIS6600T to implement DR protection.

The active-active (VIS) technology uses the mirroring function provided by Huawei VIS6600T to implement DR protection for two production data centers (DCs) located at two distant places.

VIS6600T adds two groups of LUNs from two storage arrays into one group of VIS volumes. The two groups of LUNs provide services to the hosts simultaneously and act as a mirror of each other, thereby achieving data redundancy; in this case, the mirrors of the two groups of LUNs are stored on two independent storage arrays. In addition, the VIS6000T isolates the host layer from the application layer; that is, the hosts detect only the virtual VIS volume in all occasions, without being affected by storage array failovers.

For VIS6600T mirroring principles, see Mirroring (VIS) DR Principles.

HyperMetro (SAN) DR Principles

HyperMetro provided by storage devices are used to implement DR.

HyperMetro uses the dual-write and data change log (DCL) technologies to synchronize data changes between two data centers, ensuring data consistency. In addition, HyperMetro enables the storage arrays in the two data centers to concurrently provide services for hosts.

NOTE:
  • Dual-write enables I/O requests of an application host to be synchronized to both a local LUN and a remote LUN.
  • DCL records data changes of the storage arrays in two data centers.
  • Write I/O process:

    The effective locking and dual-write mechanisms are critical to HyperMetro of storage arrays. Data changes can be synchronized using the dual-write and DCL technologies while services are running, ensuring data consistency between the storage arrays in the two data centers.

    NOTE:
    Two storage arrays where HyperMetro is installed can process I/O requests concurrently. The locking mechanism is used to prevent access conflicts that occur when different hosts concurrently access the same storage array. Data can be written into a storage array only after the storage array is granted by the locking mechanism. If a storage array is not granted by the locking mechanism, the storage array must wait until the previous I/O is complete and then obtains the write permission after the previous storage array is released by the locking mechanism.
    • The dual-write technology enables I/O requests of application servers to be delivered to the local cache and remote cache, ensuring data change consistency between the local cache and remote cache.
    • If the storage array in one data center malfunctions, a DCL records data changes in the data center. After the storage array is recovered, the data changes are synchronized to the storage array, ensuring data consistency between the storage arrays in the two data centers.
    Figure 1-30 shows the write I/O process when an application host delivers an I/O request and causes data changes.
    Figure 1-30  Write I/O process
    1. An application host delivers a write I/O to HyperMetro.
    2. A log is recorded.
    3. HyperMetro concurrently writes the write I/O to both the local cache and remote cache.
    4. The local cache and remote cache return the write I/O result to HyperMetro.
    5. A storage array returns the write I/O result to the application host after receiving the feedback from the local cache and remote cache.
    6. The storage array determines whether dual-write succeeds.
      • If the write I/O request is processed successfully, the log is deleted.
      • If the write I/O fails to be written to the local cache or remote cache, the log is converted into a DCL. The DCL records the differential data between the local LUN and remote LUN.
      NOTE:
      If the write I/O fails to be written to the local cache or remote cache, HyperMetro services are suspended and the storage array in each data center sends an arbitration request to the cloud platform quorum server. The storage array that wins the arbitration continues providing services but the storage array that fails in the arbitration stops providing services. The working storage array uses the data change log (DCL) to synchronize data in the background. After the data on the local LUN is the same as that on the remote LUN, HyperMetro services are restored.
  • Read I/O process:

    Data on the LUNs at the two ends are synchronized in real time, and hosts can read and write LUNs at both ends. If the storage array in one data center malfunctions, the storage array in the other data center takes over host services.

    NOTE:
    Huawei optimizes UltraPath to meet HyperMetro requirements. After the optimization, UltraPath can identify host locations so that hosts can access the nearest storage array, reducing cross-site accesses and latency while improving access efficiency and storage performance. UltraPath can read data from the local or remote storage array. However, if the local storage array is working properly, UltraPath preferentially reads data from the local storage array, preventing data read across data centers.
    Figure 1-31 shows the read I/O process.
    Figure 1-31  Read I/O process
    1. An application host applies for the read permission from HyperMetro.
      NOTE:
      If the link between the storage arrays in the two data centers is down, the cloud platform quorum server determines which storage array continues providing services for hosts.
    2. HyperMetro enables the local storage array to respond to the read I/O request of the host.
    3. HyperMetro reads data from the local storage array.
      • If the local storage array is working properly, it returns data to HyperMetro.
      • If the local storage array is working improperly, HyperMetro enables the host to read data from the remote storage array. The remote storage array returns data to HyperMetro.
    4. The read I/O request of the host is processed successfully.
      NOTE:
      If the data of one storage array is abnormal, HyperMetro uses data on the other storage array to repair the data, ensuring data consistency between the two data centers.

HyperMetro (SAN) and Snapshot (SAN) DR Principles

The Huawei storage HyperMetro DC solution combines the HyperMetro and snapshot disaster recovery (DR) features of storage systems and provides storage-layer-based one-to-many DR protection.

In addition to HyperMetro (SAN) DR functions, HyperMetro (SAN) and snapshot (SAN) DR writes multiple copies of application services and VM services, periodically generates virtual copies of service data in the storage system, and thereby provides one-to-many DR based on the storage layer.

For HyperMetro (SAN) DR principles, see HyperMetro (SAN) DR Principles.

HyperMetro (NAS) DR Principles

HyperMetro provided by storage devices are used to implement DR.

Basic Concepts
  • vStore:

    Multiple virtual storage systems can be created in one physical storage system and multiple vStores can share the same storage hardware resources without affecting data security and privacy of each other. vStores enable flexible, easy-to-manage, and cost-effective shared storage in a multi-protocol unified storage architecture.

  • HyperMetro vStore Pair:

    A HyperMetro vStore pair indicates a HyperMetro relationship between vStores of the local and remote storage arrays. The HyperMetro arbitration is implemented in the unit of a HyperMetro vStore pair. If a fault occurs in a HyperMetro vStore pair, ensure the arbitration results of all file systems in the vStores of the HyperMetro vStore pair are the same and the environments in which the file systems are running are consistent between the vStores.

  • Logical Port:

    Logical ports are created based on physical Ethernet ports, bond ports, or VLANs and used for file service operation.

  • Local File System and Remote File System:

    In a HyperMetro pair, the file system on the local storage array is called local file system and the file system on the remote storage array is called remote file system.

  • Dual-Write:

    Dual-write enables the synchronization of application host I/O requests with both local and remote file systems.

  • DCL:

    DCLs record changes in the data of storage arrays.

  • Quorum Server:

    For NAS HyperMetro, if the heartbeats between two storage arrays are interrupted, the quorum server decides which storage array continues providing services, thereby greatly improving host service continuity.

  • HyperMetro Domain:

    A HyperMetro domain consists of the local storage array, remote storage array, and the quorum server. Application servers can access data across data centers using a HyperMetro domain. Before configuring a HyperMetro pair, you must configure the HyperMetro domain first. Each HyperMetro pair must be created in the HyperMetro domain.

  • NAS HyperMetro Pair:

    A NAS HyperMetro pair indicates a HyperMetro relationship between the local and remote file systems. After HyperMetro is configured, a local file system on the local storage array and a remote file system on the remote storage array form a NAS HyperMetro pair. By viewing the state of a HyperMetro pair, you can determine whether you need to perform synchronization and suspension operations. After performing an operation, you can view the state of the HyperMetro pair to determine whether the operation succeeded.

HyperMetro I/O Processing Mechanism

HyperMetro uses the dual-write and DCL technologies to synchronize data changes between two data centers, ensuring data consistency.

  • Write I/O Process:

    The core for implementing data HyperMetro of two storage arrays lies in the vStore-based logical port mechanism and dual-write mechanism. Data changes can be synchronized using the dual-write and DCL technologies while services are running, ensuring data consistency between the storage arrays in two data centers.

    Figure 1-32 shows the write I/O process (write back as an example) when a host sends an I/O request and gives rise to data changes in scenarios where services are running properly.
    Figure 1-32  Write I/O process
    1. A host delivers a write I/O to the HyperMetro management module.
    2. A log is recorded in the local storage array.
    3. The HyperMetro management module writes the write I/O to both the local and remote file systems concurrently.
    4. The local file system writes the write I/O to local cache and the remote file system writes the write I/O to remote cache.
    5. The local cache returns the write I/O result to the local file system and the remote cache returns the write I/O result to the remote file system.
    6. The local and remote file systems return the write I/O results to the HyperMetro management module.
    7. The storage array determines whether dual-write is successful.
      • If the write I/O request is processed successfully, the log is deleted.
      • If the write I/O fails to be written to the local or remote cache, the log is converted into a DCL. The DCL records the differential data between the local and remote file systems.
      NOTE:
      If the write I/O fails to be written to the local or remote cache, HyperMetro services are suspended and the storage array in each data center sends an arbitration request to the quorum server. The storage array that wins the arbitration continues providing services and the one that fails stops. In the background, the storage array uses the DCL to synchronize data. Once the data in the local file system is identical to the data in the remote file system, HyperMetro services are restored.
  • Read I/O Process:

    Data on the file systems of both storage arrays are synchronized in real time. If the storage array in one data center malfunctions, the storage array in the other data center continues providing host services alone.

    Figure 1-33 shows the read I/O process.
    Figure 1-33  Read I/O process
    1. A host applies for read permission from the HyperMetro management module.
      NOTE:
      If the link between the storage arrays in the two data centers is down, the quorum server determines which storage array continues providing services for hosts.
    2. The HyperMetro management module enables the local storage array to respond to the read I/O request made by the host.
    3. If the local storage array is operating properly, it returns data to the HyperMetro management module. The logical ports of the local storage array are activated but the logical ports of the remote storage array are not activated. The local storage array provides services for hosts.
    4. If the local storage array is not operating properly.
      • The logical ports of the remote storage array are activated and the logical ports of the local storage array are deactivated.
      • The remote storage array provides services for hosts and returns data to the HyperMetro management module.
    5. The read I/O request made by the host is processed successfully.

HyperMetro (NAS) and HyperVault DR Principles

The Huawei storage HyperMetro DC solution combines the HyperMetro and snapshot disaster recovery (DR) features of storage systems and provides storage-layer-based one-to-many DR protection.

In addition to HyperMetro (NAS) DR functions, HyperMetro (NAS) and HyperVault DR writes multiple copies of application services and VM services, periodically generates virtual copies of service data in the storage system, and thereby provides one-to-many DR based on the storage layer.

For HyperMetro (NAS) DR principles, see HyperMetro (NAS) DR Principles.

For HyperVault DR principles, see HyperVault DR Principles.
NOTE:
In scenarios where HyperMetro (NAS) and HyperVault are used, you can only use HyperVault to create remote snapshots.
Translation
Download
Updated: 2019-05-21

Document ID: EDOC1100075861

Views: 10781

Downloads: 55

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