Dell SRDF Introduction

Key differences in SRDF/Metro compared to traditional SRDF

In SRDF/Metro configurations:

• R2 device is Read/Write accessible to the application host.
• The R1 and R2 devices have federated personalities. That is, both sides of the SRDF device pair appear to the application hosts as the same device. When the device pair becomes RW on the SRDF link, the R2 device assumes the personality of its R1 partner (such as geometry and device WWN).

  The R2 device retains this assumed identity until the device pair is removed from the SRDF/Metro configuration. From then on the two devices have unique personalities to avoid device collusion. The storage administrator can reset the device personality manually, but this is not required.

• Both arrays in the configuration monitor the health of the devices in the SRDF group and of the SRDF link between the arrays. If any of the following occur, the arrays cooperate to ensure that that data remains available for reads and writes without allowing inconsistencies to occur between them.
  • A device fails.
  • The SRDF link fails.
  • Devices are made Not Ready on the SRDF link.
• Devices in a SRDF/Metro configuration operate in Active SRDF mode. SRDF modes of operation contains information about SRDF modes.
• There are two extra SRDF pair states that only SRDF/Metro uses. These states indicate that the configuration is ready to provide high data availability:
  • ActiveActive for configurations using the Witness options (Array and Virtual)
  • ActiveBias for configurations using bias
  NOTE:R2 devices should not be presented to the application hosts until they reach one of these two states at which time both devices present the same WWN.

  SRDF/Metro resilience has more information about the Witness and bias mechanisms.

Device management

All device pairs in a SRDF/Metro group are managed together for all supported operations, except when changing the contents of the group:

• Create pair and move pair operations can add devices to the SRDF/Metro group.
• Delete pair and move pair operations can remove devices from the SRDF/Metro group.

Failure resilience

While providing high data availability, SRDF/Metro ensures that the data is consistent on both sides of the configuration. If data consistency can no longer be guaranteed due to, for example, the failure of a device or the SRDF link, SRDF/Metro:

• Allows one side to remain accessible to the application host (the winner)

  This side continues to service I/O requests from the application host.

• Makes the other side inaccessible to the application host (the loser)

Making only one side accessible to the application host eliminates the possibility of a split brain situation occurring. A split brain scenario could result in inconsistent data accumulating on both sides of the SRDF/Metro group.

SRDF/Metro provides two mechanisms for determining the winner:

• Witness option: A Witness is a third party that mediates between the two sides to help decide which remains available to the application host if there is a failure. The Witness method provides intelligent selection of the winner at the time of failure to facilitate continued host availability.

  The Witness option is the default and there are two types of Witness:

  • Array Witness : The operating environment on a third array acts as the mediator to decide the side of the device pair that remains R/W accessible to the application host. It gives priority to the winner, but should that side be unavailable the other side remains available.
  • Virtual Witness (vWitness) option: vWitness provides the same functionality as the Array Witness option, but it is packaged to run in a virtual appliance or as a daemon on a Linux system, rather than on an array.

    The vWitness runs as a Linux daemon when either or both arrays in the SRDF/Metro configuration run PowerMaxOS 10 (6079).

  The vWitness and Array Witness options are treated the same in the operating environment, and can be deployed independently or simultaneously. When deployed simultaneously, SRDF/Metro favors the Array Witness option over the vWitness option, as the Array Witness option has better availability.

• Device Bias option: Device pairs for SRDF/Metro have a bias attribute. SRDF/Metro designates the R1 side of a device pair at the time that the devices become Ready on the SRDF link as the winner. If the device pair becomes Not Ready (NR) on the link, the R1 (bias side) remains accessible to the application host. The R2 (nonbias side) is inaccessible to the application host.

The Witness option has key advantages over the Device Bias option:

• The Witness option provides intelligent selection of the winner and loser at the time of a failure.

  The Device Bias option, decides on the winner and loser before any failure.

• As a result, the Witness option can designate as the winner the side that appears most capable of providing continued data availability to the host.

  The Device Bias option can only designate the bias (R1) side as the winner. Device Bias cannot make the R2 side available to the application host. If the R1 side is unavailable, the application host loses all data availability that the devices provide.

Wherever possible, do not use Device Bias in a production environment.

SRDF/Metro resilience has more information about these failure-recovery mechanisms.

Disaster recovery

SRDF/Metro provides high availability while traditional SRDF provides disaster recovery. The two technologies can exist together to provide disaster recovery facilities for an SRDF/Metro. Disaster recovery facilities has more information about using disaster recovery in an SRDF/Metro configuration.

Operating environment

Arrays in a SRDF/Metro configuration run HYPERMAX OS 5977.691.684, or later, any version of PowerMaxOS 5978, or any version of PowerMaxOS 10 (6079). SRDF and NDM Interfamily Connectivity Information defines the combinations of operating environments that an SRDF/Metro configuration can contain.