Device Status

User Guides for VMware Solutions
Audience
Public
Content Type
User Guides
Source Type
Documentation

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.

For a detail description of discovery, please refer to this Wiki page.

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.

    Note:

    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.