Solved!
Go to SolutionR2 in NR state
I noticed that on one of our Symm, the R2 devices usually go into NR state when the pairs are created.
I issue "symdev ready" to get them into WD state.
There aren't any hosts connected to R2 and they are unmapped so I am not worried.
But is this normal behaviour?
I issue "symdev ready" to get them into WD state.
There aren't any hosts connected to R2 and they are unmapped so I am not worried.
But is this normal behaviour?
1193
0
Posted October 11th, 2007 22:00
It's mostly a mainframe feature .. there is a flag in the binfile (a flag we can not manipulate via either symconfigure or symrdf) that forces R2 devices to go NR instead of WD. Doing so will avoid confusion at the host level if your host can see both R1 and R2 devices .. Don't ask more 'couse it's an unsupported configuration.. It's mostly a mainframe feature.
If you can, please split R2 devices .. and look at their state just after the split. If you have my own problem you'll have R2 devices RW enabled (needed to reach the "split" status) .. If later you'll establish again, you'll see them going NR again.
Message was edited by:
Stefano Del Corno1193
0
Posted October 11th, 2007 23:00
interesting...
is this flag documented or named somwhere?
i have not connected any MF beasts on this box and we never assign R1/R2 to same hosts...827
0
Posted October 11th, 2007 23:00
Could you please tell us the Ucode revision of the "different" box ?? I need the output of symcfg -v -sid 123 list
I need only those lines:
Microcode Version (Number) : 5771 (168B0000)
Microcode Date : 08.01.2007
Microcode Patch Date : 08.01.2007
Microcode Patch Level : 991196
0
Posted October 12th, 2007 00:00
i think i can add this to my options file
SYMAPI_RDF_RW_DISABLE_R2
Causes the R2 device to be set to read/write disabled, or
not-ready, on the RA during establish, restore, failback, or
createpair-establish operations.
= ENABLE | DISABLE
can you try it?1193
0
Posted October 12th, 2007 00:00
Unfortunatly the flag can be seen only from the Service Processor AFAIK ... I don't know any other way to look at this specific flag. If you allow us to dial your box and give us its serial number, I can ask my friendly RTS to check if your volumes have the specific flag .. and maybe he can send you a screenshot from the Service Processor to show if the flag is enabled or disabled on your devices. I will send you a screenshot taken from our box with an explanation1196
0
Posted October 12th, 2007 00:00
The flag you mention will change Solution Enabler behaviour .. When establishing/restoring/whatever-you-want Solution Enabler will look at this flag to choose the command to issue against R2 devices. My problem is different and have nothing to share with this variable. As you'll see in my mail, we have a mix of flags on our R2 devices that will force SOME of the devices to be NR while some other will be -as usual- WD .. In the same SRDF/A session1196
0
Posted October 12th, 2007 01:00
1) we have SRDF/A and while it's in consistent state we can't issue "symrdf -g xxx write_disable" ...
2) the only "true" test is to split the DG and establish it again ..
3) the environment variable you found, if enabled, will force R2 devices as NOT READY
If you can issue the "symrdf -g xxx write_disable r2", please tell us what you get1196
0
Posted October 12th, 2007 01:00
thanks for the response...
we always expected the R2 to go into WD state so I believe setting the flag will make us happy (as we do not have mainframes as stated)
i got one primus (closed the window unfortunately and now i do not want to play find-the-primus game on powerlink today)
it mentioned following...
symrdf -g not_ready/ready/write_disable r2
this will update complete group and set the R2 device status in a single step...hope this helps you...830
0
Posted October 14th, 2007 21:00
bin file has this default states. CE should remove "R2 INV" and "R2 NR" in "VolEdit" page. They mean R2 in "not ready" and "R2 not ready if it has invalid tracks" states after it is created. From inline command, RDF device status flag is "52", not "40".
If CE creates R2 volumes in "VolReq" page with R2 attributes, current all target codes will enable both "R2 INV" and "R2 NR". We don't preferred it.
If CE create local volumes in "VolReq" page, and then go to "VolMap" to change them into R2 feature, above 2 settings wouldn't be enabled. This is the correct settings.
Please ask your CE/RTS to look into bin file, avoid to enable above 2 settings.
For Celerra RDF setting, R2 volume MUST be having these 2 states disabled, or DR site Celerra initiation won't be passed.
mlee2
108 Posts
1612
0
Posted October 28th, 2007 19:00
I just wanted to check that your original question had been answered?
I noticed that on one of our Symm, the R2 devices usually go into NR state when the pairs are created.
I issue "symdev ready" to get them into WD state.
There aren't any hosts connected to R2 and they are unmapped so I am not worried.
But is this normal behaviour?
As already kindly noted by Stefano, the default behavior of any newly created static R2 devices depends on the bin file settings (this is actually regardless of the host type).
And as kindly noted by Jianyun this bin file behaviour can vary depending on how the static R2 volumes are created in the bin file. This pertains more to EMC CE modified bin files but these differences may apply depending on how the R2's were created via the CLI.
Please note that Dynamic RDF pairs are different and these bin file attributes don't apply (the bin file only shows that the volumes are Dynamic RDF capable devices).
As per the SYMCLI manual:
Note: For the createpair -establish option, the R2 may be set to Read/Write Disabled (Not Ready) if SYMAPI_RDF_RW_DISABLE_R2=ENABLE is set in the options file. For more information, refer to the EMC Solutions Enabler Symmetrix Array Management CLI Product Guide.
So this can be considered "normal" behavior since, once the R2 or DR2 have been created, you can reset the default state via symrdf commands.....
Best Regards,
Michael.