HUAWEI OceanStor Series Enterprise Storage System Disaster Recovery White Paper HUAWEI TECHNOLOGIES CO., LTD. Issue 01.

Transcription

1 HUAWEI OceanStor Series Enterprise Storage System Issue 01 Date HUAWEI TECHNOLOGIES CO., LTD.

2 2013. 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 a warranty of any kind, express or implied. Huawei Technologies Co., Ltd. Address: Website: Huawei Industrial Base Bantian, Longgang Shenzhen People's Republic of China [email protected]. ii

3 Contents Contents 1 Overview Introduction to the OceanStor Enterprise Storage System Disaster Recovery Solution of the OceanStor Enterprise Storage System Definition and Standards of Disaster Recovery Definition Standards for Constructing a Disaster Recovery System Summary Method for Constructing a Disaster Recovery System Method Overview Service Analysis Policy Making Implementation and O&M Management Summary Working Principles of HyperReplication HyperReplication/S Working Principle Functions HyperReplication/A Working Principle Functions Disaster Recovery Solutions DC (In Two Places) Disaster Recovery Solution (Roadmap Planning) Centralized Disaster Recovery Solution for Branches VMware Virtualization Disaster Recovery Solution Advantages of the Disaster Recovery Solutions Over a Decade of Accumulated Investment in Storage Multi-Level Disaster Recovery Solution Business Continuity and Professional Service Throughout the Entire Process Simplified and Efficient Disaster Recovery with High Replication Ratio and Wide Compatibility Centralized Disaster Recovery Management Based On the All In One Platform iii

4 Contents 7 Disaster Recovery Drill and Switchover Process Local (Same-City) Disaster Recovery Drill Process Drill Process for Testing Data Availability at the Local Disaster Recovery Site Process for Switching Services to the Local Disaster Recovery Center Local Switchback Drill Process Switchback Process for Testing Data Availability at the Local Disaster Recovery Site Process for Switching Services Back Remote Disaster Recovery Drill Process Drill Process for Testing Data Availability at the Remote Disaster Recovery Site Process for Switching Services to the Remote Disaster Recovery Center Remote Switchback Drill Process Switchback Process for Testing Data Availability at the Remote Disaster Recovery Site Process for Switching Services Back Technology Requirements for disaster recovery Solution Implementation A Acronyms and Abbreviations iv

5 Change History Change History Date Issue Description Prepared By V 1.0 Qin Xuan/ Zeng Jingyong/ Chen Xiaoli/ v

6 1 Overview 1 Overview 1.1 Introduction to the OceanStor Enterprise Storage System Developed by Huawei Technologies Co., Ltd. (Huawei), the OceanStor enterprise storage systems are new-generation storage systems featuring virtualization, hybrid cloud, thin IT, and low carbon footprint. Designed for medium- and large-sized data centers in enterprises, the OceanStor enterprise storage system focuses on critical services in enterprise data centers, virtualization data centers, and cloud data centers. Also, it meets requirements on massive data storage, speedy data storage and access, high availability, optimized utilization, energy conservation, and ease-of-use. Service data amounts in enterprises keep rising quickly with service development and pose more rigorous demands on storage systems. Traditional storage systems have troubles in coping with this fast data growth and are facing a series of problems: storage performance bottlenecks, maintenance and capacity expansion interrupting services, inability to distinguish hot data and cold data, slow response to service requests, and storage system operation and maintenance (O&M) costs rising in total cost of ownership (TCO). To resolve all these problems for customers, Huawei has launched the OceanStor enterprise storage system. The OceanStor enterprise storage system inherits the flexible and scalable design and adopts the horizontally scalable Smart Matrix architecture. The architecture has multiple engines (each engine containing two controllers) and provides up to eight system bays and two disk bays for enterprise data centers. The hardware is seamlessly integrated into enterprise data centers, boosting their efficiency and scalability to perfectly meet requirements of Online Transaction Processing/Online Analytical Processing (OLTP/OLAP), high-performance computing (HPC), digital media, Internet-based operation, centralized storage, backup, disaster recovery, and data migration. 1

7 1 Overview Figure 1-1 OceanStor enterprise storage system 1.2 Disaster Recovery Solution of the OceanStor Enterprise Storage System As social and economic informatization accelerates, enterprises and government departments become more and more dependent on information, and are facing more serious information security challenges. Any data loss or service interruption can cause a severe impact on the operation of an enterprise or a government department, such as huge economic or reputation loss. After the 911 attack, various enterprises and governments quickly included backup and disaster recovery of data and services in their requirements on information system construction. The Chinese government released Opinions of the National Informatization Leading Group on Reinforcing Information Security (No.27 [2003] of the General Office of the Central Committee of the Communist Party of China[CPC]), Notice of Constructing Sound Disaster Recovery and Backup for Significant National Information Systems (No. 11[2004] of the Information office of the State Council), Disaster Recovery Guidelines for Significant Information Systems, Disaster Recovery Specifications for Information Systems (GB/T ) to gradually standardize activities related to information security and disaster recovery. In addition, China frequently suffered various natural disasters such as earthquakes and mudslides in the past few years. As a result, large enterprises and governments attach great importance to disaster recovery and backup. In 2002, Huawei started storage technology development and exploration in the storage industry. Since then, Huawei has made persistent efforts to develop storage technologies. Therefore, Huawei provides a range of competitive disaster recovery solutions as wide as that of any other IT giant. With the Hyper series software and ReplicationDirector (UltraAPM), the OceanStor enterprise storage system protects customers' data and service continuity at the shortest RPO in the industry in a cost-effective way. This document details the disaster recovery solutions of the OceanStor enterprise storage system, including central disaster recovery, virtualized disaster recovery, and the popular 3DC (stands for three data centers) disaster recovery solutions, as well as the remote replication technology used in these solutions. 2

8 2 Definition and Standards of Disaster Recovery 2 Definition and Standards of Disaster Recovery 2.1 Definition Now, disaster recovery has some synonyms in the industry, for example, backup and disaster backup. In addition, there is no industry-unified definition of disaster recovery. In China, the most widely accepted definitions are that in international standard SHARE78 and that in Disaster Recovery Specifications for Information Systems (GB/T ). This document uses the latter one. Disaster: A sudden man-made or natural event resulting in an information system failure or paralysis that interrupts services supported by the information system or makes the service level unacceptable for a specific period. Usually, services of an information system need to be switched to a disaster recovery center upon a disaster. Disaster recovery: The activities and procedures designed to recover an information system from a failure or paralysis caused by a disaster to an operational state and to recover services supported by the information system from the post-disaster abnormal state to an acceptable state. Data disaster recovery technology: also called remote replication technology. The technology can be implemented in two modes: synchronous mode and asynchronous mode. 2.2 Standards for Constructing a Disaster Recovery System The Disaster Recovery Specifications for Information Systems defines the seven critical factors of information system disaster recovery: 1. Data backup system: usually consists of data backup hardware, software, and data backup media (media). A data backup system using electronic transmission also has data backup lines and corresponding communications equipment. 2. Backup data processing system: includes standby computers, peripheral devices, and software. 3. Backup network system: refers to the network through which end users access the backup data processing system. The backup network system contains backup network communications devices and backup data communication lines. 3

9 2 Definition and Standards of Disaster Recovery Level 1: Basic Support 4. Backup infrastructure: refers to the buildings, devices, and organizations required to support the disaster recovery system. The infrastructure includes the offsite storage place, backup equipment room, disaster recovery auxiliary equipment, and living facilities for disaster recovery personnel. 5. Technical support capabilities: refers to the capability to support and protect operation of a disaster recovery system to achieve the preset objectives of the disaster recovery system, including the problem analyzing and processing capabilities of hardware, system software, and applications, capability of managing network system security, and communication and coordination capability. 6. Operation and maintenance management capabilities: include operational environment management, system management, security management, and change management. 7. Disaster recovery plan: includes tested documents used for anti-disaster training and emergency drills. According to the previous seven factors, disaster recovery can be classified into six levels. Disaster recovery policies should be formulated based on the conclusion of risk analysis and business impact analysis. Backup policies of level 2, level 3, and level 5 are most widely used. The following describes the six disaster recovery levels. Level 1 disaster recovery has the following requirements: At least one full data backup is performed every week. Backup media are stored in a place that meets the media storage requirements and is off the production site. The owner of the information system (owner) must work out relevant specifications to regulate accessing, verifying, and dumping data on the backup media, and regularly check the backup data (frequency depending on the media type). The owner must provide a disaster recovery plan that has gone through a full test procedure and has been used for drills. Level 2: Backup Site Support The following figure shows the technical and managerial support required by level 2 disaster recovery. 4

10 2 Definition and Standards of Disaster Recovery Besides offsite storage of backup media which is also required by level 1, level 2 requires a recovery operation site that is equipped with data processing devices, network devices, and communications devices required by disaster recovery. In terms of data transmission and storage technologies, level 2 has the same requirements as level 1, but poses higher requirements on management support. Level 3: Electronic Transmission and Part Device Support The following figure shows the technical and managerial support required by level 3 disaster recovery. Besides requirements of level 2, level 3 also requires electronic transmission. That is, critical data must be transmitted through the communications network to the backup site in batch at 5

11 2 Definition and Standards of Disaster Recovery scheduled time. In addition, level 3 has higher requirements on offline backup. Specifically, level 3 requires that one full backup activity every day. Level 4: Electronic Transmission and Full Device Support Level 3 requires only part data processing and network devices. In contrast, level 4 requires that all data processing devices, communications lines, and network devices for disaster recovery be equipped and ready. Level 4 also requires that the backup site support 24/7 operation. In addition, level 4 poses high requirements on the operation and management skills of the technical support personnel. Level 5: Real-Time Data Transmission and Full Device Support The following figure shows the technical and managerial support required by level 5 disaster recovery. Specifications of level 5 pose explicit requirements on application system recovery. Level 5 requires that all devices for disaster recovery specified in level 4 specifications be available and that data be replicated to the backup site in real time. In addition, level 5 requests that the application system support automatic or centralized switchovers. Two critical points of level 5 specifications are real-time data replication and automatic or centralized system switchover. Compared with the previous four levels, level 5 achieves the minimum RTO and RPO, meeting disaster recovery requirements of most users. Level 6: Zero Data Loss and Remote Cluster Support Besides requirements of level 5, level 6 also requires the following: Real-time remote data replication be implemented with zero data loss. The backup data processing system has the same processing capability as the production data processing system, full compatibility with the production system, and clustered application that supports seamless switchover, real-time monitoring, and failover. The backup network system must allow end users to access both the production and backup data centers through a network. 6

12 2 Definition and Standards of Disaster Recovery The backup site has comprehensive and strict operation management specifications and 24/7 technical support personnel for the operating system, databases, and applications. 2.3 Summary According to the definition and standards of various disaster recovery levels in the Disaster Recovery Specifications for Information Systems, offline backup of critical data and offsite storage of backup media are the foundation of constructing a disaster recovery system and minimum requirements for a disaster recovery system. Any complete disaster recovery system contains not only a simple data backup system but also the rest of the seven factors. Each factor must be carefully considered during design of a disaster recovery system so that the design objectives of the disaster recovery system can be reached. 7

13 3 Method for Constructing a Disaster Recovery System 3 Method for Constructing a Disaster Recovery System 3.1 Method Overview Building a disaster recovery system is a systematic project that has certain rules to abide by. To fully meet the disaster recovery goal, we must take into consideration all related factors and complete each step in strict accordance with the process. No matter what level of disaster recovery system you want to build (for information about the levels, see the Disaster Recovery Specifications for Information Systems), follow the steps in the following figure. Personnel: personnel organization for analyzing, designing, implementing, and maintaining the disaster recovery system. 8

14 3 Method for Constructing a Disaster Recovery System Process: the necessary conditions (including switchover process, failback process, test process, and drill process) for the disaster system's normal operation and quick response to faults. Technology: the technologies used in the disaster recovery, such as data replication technology, application switchover, interface switchover, and service continuity related technologies. A disaster recovery system can be constructed by following four steps: service analysis, policy making, implementation, and O&M management. At the early stage of the disaster system construction, the first two steps are the focuses, which determine the complexity of the implementation and O&M management. 3.2 Service Analysis Service analysis consists of risk analysis and service impact analysis. Risk analysis covers possible organization and facilities breakdowns caused by ambient environment factors, events having adverse impact, and possible losses. In risk analysis, countermeasures and corrective actions must be taken to reduce or prevent potential impact and losses. Risk analysis aims to make quantitative and qualitative evaluations on possible project risks, to define risk levels based on the risk probability and risk impact, and to determine focused protection scopes based on the risk level. Risk analysis provides basis for the follow-up policy making. Service impact analysis quantifies and qualifies the impact of disasters and accidents. It helps determine the criticality of different business systems and the disaster recovery priority and recovery time objective (RTO) for mission-critical services and departments. Based on the service impact analysis, investments can be concentrated mission-critical services. In service impact analysis, two key indicators must be determined: RTO: defines the length of time it takes to recover services from an outage to an operational state. This index is used to measure the service recovery capability of a disaster recovery system. Recovery point object (RPO): refers to the amount of lost data during the period from the time when the disaster occurs to the time when the application system recovers to an operational state. This index is used to measure the data redundancy capability of a disaster recovery system. 3.3 Policy Making Policy making is the most important step of constructing a disaster recovery system. It contains disaster recovery level planning, site selection, technology (such as the data replication technology) selection, and total cost benefit analysis. First, users need to determine their own disaster recovery levels (data level or application level disaster recovery) based on their service analysis results. Currently, many users do not know what disaster recovery level do they need. They just pursue the highest level (application level disaster recovery with failover) but ignore many constraints such as live network environment, budget, and maintenance personnel. Actually, users need to objectively view data level disaster recovery and application level disaster recovery and choose a disaster recovery level as an objective based on their own conditions. 9

15 3 Method for Constructing a Disaster Recovery System Then users need to select a site for and determine the type of the disaster recovery center based on the type of disaster against which they build the disaster recovery center. For example, in case of a fire, a flood, and an earthquake, the disaster recovery center should respectively be several hundred meters, several miles, and several hundred miles away from the production center. Site selection requirements also vary with the region. Users should ensure that all possible disasters are considered during site selection. Sites can be classified based on working mode. Available working modes include cold backup, hot backup, and active-active modes. After determining the site location and type, users need to choose the data replication technology used between the production center and the disaster recovery center. The data replication technology is the core of a disaster recovery system. Huawei divides the data replication technology into host-level replication, SAN-level replication, and storage arraylevel replication. The host-level disaster recovery system consists of operating systems, applications, and databases. The three types of replication technology deliver different advantages and disadvantages. The following table compares the three types of replication technology. Level Advantage Disadvantage Host-level replication SAN-level replication Array-level replication Supports heterogeneous storage arrays at the production center and the disaster center. Integrates with applications seamlessly. Supports and consolidates heterogeneous storage arrays at the production center and the disaster recovery center. Features small changes to the live network and simple implementation. Constructs a basic replication platform to facilitate the expansion of hosts and storage arrays. Exerts no impact on host applications and can be simply constructed. Charges based on storage arrays instead of host license. Depends on the host platform. The production center and the disaster recovery center must have the same host deployment. Implements limited application replication. Some applications cannot be replicated. Occupies host resources. Requires additional hardware, causing high implementation costs. Does not support heterogeneous storage arrays. Storage arrays at the production center and the disaster recovery center must be from the same vendor. Users should carefully weigh the advantages and disadvantages of different levels of replication technologies. Additionally, They should carefully consider the replication links for data transmission between the production center and disaster recovery center. If remote backup is implemented based on backup software, full backup must be performed periodically (synthetic full backup applies only to file applications but not databases). In addition, this type of remote backup incurs complicated management. Therefore, it is not suitable for many users. As a result, asynchronous replication or asynchronous mirroring is 10

16 3 Method for Constructing a Disaster Recovery System used to implement data transmission instead of backup software in a low-bandwidth electronic transmission scenario. Finally, when constructing an application-level disaster recovery system, users should consider network and application switchover technologies between the two sites. The network switchover technology becomes mature in recent years. Common network switchover technologies are based on the floating IP address, DNS, layer 4-7 switch, and application. Cluster software is used to automatically or semi-automatically implement remote switchovers of applications between the production center and the disaster recovery center. Applications can also be manually switched over as long as the manual switchover is appropriately designed and monitored. 3.4 Implementation and O&M Management The implementation of the disaster recovery plan consists of the equipment room construction and the IT system construction. Equipment room construction: civil engineering, auxiliary projects, product model selection, supplier selection, project construction management, electrical engineering, air conditioning, environment engineering, fire engineering, equipment room decoration, safety monitoring, and cable layout IT system construction: product model selection and test, supplier selection, project construction management, external communication projects, server deployment, IP network construction, storage network construction, O&M platform construction, office environment construction, technical tests, and integrated tests A comprehensive O&M management system must be constructed to support the smooth operation of the disaster recovery system. The following figure shows the framework of a common O&M management system: The disaster recovery O&M includes: 1) O&M assurance: system health status, operation management and support, and system maintenance 2) Operation management and control: change management and control, internal audit, and QoS management 3) Facilities management: facilities O&M monitoring, facilities maintenance, and security monitoring 11

17 3 Method for Constructing a Disaster Recovery System 4) Logistics support: document management, administration and human resources, and property management 3.5 Summary The Disaster Recovery Specifications for Information Systems (GB/T ) provides unified methods and process for disaster recovery system construction. The construction of a disaster recovery system consists of four sequential steps: service analysis, policy making, implementation, and O&M management. The design and implementation of the construction plan must follow a complete process with every detail covered so that the disaster recovery system can really protect applications and data well upon a disaster. 12

18 4 Working Principles of HyperReplication 4 Working Principles of HyperReplication The OceanStor enterprise storage system supports synchronous remote replication (HyperReplication/S) and asynchronous remote replication (HyperReplication/A). The two mainstream remote replication technologies meet various customer requirements for disaster recovery. This chapter describes the working principles of HyperReplication/S and HyperReplication/A. 4.1 HyperReplication/S Working Principle Based on a log mechanism, HyperReplication/S of the OceanStor enterprise storage system maintains data consistency between a primary LUN and its secondary LUN. The working principle of HyperReplication/S is as follows: After a synchronous remote replication relationship is set up between a primary LUN at the primary site and a secondary LUN at the secondary site, an initial synchronization is implemented to replicate all the data from the primary LUN to the secondary LUN. If the primary LUN receives a write request from the 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 already been synchronized, the new data block must be written to the primary and secondary LUNs. 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 the primary and secondary LUNs. After the initial synchronization is complete, data on the primary LUN and that on the secondary LUN are the same. If the primary LUN receives a write request from the production host later, the I/O will be processed based on the following procedure (the following figure shows the I/O processing principle). 13

19 4 Working Principles of HyperReplication Functions Zero Data Loss Split Mode 1. The primary site receives a write request from the host and sets the differential log value to "differential" for the data block corresponding to the I/O. 2. The primary site writes the data of the request to the primary LUN (LUNA) and sends the write request to the secondary site through the configured replication link. 3. If data is successfully written to both the primary LUN and secondary LUN (LUN B), 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 process. 4. The primary site sends a write success response to the host. HyperReplication/S of the OceanStor enterprise storage system updates data on the primary and secondary LUN at the same time, ensuring that the RPO is 0. A disaster recovery system constructed based on HyperReplication/S implements data-level disaster recovery with a high disaster recovery level (tier 6 zero data loss and remote cluster support). HyperReplication/S supports the split mode. In this mode, write requests of production hosts go only to the primary LUN, and the difference between the primary and secondary LUNs is recorded by the differential log. If users want to achieve data consistency between the primary and secondary LUNs again, they can start a manual synchronization process, during which data blocks marked as differential in the log are copied from the primary LUN to the secondary LUN. The I/O processing process is similar to the initial synchronization process. This mode meets some user requirements such as temporary link maintenance, network bandwidth expansion, saving data at a certain point in time on the secondary LUN. 14

20 4 Working Principles of HyperReplication Quick Response and Rectification of Faults Writable Secondary LUN HyperReplication/S immediately enters the Interrupted state when a system fault such as a down link or failure of the primary or secondary LUN. In the Interrupted state, I/Os are processed in a way similar to the scenario where a remote replication pair is split. That is, data is written only to the primary LUN and the data difference is recorded. If the primary LUN fails, it cannot receive I/O requests from the production host. After the fault is resolved, the synchronous remote replication pair is recovered based on the specified recovery policy. If the policy is automatic recovery, the pair automatically enters the Synchronizing state, and incremental data is copied to the secondary LUN. If the policy is manual recovery, the pair enters the To Be Recovered state. A user needs to manually initiate a synchronization process. Incremental synchronization greatly reduces the fault/disaster recovery time of HyperReplication/S. The writable secondary LUN function enables the secondary LUN to receive data from hosts. HyperReplication/S supports this function. That is, production hosts can directly access data on the secondary LUN. This function is used mainly in the following scenarios: Users want to use data on the secondary LUN for data analysis and mining without affecting services supported by the primary LUN. The production storage system at the primary site is faulty and the disaster recovery storage system at the secondary site needs to take over services of the production storage system. However, a primary/secondary switchover fails or the secondary site cannot communicate with the production array normally. Usually, the secondary LUN of a remote replication pair is read only. When the primary LUN is faulty, the administrator can cancel secondary LUN write protection to set the secondary LUN writable. Then the disaster recovery storage system can take over host services to ensure business continuity. The secondary LUN of a synchronous remote replication pair can be set to writable only when the following two conditions are met: The remote replication pair is in the split or abnormally interrupted state. Data on the secondary LUN is complete (when the data on the secondary LUN is not complete, the data is not available and the secondary LUN cannot be set to writable). The OceanStor enterprise storage system can record difference between the primary and secondary LUNs after host data is written to the secondary LUN. After the production storage 15

21 4 Working Principles of HyperReplication system at the primary site recovers, users can perform incremental synchronization to quickly switch services back. Primary/Secondary Switchover A primary/secondary switchover is the process where the primary and secondary LUNs in a remote replication pair exchange roles. HyperReplication/S allows users to perform primary/secondary switchovers. Primary/Secondary switchovers are affected by the secondary LUN data state, which indicates the availability of data on the secondary LUN. There are two secondary LUN data states: Consistent: Data on the secondary LUN is a duplicate of the data on the primary LUN (at the time the previous synchronization ended). In this state, data on the secondary LUN is available but not necessarily the same as the current data on the primary LUN. Inconsistent: Data on the secondary LUN is a duplicate of the data on the primary LUN (at the time the previous synchronization ended). In this state, data on the secondary LUN is available. As shown in the previous figure, the primary LUN at the primary site becomes the new secondary LUN after the switchover, and the secondary LUN at the secondary site becomes the new primary LUN. After users perform some simple operations on the host side. The major operation is to map the new primary LUN to the backup production hosts (this can be performed in advance). The backup production hosts at the secondary site take over services and issue new read and write requests to the new primary LUN. A primary/secondary switchover can be performed only when data on the secondary LUN is consistent. Synchronization after a primary/secondary switchover is incremental synchronization. The following must be noted before a primary/secondary switchover is performed for a synchronous remote replication pair: When the pair is in a normal state, a primary/secondary switchover can be performed. 16

22 4 Working Principles of HyperReplication In the split state, a primary/secondary switchover can be performed only when the secondary LUN is set to writable. Functions Related to Consistency Groups In medium- and large-sized database applications, data, logs, and modification information are stored on different LUNs. If data on one of the LUNs is unavailable, data on the other LUNs is also invalid. How to keep the same synchronization pace between multiple remote replication pairs must be considered if remote disaster recovery is required to be implemented for these LUNs simultaneously. HyperReplication/S provides the consistency group function to maintain the same synchronization pace between multiple remote replication pairs. A consistency group is a set of multiple remote replication sessions, ensuring data consistency in the scenario where a host writes data to multiple LUNs on a single storage system. After data is written to a consistency group at the primary site, all data in the consistency group is simultaneously copied to the secondary LUN by using the synchronization function of the consistency group, ensuring integrity and availability of the data used for backup and disaster recovery purposes. HyperReplication/S allows users to add up to 8192 remote replication pairs to a consistency group. When users perform splitting, synchronization, or a primary/secondary switchover or set secondary LUNs to writable for a consistency group, the operation applies to all members in the consistency group. When a link fault occurs, all members of the consistency group enter the abnormally interrupted state together. After the fault is rectified, data synchronization is performed again to ensure availability of the data on the secondary storage system. Primary LUNs in a consistency group can belong to different working controllers. The same applies to secondary LUNs. This allows users to configure the LUNs flexibly. 4.2 HyperReplication/A Working Principle HyperReplication/A of the OceanStor enterprise storage system adopts the multi-timesegment caching technology (patent number: PCT/CN2013/080203). The working principle of the technology is as follows: 1) After an asynchronous remote replication relationship is set up between a primary LUN at the primary site and a secondary LUN at the secondary site, an initial synchronization is implemented to fully copy data on the primary LUN to the secondary LUN. 2) When the initial synchronization is complete, the secondary LUN data status becomes consistent (data on the secondary LUN is a copy of data on the primary LUN at a certain past point in time). Then I/O processing shown in the following figure starts. 17

23 4 Working Principles of HyperReplication 1. Incremental data is automatically synchronized from the primary site to the secondary site based on the user-defined synchronization period that ranges from 3 seconds to 1440 minutes. (If the synchronization type is Manual, a user needs to trigger the synchronization manually.) When a replication period starts, new time segments (TP N+1 and TP X+1 ) are respectively generated in the caches of the primary LUN (LUN A) and the secondary LUN (LUN B). 2. The primary site receives a write request from a production host. 3. The primary site writes data of the write request to cache time segment TP N+1 and sends a write success response to the host immediately. 4. During data synchronization, the storage system reads data in cache time segment TP N of the primary LUN in the previous synchronization period, transmits the data to the secondary site, and writes the data to cache time segment TP X+1 of the secondary LUN. When the write cache of the primary site reaches the high watermark, data in the cache is automatically flushed to disks. In this case, a snapshot is generated for data of time segment TP N. During synchronization, such data is read from the snapshot and copied to the secondary LUN. 5. When the synchronization is complete, the storage system flushes data of time segments TP N and TP X+1 in the caches of the primary and secondary LUNs (the corresponding snapshots are deleted automatically), and waits for the next synchronization period. Time segment: logical space in a cache that manages new data received during a specific period of time. (Data size is not restricted.) Functions Second-level RPO In scenarios of a low RPO and short replication period, the caches of the primary and secondary LUNs can store all data in multiple time segments. However, if the host bandwidth or disaster recovery bandwidth is abnormal and the replication period is prolonged or interrupted, data in the caches is flushed into disks in the primary and secondary storage systems for consistency protection. Upon replication, the data is read from the disks. As HyperReplication/A employs the innovative multi-time-segment caching technology, data in the cache and I/Os interacts with the cache carry time information. During replication and 18

24 4 Working Principles of HyperReplication synchronization, the storage system directly reads data of corresponding time segments from the primary LUN cache and copies the data to the secondary LUN. This lowers the latency and eliminates the impact of traditional asynchronous remote replication snapshots on system performance. Therefore, the synchronization period can be shortened to second-level. HyperReplication/A does not copy data updates on the primary LUN to the secondary LUN in real time. Therefore, the RPO is determined by the user-defined synchronization period (from 3 seconds to 1440 minutes). Quick Response to Host Write Requests HyperReplication/A responds to write requests of application hosts rapidly. The primary site returns a write success response to the host immediately after data of a host write request to the primary LUN is written to the cache but not after the data is written to the secondary LUN. Moreover, data synchronization between the primary and secondary LUNs is performed in the background. Therefore, the synchronization has a very slight impact on host performance. Split Mode and Quick Fault Rectification Similar to HyperReplication/S, HyperReplication/A also allow users to split and resume replication pairs. After being split, an asynchronous remote replication pair does not perform periodic synchronization. After a manual synchronization operation, the pair starts synchronization according to the configured synchronization policy (manual or automatic). HyperReplication/A provides three data synchronization types: Manual: A user needs to manually synchronize data from the primary LUN to the secondary LUN. When this synchronization type is selected, users can copy data updates from the primary LUN to the secondary LUN at any time. Timed wait when synchronization begins: When a data synchronization process starts, the system starts timing. After one synchronization period, the system starts synchronization and timing again. After a specified period of time since the start of the most recent synchronization process, the system automatically copies data from the primary LUN to the secondary LUN. Timed wait when synchronization ends: When the previous synchronization process ends, the system starts timing. After a specified period of time since the end of the most recent synchronization process, the system automatically copies data from the primary LUN to the secondary LUN. The previous three synchronization types are applicable to different scenarios. Users can choose one that best fits their needs. Full Protection for Data on the Secondary LUN HyperReplication/A provides full protection for data on the secondary LUN. At the secondary site, hosts' permission to read and write the secondary LUN is under control. When a synchronization process is interrupted or data on the secondary LUN becomes unavailable, data of the previous period TP X can be recovered to the secondary LUN to overwrite data of the current period TP X+1. Then the secondary LUN stores available data of the point in time before the latest synchronization process. After a primary/secondary switchover, HyperReplication/A determines whether to recover data on the original secondary LUN based on the data availability of the original secondary LUN. If data on the original secondary LUN is available, HyperReplication/A does not 19

25 4 Working Principles of HyperReplication Writable Secondary LUN perform a rollback for the LUN. If data on the original secondary LUN is unavailable, HyperReplication/A recovers data on the original secondary LUN by rolling back the LUN to the state of the point in time before the latest synchronization process. The entire data recovery process is implemented in the background. When the recovery is complete, a message is displayed to inform users of the completion. Similar to HyperReplication/S, HyperReplication/A also supports the writable secondary LUN function. By default, the secondary LUN of an asynchronous remote replication pair is read only. The secondary LUN of an asynchronous remote replication pair can be set to writable only when the following two conditions are met: The remote replication pair is in the split or abnormally interrupted state. Data on the secondary LUN is complete (when the data on the secondary LUN is not complete, the data is not available and the secondary LUN cannot be set to writable). The OceanStor enterprise storage system can record difference between the primary and secondary LUNs after host data is written to the secondary LUN. After the production storage system at the primary site recovers, users can perform incremental synchronization to quickly switch services back. Primary/Secondary Switchover Similar to HyperReplication/S, HyperReplication/A also supports primary/secondary switchovers. For the working principle of a primary/secondary switchover, see section A primary/secondary switchover is performed for an asynchronous remote replication pair when the following conditions are met: The asynchronous remote replication pair is in the split state and the secondary LUN is set to writable. The secondary LUN of the pair is not in the rollback state. Consistency Group Similar to HyperReplication/S, HyperReplication/A supports the consistency group functions. Users can create or delete a consistency group or members of the group. 20

26 5 Disaster Recovery Solutions 5 Disaster Recovery Solutions 5.1 3DC (In Two Places) Disaster Recovery Solution (Roadmap Planning) In recent years, China is frequently attacked by severe natural disasters. In such a condition, 3DC disaster recovery solutions receive more attention and recognition. A 3DC solution usually contains a production center, a same-city disaster recovery center and a remote disaster recovery center. The same-city disaster recovery center is in the same city as or a nearby city to the production center. The same-city disaster recovery center has similar service processing capability to the production center and can independently run key service systems. Data in the same-city disaster recovery center is synchronized with that in the production center in real time through high-speed links. Services in the production center can be switched to the same-city disaster recovery center. Even upon a disaster, such a switchover can be performed without causing data loss to protect service continuity. The remote disaster recovery center is a secondary disaster recovery center in a remote city. When both the production center and the same-city disaster recovery center fail, the remote disaster recovery center can use backup data to recover services. 21

27 5 Disaster Recovery Solutions The OceanStor enterprise storage system implements a 3DC solution Based on the multi-hop remote replication technology and the ReplicationDirector (UltraAPM) professional disaster recovery management software. When the production center suffers a disaster, users can perform a primary/secondary switchover at the local disaster recovery center to run services at this center and maintain the replication relationship between the local and remote disaster recovery centers. If both the production center and the local disaster recovery center suffer a disaster, users can perform a primary/secondary switchover at the remote disaster recovery center to take over services. The following describes the architecture and networking of typical 3DC solutions. 3DC-cascade mode (cascade mode) The OceanStor enterprise storage systems are deployed at the production center, local disaster recovery center, and the remote disaster recovery center. Data at the production center is copied to the local disaster recovery center in real time using HyperReplication/S. Data at the local disaster recovery center is copied to the remote disaster recovery center through the remote replication links using HyperReplication/A. 3DC-concurrent mode (or 3DC-multi-target mode) The OceanStor enterprise storage systems are deployed at the production center, local disaster recovery center, and the remote disaster recovery center. Data at the production center is copied to the local disaster recovery center using HyperReplication/S or HyperReplication/A and to the remote disaster recovery center using HyperReplication/A. 22

28 5 Disaster Recovery Solutions Business continuity ensured by multi-level disaster recovery centers A local disaster recovery center and a remote disaster recovery center are built to provide multi-level protection for data and services of the production center. If the production center fails in a disaster, services are quickly switched to the local disaster recovery center. If both the production center and the local disaster center fail in a disaster, data copies stored in the remote disaster recovery center can be used to recover production services, protecting business continuity. Centralized disaster recovery management, simplifying disaster recovery system management and maintenance Traditional storage management software cannot centrally manage an entire 3DC disaster recovery system. Based on a thorough and accurate understanding of customer requirements, Huawei developed ReplicationDirector (UltraAPM), a piece of professional disaster recovery management software) that can centrally manage a 3DC disaster recovery system. ReplicationDirector (UltraAPM) manages various resources, such as servers, storage devices, and software. In addition, it manages the entire disaster recovery process, covering drills, recovery, inspections, analysis, and reports. In this way, disaster recovery system management is greatly simplified and the disaster recovery system maintenance costs are significantly reduced. Flexible networking modes, simplifying network deployment 23

29 5 Disaster Recovery Solutions Replication technologies employed by the OceanStor enterprise storage system support Fibre Channel and IP links. Users can determine a specific network deployment mode based on actual requirements. 5.2 Centralized Disaster Recovery Solution for Branches A series of disasters such as earthquakes and fires that occurred in China in recent years reminded the government at all levels and large-scale enterprises of the necessity of disaster recovery. Based on the experience gained from past informatization construction, construction of a disaster recovery system is a systematic project that requires a large amount of investment (millions of RMB or more). In terms of informatization of government departments (for example), each province or city has tens of government departments. If these government departments at the province, city, and county levels build disaster recovery systems independently, a huge amount of expenditure will be paid, not to mention the training cost of professional operation and maintenance (O&M) personnel. Therefore, governments with many vertical branches and large-sized enterprises have an urgent need to construct centralized shareable disaster recovery systems to share disaster recovery resources and reduce the disaster recovery system construction costs. The centralized disaster recovery solution is applicable to government departments and enterprises that have many branches. Integrated disaster recovery platform architecture, meeting requirements for endto-end centralized disaster recovery The OceanStor enterprise storage system supports IPSAN, FCSAN, storage consolidation using virtualization. Therefore, it can provide various centralized disaster recovery solutions covering multiple levels of users, transmission networks, and disaster recovery centers to meet various customer requirements. The disaster recovery level of a disaster recovery center 24

30 5 Disaster Recovery Solutions can be easily upgraded from data level to application level with high-end applications such as data mining. Hierarchical access, as well as compatibility between high-end, mid-range, and lowend storage systems, reducing construction costs of the disaster recovery system By conducting a branch research at the early stage, Huawei obtains a thorough understanding of branches' service requirements. Based on the characteristics of each branch, Huawei provides a branch-specific access solution. This solution allows branches to choose storage devices and access approaches based on their service characteristics. This can meet disaster recovery system construction needs better and simplify system construction. Scale-out and two-level cascading, enabling users to build simplified and shareable disaster recovery systems With the industry-highest replication ratio (32:1), the OceanStor enterprise storage system enables users to quickly scale out the disaster recovery solution for new branches. In addition, the OceanStor enterprise storage system supports scale-up of 3DC disaster recovery solution based on centralized disaster recovery. The scale-up can protect business continuity of the simplified and shareable disaster recovery system. Centralized disaster recovery management, simplifying disaster recovery system management and maintenance The centralized disaster recovery solution for multiple branches employs the ReplicationDirector (UltraAPM) software to achieve hierarchical and permission specific management of the entire disaster recovery system. Under the management, the disaster recovery center and various branches have clear responsibilities and rankings. The centralized management platform remarkably simplifies system management, and the one-click disaster recovery drill function lowers the maintenance complexity. 5.3 VMware Virtualization Disaster Recovery Solution According to the market research about game changing virtual technology conducted by the Internet Data Center (IDC) in 2011, the workload using virtualized platform has increased greatly in recent years. In 2010, the growth rate exceeded 50% for the first time. In 2011, the figure hit 59%. Now, the growth rate is still going up steadily. Virtualization is being applied to a wider range. A service interruption in a virtual machine data center running critical applications may cause the enterprise that owns the center huge loss. As a result, a disaster recovery center becomes a necessary part of a data enter. Essential characteristics of virtualization including partitioning, isolation, encapsulation, and independence make virtualized environments more flexible. Enterprises pose more demanding requirements for disaster recovery in virtualized environments, including simple and convenient disaster recovery management and maintenance, cost-effective and flexible disaster recovery drills, as well as failover. VMware vcenter Site Recovery Manager (SRM) is a business continuity and disaster recovery solution provided by VMware. SRM can help users plan, test, and execute recovery of virtual machine services between the production and disaster recovery sites. For enterprises' critical applications, the OceanStor enterprise storage system provides the SRA suite to work with the SRM to provide simple and efficient disaster recovery solutions for virtualized environments. 25

31 5 Disaster Recovery Solutions Simple management and low maintenance costs Disaster recovery management is integrated into the original vsphere management platform. The complex array management and virtual machine operations are encapsulated into simple operations on the interaction interface. The solution is easy to deploy and maintain, reducing the maintenance cost a lot. One-key switchover, reducing the RTO to the maximum After the disaster recovery solution is deployed, users can switch services over to the disaster recovery center by a one-click operation. Then the switchover process is completed by the system automatically. This minimizes the RTO and avoids manual operations that could result in severe consequences. Flexible disaster recovery plan configuration and on-demand drills Users can make disaster recovery plans based on their actual needs and perform efficient disaster recovery drills. The drills use a private network, and therefore, does not affect services of the original production site. During a drill, users can view the result of each step in real time. This improves users' confidence in the disaster recovery solution. 26

32 6 Advantages of the Disaster Recovery Solutions 6 Advantages of the Disaster Recovery Solutions 6.1 Over a Decade of Accumulated Investment in Storage As a professional Chinese local storage vendor with over 10 years of experience in the storage field, Huawei insists on self-development of storage products and is dedicated to providing simple and cost-efficient storage products and solutions to optimizing enterprise IT applications. Now, Huawei has five R&D centers in the world with over 3000 professional storage R&D engineers. It has invested over 10 million USD in the storage compatibility test lab, storage performance test lab, solution verification center, and China's first disaster recovery and cloud storage lab in Chengdu. Depending on its capability in chips, network, core software and hardware technologies and shared platforms, Huawei delivers a full range of storage products and solutions covering from unified storage, big data storage, to cloud storage, from main storage to auxiliary storage, and from hardware to independent software. With the best R&D capability in China, Huawei delivers one-stop infrastructure solutions and service containing storage, servers, cloud computing, and networks. Among the professional storage R&D team, over 400 engineers are dedicated to disaster recovery solutions. With constant input and innovation, these engineers delivers localized and customized storage service and core technology support for users. 6.2 Multi-Level Disaster Recovery Solution The OceanStor enterprise storage system adopts the innovative Smart Matrix architecture, which has multiple engines (each engine containing two controllers) and supports scale-out. Therefore, the OceanStor enterprise storage system delivers performance fitting to the requirements of applications in each construction phase of the IT system and provides customized disaster recovery solutions (backup, media disaster recovery, data-level disaster recovery, or application-level disaster recovery) with predictable service level for customers. 6.3 Business Continuity and Professional Service Throughout the Entire Process Huawei designed disaster recovery solutions using the OceanStor enterprise storage system based on a thorough and accurate understanding of customer requirements for disaster 27

33 6 Advantages of the Disaster Recovery Solutions recovery. Besides solutions, Huawei also provides customers with professional consulting service covering business continuity planning and analysis, site selection for the disaster recovery center, equipment room design, infrastructure, disaster recovery design, deployment and implementation, and operation and maintenance of the disaster recovery center. 6.4 Simplified and Efficient Disaster Recovery with High Replication Ratio and Wide Compatibility HyperReplication of the OceanStor enterprise storage system supports data replication from 32 storage devices to one storage device for central backup (32: 1 replication ratio, which is four to eight times that of a piece of peer software from another vendor). This realizes disaster recovery resource sharing and greatly reduces the cost in deploying disaster recovery devices. In addition, Huawei is the first vendor who realized data replication between high-end, midrange, and low-end storage systems. In addition, Huawei offers multiple types of multi-hop 3DC disaster recovery modes. Therefore, Huawei's simple and hierarchical low-tco disaster recovery solutions are suitable to Chinese customers (for example, government departments with vertical hierarchical structure). 6.5 Centralized Disaster Recovery Management Based On the All In One Platform After a disaster recovery system is built, how to manage this complicate system is a big challenge. Traditional management methods cannot manage an entire disaster recovery system centrally. Huawei thoroughly understands customer requirements for managing a disaster recovery system and develops the All In One disaster recovery management platform. This platform enables customers to centrally monitor and manage networks, storage devices, and servers in both the production center and disaster recovery center and visually manage disaster recovery services, simplifying the management and maintenance of a disaster recovery system. Disaster recovery solutions of the OceanStor enterprise storage system achieve intuitive application-level disaster recovery services management in standard process. Users can create, deploy, manage, and maintain disaster recovery services on the standard disaster recovery management interface using wizards. To ensure the availability of disaster recovery data, disaster recovery drills are mandatory. Huawei provides one-click drills to automatically improve and mount disaster recovery data, and verify data availability by integrating the management function of application systems to achieve real application-level disaster recovery management. 28

34 7 Disaster Recovery Drill and Switchover Process 7 Disaster Recovery Drill and Switchover Process 7.1 Local (Same-City) Disaster Recovery Drill Process Local disaster recovery drills are performed for the following purposes: 1) To test availability of backup data at the disaster recovery center without affecting services in the production center. 2) To test whether services at the production center can be switched to the disaster recovery center (testing the feasibility of a switchover process as well as availability of data in the disaster recovery center) by simulating a production center fault. The specific drill processes are as follows: Drill Process for Testing Data Availability at the Local Disaster Recovery Site With the snapshot technology, the OceanStor enterprise storage system can generate a readable and writable snapshot for the secondary LUN of a remote replication pair. Host access to the snapshot does not affect the snapshot source LUN (the secondary LUN). In this way, the drill does not affect services at the production center or the disaster recovery system. The drill process is as follows: 1) Prepare for the drill. Make sure that the remote replication pair is in a normal state. Make sure that the network between the backup hosts and storage systems at the local disaster recovery center is normal. 2) Perform the drill. Create a snapshot for the secondary LUN of the synchronous remote replication pair (batch creation is supported if there are multiple secondary LUNs). Map the snapshot to the backup host at the local disaster recovery center. Run services on the backup host at the local disaster recovery center. Test the availability and consistency of data at the local disaster recovery center. 29

35 7 Disaster Recovery Drill and Switchover Process 3) Restore the environment after the drill. Stop host test services at the local disaster recovery center. Delete the mapping from the snapshot to the backup host in the local disaster recovery center. Delete the snapshot Process for Switching Services to the Local Disaster Recovery Center To test the switchover process, services in the production center will be actually switched to the local disaster recovery center. The drill interrupts services of the production center. The detailed process is as follows: 1) Prepare for the drill. Make sure that the remote replication pair is in a normal state. Make sure that the upper-layer application environment at the local disaster recovery center is ready. Make sure that the network between the backup host and storage system at the local disaster recovery center is normal. 2) Perform the drill. Stop host services at the production center. Delete the mapping from the primary LUN of the synchronous remote replication pair to the host at the production center. Perform a primary/secondary switchover for the synchronous remote replication pair from the production center to the local disaster recovery center. Map the secondary LUN to the backup host at the local disaster recovery center. Run services at the backup host at the local disaster recovery center. Test the availability and consistency of data at the local disaster recovery center. 3) Restore the environment (for details, see the switchback process). 7.2 Local Switchback Drill Process Switchback Process for Testing Data Availability at the Local Disaster Recovery Site No switchback is needed. During the test, the application systems at both the production and disaster recovery centers are running normally Process for Switching Services Back HyperReplication/S supports reverse incremental synchronization. During a disaster recovery drill, HyperReplication/S records addresses of new host data written to the LUNs at the production and local disaster recovery center. In this way, during the service switchback from 30

36 7 Disaster Recovery Drill and Switchover Process the local disaster recovery center to the production center, only incremental data is copied. In this way, the switchback duration is shortened. The detailed process is as follows: 1) Prepare for the switchback. Make sure that the remote replication pair is in a normal state. Make sure that the upper-layer application environment at the production center is ready. Make sure that the network between the host and storage system at the production center is normal. 2) Perform the switchback. Stop services at the backup host at the local disaster recovery center. Delete the mapping between the backup host and storage system at the local disaster recovery center. Start synchronization for the synchronous remote replication pair from the local disaster recovery center to the production center to achieve data consistency between the primary and secondary LUNs. Perform a primary/secondary switchover for the synchronous remote replication pair from the local disaster recovery center to the production center. Map the LUN to the production host at the production center. Run services on the production host. 3) Perform the post-switchback check. Check that services of the production system are normal. Check that the disaster recovery system is normal by viewing the remote replication pair status. 7.3 Remote Disaster Recovery Drill Process Remote disaster recovery drills are performed for the following purposes: 1) To test the backup data availability without affecting services in the production center. 2) To test whether services at the production center can be switched to the remote disaster recovery center (testing the feasibility of a switchover process and availability of data in the disaster recovery center) by simulating a situation where both the production center and local disaster recovery center fail. The specific drill processes are as follows: Drill Process for Testing Data Availability at the Remote Disaster Recovery Site With the snapshot technology, the OceanStor enterprise storage system can generate a readable and writable snapshot for the secondary LUN of the remote replication pair. Host access to the snapshot does not affect the snapshot source LUN (the secondary LUN). In 31

37 7 Disaster Recovery Drill and Switchover Process this way, the drill does not affect services at the production center or the disaster recovery system. The drill process is as follows: 1) Prepare for the drill. Make sure that the remote replication pair is in a normal state. Make sure that the network between the backup host and storage system at the remote disaster recovery center is normal. 2) Perform the drill. Create a snapshot for the secondary LUN of the synchronous remote replication pair (batch creation is supported if there are multiple secondary LUNs) at the remote disaster recovery center. Map the snapshot to the backup hosts at the remote disaster recovery center. Run services at the backup host at the remote disaster recovery center. Test the availability and consistency of data at the remote disaster recovery center. 3) Restore the environment after the drill. Stop host test services at the remote disaster recovery center. Delete the mapping from the snapshot to the backup hosts in the remote disaster recovery center. Delete the snapshot Process for Switching Services to the Remote Disaster Recovery Center To test the switchover process, services in the production center will be actually switched to the remote disaster recovery center. The drill interrupts services of the production center. The drill process is as follows: 1) Prepare for the drill. Make sure that the remote replication pair is in a normal state. Make sure that the upper-layer application environment at the remote disaster recovery center is ready. Make sure that the network between the backup host and storage system at the remote disaster recovery center is normal. 2) Perform the drill. Stop host services at the production center. Delete the mapping from the primary LUN of the remote replication pair to the host at the production center. Perform a primary/secondary switchover for the synchronous remote replication pair from the production center to the local disaster recovery center. Perform a primary/secondary switchover for the asynchronous remote replication pair from the local disaster recovery center to the remote disaster recovery center. Map the secondary LUN to the backup host at the remote disaster recovery center. 32

38 7 Disaster Recovery Drill and Switchover Process Run services at the backup host at the remote disaster recovery center. Test the availability and consistency of data at the remote disaster recovery center. 3) Restore the environment (for details, see the switchback process). 7.4 Remote Switchback Drill Process Switchback Process for Testing Data Availability at the Remote Disaster Recovery Site No switchback is needed. During the test, the application systems at both the production and disaster recovery centers are running normally Process for Switching Services Back HyperReplication/A supports reverse incremental synchronization. During a disaster recovery drill, HyperReplication/S records addresses of new host data written to the LUNs at the disaster recovery centers. In this way, during the service switchback from the remote disaster recovery center to the local disaster recovery center and production center, only incremental data is copied. In this way, the switchback duration is shortened. The detailed process is as follows: 4) Prepare for the switchback. Make sure that the remote replication pair is in a normal state. Make sure that the upper-layer application environment at the production center is ready. Make sure that the network between the host and storage system at the production center is normal. 5) Perform the switchback. Stop services at the backup host at the remote disaster recovery center. Delete the mapping between the backup host and storage system at the remote disaster recovery center. Start synchronization for the asynchronous remote replication pair from the remote disaster recovery center to the local disaster recovery center to achieve data consistency between the primary and secondary LUNs. When the asynchronous remote synchronization is complete, start synchronization for the remote replication pair from the local disaster recovery center to the production center. After the synchronization is complete, perform a primary/secondary switchover for the asynchronous remote replication pair from the remote disaster recovery center to the local disaster recovery center. Perform a primary/secondary switchover for the synchronous remote replication pair from the local disaster recovery center to the production center. Map the primary LUN to the production host at the production center. Run services on the production host. 33

39 7 Disaster Recovery Drill and Switchover Process 6) Perform the post-switchback check. Check that services of the production system are normal. Check that the disaster recovery system is normal by viewing the remote replication pair status. 34

40 8 Technology Requirements for disaster recovery Solution Implementation 8 Technology Requirements for disaster recovery Solution Implementation For HyperReplication/S, a write success response is returned only after the data in each write request is written to the primary site and secondary site. If the primary site is far away from the secondary site, the write latency of foreground applications is quite long, affecting foreground services. Therefore, HyperReplication/S is usually implemented in a situation where the primary site is near to the secondary site, for example, same-city disaster recovery. The following lists the requirements posed by HyperReplication/S: Distance between the primary and secondary sites < 200 km Minimum link bandwidth 64 Mbit/s Unidirectional transmission latency < 1 ms Actual network bandwidth > peak write I/O bandwidth For HyperReplication/A, the write latency of foreground applications is independent of the distance between the primary and secondary sites. Therefore, HyperReplication/A applies to disaster recovery scenarios where the primary and secondary sites are far away from each other, or the network bandwidth is limited. The following lists the requirements posed by HyperReplication/A: No explicit limit on the WAN distance between the primary and secondary sites; Minimum link bandwidth (bidirectional) 10 Mbit/s; Unidirectional transmission latency < 50 ms; Actual network bandwidth > average write I/O bandwidth The following table lists the maximum transmission distance supported by HyperReplication in different network environments. Networking Mode Direct connection through iscsi Direct connection through multimode optical fibers Maximum Transmission Distance Synchronous Asynchronous 100 m to 150 m 500 m a Remarks The supported maximum distance varies depending on the transmission 35

41 8 Technology Requirements for disaster recovery Solution Implementation Networking Mode Long-distance transfer (switches, trunk devices, DWDM, and FC/IP gateways) Maximum Transmission Distance Synchronous Asynchronous 200 km No restriction Remarks media. The supported maximum distance varies depending on the networking mode. For the transmission distance of multi-mode optical fibers, see the following table: Transfer rate Optical Fiber Type OM1 OM2 OM3 2 Gbit/s 150 m 300 m 500 m 4 Gbit/s 70 m 150 m 380 m 8 Gbit/s 21 m 50 m 150 m 36

42 A Acronyms and Abbreviations A Acronyms and Abbreviations Acronyms and Abbreviations TCO RPO RTO DC LUN Full Spelling Total cost of ownership Recovery point object Recovery time object Data center Logical unit number 37