This post is more than 5 years old
1 Rookie
•
92 Posts
0
2161
January 4th, 2008 13:00
Unmapped BCV's
i have lot of devices of BCV Type which are under unmapped category ( bcv devices , bcv meta devices , bcv meta R1 devices )
and also i have bcv devices under mapped category..we are using TimeFinder/ SRDF for DR ..
1. i am wonder those devices which are under unmapped are ready to use for future ??? or those are currenty under use ??? ..
2. say if dev01 is attached to FA 13A -p 1 so the associated bcv for that standard device dev01 need to be mapped to same FA or no need
3.even can we change those device protection type like from BCV --> Raid ..
thank you...
and also i have bcv devices under mapped category..we are using TimeFinder/ SRDF for DR ..
1. i am wonder those devices which are under unmapped are ready to use for future ??? or those are currenty under use ??? ..
2. say if dev01 is attached to FA 13A -p 1 so the associated bcv for that standard device dev01 need to be mapped to same FA or no need
3.even can we change those device protection type like from BCV --> Raid ..
thank you...
No Events found!


pctech321
1 Rookie
•
92 Posts
0
January 7th, 2008 11:00
server1/root: / > symrdf -g XXX query
Device group 'XXX' ' is not an RDF group.
but symrdf list command tells me that MDA is of type s.. ( synchronous ) mode...can anyone explain the symdev ,
Rdev ,RDF TYP:G meanings here.....02CB is bcv or standard dev ? whats the relation between 02CB & 001B & whats the number
2 means ( 02CB 001B B-R1:2--> this 2 digit ) & 02CB & 001B are local or remote symmetrix devices ?
server1/root: / > symrdf list
Symmetrix ID: XXXXX1234 ( Local symmtrix )
Local Device View
-------------------------------------------------------------------------
STATUS MODES RDF S T A T E S
Sym RDF --------- ----- R1 Inv R2 Inv ----------------------
Dev RDev Typ:G SA RA LNK MDA Tracks Tracks Dev RDev Pair
---- ---- ------ --------- ----- ------- ------- --- ---- -------------
02CB 001B B-R1:2 ?? RW NR S.. 0 0 RW WD Suspended
02CC 001C B-R1:2 ?? RW NR S.. - - RW WD Suspended
server1/root: / > symrdf -sid 5678 -R2 list
Symmetrix ID: XXX5678 ( remote DMX )
Local Device View
-------------------------------------------------------------------------
STATUS MODES RDF S T A T E S
Sym RDF --------- ----- R1 Inv R2 Inv ----------------------
Dev RDev Typ:G SA RA LNK MDA Tracks Tracks Dev RDev Pair
---- ---- ------ --------- ----- ------- ------- --- ---- -------------
001B 02CB R2:1 RW WD NR S.. 0 0 WD RW Suspended
001C 02CC R2:1 RW WD NR S.. - - WD RW Suspended
xe2sdc
6 Operator
•
2.8K Posts
0
January 8th, 2008 01:00
Device group 'XXX' ' is not an RDF group.
Could you please show us the output of "symdg list" command ?? I think that the issue is that you created a REGULAR DG that allows you to handle local BCVs but does not allow you to look at SRDF .. From the error above, the symrdf command is complaining since XXX is not a RDF group (in fact I think it's a regular one).
s.. ( synchronous ) mode...can anyone explain the
symdev ,
Rdev ,RDF TYP:G meanings here.....02CB is bcv or
standard dev ? whats the relation between 02CB &
001B & whats the number
means ( 02CB 001B B-R1:2--> this 2 digit ) & 02CB
& 001B are local or remote symmetrix devices ?
From the output of the command I can say that
1) devices 2CB and 2CC belong to box sn 1234 (they are in the leftmost column labelled "local" in the first part of the output)
2) devices 01B and 01C belong to box sn 5678 (for almost the same reason as above
3) you have 2 pairs: 2CB is bound to 01B and dev 2CC is bound to 01C.
4) devices 2CB and 2CC are R1 devices and box 1234 is using RDF group 2 to link its R1 devices with R2 remotes (R1:2).
5) devices 01B and 01C are R2 devices and box 5678 is using RDF group 1 to link its R2 devices with R1 remotes (R2:1).
6) no BCV in this output .. only R1 and R2 pairs as seen from either 1234 or 5678 point of view.
7) the replica is NOT running since pairs are in Suspended state (NR in LNK column). They are NOT READY on the RDF LINK -> SRDF replica not running.
8) your host can query both boxes (it's correct since they have a RDF link) so the output contains the view from both boxes.
Could you please tell me who did create an RDF link with different number from the two sides of the link ?? You have a "pipe" between the boxes that is called "2" if you look at the pipe from the 1234 side and is called "1" if you look from 5678 side .. Hmm quite confusing in my poor mind
Maybe there was restrictions .. However it's usually better to use the same number from both sides IMHO
Obviuosly YMMV (eheheh)
-s-
Message was edited by:
Stefano Del Corno
pctech321
1 Rookie
•
92 Posts
0
January 8th, 2008 13:00
here, all of the device groups are regular only...
server1/root: /var/symapi/log > symdg list
D E V I C E G R O U P S
Number of
Name Type Valid Symmetrix ID Devs GKs BCVs VDEVs
county1_dg REGULAR Yes XXXXX 2 0 4 0
county2_dg REGULAR Yes XXXXX 3 0 6 0
zone3_dg REGULAR Yes XXXXX 2 0 4 0
zone5_dg REGULAR Yes XXXXX 3 0 6 0
zone6_dg REGULAR Yes XXXXXX 37 0 74 0
--------snipped------
we are using Timefinder/mirror for local replication and SRDF/S for RDF process..
number of bcvs should of same as standard devs right ..why the number of BCV's number is double ??
i am wonder all these Groups SRDF are running at diff stages like one group is at synchronizing state , the other is at split state ....so we need to make sure that replication stages of groups shouldn't be overlapped ???
as i said earlier i am new to this Replication stuff even EMC tech....Pipe is like hardcored structure to link between local and remote or its like WAN link ..how can we find out pipe charactaristics? is EMC engineer will design that at initial setup ??
thank you..
xe2sdc
6 Operator
•
2.8K Posts
0
January 9th, 2008 01:00
here, all of the device groups are regular only...
You can't run symrdf against a "regular" group .. You need either a RDF1 or a RDF2 group if you want to look at SRDF. The best way is to write down the configuration of every DG (symdg show country1_dg), delete them (symdg -force delete country1_dg) and recreate from scratch (symdg -type RDF1 create country1_dg). Now you can add again the devices via symld and symbcv.
I assume you are creating DGs on the host that you used when issuing the "symrdf list" command. The host have a local box that contain R1 devices so you have to create a RDF1 type device group.
..why the number of BCV's number is double ??
Really difficult to say WHY you have 2 STD and 4 BCV
stages like one group is at synchronizing state , the
other is at split state ....so we need to make sure
that replication stages of groups shouldn't be
overlapped ???
You can split and establish all the groups one by one or all together .. or half and half ..
With SRDF/S you can change the status of the replica for every single device pair (R1/R2).
even EMC tech....Pipe is like hardcored structure to
link between local and remote or its like WAN link
..how can we find out pipe charactaristics? is EMC
engineer will design that at initial setup ??
I used the word "pipe" just to give something easier then "RDF group". A RdfGroup in my mind is something like a pipe that goes from one box to the other .. Given the pipe you know who is your peer (the pipe is a point-to-point connection). So in your example when you are inside box 1234, you know that pushing data into pipe named "2" will send data to box 5678 .. and from the other side of the rdf link (on box 5678) you know that data coming from pipe 1 is coming from box 1234.
Please note that it's perfectly legal to have different numbers for the same pipe when seen from the two different sides .. It's only a little cumbersome to me
Usually RDF groups are created in the binfile (so usually the Customer Engineer will create them for you) .. But since we have also Dynamic RDF, you can even create your own RDF groups (if you have the right "flags" here and there)
Cheers !!
MarcT2
2 Intern
•
131 Posts
0
January 9th, 2008 04:00
Try:
symmir -g query -multi
...and see if there are two BCVs per standard.
I also suspect (from what you've said) that the BCVs are actually BCV/R1 devices. They get established periodically and the changes are sent over the RDF link (usually in Adaptive Copy) when they're subsequently split.
This would explain why the device group type is REGULAR (because the STD is a regular device with no RDF). The BCV is the RDF device.
These BCVs wouldn't need to be mapped to an FA port, because they don't need to be seen by a host.
Often there is some custom scripting to drive all this.
M
Message was edited by:
MarcT