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!
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:
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.
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 ?
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.
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!
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.
echolaughmk
2 Intern
•
522 Posts
2286
0
Posted 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: