Home > Storage > Unity XT > Data Protection > Dell Unity: Replication Technologies > Common Base Snapshots
In Dell UnityOS version 5.1 and later, Read-Only snapshots created on a resource contain a new internal system ID for tracking purposes. This ID is not visible to a user. When a snapshot is replicated, the ID will also be replicated with the snapshot to all destinations, including across all replication sessions within an advanced File remote replication topology. To support this feature both the source and destination systems must be running UnityOS version 5.1 or later. For local replication, the ID is supported if the system is running UnityOS version 5.1 or later.
In certain circumstances, a full synchronization of data is needed to restart or continue replication. In UnityOS version 5.1 and later, replicated snapshots can be used to avoid full synchronization of data in certain situations. The snapshot ID allows the system to easily determine if a snapshot on the source and destination are exactly the same. If the systems confirm the IDs of a pair of snapshots are the same, the snapshots can be used as a common base to start or continue replication. This can help reduce the amount of time it takes to return replication to a good state. The amount of data to be copied directly depends on the amount of data that has changed since the creation of the common base snapshots. This feature is supported on LUNs, thin clones, consistency group, file systems, and VMFS and NFS datastores for specific replication modes described below.
In situations where a replication session must be deleted and recreated, a full synchronization of data is required in UnityOS versions prior to the 5.1 release. This is true even if no data has changed between the source and destination. If a snapshot has been created on a system running 5.1 or later and replicated to the destination running 5.1 or later, the replication session can leverage the replicated snapshot as a common base. Full copy avoidance is supported for file synchronous replication, and block and file asynchronous replication. It is highly suggested to create a new snapshot and replicate it to the destination just before deleting the replication session. Creating the snapshot with No Automatic Deletion policy is also suggested. For synchronous replication, only the latest 21 snapshots on a resource are searched for a common base, therefore it is also suggested to delete and recreate the sessions as soon as possible. Once the replication session has been recreated and is active, the snapshot can be deleted.
In the following example, an asynchronously replicated NAS Server and file system are being transitioned to a synchronous replication configuration. Full copy avoidance can occur as long as a common base snapshot is available. When creating the replication session on the NAS Server, the Reuse destination resource and Automatically search user snap as common base options are available. Figure 70 below shows an example of these options on the Replication Settings step within the Create a Session wizard.
In Figure 71 below the Destination step is shown. Enabling the Reuse destination resource option will automatically search the destination system and establish replication to an existing resource if the Name entered on this step matches one on the destination. In this example, the system will search for existing NAS Servers on the destination with the name TEST. If a NAS Server named TEST exists on any Pool within the destination system, replication will be established to the resource. If a resource with the same name is not found, the resource will be created based on the configuration on the Destination step. This is also true for file systems and NFS datastore on the NAS Server, and other resource types.
When replication is configured on a NAS Server, replication is automatically configured for file systems and NFS datastores on the NAS Server. When the Automatically search user snap as common base option is enabled, snapshots on the source and destination file resources will be searched for a snapshot with a matching ID. If a match is found that resource will use the latest matched snapshot as a common base. Only data that has changed on the source since the snapshot was created will be copied to the destination. This comparison will occur for each file system or NFS datastore on the NAS Server. For tracking purposes, the Logs page in Unisphere will have an entry for each storage resource if a common base snapshot was found or not.
If replication needs to be deleted and recreated on a file system or NFS datastore, similar options on the Replication Settings page for the NAS Server are available. Figure 72 below shows the Replication Settings step within the Create a Session wizard for a file system. Here the Reuse destination resource and Automatically search user snap as common base options are available directly on the resource.
For Block resources the Reuse destination resource and Automatically search user snap as common base options are available. The Overwrite Destination option is also available. If this checkbox is selected the entire contents of the destination resource are overwritten with data from the source. This option can be used when the source resource has been restored to a previous point in time, and the destination must be completely replaced. Figure 73 below shows an example of this window.
With the enhancements in the 5.1 release, changing File replication topologies with advanced File replication is possible. One example is if replication is configured in an Aà B à C cascade configuration. If snapshots are created on System A and replicated to System B and System C, they can be used as common base when recreating replication sessions if required. As shown in the figure below, System B can easily be removed from the configuration as common base snapshots can be leveraged to create replication directly from System A to System C. These snapshots would reduce the amount of data that needs to synchronize between the source and destination.
Common base snapshots can also be used to recover from an unplanned failover event. Using common base snapshots may help reduce the amount of data that needs to be synchronized between the source and destination after the Failback or Resume option is initiated. An unplanned failover occurs when the Failover option is issued on the replication session for a destination resource. When this occurs, a disaster situation is assumed, and the destination resource becomes Read/Write. If management connectivity is still available between the source and destination systems, the source will automatically be made unavailable or Read-Only depending on the resource type. Common base snapshots and full copy avoidance is not available for block synchronous replication sessions.
Some customers require regular failover testing to ensure their disaster recovery operations are functional. When Failover is issued from the destination of a file synchronous replication session, a full synchronization of data is required when re-establishing the replication session. With the enhancements in UnityOS version 5.1 and later, common base snapshots can help reduce the overall recovery time. It is highly suggested to create a new snapshot and replicate it to the destination on all resources involved just before issuing Failover on the replication session. As mentioned previously, only the latest 21 snapshots on a file synchronous replication session are searched for a common base.
To confirm a common base snapshot is present on a file synchronous replication session, the uemcli /prot/rep/session/commonbase command can be utilized. This command will search the source and destination resources and determine if a common base snapshot is present. This command should be run on the active replication session before issuing the Failover operation. If the command is run on a NAS Server, the outputs for all file systems and NFS datastores will be displayed. This command can also be run directly on a file system or NFS datastore replication session.
As shown below, common base snapshots were found for the first replication session, but not the second. The Session ID shown can be used to locate the resource if required. If the Failover operation was issued while in this state, the first session would use snapshots to establish a common base, while the second session would require a full synchronization of data.
uemcli /prot/rep/session/commonbase -sessionName rep_sess_nas_2_nas_9_APM01204908035_APM00211114469 show
1: Session ID = 171798691855_APM01204908035_0000_171798692131_APM00211114469_0000
Source common base snapshot ID = 171798691873
Destination common base snapshot ID = 171798692191
2: Session ID = 171798691889_APM01204908035_0000_171798692338_APM00211114469_0000
Source common base snapshot ID = (No common base snapshot)
Destination common base snapshot ID = (No common base snapshot)
For asynchronous block and file replication sessions, the internal system snapshots created by asynchronous replication can be used to recover after an unplanned failover event. In Dell UnityOS version 5.1 and later, replicated user snapshots can also be utilized. If for any reason the asynchronous replication snapshots are unavailable, the user created and replicated snapshots can be used to establish common base and avoid a full copy of data. This is also true for asynchronous replication sessions that are part of a MetroSync (file synchronous replication) solution.