Skip to main content
  • 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.

PowerMaxOS: How to set SRDF Metro preference for Witness protected groups

Summary: PowerMaxOS: How to set SRDF or Metro preference for Witness protected groups?

This article may have been automatically translated. If you have any feedback regarding its quality, please let us know using the form at the bottom of this page.

Article Content


Instructions

You can change the indicated preference site when using a witness (for an SRDF/Metro Group that is Active and has a Configured Type of Witness. The preference, or "winning" side is represented as R1 and the non-preference, or "loser" side is represented as R2. The symrdf command provides a
set preference R1 | R2
option that changes the preference site to be used as part of the decision made by the witness when determining the site which remains host accessible on a failure. The preference is set at the SRDF or Metro group level.
To make us of this feature the following is required:
  • Both Arrays are PowerMaxOS 5978.711 (and above)
  • Management control is Solutions Enabler 10.x and or Unisphere for PowerMax 10.x (and above)
SYMCLI example:
symrdf -sid 001 -sg rdfg1_SG -rdfg 1 set preference R2
Unisphere for PowerMax example:
Array SID > Storage > Storage Groups > rdfg1_SG > Set Metro Preference
Or
Array SID > Dashboard > Replication Dashboard > SRDF/Metro Storage Groups > rdfg1_SG > Set Metro Preference

Additional Information

NOTE: When Metro is configured to use a witness, the role of the witness is to determine which side of the Metro session is the best choice to remain accessible to the host if there is a failure. The devices, on the side which is chosen to remain accessible to the host, are reported as R1 devices and the other side devices are reported as R2 devices. The choice which the witness makes may not align with the preference the user chooses.

The reason the choice may not align is: 
When both sides run PowerMaxOS, SRDF/Metro takes extra factors into account to determine the preferred winner (in priority order):
  1. The side that has host connectivity (requires PowerMaxOS 10 (6079) or PowerMaxOS 5978.444.444 or later) This functionality monitors the connections to the host that are mapped to SRDF/Metro devices to check that the connections are operational.
  2. The side that has a write pending (WP) value that is less than 80% of the System WP Limit (requires PowerMaxOS 5978.669.669 or later)
  3. The opposite side from the side that has a dual RAID failure. That is two spindles are down in a RAID 5 group or three spindles are down in a RAID 6 group, (requires PowerMaxOS 10 (6079)).
  4. The side that has a SRDF/A DR leg
  5. Whether the SRDF/A DR leg is synchronized
  6. The side that has an active SRDF/A DR leg
  7. The side that has a ready mirror on the SRDF/A DR leg
  8. The side that has more than 50% of the RA or FA directors that are available 
  9. 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 an 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 first of these criteria that one array has, and the other does not, stops the selection process. The side with that criteria is the preferred 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 sides 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.

So in summary, after setting the preference of a SRDF/Metro group to one side (Array A), if the other side (Array B) has one of the above criteria that Array A does not, then preference is assigned to Array B. 
To explain this further, consider the following example.
Array A has rdfg 100 devices currently R1, Array B has rdfg 100 devices currently R2.
Array A has rdfg 100 devices in a Masking View whose Front-end Ports are Online and Fabric Switch attached.
Array B has rdfg 100 devices unassigned, (meaning not in any Masking View so not available on any Front-End Port).
 
Then below command would return: The device is already in the requested state
symrdf -sid Array A -sg <sg> set preference R2
and in the symapi.log returns - The device is already in the requested state
sg <sg>: Set type Preference R2
So since Array A has host connectivity for rdfg 100 devices, and Array B does not have host connectivity for rdfg 100 devices, then Array A remains as the preferred winner (R1) as the two arrays for rdfg 100 differ on criteria 1.

The set preference option is only allowed for an Active SRDF/Metro group that has a Configured Type of Witness. An Active SRDF/Metro group can have different Pairstate and Witness Status combinations.
Using a naming convention of <Pairstate> - <Configured Type> - <Effective Type> - <Witness Status>
to represent the combinations and:
Pairstate AA is ActiveActive and AB is ActiveBias
Configured Type W is Witness
Effective Type W is Witness and B is Bias
Witness Status N is Normal, D is Degraded and F is Failed
the following table informs the combination status after a preference change:
 
 Current Status
 Status after set preference change
 AA - W - W - N AA - W - W - N
 AA - W - W - D
AB - W - B - F
 AB - W - B - F
AB - W - B - F

Videos

 

Article Properties


Affected Product

PowerMaxOS 10

Last Published Date

25 Apr 2024

Version

5

Article Type

How To