Skip to main content
Pure Technical Services

SRM User Guide: Discovering Replicated Devices with the FlashArray SRA

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

KP_Ext_Announcement.png

Replicated Devices

SRM often refers to a "device"; this will generally also be referred to here as a "FlashArray volume". These terms should be considered interchangeable.

Once SRM array managers have been configured, SRM can use the FlashArray SRA (VMFS or RDMs) or the FlashArray VASA provider (vVols) 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, FlashArray volumes generally are supported to be discovered by the SRA or VASA Provider if they are protected in one of the following ways:

  • VMFS, RDMs or vVols: 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+)
  • VMFS or RDMs: 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 and failover is to the target of the protection group. (SRA 3.1+)
  • VMFS or RDMs: In a FlashArray pod that is enabled for ActiveDR (SRA 4.0+)
  • VMFS only: 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. Failover is between the two arrays hosting the pod.

The following replication options are not currently supported for SRM-controlled failover:

  • 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 or VASA provider. 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 then SRM looks to see if it is in a supported mode. The following list are the requirements:

  • iSCSI or Fibre Channel
  • VMFS version 5 or 6
  • Raw Device Mapping (RDM - 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)

Note that Virtual Volume-based VMs and their storage are not listed in the discovered devices table.

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.

ESXi also does not currently supported storage connected via NVMe-oF. Pure Storage is working with VMware on NVMe-oF support. SRM support timelines for 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. For Non-Active DR volumes:
      1. This means the volume is replicating from the site of the local vCenter (listed in the column title by Device) to the site of the remote vCenter.
    2. For ActiveDR volumes:
      1. This means the volume is replicating from the site of the local vCenter (listed in the column title by Device) to the site of the remote vCenter and there are no tags with puresra-demoted or puresra-failover for the volumes in the puresra namespace.
  2. Reverse.
    1. For Non-Active DR volumes:
      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.
    2. ​​​​​​​For ActiveDR volumes:
      1. This means the volume is replicating from the site of the local vCenter (listed in the column title by Device) to the site of the remote vCenter​​​​​​​ and there are no tags with puresra-demoted or puresra-failover for the volumes in the puresra namespace.
  3. Failover in Progress
    1. For Non-Active DR volumes:
      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.
    2. For ActiveDR volumes:
      1. ​​​​​​​Host connection state is not relevant--instead the SRA uses FlashArray volume tags and pod state to detect the status of the device pair.
      2. Both the source and target pods are demoted.
      3. Both the source and target pods are demoted and either or both:
        1. The target volumes are not tagged in the puresra namespace with a key of puresra-failover with a value of the UUID of the pod they are in.
        2. Thes ource volumes are not tagged in the puresra namespace with a key of puresra-demoted with a value of the UUID of the pod they are in.
  4. Failover Complete
    1. For Non-Active DR volumes:
      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.
    2. For ActiveDR volumes:
      1. Host connection state is not relevant--instead the SRA uses FlashArray volume tags and pod state to detect the status of the device pair.
      2. The source pod is demoted and the target pod is promoted. Target volumes are tagged in the puresra namespace with a key of puresra-failover with a value of the UUID of the pod they are in and the source volumes are tagged in the puresra namespace with a key of puresra-demoted with a value of the UUID of the pod they are in.
  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.

For most replication options, 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, for most replicated devices, the Local Consistency Group column in the Discovered Devices table will always be blank.

With ActiveDR devices, the consistency group is in fact advertised and the consistency group is the pod name of the pod that owns the volume. This forces SRM to failover all devices at once within a given ActiveDR pod.

clipboard_ed92577ca4cf6d0bdd990fc0acab107e7.png