Skip to main content
Sign Out

Welcome to Dell

My Account
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products
  • Manage your Dell EMC sites, products, and product-level contacts using Company Administration.
Sign In Create an Account Dell Financial Services Premier Sign In Partner Program Sign In
Contact Us

Your Dell.com Carts

Dell SRDF Introduction

PDF

Witness negotiation and selection

SRDF/Metro checks that at least one witness is available before setting the devices in a SRDF/Metro pair Ready on the SRDF link. The two arrays that host the device pair carry out the negotiation of which witness to use. This negotiation occurs when the devices are ready to move to the ActiveActive pair state.

NOTE:The process of selecting a witness is autonomous. The administrator cannot specify the witness that any SRDF/Metro pair is to use.

Witness negotiation

Each side of the SRDF/Metro configuration maintains a list of witnesses that the administrator sets up. To begin the negotiation process, the nonbias side sends its list of witnesses to the bias side. On receiving the list, the bias side compares it with its own list of witnesses. The first matching witness definition is selected as the witness and the bias side sends its identification back to the nonbias side. The two sides then establish communication with the selected witness.

Before allowing the devices in a pair to become Ready on the SRDF link, SRDF/Metro checks that the arrays have at least one witness definition in common. If there is no common witness, SRDF/Metro does not allow the devices to become Ready on the link. In this situation, the administrator reconfigures either or both arrays so that they have at least one witness definition in common.

NOTE:If the arrays cannot agree on a witness, the session operates in Device Bias mode. However, should a common witness become available, the two sides negotiate the use of that witness. The sides then continue in witness mode.

Intelligent witness management

When both sides run PowerMaxOS, the negotiation process is enhanced to include a decision on the winning side if there is a failure. The selection of the winning side is based on (in priority order):

  1. The side that has connectivity to the application host (requires PowerMaxOS 10 (6079) or PowerMaxOS 5978.444.444, or later).
  2. The side that has a write pending (WP) value that is less than 80% of the System WP Limit (requires PowerMaxOS 10 (6079) or PowerMaxOS 5978.669.669, or later).
  3. The side that has a SRDF/A DR leg
  4. Whether the SRDF/A DR leg is synchronized
  5. The side that has an active SRDF/A DR leg
  6. The side that has a ready mirror on the SRDF/A DR leg
  7. The side that has more than 50% of the RA or FA directors that are available
  8. The side that is the preferred side (if the user has set one).

    From PowerMaxOS 10 (6079) the storage administrator can specify the preferred side of a SRDF/Metro pair. In previous versions of the operating environment, or when the administrator has not specified a preferred side, the R1 side is the winner.

The two sides regularly repeat this selection process for each SRDF/Metro group to ensure that the winning side remains the one that is most preferable. So, the winning side may change during the SRDF/Metro session. SRDF/Metro always reports the winning side as the R1 device and the losing side as R2. So each switch in the winning side causes an apparent swap of the R1 and R2 personalities in the session.

The assessment of the winning and losing side occurs separately for each SRDF/Metro group that exists between two arrays. So, on a particular array, some devices could be R1 devices while others are R2 devices. Which are R1 and which are R2 depends on the outcome of assessing their respective SRDF/Metro groups.

Witness connection failure

While using a witness, an error could cause either or both sides of a SRDF/Metro session to lose contact with that witness.

Table 1. SRDF/Metro actionThis table summarizes the actions that SRDF/Metro takes in these cases:
Error SRDF/Metro action
One side loses contact with the witness.

The session continues to run, but in a degraded, high-availability condition. The side that remains in contact with the witness is designated the winner. That side remains available to the application host should the two sides lose contact with each other.

While only one side has contact with the witness, the witness status is Degraded.

If contact with the witness resumes, the session operates in the normal way.

Both sides lose contact with the witness.

If at least one other witness is available, the two sides negotiate the use of another witness.

When there is no other witness available:

  • The state of the device pair changes from ActiveActive to ActiveBias.

    SRDF/Metro considers the session to still be in witness mode. So the ActiveBias pair state represents a degraded, high availability condition.

  • The R1 device is designated the winner. That side remains available to the application host should the two sides lose contact with each other.
  • The witness status is Failed.

Witness failure scenarios has more on how SRDF/Metro reacts to various failure scenarios.

Characteristics of witness negotiation

As a result of witness negotiation:

  • An SRDF/Metro configuration uses one witness at a time.
  • An individual witness may simultaneously protect multiple SRDF/Metro sessions.
  • When multiple witnesses are available, different SRDF/Metro sessions between two arrays may use different witnesses. Alternatively they may all use the same witness.
  • An error may cause the devices in an SRDF/Metro session to become Not Ready on the SRDF link. When the devices become Ready on the link, the session might use a different witness.

Rate this content

Accurate
Useful
Easy to understand
Was this article helpful?
0/3000 characters
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please select whether the article was helpful or not.
  Comments cannot contain these special characters: <>()\