Home > Storage > Unity XT > Storage Admin > Dell Unity: NAS Capabilities > Remote protection
Remote protection provides business continuity by copying the data to a remote system, enabling data access in situations where the primary system is no longer accessible. Dell Unity supports both synchronous (MetroSync) and asynchronous replication for file and block resources.
In situations where one system is running a newer version of OE than the other, replication is supported. However, if there is a new feature that is in use but is not available on the peer system, the replication session may not be supported and may fail to configure. For existing replication sessions, you may be prevented from enabling some of these new features. Some examples of this include CEE CEPA, IP multi-tenancy, and the folder rename and locking policies. In these situations, upgrade the older system to be on the same OE as the newer system before configuring replication.
In certain situations, such as after an unplanned failover or when switching replication modes, a full copy is required to sync the data and start replication. Starting with OE version 5.1, MetroSync and asynchronous replication can avoid a full synchronization by leveraging snapshots. The systems attempt to locate a system, user, or scheduled read-only snapshot that exists on both the source and destination. If one is available, a shared common base is established and only deltas need to be copied. To leverage this feature, both the source and destination system must be running OE version 5.1 or later. When configuring a replication session, there are checkboxes Reuse destination resource and Automatically search user snap as common base, as shown in the figure below.
For more information about replication full copy avoidance, reference the Dell Unity: Replication Technologies white paper on Dell Technologies Info Hub.
MetroSync is available on systems running OE version 4.4 or later. This feature provides the ability to create remote synchronous replication sessions for file storage resources including NAS servers, file systems, and VMware NFS datastores. Synchronous replication is a zero-recovery point objective (RPO) data protection solution which ensures each block of data stored locally is also saved to a remote image before the write is acknowledged back to the host. This ensures that in the event of a disaster, there is zero data loss. In synchronous replication solutions, there are trade-offs. As each write needs to be saved locally and remotely, added response time occurs during each transaction. This response time increases as distance increases between remote images. Synchronous replication has a distance limitation based on latency between systems. This limitation is generally 60 miles or 100 kilometers between sites. To support synchronous replication, the latency of the link must be less than 10 milliseconds.
Synchronous replication uses the first Fibre Channel (FC) port on the system to replicate both the NAS server and file system data. The synchronous replication management virtual port is used to send management and orchestration commands between systems. Since there is no Fibre Channel support on Dell UnityVSA systems, synchronous replication cannot be configured on the virtual storage appliance.
Synchronous replication requires two separate physical Dell Unity systems, meaning it cannot be used to replicate file resources locally within the same system. Both the source and the destination systems must be running OE version 4.4 or later to support synchronous replication.
To synchronously replicate a file resource, the associated NAS server must be synchronously replicated first. After this is configured, synchronous replication can be configured on its associated file systems. When MetroSync is configured, the following functionality is also available:
In OE version 4.5, MetroSync Manager is available. This is an optional Windows application that monitors the systems participating in synchronous replication for critical failures, such as a power outage. If a failure is detected, MetroSync Manager initiates a cabinet level failover to simultaneously failover all synchronously replicated NAS servers and their file systems to the peer system in parallel. Without MetroSync Manager, manual intervention is required to initiate the failover process which could lead to periods of data unavailability.
Under normal circumstances, the SP owner of the NAS server should match on both the source and destination systems. If there is a SP ownership mismatch, MetroSync temporarily pauses the synchronization, keeps track of the changed blocks, and continues synchronization once the mismatch is corrected. Starting with OE version 5.1, file synchronous replication can continue even when SP ownership is different. When the destination system detects file synchronous replication I/O arriving on the wrong SP, it leverages an internal redirect to continue replication. To leverage this functionality, only the destination system needs to be running OE version 5.1 or later. It is not recommended to maintain a mismatched configuration long-term as this can impact performance. When this is detected, Unisphere displays a warning and it is recommended to investigate the underlying cause of the mismatch.
Certain operations cannot be replicated when there is an SP ownership mismatch. If the source resource is resized by the administrator or auto extended by the system, the resize operation cannot be replicated and the sessions changes to a “Syncing” state. In this state, the source is actively attempting to sync the resize operation to the destination but is unable to complete. The resize operation and any subsequent changes on the source become queued and are synchronized once the session returns to a healthy state. The “Syncing” state enables the session to continuously retry and automatically start syncing as soon as the SP ownership mismatch is corrected. Also, any snapshot operations such as create, refresh, and delete are not synchronized while in this state. These snapshot operations are not retroactively updated after the session returns to a healthy state.
For more information about Dell Unity MetroSync and MetroSync Manager, reference the Dell Unity: MetroSync white paper on Dell Technologies Info Hub..
Asynchronous replication is primarily used to replicate data over long distances, but also can be used to replicate file resources between pools within the same system. Asynchronous replication does not impact host I/O latency as host writes are acknowledged once they are saved to the local storage resource. Because write operations are not immediately replicated to a destination resource, all writes are tracked on the source. This data is replicated during the next synchronization.
Asynchronous replication introduces the concept of a recovery point objective (RPO). RPO is the acceptable amount of data, measured in units of time, which may be lost due to a failure. This delta of time also affects the amount of data which needs to be replicated during the next synchronization, and the amount of potential data loss if a disaster scenario were to occur.
By leveraging the unified snapshots technology to preserve point-in-time file and block data, Dell Unity can provide unified local and remote asynchronous replication using the same technology for file and block resources. Dell Unity supports asynchronous replication down to a 5-minute RPO for NAS servers and their file systems.
Asynchronous Replication is supported on all Dell Unity systems for both file and block resources. The supported systems include the All Flash models, the Hybrid models, and the Dell UnityVSA.
Prior to OE version 5.0, there can only be a single source system and single destination system for a given file resource. However, there could be multiple resources on a single system replicating to different target systems as shown in the figure below.
With the release of OE version 5.0, asynchronous replication can be configured in advanced topologies. This allows for configurations such as fan-out and cascading replication at the file resource level along with the corresponding NAS server. These configurations give the ability to replicate and store the same dataset on multiple systems provides additional data protection and enables use cases such as content distribution. This feature does not support synchronous replication and is not available for block resources.
To use this feature, all systems in the topology must be running OE version 5.0 or later. Although, replication between OE 5.0 and 4.x is still supported in a one-directional configuration. Aside from that, this feature is available on both physical and virtual Dell Unity systems. The following advanced topologies are supported:
File resource level:
One-directional
Fan-out
Cascade
Mixed
In the figure below, a topology has been constructed that showcases both cascade and fan-out replication configurations.
When configuring asynchronous replication sessions on file systems and NFS datastores, a checkbox is available to Support Asynchronous Snap Replication. Starting with OE version 5.1, snapshot replication can be enabled on all sessions in fan-out and cascaded asynchronous replication configurations. Previously, this was limited to just one session in the topology. This release also adds a new checkbox called Cascade replicated snapshots. When the cascade box is checked, any snapshots that are replicated to the middle system are also cascaded to the third system. The figure below shows the asynchronous snap replication options when creating a new asynchronous replication session.
Dell Unity provides the ability to perform operations such as failover, failback, pause, and resume on individual NAS servers and file systems. For example, to initiate a failover, you must first fail over the NAS server and then fail over the individual file systems afterwards to enable access on the destination system. OE version 4.2 includes an enhancement that enables group operations. The group operation automatically fails over all the associated file systems if a failover is initiated on the NAS server. Group operations can be used for failover, failover with sync, failback, pause, and resume. These operations remain available at the individual file system level, but any operation applied at the NAS server level is a group operation. All other replication related operations such as create, sync, delete, and modify remain available only as individual operations. The figure below shows the failover group operation.
The NAS server and file systems’ replication sessions must be in a healthy state for group operations to properly function. If a NAS server replication session is in a paused or error state, all group operations are prohibited. If any of the associated file system replication sessions are in a paused, error, or non-replicated state, the group operation skips those sessions and an alert is generated. Also, do not perform a group operation at both sides of a replication session at the same time. This action is not prohibited by the storage system, however, a group operation performed at the same time at both sides of a replication session can cause the group replication session to enter an unhealthy state.
To minimize downtime during a failover with sync group operation, it is recommended to perform a manual sync on the NAS server and all associated file systems before starting the group operation. The manual sync operation performs an incremental update so that most changes are replicated to the destination. Wait until all the sync operations are complete prior to starting the failover with sync operation. Because of the previous incremental sync, any remaining deltas are small, which enables the failover with sync group operation to finish quickly and for downtime to be minimized.
OE version 4.2 also includes the ability to replicate file and block snapshots along with the primary storage resource. Some benefits include the ability to configure a different retention policy on the destination for compliance purposes, improving cost efficiency by freeing up capacity from snapshots on the source system, and improvising resiliency by storing snapshots in a different fault domain. This feature requires both the source and destination system to be running OE version 4.2 or later. Snapshot replication from OE version 4.4 or earlier to OE version 5.0 is not supported, it is recommended for users to first upgrade to OE version 4.5 to replicate to a version 5.0 system. Also, an asynchronous replication session must be created on the primary storage resource. This feature can be enabled during creation of the replication session or at any time afterwards.
This feature works with both manually initiated and snapshots taken by the integrated snapshot scheduler. A replicated snapshot retains the same properties and attributes as the source snapshot. This includes the name, description, creation time, taken by, and so on. For file snapshots, only read-only snapshots are eligible for replication. Read/write snapshots that are used for shares and exports cannot be replicated.
For more information about Dell Unity native asynchronous replication, reference the Dell Unity: Replication Technologies white paper on Dell Technologies Info Hub.
OE version 4.3 includes support for read-only proxy NAS servers. This provides the ability to access all the file system and snapshot data on the destination NAS server through SMB and NFS. There is no ability to write to the file systems or snapshots using the proxy NAS server, even if the snapshot is read/write.
The figure below shows the proxy NAS server configuration.
This feature works with both asynchronous and synchronous replication. Although it may be possible to directly access the file system data using the proxy NAS server, it is recommended to use this feature to access data residing on snapshots. This is since the destination file system is still being actively replicated. For asynchronous replication, there may be instances where the destination file system becomes temporarily unavailable due to a replication sync. For synchronous replication, the destination file system is not fully mounted and is not accessible.
Each proxy NAS server can be configured to provide access to one or more NAS servers’ data. All the NAS servers’ file systems and their snapshots are displayed when connecting to the proxy NAS server as shown in the figure below. Due to this, the user must be part of the local administrators group for SMB or root for NFS to access the data.
To create a proxy NAS server, create a new NAS server on the system with an interface, the appropriate protocols, and configure the appropriate services such as DNS and LDAP. The new proxy NAS server should be configured the same way as the NAS servers that it is providing access to such as protocols, tenants, and so on. The new proxy NAS server must reside on the same SP as the NAS server that it will be providing access to.
To designate the new NAS server as a proxy NAS server, a CLI service command must be used. SSH in to the system and run the svc_nas <Proxy_NAS_Server> -proxy –add <Target_NAS_Server> command where <Proxy_NAS_Server> is the name of the new proxy NAS server you just created and <Target_NAS_Server> is the name of the destination NAS server you want users to access. For NFS access, also include –NFSRoot <Allowed_Nodes> option to specify the nodes that should have access over NFS. To view the proxy NAS server configuration on the system, run the svc_nas ALL -proxy –show command.
For example, run svc_nas Proxy_NAS_Server -proxy -add NAS_Server -NFSRoot ip=10.10.10.10 to configure the proxy NAS server for NFS access and limit access to client IP 10.10.10.10. Run mount Proxy_NAS_Server:/NAS_Server /mnt on the host that is provided access or \\Proxy_NAS_Server\NAS_Server from a SMB client to mount the proxy NAS server and view the contents.
For more information about configuring Proxy NAS servers, reference the Dell Unity: DR Access and Testing document on Dell Technologies Info Hub.
OE version 4.5 introduces the ability to create SMB shares for writable and read-only snapshots on the destination NAS server. This feature is designed to enable DR testing without any impact to the ongoing replication session. It allows customers to confirm that an application can be brought online and write to a share hosted on the destination system. This feature works with both asynchronous and synchronous replication. This feature leverages a proxy NAS server and proxy share created on the destination system to provide access to the snapshot, as shown in the figure below.
In contrast to the read-only proxy NAS server feature, this feature allows any domain user to access the share and is not limited to Administrators or root. This is because each share points to a specific snapshot, as opposed to the entire contents of the NAS server. The proxy share can be configured to point to either a RO or RW snapshot that exists on the destination file system. If a RW snapshot is selected, then the client can write to the share.
To configure a proxy share, a new proxy NAS server must be created on the destination Dell Unity system. The NAS server must reside on the same SP it is providing access to and must be joined to the same SMB domain as the destination NAS server. If these requirements are met, a single proxy NAS server can be used to access data on one or more destination NAS servers.
Once the proxy NAS server is configured, SMB shares can be created for snapshots. These special proxy SMB shares can only be configured and managed by using the svc_nas command. Once created, these shares are not visible through normal interfaces such as Unisphere, UEMCLI, or REST API. These shares also do not count towards the system limits and there is no hard limit on how many proxy SMB shares can be created.
To create a proxy SMB share, use the svc_nas <Proxy_NAS_Server> -proxy_share -add <Target_NAS_Server> -share <Share_Name> -path <Snapshot_Path> command, where:
For example, svc_nas Proxy_NAS_Server –proxy_share –add Prod_NAS_Server –share FS –path /UTC_2018-09-13_15:31:25. Once this is created, any domain user can access the snapshot by mapping the UNC path \\Proxy_NAS_Server\FS, as shown in the figure below.
For more information about configuring SMB proxy NAS shares, reference the Dell Unity: DR Access and Testing document on Dell Technologies Info Hub.
When using replication, the interfaces and services on the destination system can be configured with overridden IP addresses. This enables the use of separate IP addresses if there is a failover to the DR site. These can be pre-configured on the DR NAS server, so production can resume as soon as the failover process is complete. This is important for customers that have different network schemas between their production and DR sites. In addition, backup and test interfaces can also be configured on the NAS server to enable NFS access for backup and DR testing purposes. These interfaces can be active on either the source or the destination NAS server, but they are not replicated in the replication session.
When replicating from one system to another, it is important to ensure the port configuration matches on both systems. If link aggregation and/or FSN are used, ensure the link aggregation and/or FSN also exists on the destination system. If the specified port, link aggregation, or FSN is not found on the destination system, the interfaces on the destination NAS server are created without a port assignment. You must then override the IP addresses on the destination NAS server to assign them to a valid port. Otherwise, data access becomes unavailable in the event of a failover.