Remote Replication

Introduction

This section describes the definition, purpose, and benefits of the remote replication feature.

Definition

Remote replication is the core of the disaster recovery system. Remote replication realizes remote data replication and even real-time mirroring, which helps users to prevent data loss caused by disasters.

Remote replication is classified into remote replication/Synchronous and remote replication/Asynchronous.

Purpose

Remote replication creates long-term backup protection for users' data in case of disasters. When data is damaged, backup data can take over services in the shortest time.

Benefits

Remote replication is LUN-based data mirroring. Remote replication involves the master and slave LUNs. The master LUN provides data access, whereas the slave LUN stores a copy of the data on the master LUN. If the master LUN is faulty, the slave LUN takes over the services on the master LUN because it stores the data on the master LUN. After the master LUN is recovered, the changed data are synchronized from the slave LUN to the master LUN and the services are switched over to the master LUN. This ensures service continuity and data consistency, integrity, and availability.

Specification

This section describes the specification parameters of the remote replication feature.

Table 1 and Table 2 lists the specification parameters of the remote replication feature.

Availability

This section describes the availability of the remote replication feature in terms of license support and version support.

License Support

A license needs to be purchased to enable the remote replication feature.

Version Support

The V100R005C02 version of the S2600 storage system

Impact

This section describes the impact of the remote replication feature on system performance and other features.

Impact on System Performance

The remote replication/synchronous will slightly reduce the IO performance of the host.

Impact on Other Features

• The master LUN and slave LUN of a remote replication can neither be used as the target LUN of the full LUN copy, nor the source LUN or target LUN of the incremental LUN copy.
• The master LUN and slave LUN of a remote replication cannot be added to the resource pool, and the resource LUN in the resource pool cannot be used as the master LUN or slave LUN of a remote replication.

Principles

This section describes the implementation principles of the remote replication feature.

Principle Description

Remote replication is classified into remote replication/Synchronous and remote replication/Asynchronous.

Remote replication/Synchronous does LUN-based synchronization, that is, while writing the master LUN, the system sends an I/O write request to the slave LUN. After both the master and slave LUNs return a write success response, the system returns an I/O write success response to the host. In this way, the data on the master LUN is closely synchronized with the data on the slave LUN.

Remote replication/Asynchronous provides LUN-based, asynchronous mirror capability. The master LUN sends a write success response to the host immediately after a write operation is successfully performed on the master LUN, meanwhile the master site records the written data block. Then, the new data on the master LUN is synchronized to the slave LUN with the preset synchronization method. In this way, the write delay of the foreground applications is reduced to the minimum.

Processing Procedure

Figure 1 shows the I/O process of remote replication/Synchronous.

Figure 1 I/O process of remote replication/Synchronous

The process of remote replication/Synchronous is as follows:

1. After a remote synchronous mirror is set up between the master LUN of the master site and the slave LUN of the remote mirror site, initial synchronization is performed, that is, the data on the master LUN is fully copied to the slave LUN.
2. If the master LUN receives a write request from the host during the initial synchronization, it checks the synchronization progress before responding to the request. If the data block to be written is not copied to the slave LUN, data is written to the master LUN and the master LUN returns a write completion response to the host. Then a full copy is performed to synchronize the entire data block to the slave LUN. If the data block to be written is already copied, the new data block need be written to the master and slave LUNs. If the data block is being copied, wait until coping the data block is completed and then write the new data block to the master and slave LUNs.
3. After the initial synchronization is completed, the data on the master LUN is the same as that on the slave LUN. If the master LUN receives a write request from the host at this time, follow the process as shown in Figure 1 to handle I/Os.
1. The master LUN receives a write request from the host and records the bit in the bitmap of the data block corresponding to the I/O as differential.
2. The data of the write request is written to the master and slave LUNs at the same time. That means, when writing data to the master LUN, the device uses the configured link to write data onto the slave LUN in the remote mirror site.
3. If writing data to the master and slave LUNs is successful, change the value of the bit in the bitmap to non-differential. Otherwise, reserve the previous value. In the next synchronization, copy this data block again.
4. The master LUN returns the write completion response to the host.

Figure 2 shows the I/O process of remote replication/Asynchronous.

Figure 2 I/O process of remote replication/Asynchronous

The process of remote replication/Asynchronous is as follows:

1. Similar to remote replication/Synchronous, after an asynchronous mirror is set up between the master LUN of the master site and the slave LUN of the remote mirror site, an initial synchronization is initiated.
2. If the master LUN receives a write request from the host during the initial synchronization, it writes data to the master LUN and records the bit in the bitmap of the data block corresponding to the I/O as differential.
3. After the initial synchronization is completed, the status of the data on the slave LUN is changed to synchronized or consistent. If the master LUN does not receive any write request from the host during the entire initial synchronization, the status of the data on the slave LUN is synchronized. Otherwise, the status is consistent. Then, follow the process as shown in Figure 2 to handle I/Os.
1. The master LUN receives a write request from the host.
2. After data is written to the master LUN, the master LUN immediately returns the write completion response to the host.
3. After a synchronization period (preset by users and ranging from 1 to 1440 minutes), the remote replication automatically initiates an incremental copy of the data on the master LUN to the slave LUN. If the synchronization type is manual, users need to trigger the synchronization manually. Before the synchronization, create snapshots for the master and slave LUNs. The snapshot of the master LUN ensures that the data read from the master LUN during the synchronization is consistent. The snapshot of the slave LUN is to back up the data on the slave LUN, which prevents unavailable data on the slave LUN in case an exception occurs during the synchronization. During the synchronization, data is read from the snapshot LUN of the master LUN and copied to the slave LUN.
4. After the synchronization is completed, disable the snapshots of the master and slave LUNs and wait for the next synchronization time point.

Application Scenarios

This section describes the application scenarios of the remote replication feature.

Remote replication is mainly applied to disaster recovery of the data.

For remote replication/Synchronous, a write completion response is returned only after the data in each write request is written to the master site and the remote mirror site. If the master site is far away from the mirror site, the write delay of the foreground applications is significant, which affects the efficiency of services. Therefore, remote replication/Synchronous is mainly applied in the scenario when the master site is near the mirror site (within tens of kilometers; otherwise a trunk is required to connect the two sites if the distance between them is more than 20 km), for example disaster recovery in a city.

The disaster recovery process of remote replication/Synchronous is as follows:

1. In normal cases, the master site provides services and the data on the master LUN of the storage array at the master site is copied in synchronous mode to the slave LUN of the storage array at the mirror site.
2. After a disaster occurs at the master site, the remote mirror is disconnected from the master site and a master/slave failover occurs. Then, the slave LUN of the mirror site is switched over to the master LUN.
3. The mirror site takes over the services of the master site to ensure service continuity.
4. After the disaster is recovered, synchronize the data on the new master LUN of the mirror site to the new slave LUN (original master LUN) of the master site.
5. After the synchronization is complete, a master/slave failover occurs again and then the previous synchronous mirror is recovered.
6. Finally, the master site takes over the services. After that, the entire disaster recovery process is complete.

For remote replication/Asynchronous, the write delay of foreground applications in the storage system has no relation with the distance between the master and mirror sites. Therefore, remote replication/Asynchronous is applied in the disaster recovery scenario when the master and mirror sites are far away from each other or the network bandwidth is limited.

The disaster recovery process of remote replication/Asynchronous is as follows:

1. In normal cases, the master site provides services and the data on the master LUN of the storage device at the master site is copied in asynchronous mode to the slave LUN of the storage device at the mirror site.
2. After a disaster occurs at the master site, the remote mirror is disconnected from the master site and a master/slave failover occurs. Then, the slave LUN of the mirror site is switched over to the master LUN.
3. The mirror site takes over the services of the master site to ensure service continuity.
4. After the disaster is recovered at the master site, multiple synchronization operations are performed to synchronize the data on the new master LUN of the mirror site to the new slave LUN of the master site. In this way, the write delay between the two LUNs is reduced to the minimum.
5. The services at the mirror site are stopped.
6. Another synchronization operation is performed to make the data on the two LUNs the same. This synchronization is to eliminate the difference caused by write operations done since the last synchronization and will be complete quickly because there are multiple synchronization operations before.
7. A master/slave failover occurs again and then the previous asynchronous mirror is recovered.
8. Finally, the master site takes over the services. After that, the entire disaster recovery process is complete.