This post is more than 5 years old
30 Posts
0
3229
Any problem using a BCV as an STD?
Hello all,
I currently have Server2 running on BCV+TDEV's cloned from RDF1+TDEV's used by Server1. I've been instructed to divest of Server1 and its storage now and to keep Server2 running on its BCV+TDEV's temporarily until it is also divested in the near future, whatever "near" means. I imagine it should be pretty easy:
1) Split (is that the right term?) the clones so they run independently from the source devices
2) Dismantle the cloning relationship between Server1's RDF1+TDEV volumes and Server2's BCV+TDEV volumes
3) Delete Server1's RDF1+TDEV volumes
4) Let Server2's BCV+TDEV volumes function independently as though they were STD's, filling the role of a regular TDEV for Server2
Before I implement this, I want to ask whether anyone can confirm for me that the BCV's will still have all of the cloned data even after I end the cloning relationship and delete their source devices, the RDF1+TDEV's. I'm afraid that when I break the replication relationship or when I delete the RDF1+TDEV's, the BCV+TDEV's might realize that they're now being used in the role of STD's instead of BCV's and might somehow freak out and dump all of the data that has been copied over to them from the RDF1+TDEV's.
Can anyone tell me that that won't happen? Thanks!
echolaughmk
522 Posts
0
July 27th, 2016 04:00
Hi Ben,
Your procedure is correct. For #1, it is more than likely using clone emulation under the covers and if that is the case and it is not using true symmir BCV's, you could accomplish #1 and #2 in the same step by just terminating the clone relationship between the pairs. But either way, you have the correct thought process down, just make sure in #3 you are unmapping and unmasking the devices to Server1 prior to deletion since it will prevent you if you don't.
For #4, you can leave them with the BCV attribute on the volumes or you could remove the BCV attribute online with a volume config change using the "convert dev" command and flip them back to regular STD's for any reporting you might have:
echolaughmk
522 Posts
1
July 27th, 2016 05:00
Yup...you raise a good point dynamox!.....I made some assumptions in my reply (I usually see precopies with -diff used the majority of the time) without all the info. But you are correct on nocopy mode that if used, since it is CoA, you will want to set the mode to copy, wait til you have verified all the tracks have copied to Server2's targets, and then do the termination, otherwise if you terminate while it is CopyOnAccess, it could render Server2's LUNs as unuable cause it never copied all of the data.
The one part I can't test at the moment and is fuzzy in my head is if you have to re-create the activation after changing the mode to copy. My assumption is that upon setting that mode, it would just start to copy all of the tracks since I am guessing the Server2's LUNs are already in use and therefore the session (using symclone) is activated to make them R/W.
Ben - if you get a chance to further define the environment (symclone vs emulation, copy session variables, etc), let us know.
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
1
July 27th, 2016 05:00
Keith, what if it's a clone that was created using -nocopy. I have never used that option but it's something that needs to be looked at before terminating the session. I don't think terminate -nocopy session will force source to copy everything to target. Thoughts ?
ben_brooks
30 Posts
0
July 27th, 2016 22:00
$ sudo symclone query -g _dg
Device Group (DG) Name: _dg
DG's Type : RDF1
DG's Symmetrix ID : 00019570
Source Device Target Device State Cpy
--------------------------------- ---------------------------- ------------ ---
Sym Protected Modified Sym Modified
Logical Dev Tracks Tracks Logical Dev Tracks CGDP SRC <=> TGT (%)
--------------------------------- ---------------------------- ------------ ---
DEV001 016C6 0 0 N/A 016DC 0 X.X. Copied 100
DEV002 016C7 0 0 N/A 016DD 0 X.X. Copied 100
DEV003 016C8 0 0 N/A 016DE 0 X.X. Copied 100
DEV004 016C9 0 0 N/A 016DF 0 X.X. Copied 100
DEV005 016CA 0 0 N/A 016E0 0 X.X. Copied 100
DEV006 016CB 0 0 N/A 016E1 0 X.X. Copied 100
DEV007 016CC 0 0 N/A 016E2 0 X.X. Copied 100
DEV008 016CD 0 0 N/A 016E3 0 X.X. Copied 100
DEV009 016CE 0 0 N/A 016E4 0 X.X. Copied 100
DEV010 016CF 0 0 N/A 016E5 0 X.X. Copied 100
DEV011 016D0 0 0 N/A 016E6 0 X.X. Copied 100
DEV012 016D1 0 0 N/A 016E7 0 X.X. Copied 100
DEV013 016D2 0 0 N/A 016E8 0 X.X. Copied 100
DEV014 016D3 0 0 N/A 016E9 0 X.X. Copied 100
DEV015 016D4 0 0 N/A 016EA 0 X.X. Copied 100
DEV016 016D5 0 0 N/A 016EB 0 X.X. Copied 100
DEV017 016D6 0 0 N/A 016EC 0 X.X. Copied 100
DEV018 016D7 0 0 N/A 016ED 0 X.X. Copied 100
DEV019 016D8 0 0 N/A 016EE 0 X.X. Copied 100
DEV020 016D9 0 0 N/A 0192F 0 X.X. Copied 100
DEV023 0282B 0 0 N/A 02830 0 X.X. Copied 100
DEV024 0282C 0 0 N/A 02831 0 X.X. Copied 100
DEV025 0282D 0 0 N/A 02832 0 X.X. Copied 100
DEV026 0282E 0 0 N/A 02833 0 X.X. Copied 100
DEV027 0282F 0 0 N/A 02834 0 X.X. Copied 100
DEV028 0163E 0 0 N/A 01FD5 0 X.X. Copied 100
DEV029 0163F 0 0 N/A 01FD6 0 X.X. Copied 100
DEV030 01640 0 0 N/A 01FD7 0 X.X. Copied 100
Total --------- -------- --------
Track(s) 0 0 0
MB(s) 0.0 0.0 0.0
Legend:
(C): X = The background copy setting is active for this pair.
V = The VP Snap setting is active for this pair.
. = Neither setting is active for this pair.
(G): X = The Target device is associated with this group.
. = The Target device is not associated with this group.
(D): X = The Clone session is a differential copy session.
. = The Clone session is not a differential copy session.
(P): X = The pre-copy operation has completed one cycle.
. = The pre-copy operation has not completed one cycle.
$
ben_brooks
30 Posts
0
July 27th, 2016 22:00
$ sudo symsg -sid show _SG
Name: _SG
Symmetrix ID : 00019570
Last updated at : Tue Apr 07 06:06:29 2015
Masking Views : Yes
FAST Managed : Yes
SLO Name : N/A
Workload : N/A
SRP Name : N/A
Host I/O Limit : None
Host I/O Limit MB/Sec : N/A
Host I/O Limit IO/Sec : N/A
Dynamic Distribution : N/A
Number of Storage Groups : 0
Storage Group Names : N/A
Number of Gatekeepers : 0
Devices (65):
{
----------------------------------------------------------------
Sym Device Cap
Dev Pdev Name Config Attr Sts (MB)
----------------------------------------------------------------
016DC N/A BCV+TDEV RW 69053
016DD N/A BCV+TDEV RW 69053
016DE N/A BCV+TDEV RW 69053
016DF N/A BCV+TDEV RW 69053
016E0 N/A BCV+TDEV RW 69053
016E1 N/A BCV+TDEV RW 69053
016E2 N/A BCV+TDEV RW 69053
016E3 N/A BCV+TDEV RW 69053
016E4 N/A BCV+TDEV RW 69053
016E5 N/A BCV+TDEV RW 69053
016E6 N/A BCV+TDEV RW 69053
016E7 N/A BCV+TDEV RW 69053
016E8 N/A BCV+TDEV RW 69053
016E9 N/A BCV+TDEV RW 69053
016EA N/A BCV+TDEV RW 69053
016EB N/A BCV+TDEV RW 69053
016EC N/A BCV+TDEV RW 69053
016ED N/A BCV+TDEV RW 69053
016EE N/A BCV+TDEV RW 69053
0192F N/A BCV+TDEV RW 69053
01FD5 N/A BCV+TDEV RW 69053
01FD6 N/A BCV+TDEV RW 69053
01FD7 N/A BCV+TDEV RW 69053
02301 N/A TDEV RW 69053
02302 N/A TDEV RW 69053
02303 N/A TDEV RW 69053
02304 N/A TDEV RW 69053
02305 N/A TDEV RW 69053
02306 N/A TDEV RW 69053
02307 N/A TDEV RW 69053
02308 N/A TDEV RW 69053
02309 N/A TDEV RW 69053
0230A N/A TDEV RW 69053
0230B N/A TDEV RW 69053
0230C N/A TDEV RW 69053
0230D N/A TDEV RW 69053
0230E N/A TDEV RW 69053
0230F N/A TDEV RW 69053
02310 N/A TDEV RW 69053
02311 N/A TDEV RW 69053
02312 N/A TDEV RW 69053
02313 N/A TDEV RW 69053
02314 N/A TDEV RW 69053
02315 N/A TDEV RW 69053
02316 N/A TDEV RW 69053
02830 N/A BCV+TDEV RW 69053
02831 N/A BCV+TDEV RW 69053
02832 N/A BCV+TDEV RW 69053
02833 N/A BCV+TDEV RW 69053
02834 N/A BCV+TDEV RW 69053
02850 N/A TDEV RW 69053
02851 N/A TDEV RW 69053
02852 N/A TDEV RW 69053
02853 N/A TDEV RW 69053
02854 N/A TDEV RW 69053
02855 N/A TDEV RW 69053
02856 N/A TDEV RW 69053
02857 N/A TDEV RW 69053
02858 N/A TDEV RW 69053
02859 N/A TDEV RW 69053
0285A N/A TDEV RW 69053
0285B N/A TDEV RW 69053
0285C N/A TDEV RW 69053
0285D N/A TDEV RW 69053
0285E N/A TDEV RW 69053
}
$
ben_brooks
30 Posts
0
July 27th, 2016 22:00
echolaughmk and dynamox, thank you for your very thorough answers! It sounds like it will take some work to figure out the correct way to end the cloning relationship, but I will ultimately be able to keep the BCV's in use without data loss, even after the source devices are destroyed. That's good news.
I'm new to BCV's and I don't know how to answer your questions about symclone vs. emulation, copy session variables, and the like. If you can tell me some SymCLI commands, I can run them and paste their output here.
The thing that confuses me about these BCV's and makes it difficult to know how to dismantle the replication relationship, is that these BCV's are read/write to Server2 but they also show zero modified tracks between them and their source devices, as though they're still synchronized. I thought a clone device could be either sync'ed to its source device or RW to a server but not both simultaneously. Clearly, I don't know BCV's very well.
After this post, I'll post the output of three commands to show what I'm talking about.
1) "symsg show" on the BCVs' SG. (You can see that Server2 has some ordinary TDV's mixed in with the BCV+TDEV's.) All the BCV's are RW to Server2.
2) "symdev show" on the first device listed in the "symsg show". It doesn't say much to me, but perhaps you will be able to make something out of it, especially the "BCV Pair Information" and "Clone Device Information" sections at the bottom.
3) "symclone query" on the device group that represents Server1's RDF1+TDEV's. It shows no modified tracks on any device, and the CGDP column says, "The background copy setting is active for this pair," for every pair in the list. This is what makes me think data is being copied to these BCV's, even while Server2 is able to write to them.
I've edited the array SID and the servers' true names in these outputs.
ben_brooks
30 Posts
0
July 27th, 2016 22:00
$ sudo symdev -sid show 016DC
Device Physical Name : Not Visible
Device Symmetrix Name : 016DC
Device Serial ID : N/A
Symmetrix ID : 00019570
Number of RAID Groups : 0
Encapsulated Device : No
Encapsulated WWN : N/A
Encapsulated Device Flags: None
Encapsulated Array ID : N/A
Encapsulated Device Name : N/A
Vendor ID : EMC
Product ID : SYMMETRIX
Product Revision : 5876
Device WWN : 6000097000019570 533031364443
Device Emulation Type : FBA
Device Defined Label Type: N/A
Device Defined Label : N/A
Device Sub System Id : 0x0001
Cache Partition Name : DEFAULT_PARTITION
Bound Pool Name : SATA_F_Pool
Device Block Size : 512
Device Capacity
{
Cylinders : 73657
Tracks : 1104855
512-byte Blocks : 141421440
MegaBytes : 69053
KiloBytes : 70710720
Geometry Limited : No
}
Device External Identity
{
Device WWN : 6000097000019570 533031364443
Front Director Paths (2):
{
------------------------------------
DIRECTOR PORT LUN
------------ ---- -------- ---------
Type Num Sts VBUS TID SYMM Host
------------------------------------
FA 01F:001 RW 000 03 001 N/A
FA 16F:001 RW 000 03 001 N/A
}
Geometry : Native
{
Sectors/Track : 128
Tracks/Cylinder : 15
Cylinders : 73657
512-byte Blocks : 141421440
MegaBytes : 69053
KiloBytes : 70710720
}
}
Device Configuration : BCV+TDEV
SCSI-3 Persistent Reserve: Enabled
Dynamic Spare Invoked : No
Dynamic RDF Capability : None
STAR Mode : No
STAR Recovery Capability : None
STAR Recovery State : NA
SQAR_MODE : No
Device Service State : Normal
Device Status : Ready (RW)
Device SA Status : Ready (RW)
Device User Pinned : False
Host Access Mode : Active
Device Tag(s) : None
Extent Based Clone : None
DIF1 Flag : False
Gatekeeper Device : False
AS400_GK : False
Host Cache Registered : False
Optimized Read Miss : System
Front Director Paths (2):
{
-----------------------------------------------------------------------
POWERPATH DIRECTOR PORT LUN
--------- ------------ ---- -------- ---------
PdevName Type Type Num Sts VBUS TID SYMM Host
-----------------------------------------------------------------------
Not Visible N/A FA 01F:001 RW 000 03 001 N/A
Not Visible N/A FA 16F:001 RW 000 03 001 N/A
}
Mirror Set Type : [Thin,N/A,N/A,N/A]
Mirror Set DA Status : [RW,N/A,N/A,N/A]
Mirror Set Inv. Tracks : [0,0,0,0]
Mirror Configuration Information
{
Mirror Number : 1
Mirror Type : Thin
Mirror Status : Ready (RW)
}
BCV Pair Information
{
Standard (STD) Device Symmetrix Name : N/A
Standard (STD) Device Serial ID : N/A
Standard (STD) Device Group Name : N/A
Standard (STD) Composite Group Name : N/A
BCV Device Symmetrix Name : 016DC
BCV Device Serial ID : Not Visible
BCV Device Associated Group Name : Not/Associated
BCV Device Associated CG Name : Not/Associated
BCV Device Status : Ready (RW)
State of Pair ( STD BCV ) : NeverEstab
Time of Last BCV Action : N/A
State of BCV Mirrors : Synchronized
BCV State Flags : (AllReady)
Number of Inv. Tracks for STD Device : 0
Number of Inv. Tracks for BCV Device : 0
}
Clone Device Information
{
Source (SRC) Device Symmetrix Name : 016C6
Source (SRC) Device Group Name : _dg
Source (SRC) Composite Group Name :
Target (TGT) Device Symmetrix Name : 016DC
Target (TGT) Device Group Name : N/A
Target (TGT) Composite Group Name : N/A
State of Session (SRC ====> TGT) : Copied
Percent Copied : 100%
Time of Last Clone Action : Tue May 17 19:32:52 2016
Clone State Flags : (Copy) (Diff)
Number of Prot. Tracks for SRC Device : 0
Number of Indir Tracks for TGT Device : 0
Number of Changed Tracks for SRC Device: 0
Number of Changed Tracks for TGT Device: 0
Number of Inactive Duplicate Sessions : 0
}
$
ben_brooks
30 Posts
0
July 27th, 2016 22:00
Oof, sorry for the formatting on these three outputs. It looked tidier in Notepad. Let me know if you'd like it delivered as .txt attachments or screenshots or something. Thanks for all your help with this!
echolaughmk
522 Posts
1
July 28th, 2016 04:00
that output looks like it is a copy/differential session so that takes the "nocopy" discussion out of it. It looks like emulation was used, but under the covers it is symclone. since they are 100% copied, you can likely just terminate them to split the relationship...which will remove any query (since they are not associated to each other anymore) and leave both the Source and Targets as R/W as they are.
The "0" tracks modified would change if you did a re-create and it had to update the session information between the pairs to know what incremental changes need to be copied. You look pretty clean here so that is good news. Since you are using DG's, you'll likely want to delete that DG as well as part of your list since it won't have any pairings in it anymore after you terminate.
-Keith
ben_brooks
30 Posts
0
July 28th, 2016 15:00
Thanks, Keith! So it sounds like it should be as simple as...
1) symclone query -g _dg # To verify all device pairs are still in the Copied state
2) symclone terminate -g _dg
3) symdg delete _dg -force
4) Unbind and delete the RDF1+TDEV's
Am I missing any important options or arguments above?
Many thanks,
Ben
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
0
July 28th, 2016 16:00
Ben,
pretty close, you will not be able to delete RDF1+TDEVs until you delete RDF relationship (deletepair).
echolaughmk
522 Posts
0
July 28th, 2016 16:00
dynamox beat me to it!
The only other thing I might add is that if you have any meta volumes, after you do what dynamox says to delete the rdf pair, you will have to dissolve the meta's and then delete this individual members. Otherwise you should be ready to rock.
ben_brooks
30 Posts
0
July 29th, 2016 02:00
dynamox and Keith, thanks again for all your help on this; I feel a lot better about it now. I will undo the SRDF pairings before I delete the RDF1+TDEV's, and they aren't metas so I won't have to dissolve them. I'll pass out some green and yellow stars for your answers.
Thanks,
Ben