Replicating a consistency group
The consistency group is replicated as a whole. The replica is comprised of a source consistency group and a target consistency group. All of the consistency group's members are replicated, and the replica state of the consistency group abides all of its members.
The replica RPO
For instructions on how to set the RPO, see: How to set the replica RPO and interval.
The RPO (Recovery Point Objective) is the maximum time the replica is allowed to lag. The RPO is configured with another parameter - the Sync Interval. The RPO has to be greater than the Sync Interval and the sync job is expected to be completed prior to the completion of the Sync Interval. The best practice is to set the RPO to be twice the time of the Sync Interval.
The RPO is measured in seconds.
- RPO OK – The lag between the source and target < RPO
- RPO LAGGING - The lag between the source and target > RPO
- N/A – RPO not set
The system creates events for changes to the RPO status.
Adding a member to a replicating consistency group
As the consistency group always has all of its members replicated (or all of them not replicated), adding a member to a consistency is available according to the following guidelines:
- It is OK to add a non-replicating dataset to a non-replicating consistency group
- it is impossible to add a replicating member to a non-replicating consistency group.
Adding a member to a replicating consistency group is done by adding a source member to the source consistency group and instructing the replica to either add a target member to the target consistency group or to create a target member to a non-replicating member that is added to the source. The instruction is provided to the source system, where the Adding a Member operation takes place.
The consistency group settings (interval and RPO) are imposed on the added member.
Impact on the consistency group state
The added member undergoes initialization upon the next sync job. This causes the entire consistency group to undergo an initialization. A replicating consistency group is usually in either replicating or idle state. Adding a member to the consistency group forces the entire consistency group to yield to an initializing state. This state is imposed on the consistency group even if all of its members (but the new addition) are synchronized with the target.
A consistency group that is in initialization state cannot have its role changed in case of a disaster recovery. In order to change the role of the consistency group, the initializing member has to be removed - losing any advancement in replicating to the target member - in order to move the consistency group out of the initializing state and allow the role change.
It is advised to consider this implication prior to adding the new member to the consistency group. It might prove useful to replicate this member separately - prior to adding it to the consistency group - and only when it is synchronized with the target, to add it to the consistency group (as well as add its target to the target consistency group).
Removing a member from a replicating consistency group
Removing a member from the consistency group removes the source member from the source consistency group, removes the target member from the target consistency group, and - optionally - retains the replica between the source and target member. If instructed by the user to be retained, the replica of the removed dataset keeps the settings (interval and RPO) and the state (synchronized, not-synchronized) of the consistency group. It is possible to remove a member out of a consistency group regardless of the state of the consistency group.
Capacity and throughput reporting
- The system reports the capacity consumption of the replication snapshots
- The system reports the throughput of replica that is currently replicating