Home > Storage > PowerStore > Data Protection > Dell PowerStore: Replication Technologies > Theory of operation
Remote replication between PowerStore systems relies on a remote system configuration and uses policy-based protection. Protection policies allow the user to configure remote and local protection using replication rules, snapshot rules, or remote backup rules. The policies combine one or more rules to fulfill the protection requirements for a storage resource on PowerStore. A protection policy must contain at least one protection rule, regardless of whether it is a local or remote protection rule. Each protection policy can contain up to one replication rule, up to four snapshot rules and up to one remote backup rule. A remote backup rule can only be combined with snapshot rules and an asynchronous replication rule.
Volume replication type | Snapshots | Asynchronous replication | Synchronous replication | Remote Backup |
Asynchronous replication | up to 4 | 1 | - | up to 1 |
Synchronous replication | up to 4 | - | 1 | - |
Metro volumes | up to 4 | - | - | - |
The replication rule defines the parameter for the replication on PowerStore and is set up on the source array. Even when the rule is synchronized to remote systems when it is added to a protection policy, it is not possible to edit a replication rule on the remote system. It is also not possible to view it in the replication rule overview in PowerStore Manager. The required information for creating a rule includes the partner remote system, replication type with RPO, and alert threshold for the planned replication session. A zero “0” RPO also indicates the native synchronous replication in PowerStore Manager. When a protection policy with a replication rule is assigned to a storage resource, the configured RPO in the rule is used to set up the replication. After initial synchronization, the replication session sets up a mirror from source to destination for synchronous replication. For asynchronous replication, the replication session sets up an internal event scheduler for the recurring replication of the storage resource, based on the RPO setting as defined in the replication rule.
To minimize the chance of RPO compliance issues in an asynchronous replication configuration, replication cycles are scheduled at 50% of the RPO value. For example, a one-hour RPO leads to a replication event every 30 minutes to provide enough overlapping to meet the target of a one-hour RPO. The scheduled RPO events for the following example are at x:00 and x:30 every hour. PowerStore optimizes the replication schedules to serialize the individual synchronization events. The events for the RPO are based on the configured RPO time and not on the amount of data that is written on the source storage resource.
Each storage resource can only have one active replication synchronization at a time. For example, the event scheduler cannot initiate a replication at a given time because replication is paused, or a previous replication has not finished. In this case, the schedule is skipped, and replication proceeds with the next planned replication.
The alert threshold defines the time when an alert is triggered after a target RPO is missed during continuous replication. There is no event that is triggered when the initial replication needs more time to complete. When a compliance alert is raised for replications using an RPO of more than five minutes, it is cleared when the next replication cycle finishes successfully.
The following steps and Figure 27 illustrate the workflow of a storage resource that is scheduled with a target RPO of one hour and an alert threshold of zero minutes:
Assigning a protection policy with replication rule to a storage resource creates the replication session. The replication session operates the scheduling and replication from the source resources to the target storage resources. When a replication session is created in PowerStore, a storage resource of the same size and type is created on the destination system. PowerStore creates an individual RPO schedule or a mirror for each storage resource in that replication session. When the replication session is set up, existing scheduled or manual user snapshots of block storage resources are also replicated in chronological order to the destination during initial synchronizations. Snapshots created while an asynchronous replication is set up are replicated in the next RPO cycle. Snapshots of file storage sources in a replication session are not replicated to the destination.
Asynchronous replication synchronizations are triggered by a user-defined RPO or at any time manually by the user. The following characteristics define asynchronous replication:
When a replication session is created, and before the mirror or incremental cycles begin, a full synchronization of the source and destination storage resource is automatically initiated. If replication is configured when a new storage resource is created, the synchronization is quick because no user data needs to be copied to the destination storage resource. If a protection policy with replication is added to an existing storage resource, a full synchronization is initiated from the source to the destination storage resource. Writes occurring during the initial-synchronization period are not copied to the destination storage resource but remain in the snapshot differential for the next synchronization cycle.
When the initial synchronization is completed, a common base is established between the source storage resource and the destination. Host-write operations that occur after the initial synchronization are acknowledged with the host, and no data is replicated to the destination until the next synchronization cycle. On any recurring cycle, a new snapshot is created and all changes between the current and previous snapshots are replicated to the destination. A new common base is then established. If another replication is still running, either manually triggered or by the RPO event scheduler, the replication is skipped.
Asynchronous replication in PowerStore uses snapshots to maintain the common base images explained previously. The following steps and Figure 28Figure 28 show how snapshots are used with asynchronous and manually triggered replication.
Each time the replication interval (half of the RPO setting) is reached or a manual update is started, the common base image updates with the latest RPO snapshots.
Snapshots that are used for asynchronous replication operate the same as user snapshots and are based on redirect-on-write technology. Although user snapshots and replication snapshots share the same technology, replication snapshots have use restrictions. Although replication snapshots can be viewed in the PowerStore REST API and PowerStore CLI, user operations such as restore operations are not allowed. Snapshots that are allocated for replication purposes do not count toward user-snapshot maximums.
For synchronous replication, the initial replication is similar up to the point where the common base is created. While asynchronous replication continues its replication based on the set RPO, additional steps are required to have the source and destination be in a continuous synchronized state.
After the empty destination volume and an internal writeable Shadow Snapshot is set up on the destination, the internal Shadow Snapshot gets all replicated data before being pushed to the destination volume. When destination and Shadow Snapshot are set up, the initial synchronization starts:
Because asynchronous replication and synchronous replication for block are using a common base, it is possible to change between replication types without a new full synchronization. Changing replication type for a NAS server (File replication) is not supported and requires a full synchronization after the change.
In PowerStore, native synchronous replication is supported on the following storage resources:
The replication operates in the same way for volumes, volume groups, thin clones, and file resources on PowerStore. When replication is configured on a volume in PowerStore Manager, a single replication session is created, and the destination storage resource is created with the same size and type as the source storage resource. When configuring a replication session on a thin clone, the destination storage resource is a regular volume and not a thin clone. While asynchronous replication is configured, the volumes and thin-clone size can be extended, and the changes are reflected on the destination storage resource after the next synchronization cycle. For synchronous replicated storage resources, it is required to pause the replication session first. All changes are replicated after the session resumes.
On PowerStore, a volume group is a storage resource that contains one or more volumes within a storage system. Volume groups help organize storage resources allocated for a particular host, hosts, or host groups. Volume groups are treated as a single entity when they are replicated. When replication is configured in PowerStore Manager for a volume group, the destination storage resource and its contents are created automatically. While a volume group is part of an asynchronous replication session, volumes within the volume group can be expanded. All changes to volumes within a volume group are reflected on the destination image after the next completed synchronization. Synchronous replicated volume group attributes and volume group members can be changed when the replication session is paused. Changes will be synchronized after the session is resumed. When replication is paused or resumed on a volume group, the replication operation affects the entire group.
There are two general operation models when using Volume Groups:
Note: Select the write-order consistency option for the volume group to have a consistent replica at the volume-group level.
The decision to enable write-order consistency is based on some considerations:
File system and NAS server replication sessions are created by assigning a protection policy with a replication rule to a NAS server. Once applied to a NAS server, the NAS server and all underlying file systems are replicated to the destination system. An individual replication session is created for each file system associated with the NAS server being replicated and for the NAS server itself. File replication can only be applied, managed, and removed at the NAS server level. It is not possible to modify the replication state at the individual file system level. Any file systems created or deleted from the NAS server automatically have a replication session created or deleted as applicable. While user operations and management for file replication are handled at the NAS server level, each file system has its own replication session. This is a key distinction between how a NAS server and file systems replicate compared to a volume group and its member volumes.