Dell PowerStore 3.0, Part2 – vVols Replication with VMware SRM

During Dell Tech World 2022, we announced PowerStore 3.0 and later on, I also covered the PowerStore Metro capabilities.

Dell PowerStore provides native solutions to protect data and help organizations meet business goals for both data availability and protection. PowerStore provides native asynchronous replication solutions that can replicate data to other systems, whether they are at the same site or a remote facility. Remote copies of data protect against outages on the main system. They also enable quick recovery on a destination system with minimal to no data loss depending on the replication method selected.

PowerStoreOS v3.0 is introducing asynchronous replication for vVol based VMs, this new release supports VASA 3.0 native storage based asynchronous replication for vVol based VMs. This feature uses VMware Storage Policies and requires VMware Site Recovery Manager instances in both sites. In traditional storage environments, volumes or file systems are formatted as VMFS or NFS datastores for VMs. Data services are applied at the volume or file-system level, which means all VMs that reside on that datastore are also affected. With vVols, VM data is stored on dedicated storage objects that are called storage containers, which become vVol datastores in vSphere. A VM consists of multiple vVols depending on its configuration and status. PowerStore works with vSphere to track which vVols belong to which VM

The configuration of asynchronous replication for vVol based VMs requires a remote system pair configured for two PowerStore clusters running PowerStoreOS 3.0 or later. Each of the PowerStore Clusters for vVol replication needs registration in vCenter as a storage provider and VASA 3.0 API is used to exchange information between PowerStore Cluster and the associated vCenter. The VMware Storage Policy which could be assigned to VMs in vCenter leverages the same replication rules in PowerStore Manager as used for other PowerStore asynchronous replications. Asynchronous replication for vVol based VMs use the same snapshot based async replication technology as native block replication which is described in section native asynchronous block replication.

The integration of SRM with vVols introduced the concepts of replication groups and fault domains, which the SRM integration builds on. A fault domain roughly translates to a site or an array replication pair. A replication group, also known as a consistency group, is made up of one or more VMs that are replicated in a consistent state. A vVol protection group can consist of one or more replication groups. All of a replicated VMs disks must belong to the same replication group.

Once a VMware Storage Policy with PowerStore replication is assigned to a vVol based VM, a replication session is created on PowerStore for VM vVol resources in the same resource group. VMware resource groups can be selected when a VMware Storage Policy is configured for a VM. VMware SRM uses these VMware resource groups to manage the protected VMs in Replication Groups. A SRM Recovery Plan controls the PowerStore replication session for vVols in a replication group during test failover, failover, and reprotection. After a VM has a VMware Storage Policy assigned, and the Resource Group is in a Replication Group with Protection Plan in SRM a placeholder VM on destination vCenter and PowerStore is created. The storage container for placeholder VM is part of the site pair configuration in SRM.

One of the great things about vVols is that all of the workflows of SRM: Test, Cleanup, Planned Migration, Disaster Recovery, and Reprotect function just the same with vVols as they do with array-based replication. Also, vVol protection groups can be combined into the same recovery plan as array-based replication groups.

One of the benefits of SRM and vVols is that you don’t need a Storage Replication Adapter (SRA) to use array-based replication. vVols inherently use array-based replication managed via Storage Policy-Based Management (SPBM). When you set up vVols replication, it is not at a LUN or volume level, it is at the VM level. Subsequently, you have the autonomy to granular control individual VM replication. By not having to setup an SRA, you reduce additional SRM configuration and complexity in your environment. When you have SRM associated with a vVols SPBM replication policy, any VM where that policy is applied is automatically protected by SRM and added to an SRM protection group.

The VASA providers now handle all operations with the storage arrays. With vVols, replication configuration and management can be done directly from vSphere (not just the UI, through any tool used to manage vSphere – vRO, PowerCLI, etc.), and it integrates fully with VM provisioning and policy-based management. As part of the capability to manage this new integration through means other than the UI, new workflows to manage the SRM and vVols integration have been added to the SRM plugin for vRO.

The preparation for protection before involving SRM is similar to that with standard array-based replication. Replication is configured between the arrays, which includes defining replication groups and associated storage policies. With those in place, protection is as easy as associating a VM with a storage policy and placing it onto storage that complies with that policy.

vVols replication operations in PowerStore Manager

Operations on for a replication session in PowerStore Manager always affecting all vVols in the same resource group. A resource group is configured during the protection of a VM when assigning the VMware Protection Policy in vCenter.

• Synchronize – With Synchronize operations a manual replication is executed for all vVols in the replication group covered by the replication session.
  

• Pause – This operations pauses the replication session for all vVols in the replication group at the current state. After pausing a vVol replication session the scheduled RPO replications are disabled.
  

• Resume – The resume operations resume a paused replication as it was when pausing the replication session and enables the schedules for RPO based replications.
  

Configuration of vVol replication

To protect vVol based VMs with PowerStore native asynchronous replication, some configurations are required. PowerStore and vSphere vCenter do not have the capability to synchronize the configuration. Therefore, it is required to run the configuration steps for PowerStore and vSphere vCenter on both sites (Protected Site and Recovery Site).

PowerStore includes a native VASA 3.0 provider, which enables the vVols storage framework. The VASA provider must be registered in vSphere in order to use vVols. This registration can be done as part of the vCenter server connection process in PowerStore Manager.

vVols leverage Storage Policy Based Management (SPBM) to ensure VMs have the appropriate storage and replication capabilities.  After you configure your virtual volumes storage for replication, information about replication capabilities and replication groups is delivered from the array by the storage provider.

After configuring the replication policy and the remote PowerStore replication cluster, you are ready to protect virtual machines. When applying the replication policy to a virtual machine, that virtual machine will be automatically replicated to the target array. Virtual machines deployed on vVol with replication storage policies, will automatically be protected by SRM.

After configuring virtual machine storage policy and association with a vVol datastore, you can view the replication session via PowerStore Manager

vVol replication operations in VMware SRM

All vVol replication operations in SRM are based on a underlaying Replication Group. Each Replication Group can contain multiple resources groups.

Test – The test operation in VMware SRM allows to enable VM’s on DR for a failover test. While the test is running, DR VMs are using the defined networks configured during Network mapping SRM Site pair configuration. While the test is in progress, the replication continues in the background and vVols are using writable Snaps on DR.

Cleanup- A cleanup operation stops a test and stops running VM and revert VM configuration back to placeholder VM on DR.

Run – The Run operation in SRM initiates a planned- or an unplanned failover of a Replication Group to DR site. After Run, the production workload is running on DR site, and replication is in state Failed over.

Reprotect – After a failover the Reprotect operation in SRM turns the replication direction and enable schedules on PowerStore for RPO based replication. After Reprotect the original Production and DR sites are swapped.

A guest post by Tomer Eitan