ONTAP Discussions

Can I transition Volume level DR -> SVM DR?

tomekp
9,853 Views

Hi folks,

 

Short description of my environment: Data ONTAP 8.3.1, two clusters: clus1, clus2 (different physical locations)

 

In my environment I've got couple SVMs serving CIFS-only or CIFS/NFS data. Each primary_SVM (clus1)  has it's secondary_SVM created on clus2 (different location) to which all volumes are replicating (via snapmirror). No customer access to secondary_SVMs.  Both SVM subtypes are default. This configuration was created while those clusters were on ONTAP 8.2 (No "SVM_DR" available at that time). All volumes are being replicated, however secondary_SVM has no replication of CIFS shares or NFS export-policies. Please correct me if I'm wrong, but I understand such configuration as volume-level disaster recovery setup.

 

Lately a new SVM has been created, and since ONTAP version (8.3.1) gives us the possibility to create SVM DR relationship, the new_SVM (SVM subtype: default) in clus1 has it's new_SVM_DR (SVM subtype:dp-destination) on clus2. In this configuration all CIFS share information is also replicated to my DR site (clus2). 

 

Now time for main main questions:

1. Is there any way I can transition/modify my old_secondary_SVMs (subtype: default) to DR_secondary_SVMs (subtype:dp-destination)? I would like to replicate CIFS shares information, and hopefully export policies for volumes and qtrees. What I would love is to avoid a need for data baseline transfers.

If there only way is a need to destory SVM_secondary and create a new one as subtype:dp-destination, but I can still keep the volumes on clus2  -  I'll be able to resync volumes snapmirror without going through baseline again - that would be great!

 

2. My DR plan assumes: SVM_DR has a seperate CIFS server with seperate objet / different name joined to the same domain. During DR we would only create a DNS alias SVM_name (-alias->) SVM_DR_name.  In such configuration we should set  Identity-preserve to  false - correct? How can I secure my NFS shares / export-policy information to DR site then? According to what I read, export-policy is only replicated if  identity-preserve=true  is set, but that would affect my CIFS config during DR.

 

Thanks in advance.

13 REPLIES 13

aborzenkov
9,811 Views

It sounds like you need ONTAP 9 that supports both converting regular snapmirror to disaster recovery snapmirror and identity preserve excluding LIF configuration.

tomekp
9,796 Views

thanks for a quick response! Does that mean that with ONTAP 8.3.x  it's literally not possible to convert regular SM to disaster recovery SM, right?

 

I cannot find any good document that describes those functions in ONTAP 9, is there any 'data protection guide' or 'storage admin guide' for ontap 9, or not yet released?

JGPSHNTAP
9,771 Views

There are thousands of pages of documentation plus TR.  Download the ontap 9.x docs and you can go from there.

 

Also, i'm not sure why you wouldn't want to keep the CIFS server name in DR if its an active DR.

tomekp
9,725 Views

@JGPSHNTAPthanks! You have a good point! It's my lack of understanding the subject I guess.

If I decide to keep the same CIFS server name on my DR - how does that work during the potential disaster?

My primary site is not available, then I start SVM on my secondary_site.. Should I join the CIFS server to domain under same name as it was on source, or is CIFS server will automatically start as a member of domain, since it was somehow replicated from source?

 

I'm also confused about LIF replication. If I keep identity-preserve=true it wil also replicate my data/NAS LIFs.. I guess it's not only the LIF name, but also the IP configuration. In such cases both source and destination must configured wit the same VLAN, so they can keep same IP addresses, right ?

 

JGPSHNTAP
9,712 Views

I would always recommend using identity preserve b/c of the CIFS server.  You want the same cifs server name in DR, and not an alias or use of SPNS.  It makes life easier.  

 

 

If your primary site is down you don't have to do anything different, you bring up the DR site and flip your DNS (we use 3DNS GTM) so its auto for us, but that is how we do it.

 

In 9.0, we use identity preserve and discard network configs b/c our VLAN is different in the DR site.

 

 

There is tons of documentation on SVM DR, but for the old timers like us, this is pretty common from the 7-mode days.  It was called vfiler-dr and works amazing

Lei
9,154 Views

we have the similar issues after the 7 to C transition.

even i am in 9.2P1 , this one still not working 

 

Converting volume-level SnapMirror relationships to an SVM disaster recovery relationship 

From Data Protection Using SnapMirror®and SnapVault® Technology

Vidhs
8,063 Views

After transition, volume level snapmirror can be converted to SVM level snapmirror, guess starting 9.X

 

Was able to get it working for a SVM which has NFS/CIFS and NO SAN on ontap 9.1 P10.

 

For this to work, volume level snapmirrors should be undisturbed.

 

create a new snapmirror relationship including both vservers with identity preserve option as true. Then a resync directly (initially will warn the DR SVM should be stopped) will get a new SVM level snapmirror by itself deleting volume level relationships.


@Lei wrote:

we have the similar issues after the 7 to C transition.

even i am in 9.2P1 , this one still not working 

 

Converting volume-level SnapMirror relationships to an SVM disaster recovery relationship 

From Data Protection Using SnapMirror®and SnapVault® Technology


 

Lei
8,007 Views

Thanks,

yes, you are right, we have this issues fixed.  

Lei
7,272 Views

Sorry to re-open this topic.

 

Has anyone experienced the issue in 9.3P3 or above ?

 

Seems from 9.3 the default DP replaced by XDP.  and i keep getting error message "Error: command failed: There are one or more volumes in this Vserver which do not have a volume-level SnapMirror relationship with volumes in Vserver "soure"."

 

 

snapmirror create -source-path soure: -destination-path dest: -type DP -throttle unlimited -policy DPDefault -schedule daily -identity-preserve true

vserver stop dest

 

snapmirror resync dest:

Error: command failed: There are one or more volumes in this Vserver which do not have a volume-level SnapMirror relationship with volumes in Vserver "soure".

 

 

 

Steve_Norrie
7,167 Views

Yes, I am getting exactly the same message now, after upgrading from 9.2p2 to 9.3p5

 

did you find a resolution to this?

aborzenkov
9,733 Views

@tomekp wrote:

Does that mean that with ONTAP 8.3.x  it's literally not possible to convert regular SM to disaster recovery SM, right?


 

That's something only NetApp internal can answer. I can only say that this feature is listed as new in ONTAP 9 release notes and is not documented in 8.3.x manuals.

Lei
7,156 Views
Hi,Steve,

Yes I did eventually.

Seems 9.3P2/3 behaviour are tiny little different with 9.3P5, I even updated and really expect P5 fixe it which was not!

So have to use this hidden command to force 9.3 treat default snapmirror from XDP to DP
options replication.create_data_protection_rels.enable true

Then rest are similar when we have DP can easily convert from volume snapmirror to SVM DR relationships !

Refer to this KB
https://kb.netapp.com/app/answers/answer_view/a_id/1071159/loc/en_US#__highlight

Give it a try ? If you have any problems let me know , although it still trying to replicate everything from PROD to DR including Cifs server which not good .

Cheers
Lei

Lei
7,150 Views
 
Public