Remote replication between PowerStore systems relies on a remote system configuration and uses policy-based protection. A replication rule defines the remote system and replication cycles for the asynchronous replication. 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 and up to four snapshot rules.
The replication rule defines the parameter for the asynchronous 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, RPO, and alert threshold for the planned replication session. Once 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 internal event scheduler for recurring replication of the storage resource.
To minimize the chance of RPO compliance issues, 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 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 20 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 individual RPO schedules for each storage resource in that replication session. Scheduled or manual user snapshots of block storage resources in a replication session are also replicated in chronological order to the destination during initial and continuous synchronizations. 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 an asynchronous replication session is created, and before the 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 21 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.
In PowerStore, native asynchronous replication is supported on the following storage resources:
Asynchronous replication operates in the same way for volumes, volume groups, thin clones, and file resources on PowerStore. When asynchronous 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 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 sync.
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. This behavior means that a single replication session is created for the entire volume group no matter how many volumes it contains. 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. When replication is paused or resumed on a volume group, the replication operation affects the entire group. Select the Write consistency order option for the volume group to have a consistent replica at the volume-group level.
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.