About this document
This document provides information you can use to configure and manage replication on your Unity storage system. Along with relevant concepts and instructions to configure replication using the Unisphere GUI, this document also include information on the CLI commands associated with configuring replication.
Where to get help
Support, product, and licensing information can be obtained as follows:
For product and feature documentation or release notes, go to Unity Technical Documentation at: www.emc.com/en-us/documentation/unity-family/index.htm. You can also access this page from the Unity product family page at: www.emc.com/en-us/storage/unity.htm. In the Why Unity section, click Unity Product Resources.
For information about EMC products, software updates, licensing, and service, go to EMC Online Support (registration required) at: https://Support.EMC.com. After logging in, locate the appropriate Support by Product page.
For technical support and service requests, go to EMC Online Support at: https://Support.EMC.com. After logging in, locate Create a service request. To open a service request, you must have a valid support agreement. Contact your EMC Sales Representative for details about obtaining a valid support agreement or to answer any questions about your account.
Special notice conventions used in this document
EMC uses the following conventions for special notices:
Data replication is one of the many data protection methodologies that enable your data center to avoid disruptions in business operations. It is a process in which storage data is duplicated to a remote or local system. It provides an enhanced level of redundancy in case the main storage backup system fails. It minimizes the downtime-associated costs of a system failure and simplifies the recovery process from a natural disaster or human error. The replication feature leverages the Unified Snapshots technology to produce a read-only, point-in-time copy of source storage data and periodically updates the copy to keep it consistent with the source data. It leverages crash consistent replicas to provide remote data protection of storage resources.
The system supports asynchronous replication of all storage resources and NAS servers. For block-based storage resources (LUNs, consistency groups, and VMware VMFS datastores), synchronous replication is also supported.
Replication can operate in the following modes:
- Asynchronous – (Applies to block and file storage.) Use this mode when you want the data between the source and destination storage resources synchronized automatically at a specific interval, based on the Recovery Point Objective (RPO).
- Synchronous – (Applies to block storage only.) Use this mode when you want the data between the source and destination storage resources to always remain in sync.
- Manual – (Applies to block and file storage.) Use this mode when you want to manually synchronize changes in the source storage resource to the destination storage resource. When you choose this mode, ensure that you periodically synchronize the session to avoid excessive pool space consumption.
Recovery Point Objective
Recovery Point Objective (RPO) is an industry accepted term that indicates the acceptable amount of data, measured in units of time, that may be lost in a failure. When you set up an asynchronous replication session, you can configure automatic synchronization based on the RPO. You can specify an RPO from a minimum of 5 minutes up to a maximum of 1440 minutes (24 hours). The default RPO is set at 60 minutes (1 hour) interval. In the case of synchronous replication, RPO is set to 0.
Source and destination storage resources
Once replication is configured, the destination storage resource is automatically created with the same attributes as the source destination storage resource. Any modifications to the attributes of the source storage resource are not automatically synchronized over to the destination storage resource. When a failover occurs, ensure that you modify the attributes of the associated destination storage resource to match the attributes of the source storage resource.
Using replication for disaster recovery
In a disaster recovery scenario, the primary (source) system is unavailable due to a natural or human-caused disaster. Data access is still available because a replication session was configured between the primary and destination systems, and the destination system contains a full copy, or replica, of the production data. The replica is up-to-date in accordance with the last time the destination synchronized with the source, as specified by the automatic synchronization recovery point objective (RPO) setting. By issuing a session failover on the destination system, you make the destination system the new production system, using the replica of the primary system’s data that resides on the destination system. Using replicas for disaster recovery minimizes potential data loss. The amount of potential data loss is affected by the RPO that is configured when setting up the replication session. In synchronous replication configuration, where the RPO is set to 0, the amount of potential data loss will be minimal.
Once the session is failed over to the destination system, the destination storage resource becomes read-write. At this point, ensure that the storage resource has the correct access permissions to the host and share. When originally establishing a replication session between the primary and destination systems, create the right host access on the destination system ahead of time to reduce downtime in an event of a disaster.
To resume operations on the source, fail back the replication session.
Using replication for planned downtime
Unlike a disaster, in which the primary (source) system is lost due to an unforeseen event, planned downtime is a situation for which you plan and take the source system offline for maintenance or testing purposes on the destination system. Prior to the planned downtime, both the source and destination are running with an active replication session. When you want to take the source offline in this scenario, the destination system is used as the production system for the duration of the maintenance period. Once maintenance or testing completes, return production to the original source system. Planned downtime does not involve data loss.
To initiate a planned downtime, use the Failover with sync option on the source system. When you fail over a replication session from the source system, the destination system is fully synchronized with the source to ensure that there is no data loss. The session remains active for synchronous replication, and paused for asynchronous replication, while the source becomes Read-Only and the destination becomes Read-Write. The destination storage resource can be used for providing access to the host.
To restore operations on the source, fail back the replication session.
File-based replication consideration
To minimize disruption during a planned downtime window, ensure that the NAS server and associated file system replication sessions are manually synchronized first and then failed over. Follow these steps:
- Synchronize the NAS server replication session using the Sync option.
- Synchronize the replication sessions for each of the file systems associated with the NAS server using the Sync option. This ensures that the destination file systems have the latest data and minimal data will need to be transferred when the replication sessions switch over.
- Inform file system users and quiesce I/O operations from hosts and applications using the file systems in the NAS server.
- Switch over the NAS server replication session using the Failover with sync option.
- Switch over the file system replication sessions using the Failover with sync option.
Once all replication sessions have successfully failed over, resume I/O operations with the relevant applications and hosts.
Any I/O attempted when the failover is occurring may result in read/write errors or stale file handle exceptions.
Fail back a replication session
To resume operations on a source system, the associated replication session needs to be failed back. To fail back a replication session, you use the Failback option on the original destination system. Failback synchronizes the original source with changes done on the original destination after failover, restores the source as the production system, and then restarts the replication session in the original direction.