Protection policies with replication rules

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:

1. The initial synchronization is completed successfully within the 30-minute RPO window, and the first schedule RPO synchronization cycle begins.

2. An RPO snapshot for the second regular replication cycle is performed at 11:00, and the synchronization finishes successfully within 30 minutes. The replicated snapshot meets the RPO target by 12:00.
3. The next replication cycle at 11:30 is not finished replicating to the target after reaching the 12:00 limit for the 11:00 RPO schedule (step 2). The 12:00 scheduler event is skipped, and an RPO compliance alert is raised at 12:05.
4. When the 11:30 replication finishes at 12:10, the RPO target is achieved again until 13:10. Since the raised alert needs at least one successful replication within the timeframe to be cleared, the alert remains active until it is cleared. In our example, the alert is cleared after the 12:30 replication finishes at 13:00.

Figure 20.    Replication scheduler events at 30-minute intervals for a 1-hour RPO

Replication session

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:

• All writes to a storage resource are saved to the source storage resource and acknowledged to the host before being replicated to the destination storage resource. Changes are retrieved using a snapshot-differential operation and are replicated later.
• A user-defined RPO defines the maximum time between scheduled synchronizations.
• Between synchronizations, new data is only saved on the source storage resource. The RPO is the maximum amount of data measured in time that the user is willing to lose in a disaster or failure scenario. The RPO determines how often synchronizations occur at a minimum.
• Manual replication between RPOs operates the same as scheduled 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.

1. When a replication session is created on a storage resource, a read-only internal RPO1 snapshot on the source system is created. On the destination system, a storage resource with same characteristics is created with an associated shadow read/write snapshot.

2. Data is replicated from the source RPO1 snapshot to the newly created destination shadow read/write snapshot. This replication is the initial synchronization of the source and destination storage resources and is a full copy of all the data.
3. When the remote read/write shadow snapshot is synchronized with the local RPO1 snapshot, an RPO1 snapshot is triggered on the destination. The RPO1 snapshots that are on the source and destination storage resources contain the same information and represent the point when the synchronization started. Snapshot RPO1 on each system is now a common base for the replication session. The remote storage resource is refreshed from the RPO1 snapshot, and the initial synchronization is completed.
4. Over time, the host application writes new data to the source storage resource.
5. The next update is either manually started or by the RPO with asynchronous replication. During the update, a new RPO2 snapshot is triggered to reflect the current, point-in-time view of the source storage resource. All changes that were made since the last update of the destination are copied to the destination shadow read/write snapshot.
6. After the incremental copy is complete, an RPO2 snapshot on the destination is created. This snapshot defines the new common base, and the remote storage resource is refreshed from that base.
7. Because the old, common-base compound of RPO1 snapshots on the source and destination are not relevant for upcoming replication cycles, the RPO1 snapshots are deleted. Only the RPO2 snapshots and shadow read/write snapshots remain.

Figure 21.    Asynchronous replication theory

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:

• Volumes
• Thin clones
• Volume groups
• NAS servers
• File systems

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.