Skip to main content
Pure1 Support Portal

Discovering Replicated Devices with the FlashArray SRA

Replicated Devices

A device, as SRM refers to often, will generally also be referred to here as a FlashArray volume--the terms can be considered to be interchangeable.

Once SRM array managers have been configured, SRM can use the FlashArray SRA to discover all of the replicated devices on the identified FlashArray replication pairs. While specific array manager configuration dictates whether or not a given device will be discovered, in general though FlashArray volumes are supported to be discovered by the SRA if they are protected in one of the following ways:

  • In a FlashArray protection group that is not in a pod. The FlashArray protection group must have one or more connected FlashArray replication targets in it. (SRA 1.0+)
  • In a FlashArray protection group that is in a pod (stretched or unstretched). The FlashArray protection group must have one or more connected FlashArray replication targets in it. (SRA 3.1+)
  • In a stretched pod. This is supported in "stretched" storage integration of the SRM, but does require SRM enterprise licenses. (SRA 2.0+). An array manager must be setup appropriately for this configuration to be discovered.

The following replication options are not currently supported:

  • The volume is only in a FlashArray protection group with only an object-based target (Amazon S3, Azure Blob)
  • The volume is only in a FlashArray protection group with only a NFS-based target

If a volume is in a valid replication state, it will be returned to SRM by the FlashArray SRA. This means that all valid replicated volumes will be returned to SRM--whether or not they are in-use by the VMware environment.

Below is a screenshot of a list of replicated devices from an array pair:

clipboard_e51a271440b3dad6a0a4c9374b5aa3159.png

The above list is returned to SRM and SRM looks to see if it is in a supported mode. The following list are the requirements:

  • iSCSI or Fibre Channel
  • A VMFS version 5 or 6
  • An Raw Device Mapping (this is not supported for stretched storage)
  • In use in the connected vCenters (if the volume is used by a vCenter not connected to this SRM pair it is considered not in-use)

If a discovered device is shown in the above table but the Datastore column is not populated (it is blank), the device cannot be controlled by SRM.

VMware SRM does not currently support vVol-based storage using array based replication. Pure Storage is actively working with VMware on this for a future SRM release.

ESXi also does not currently supported storage connected via NVMe-oF. Pure Storage is working with VMware on NVMe-oF support. SRM support of this connectivity option is not yet known.

Device Status

In the discovered devices screen in the SRM, each discovered device comes with a status. This status indicates what part of the SRM lifecycle that device is in. clipboard_ec432c67152e3241b9eb9c152d59dca21.png

There are five main discovered device statuses:

  1. Forward.
    1. This means it is replicating from the site of the local vCenter (listed in the column title by Device) to the site of the remote vCenter
  2. Reverse.
    1. This means it is replicating from the site of the remote vCenter (listed in the column title by Device) to the site of the local vCenter
  3. Failover in Progress
    1. Source volume is not connected to any hosts but is replicating to the remote site
    2. Source volume is connected, and there is a volume on the target array named with the same name of the source volume and has a suffix of -puresra-failover. That volume on the target array must also be sourced from a replicated snapshot of that same source volume.
    3. In any of these cases the source volume may or may not have the -puresra-demoted suffix on the volume name.
  4. Failover Complete
    1. Source volume is not connected, there is a volume on the target array named with the same name of the source volume and has a suffix of -puresra-failover. That volume on the target array must also be sourced from a replicated snapshot of that same source volume. Lastly the target volume is not connected to any hosts.
    2. Source volume is not connected, there is a volume on the target array named with the same name of the source volume and has a suffix of -puresra-failover. That volume on the target array must also be sourced from a replicated snapshot of that same source volume. Lastly the target volume is connected to one or more hosts.
    3. In any of these cases the source volume may or may not have the -puresra-demoted suffix on the volume name.
  5. No Site Preference (Stretched Storage).
    1. This is for volumes protected by ActiveCluster in stretched pod state. Volumes in this state are presented to both vCenter environments simultaneously. Note the the Pure Storage SRA 3.1 does not report site preference, so all stretched volumes will report as no preference.

clipboard_ec3c101b07e0d89a0144b5ba87cc94777.png

Note that how a device is seen is not tracked in any SRM or SRA database. It is entirely inferred from the present configuration of the device. This includes replication state, host connection status, and the source of the volume. Therefore devices that have never been controlled by SRM could have a state like "Failover in Progress". For these reasons, it is not recommended to make any changes to volume names unless it is in the "Forward" or "Reverse" state.

 As of the 3.1 release of the SRA, there is no advertisement of consistency groups to SRM for FlashArray devices. A FlashArray protection group is a consistency group, so volumes included in the same group are replicated in a write consistent manner, but there is no requirement to fail them over together. Therefore, as of the 3.1 SRA, the Local Consistency Group column in the Discovered Devices table will always be blank.