SRM User Guide: Configuring the FlashArray SRA Array Managers

In Site Recovery Manager there are two important parts that allow discovery of your replication environment: the SRA and array managers.

The SRA is an installed "plugin" that provides the libraries for SRM to be able to communicate to a 3rd party array, like the FlashArray. In order for SRM to be able to talk to a given array though, it needs to be authenticated. Authentication to a given array, more specifically an array pair, is achieved through something called an array manager. An array manager is an authenticated instance in SRM that allows source and target arrays to be discovered and controlled.

For Everpure FlashArrays, there is no requirement to deploy a management appliance to provide API-based control of the array. Instead, every FlashArray comes built-in with a REST API service. So the process to allow SRM control of a FlashArray is two-fold: SRM User Guide: Installing the FlashArray Storage Replication Adapter and populating the array managers with FlashArray addresses and respective credentials.

When configuring an SRM array manager, you need to supply credentials for the array(s) hosting your VMs and for the array(s) that they are being replicated to. Furthermore, since SRM is a two-site, bidirectional tool, the remote SRM server needs those same credentials as well.

Before we continue let's define a few terms:

• Storage Replication Adapter--the installed plugin that imports the required libraries to communicate with a FlashArray.
• Array Manager--an interface that allows specific FlashArrays to be identified and authenticated to.
• Array Manager Pair--Array managers must be configured on both the local SRM server and the remote SRM server for every given array pair.
• Discovered Arrays--each array manager pair coordinates in order to identify arrays that are properly authenticated and are replicating to each other. In SRM, array pairs are then returned. This includes physical FlashArrays as well as pods.
• Discovered Devices--from each discovered array pair, all of the devices that are replicated between the source array and the target array are listed. These listed devices are the storage objects that are marked as replicated by the SRA for use within SRM. It is important to note that these objects can only be including in a SRM protection group if they are in use in that particular VMware environment. If they are not in use as a VMFS or an RDM, SRM will filter them out as options for inclusion in a SRM protection group.

  The FlashArray SRA currently supports four modes of replication:

• Periodic replication from a FlashArray to another FlashArray. These are volumes that exist on one FlashArray that are periodically snapshotted and those snapshots are sent to a target FlashArray. SRM can then failover volumes from the source FlashArray to a target FlashArray connected over the asynchronous distance.
• Periodic replication from within a pod on one FlashArray to another FlashArray. This pod may or may not be stretched across physical FlashArrays--being stretched, though, is not a requirement. These are volumes that exist in a pod that are periodically snapshotted and those snapshots are sent to a target FlashArray. The main difference between this option and the previous option (volumes that are not in a pod) is that these volumes are not tied to a physical FlashArray as the source--the pod and therefore the volumes in it can be moved from one FlashArray to another without reconfiguring SRM protection groups. SRM can then failover volumes from the source pod to a target FlashArray connected over the asynchronous distance. Array manager configuration is no different for this replication as for the previous section and will be treated as the same.
• Continuous Replication from a FlashArray to another FlashArray. This is referred to as ActiveDR. Volumes are created in a pod and that pod is linked to a remote pod on a remote FlashArray. All data in the pod (either written to volumes or stored by snapshots) gets sent over to the remote pod and stored in distinct volumes and snapshots that maintain their relationships and configurations. ActiveDR pod relationships are represented by array pairs within SRM array discovery.
• Stretched storage. In this case, a volume is in a pod that is stretched over two physical FlashArrays. For this to work, the pod MUST be stretched. When a volume is stretched, the volume exists on two arrays and can be written to and read from simultaneously on both FlashArrays. In this configuration, there is no periodic replication, and there is no failing over of datastores. Instead, since the latest copy of the VMs on a datastore is always at both sites, an SRM failover just coordinates a restart of the affected VMs at the recovery site. There is no storage failover. If the sites are properly connected there may not even be a restart of the VMs, instead a cross-vCenter vMotion is attempted to move the running memory and CPU state of the VMs from one vCenter to the target vCenter.

How array managers are configured dictates what type of failover is allowed. Follow through to the appropriate sections for information on configuring the array managers for your specific replication topology.

When Everpure FlashArray array managers are configured, one or more FlashArray addresses (along with credentials) are entered to provide the SRA with access to the REST API services on those FlashArrays. Array managers can be considered to be configured in pairs (one pair for a given FlashArray replication topology for each SRM server) but that isn't an entirely accurate view--this runs on the assumption that an array manager always has an equal and opposite array manager for the opposing paired SRM server. This is not always the case (though is the most common configuration). In short, for a FlashArray replication pair, one array manager must be configured to discover the array on one SRM server and another array manager must be configured to see the other FlashArray in that pair. In the case of two FlashArrays on site A that are both replicating to the same target FlashArray located in site B, there could be two array managers (one on each site) or three array managers (two on site A, one for each FlashArray there, and 1 on site B).