Best Practices

ActiveDR
Audience
Public
Product
FlashArray
FlashArray > Purity//FA
Content Type
User Guides
Source Type
Documentation

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

Note:

  • ESXi Host personality is required for Purity version 6.0.x.

  • The Configuring 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 in Purity 5.3.x and 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:

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

Choose ESXi and click Save.

Note:

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.