Replication Actions

You can exercise native replication control operations from Dell storage arrays by performing “Actions” on the replicated group of volumes using the DellCSIReplicationGroup object.

You can patch the DellCSIReplicationGroup Custom Resource and set the action field in the spec to one of the allowed values (refer to tables in this document).

When you set the action field in the Custom Resource object, the following happens:

  • State of the RG CR is set to action_in_progress. For e.g. if you set the action field to SYNC, then the state will change to SYNC_IN_PROGRESS, action field will reset to empty
  • dell-csi-replicator sidecar issues the command to the CSI driver to perform the appropriate action
  • Once the CSI driver has completed the operation, State of the RG CR goes back to Ready

While the action is in progress, you shouldn’t update the action field. Any attempt to change the action field will be rejected and it will be reset to empty. There are certain pre-requisites that have to be fulfilled before any action can be done on the RG CR. For e.g. - you can’t perform a Reprotect without doing a Failover first. There are some “Workflows” defined in Section 2 of this document which provide a sequence of operations for some common use-cases. An important exception to these rules is the action UNPLANNED_FAILOVER which can be run at any time.

Note - Throughout this document, we are going to refer to “Hopkinton” as the original source site & “Durham” as the original target site.

Site Specific Actions

These actions can be run at any site, but they have some site-specific context included.

Any action with the LOCAL suffix means, do this action for the local site. Any action with the REMOTE suffix means do this action for the remote site.

For e.g. -

  • If the CR at Hopkinton is patched with action FAILOVER_REMOTE, it means that the driver will attempt to Fail Over to Durham which is the remote site.
  • If the CR at Durham is patched with action FAILOVER_LOCAL, it means that the driver will attempt to Fail Over to Durham which is the local site.
  • If the CR at Durham is patched with REPROTECT_LOCAL, it means that the driver will Re-protect the volumes at Durham which is the local site.

The following table lists details of what actions should be used in different Disaster Recovery workflows & the equivalent operation done on the storage array:

Workflow Actions PowerMax PowerStore PowerScale
Planned Migration FAILOVER_LOCAL
FAILOVER_REMOTE
symrdf failover -swap FAILOVER (no REPROTECT after FAILOVER) allow_writes on target, disable local policy
Reprotect REPROTECT_LOCAL
REPROTECT_REMOTE
symrdf resume/est REPROTECT enable local policy, disallow_writes on remote
Unplanned Migration UNPLANNED_FAILOVER_LOCAL
UNPLANNED_FAILOVER_REMOTE
symrdf failover -force FAILOVER (at target site) break association on target

Maintenance Actions

These actions can be run at any site and are used to change the replication link state for maintenance activities. The following table lists the supported maintenance actions and the equivalent operation done on the storage arrays

Action Description PowerMax PowerStore PowerScale
SUSPEND Temporarily suspend
replication
symrdf suspend PAUSE disable local policy
RESUME Resume replication symrdf resume RESUME enable local policy
SYNC Synchronize all changes
from source to target
symrdf establish SYNCHRONIZE NOW start syncIQ job

How to perform actions

We strongly recommend using repctl to perform any actions on DellCSIReplicationGroup objects. You can find detailed steps here

If you wish to use kubectl to perform actions, then use kubectl edit/patch operations and set the action field in the Custom Resource. While performing site-specific actions, please consult each driver’s documentation to get an exhaustive list of all the supported actions.

For a brief guide on using actions for various DR workflows, please refer to this document