There are a couple of options you can choose for DR - this description is just what I like in my configurations. I use this from small DR setups all the way to my current gig which flips over about 1400 volumes with associated shares/LUNs for both testing and (hopefully never) real DR.
General setup: On DR side I match SVMs one to one from production, but with different names. Our style has a location identifier in the SVM, but a functional identifier works as well. So, for example SVM prod-svm01 would have a DR equivalent SVM of dr-svm01. Although you could I don't like to use the same SVM name on both ends because then you depend on DNS or other lookups at both ends to be sure you seeing the correct one. I prefer access control to be a bit more specific when not in a DR test or actual situation. Especially for CIFS I create a different CIFS server on the DR side up front (traditionally I match SVM and CIFS server name for convenience). I prefer to have the CIFS server up and running in DR all the time rather than jump at DR time.
For SnapMirrors I use the same volume name on both ends - just convenient - unless I can't for some reason. Example - SRM on ESX hasn't always played nice with the same volume name at both ends. Where I don't use the same volume, I use a simple prefix like "DR_" in front of the DR side versions.
A tricky part of cDOT and DR is namespaces. You can't share a volume until it is mounted, and you can't mount a SnapMirror destination until after it is initialized the first time. This is similar to behavior in 7-mode but with the extra mount step. So you have two basic options - mount and share the replicas ahead of time through the DR SVMs or mount/share at actual DR time. Either one is workable. The advantage of pre-mounting is that you can then just alias the DR SVM as the Production SVM when the time is right. A disadvantage of pre-mounting is that it is somewhat less flexible. Let me explain.
For DR testing, my configuration leaves all the destination SnapMirrors running in place, since we have to maintain short RPO/RTO's and we might be running a multi-day test. For testing, I FlexClone all the target DR volumes (pre-scripted), mount the clones, and then define shares/LUNs as needed. If the originals were pre-mounted, I couldn't mount the clones at the same location. If I didn't conduct my tests this way, I'd probably pre-mount the destination volumes.
So for pre-mounting and sharing, as I create volumes that need DR, I immediately initialize the SnapMirror copy so I could then define mounts and shares on both Prod and DR at the same time. If you follow this idea, after each volume/mirror creation you will have two shares, either NFS or CIFS, just from different servers, and of course the DR copies are read-only.
When it comes time to DR a solution like this, NFS is easy - update the DNS to point the Prod server address to the DR side by CNAME, A, whatever you prefer, or add the IP address as a alias on a LIF in DR. Lot's of ways to do that. Break the mirrors to bring the volumes into read-write state, bring up your DR servers, instant data.
CIFS is a little trickier to do 100% right. Remember that CIFS clients have multiple ways of identifying who is who - DNS lookups, Active Directory, etc. And it isn't easy to just change the CIFS name on the DR server - if you delete and re-add as the original production name you wipe out the shares so any pre-mounting advantage is lost and you are back to a script to recreate them all. Here is one way you can alias CIFS servers in both DNS and AD. It is a little drastic, so be careful with it.
CIFS clients typically just need the DNS update thing to work. I prefer to actually change the original A/PTR records in DNS to set the DR version IP address. When I get to DoT 8.3, I will also add a NetBIOS alias at the DR side just for completeness of name response. This covers just about everyone's needs in practice, and it's easy to reverse.
However, some AD users that need to authenticate a machine need to do a SPN lookup in AD. I've run into this most often with SQLServer setups. SPNs don't get corrected by a simple DNS change - they want to find a particular hosting server and they get really picky about it. So for my DR, in AD I also delete the server objects that represent the production side CIFS servers, then use the "SETSPN" utility (details from Microsoft here) to add the SPN's of the production side CIFS vServers to the DR side equivalents. This covers the odd cases.
Note that this also destroys the original production side AD server object. In a real DR might not be so bad - but it is a little harder in test situations. I have a completely isolated test AD environment to use when we run our DR tests, so this is safe. If you don't have the isolation required, the SPN thing might not be available to you, but then hopefully you also don't need it. I haven't yet setup cDOT 8.3 in DR, so I don't know if the NetBIOS aliasing that is now back in cDOT would also mitigate the SPN issue.
Lastly - LUNs. Even if pre-mounting/sharing CIFS/NFS shares I don't do the same with LUNs. Depends on the OS of course, but most servers I use don't really like read-only LUNs. So those I map and mount on DR servers only at time of need, and that is just scripts - one to break/clone all the appropriate volumes, one to do the mapping/mounting (I am fortunate to use SnapDrive so the scripts are trivial but they do take a while to mount), and then a reverse pair to undo all that when my DR test is done. Igroups are preset for the target servers of course so that doesn't have to be done during a DR.
In general through the mechanisms are slightly different, I think the general approach remains the same between 7-mode and cDOT. Hope this helps you.
Bob
Lead Storage Engineer
Huron Consulting Group
NCDA, NCIE-SAN (Clustered)
