5 Posts
0
1161
SRDF Split command is showing FailedOver status
I am trying to split a SRDF\A group and after successfully executing the split command, the status shows as 'failed over'. Any idea why it is behaving like this?? The status suppose to see as 'Split' why this strange behavior?
Device Dev E Tracks Tracks S Dev E Tracks Tracks MDAE STATE
-------------------------------- -- ------------------------ ----- ------------
DEV001 00089 RW 0 0 NR 001D3 RW 0 0 A... Failed Over
Total -------- -------- -------- --------
Track(s) 0 0 0 0
MB(s) 0.0 0.0 0.0 0.0
DELL-Josh Cr
Moderator
Moderator
•
8.6K Posts
1
February 23rd, 2023 11:00
https://dell.to/3Soh02E
Symptoms
The SRDF pair state went to " Failed Over" when a SRDF split operation was performed on a DG.
The R1 and R2 states are RW and the link state was NR
SRDF mode was Asynchronous and Adaptive Copy.
Cause
The same can be verified from symdev show on the R2 device(s) in the parameter Front Director Paths (0): N/A
Resolution
When the R2 devices were mapped to the FA ports and a split operation was performed, the SRDF pair state went to "Split" as designed.
DELL-Josh Cr
Moderator
Moderator
•
8.6K Posts
0
February 23rd, 2023 07:00
Hi,
Thanks for your question. Were there any errors prior to doing the split? Were their any pending writes? https://dell.to/3XUtbWb and https://dell.to/3kv41jb this may also help. https://dell.to/3EyxpvJ
Let us know if you have any additional questions.
Cibin Varghese
5 Posts
0
February 23rd, 2023 10:00
@DELL-Josh Cr In my case, I never presented R2 devices to any host. These devices were added to the storage group, which doesn't have a masking view.
DELL-Josh Cr
Moderator
Moderator
•
8.6K Posts
0
February 23rd, 2023 10:00
Symptoms
SRDF Failover issued.
SRDF Split issued.
Possible DU against R2 device depending on mounting dependencies on attached host.
symCLI command 'symdev show ' displays some FA paths for R2 device as Write Enabled, and others Write Disabled:
Example below:
Front Director Paths (4):
{
-----------------------------------
DIRECTOR PORT LUN
---------- ---- -------- ---------
Type Num Sts VBUS TID SYMM Host
-----------------------------------
FA 04F:0 WD 000 00 021 N/A
FA 07F:1 RW 000 00 011 N/A
FA 10F:1 RW 000 00 011 N/A
FA 13F:0 WD 000 00 021 N/A
}
Host reports paths as Write Disabled on SRDF R2 device after SRDF Failover or Split command issued.
Cause
If some FA paths for an R2 device have a Write status of Write Enabled, and others as Write Disabled, Solutions Enabler will not Write Enable the Write Disabled paths as intended during the SRDF Failover or SRDF Split command is issued. This leaves the paths in mixed states which can lead some host operating system in an inability to correctly mount the R2 as intended.
This issue does not occur if all the FA paths for a given R2 device are ALL Write Enabled, or ALL Write Disabled.
Resolution
As a work-around, you can issue the following symcli command to bring the paths online:
symdev -sid rw_enable for an individual device
OR
symdev -sid rw_enable -devs : for multiple volumes in a range.
Additional Information
An R2 device can be made Write Disabled on an FA path via two scenarios:
Scenario 1:
SRDF Failover
SRDF Personality Swap
SRDF Establish
SRDF Failover or Split
If you add new FA paths between steps 3 & 4, the original FA paths are Write Disabled, and the new FA paths are Write Enabled. At step 4 above, at SE 7.6.x, the mix of WE and WD paths will cause the SW to not enable the paths.
Scenario 2:
Individual FA path is made WD by customer via symdev write_disable command.
Again, if you have a mix of WE and WD for the R2, the SW can't distinguish and won't enable the WD paths.
A note About this state.
From the R2 side
If a device has been MANUALLY MANIPULATED thru ANY task outside of RDF SE does not change the state of the device on FA under any circumstances, establish, splt, suspend, resume, failover, failback.
From the R1 side.
If a device has been MANUALLY MANIPULATED thru any task outside of RDF, SE WILL change the state of the device, but only on the failback. Establish, split, suspend, resume, SE will not change it. When the failback is issued, all the R1 devices change back to RW enabled on the FA.
This is working AS DESIGNED. This is not a bug. This is day one behavior. We will only manipulate the R1 devices on failback. Clearly the customer did some type of operation to manually manipulate a couple of the R2 devices thru the masking operation to be WD. When the failover to the R2 was issued, we will NOT manipulate the R2 devices that were manually changed. It s always been the philosophy to protect the R1 s.
Cibin Varghese
5 Posts
0
February 23rd, 2023 10:00
@DELL-Josh Cr https://dell.to/3XUtbWb and https://dell.to/3kv41jb these documents are not available for me to access. Could you please paste its contents here?