Skip to main content
Contact Us
Register
Pure Technical Services

Guidelines for ActiveDR in VMware Environments

  1. Last updated
  2. Save as PDF

Currently viewing public documentation. Please login to access the full scope of documentation.

Overview

Disaster recovery management is a critical piece of any infrastructure--and array-based replication plays an important role in that. Ensuring that the data that runs your business is not only protected in your present production site but also available in a separate location at a moments notice allows your business to remain functioning in the case of a small failure or a large catastrophe. Virtualized environments such as a VMware implementations are no exception.

ActiveDR provides an array-based mechanism to protect your important data in a simple and robust way over great distances with extremely low RPOs. The simplicity of management makes disaster recovery (and importantly testing your disaster recovery plans) straight-forward and repeatable.

In this article the configuration and recommendations concerning ActiveDR will be discussed. For detailed documentation on ActiveDR requirements, configuration, and behaviors refer to the ActiveDR documentation page.

Best Practices

All existing best practices for VMware and FlashArray environments remain for ActiveDR-enabled datastores and/or Raw Device Mappings.

As always please ensure they are followed:

Quick Reference: Best Practice Settings

 Setting the ESXi Host Personality

The ESXi host personality MUST be set in any environment where ActiveDR is enabled for use. Not having the FlashArray host personality set for ESXi hosts when ActiveDR is enabled for volumes can lead to an ESXi crash. Starting with Purity 5.3.7 the host personality can be set non-disruptively on active ESXi hosts.

When an ActiveDR pod is demoted, the volumes in it go to a read-only state. When ESXi sees volumes in a read-only state hosting VMFS volumes it can cause the hostd process to lockup trying to update VMFS metadata. To protect against this the ESXi host personality must be set on any and all FlashArray host objects that represent ESXi hosts. Set this BEFORE configuring ActiveDR on any VMware-related volumes. This can be changed non-disruptively on any FlashArray running Purity 5.3.7 or later.

While this only affects volumes in the demoted state that are simultaneously presented to hosts, this situation can occur at any time (the demotion of the hosting pod). Therefore the host personality should be configured before there is any chance to demote in-use volumes.

Login to the FlashArray and select the desired host:

clipboard_e2ed1571b19dcb164410faf69daf25141.png

Click on the vertical ellipsis on the Details box and choose Set Personality...

clipboard_e4b2302e1bb8e3d3ab9bccd0deb3a27d6.png

Choose ESXi and click Save.

clipboard_e5506bd121bef7f4fd692ae2d9d46b4bd.png

DO NOT demote a pod before checking that all hosts using affected volumes have the personality set.

Volume/Pod Placement

ActiveDR is a pod-based architecture--this means that all of the volumes in the pod are failed over together. A pod is a replication group and a consistency group.

Therefore it is important to follow these guidelines:

  • If a virtual machine spans multiple datastores it is important that all of the datastores are in the same pod. This ensures that the VM can be entirely failed over and its storage is consistent on the recovery site.
  • If a virtual machine is using both a VMFS datastore and a Raw Device Mapping, the underlying volumes should be in the same pod. This ensures that the VM can be entirely failed over and its storage is consistent on the recovery site.
  • If ActiveDR datastores are in use in a vSphere Storage DRS cluster, all of the datastores should be in the same pod.
  • Related applications that need to be recovered in unison should all be in the same pod. This will help ensure cross-application data consistency after failover.

VAAI and ActiveDR

The vSphere APIs for Array Integration (VAAI) is a set of SCSI offloads that provide accelerated data management by moving processes from the ESXi hosts to native array functions. Details of VAAI can be found here:

Web Guide: VMware Storage APIs for Array Integration with the Pure Storage® FlashArray

There are a few caveats concerning VAAI and the use of pods on the FlashArray and ActiveDR pods are no exception. Please keep the following points in mind:

  • XCOPY does not work across pod boundaries. Instead normal host copy processes will occur when performing a Storage vMotion, Clone, or Deploy from Template operation when the source datastore is not in a pod (or a pod) and the target is in a different pod. This will cause these operations to be slower and write-intensive. It is recommended to limit the frequency of these operations. For instance if deploying from template is a common operation for volumes in the pod, put the source template (or a copy of it) inside of the pod.
  • UNMAP, ATS, and WRITE SAME work with no exceptions in pods.
  • An UNMAP operation that occurs will reclaim the space on the source volumes. The UNMAP will be transmitted to the target volume in the target pod, but the reclamation will not occur immediately after the UNMAP process executes. UNMAP transmission is under the same delay as standard writes and the backend cleanup processes in general on the target FlashArray.

VMware and ActiveDR Integration Requirements and Limitations

  • FlashArray volumes in use as vSphere Virtual Volumes are not currently supported to be protected by ActiveDR replication.
  • The Pure Storage vRealize Orchestrator plugin does not have built-in workflows for ActiveDR
  • The Pure Storage vRealize Operations Manager Management Pack does not currently support ActiveDR replication relationships, alerts, or metrics.
  • ActiveDR provisioning in the Pure Storage FlashArray Plugin for the vSphere Client is only supported started with plugin version 4.4.0.
  • Site Recovery Manager support of VMFS or RDMs protected is only supported starting with FlashArray Storage Replication Adapter version 4.0.0.