ONTAP Discussions

SVM-DR, CIFS

EwyWins
6,842 Views

Hi there,

 

I know this question has been asked several times and god knows i have read every post i could find about it but i am having a hard time trying to convince myself that i understand what i am trying to do. First a little background on the environment. We currently have 2 Datacenters (DC) each with a cluster of FAS8000 (Ontap 9.2) each serving different sets of data through CIFS. Datacenter A has CIFS lifs on vlan 1 and Datacenter B has CIFS lifs on vlan 2. Streching the LAN is not an issue for us. Now, our goal is to be able to create/protect SVM-CIFS-DC-A on Datacenter B and SVM-CIFS-DC-B on Datacenter A through SVM-DR. As I read the SVM-DR express guide it seems possible to replicate the SVM network configuration as well. One of our goals is also making the failover as transparent to our clients as we can, meaning we dont want have to modify clients DNS TTLs or mess arround with CNAMES in the event of a failover. We have heard of the use of loadbalancer but havent been able to find a reference architecture that makes use of them (if you have it please share it). So, in the event of a failure in DC-A's filer would not my clients that were accessing data from DC-A be able to retrive data from the protected SVM-CIFS-DC-A brought up in DC-B after i bring it up and ARP does it things and updates the new "MAC" associated with the CIFS lif brought up on Filer B which has the same IP as in DC A? What I am missing? Where do the CNAME and loadbalancer sit here. I dont even see a need for them...

Thanks in advance and sorry for the long post 🙂

1 ACCEPTED SOLUTION

aborzenkov
6,820 Views

 

If you can stretch VLANs across datacenters, migration should just work, nothing special to be done.

View solution in original post

9 REPLIES 9

aborzenkov
6,821 Views

 

If you can stretch VLANs across datacenters, migration should just work, nothing special to be done.

JGPSHNTAP
6,808 Views

just an FYI - we don't stretch vlans, and we use the -discard network flag and we use LOTS of svm-DR.  We love it.

 

Just note that there are some new features within data ontap where svm-dr cannot work, like fabric pools

EwyWins
6,790 Views

Thank you for the quick reply. In your case doesnt that mean that you will need to modify DNS records if you have to bring the Destintion SVM up since it now has a different CIFS lif with a different IP? For instance if a custmer was accessing a CIFS root share \\ProdSVM which resolves to IP 1.2.3.4 in vlan 10 and you fail over to the Destination svm, where you didnt replicate the network config and it is using an IP on vlan 20 now, how is the client going to now be able to access the \\ProdSVM share which must resolve to a different IP on the Destination SVM without you modiying the DNS record manually for \\ProdSVM to point it to the new CIFS lif IP on the destination datacenter? Thanks in advance.

JGPSHNTAP
6,786 Views

Sorry,  I forgot the important part, we use 3DNS wide-ip pools that do all our automatic failover based on the resource pool settings

ArchonTech
6,763 Views

Are your SVM-DR failovers scripted? Or do you guys use a runbook to manually failover? Can anyone point me to the reference architecture or to an example of the SVM-DR script used to failover and failback? The OnTap 9 SVM Disaster Recovery Express Guide describes a very manual process. I'd love to see how this is being done in the real-world.

JGPSHNTAP
6,760 Views

We've developed fully functional SVM-DR Scripts for failover/failbackup and clean-up of snaps.

 

These are proprietory scripts so we cannot post, but we can answer questions

ArchonTech
6,755 Views

Not even if you remove or obfuscate personal information?

JGPSHNTAP
6,747 Views

Yup, even if I remove it.  I used to post a lot of scripts in the past, but then I get tons of private emails, so it was distracting.

 

It's really simple, all the cmdlets work

ArchonTech
6,703 Views

We're all adults here, If the cost of viewing a real-life working script is not asking any questions then you won't get a beep out of me. Should you be compelled to share privately, I would be glad to share my contact information or coordinate an upload destination. Thank you for all of the great informaiton regardless.

Public