vVols Replication Operations

API Call

Operation and Explanation

SyncReplicationGroup_Task()

Operation: Synchronize Replication Group

Purpose: To tell a replication group to synchronize from its source group. You can specify a name to also indicate a point-in-time to reference later.

Use Case: Useful for creating quiesced or special failover points.

You issue this against a target replication group—it will then return a task. When the replication to that fault domain is complete, the task will return completion.

What VASA Does: VASA on the Target FlashArray triggers an on demand snapshot to be replicated from the source FlashArray to the Target FlashArray.

For example: purepgroup snap --replicate-now --on source-fa-name source-pgroup-name

This allows the command to correctly be issued against the target replication group. VASA will add a suffix to these snapshots named "VasaSyncRG" followed 6 random letters/numbers. This is an async task and VASA will return a task ID to vCenter for this async task.

TestFailoverReplicationGroupStart_Task()

Operation: Test Failover Start

Purpose: This initiates a target replication group to present writable vVols of the VMs in a replication group to the target side. This can be issued without a point-in-time (using the latest version) or a specified point-in-time.

Use Case: Testing your recovery plans without affecting production.

A test is run against a target replication group. This changes the target replication group from the TARGET state into the INTEST state.

What VASA Does: VASA on the Target FlashArray starts the workflow of grabbing the most recent snapshot for the target replication group. Then, VASA copies out all of the volumes from the snapshot on the target FlashArray. The correct volume groups will be created and the config and data vVols will be placed in the correct vgroups.

In addition to copying out the volumes from the snapshot, VASA will create a pgroup with the same replication schedule/settings as the source replication group if this is the first time that the replication group has had a testFailover or Failover ran. If there has previously been testFailover or Failover ran on the target Replciation Group VASA will attempt to reuse the pgroup that was created in that process. If that pgroup was destroyed or if additional unknown volumes were added to the pgroup VASA will treat the testFailover as the 1st one and create a new pgroup.

In the event that the testFailover is being ran after a successful Failover and re-protect, VASA will first attempt to reuse the vgroups, volumes and pgroup when copying out the volumes from the snapshot. In the event that the pgroup has been destroyed or has been edited, VASA will create a new pgroup and will not reuse the existing vgroups and volumes.

After the volumes are copied out, all of the metadata associated with these vVol VMs are updated for the new storage container and VASA provider as needed. The files are then accessible from the target vVol storage container. Once the job is complete, the updated .vmx filepaths are returned. The VMs must be registered as part of an independent task from this API.

Here is a look at browsing the vVol Datastore on the Target vCenter/FlashArray after a testFailoverStart has completed.

Here is a look at browsing the vVol Datastore on the Source vCenter/Array. We can see the Files and paths for the source compared to how they show up on the Target.

TestFailoverReplicationGroupStop_Task()

Operation: Test Failover Stop

Purpose: This ends a test failover and cleans up any volumes or created VMs on the target side.

Use Case: Ending a test failover and cleaning up the storage provisioned for it.

A test stop is run against a target replication group that is in the INTEST state. This reverts it back to the TARGET state.

What VASA Does: VASA will destroy and eradicate the copied out volumes and vgroups that were created for the test. Note that a volume can not be destroyed if it is connected to a host. If existing binds exist, the stop task will fail. Once all the volumes and vgroups have been destroyed and eradicated the replication group be updated back to Target State.

Here is a look at the vVol Datastore on the Target after the testFailoverReplicationGroupStop has completed:

Notice that none of the VM Files exist. Please note that the VMs should be powered off and unregistered before running this API.

Otherwise the testFailoverReplicationGroup would fail to start and complete. This would be due to binds existing on these vVols.

PromoteReplicationGroup_Task()

Operation: Promote Replication Group

Purpose: In the case of a disaster during a test recovery, this allows you to specify VMs that are in the test state to become the production VMs.

Use Case: Loss of source site VMs during a test recovery.

This is executed against a target replication group in the INTEST state and converts the state to FAILEDOVER.

Note that running this will cause any attempt to run test failover stop to fail.

What VASA Does: When testFailoverReplicationGroup is run against a Target Replication Group, the Replication Group state is changed from Target to INTEST. When running a PromoteReplicationGroup on an INTEST Replication Group VASA will update the state of the Replication Group to FAILEDOVER. This then allows the ReverseReplicationGroup call to be issued to update it to Source.

PrepareFailoverReplicationGroup_Task()

Operation: Prepare Failover

Purpose: This synchronizes the replication group to a fault domain. The target replication group will no longer accept syncReplicationGroup operations.

Use Case: Doing a final synchronization before a failover.

This is issued to the source replication group, so it is really only useful for planned migrations.

It is not recommended for a test failover, just actual failovers.

FailoverReplicationGroup_Task()

Operation: Failover

Purpose: To run a migration or a disaster recovery failover of VMs in a replication group.

Use Case: Disruptively moving VMs in a replication group from one array to another for a DR event or a planned migration.

This is run against a target replication group and changes the state from TARGET to FAILEDOVER.

What VASA Does: This process is similar to the testFailover, in that the most recent snapshot (or PiT if specified) has the volumes copied out and updated on the target FlashArray (fault domain).

The difference here is that the target replication group has it's state updated to FAILEDOVER and not INTEST. Meaning that a ReverseReplicationGroup can be issued once the Failover task has completed.

In addition to copying out the volumes from the snapshot, VASA will create a pgroup with the same replication schedule/settings as the source replication group if a testFailover has not been ran and this is the first time a Failover has been ran.

If there has previously been a testFailover or Failover run on the target Replication Group, VASA will attempt to reuse the pgroup that was created in that process. If that pgroup was destroyed or if additional unknown volumes were added to the pgroup, VASA will treat the Failover as the first time and create a new pgroup.

VASA does not destroy or eradicate the source volumes, vgroup and pgroup for the VMs that are failed over as part of this replication group. In the event that a testFailover is ran, those volumes, vgroups and pgroup will be reused and then destroyed when the testFailover is cleaned up. If a Failover is ran before a testFailover is ran, then VASA will attempt to reuse the vgroups, volumes and pgroup when failing over to the target.

Please note that the API does not power off or unregister the VMs at the source vCenter/FlashArray; nor do the recovered VMs get registered in the recovery vCenter Server. This must all be done by the end user.

ReverseReplicateGroup_Task()

Operation: Reprotect

Purpose: Makes a failed over group a source that replicates back to the original source.

Use Case: Ensures that your VMs are protected back to the original site.

Run against a FAILEDOVER replication group and changes its state to SOURCE.

This is not necessarily required—you can also just apply a new storage policy to the VMs to protect them. This is only needed to reset the state of the original target group.

What VASA Does: VASA will initiate a snapshot replication from the pgroup that the copied out volumes have been added to. Once this snapshot has completed, the replication schedule is enabled and the replication group's state is updated from FAILEDOVER to Source.

The ReverseReplicationGroup does not re-apply storage policies or assign replication groups in SMS/vCenter. In order to complete the re-protect process, the end user will need to reset the storage policy to vVols No Requirements and then apply the storage policy on the new protected site and the correct replication group.

QueryReplicationGroup()

QueryPointInTimeReplica()

QueryReplicationPeer()

Operation: Queries

Purpose: Retrieve state of replication environment.

Use Case: Used to script/detect state of replication, available point-in-times, and status of a group.

These can be run against most types of groups to find out the state of replication.

What VASA Does: For each query, VASA will check the metadata and tags for each of the associated requests. Then returns the results of the request.