Subscribe
Accepted Solution

CIFS, SnapMirror and DR

Hi,

 

I need to put together a DR strategy for our CIFS data. We're moving to NetApp 9.x.

 

I think SVM-DR is out of the question because the arrays at the primary and secondary sites will be on different subnets. If it were possible I think the other drawback is that all the configured mirrors will kick off at the same time. I'm thinking that all the concurrent mirror activity may casue an issue down the road as we scale.

 

I'm thinking of re-pointing DNS after a switchiver to the secondary, i.e. netapp-pri DNS record is re-configured with the IP address of netapp-sec, but I'm concenred about the DNS cache on the servers and clients not flushing in a timely manner.

 

What's my best option please?

 

Thanks

Re: CIFS, SnapMirror and DR

Hi,

 

One option would be to configure your SMV with multiple CIFS LIFS (one on the production subnet that is enabled, the other on the DR subnet that is disabled). When you failover you can toggle the LIF up\down status depending on the site. You may consider setting a DNS CName alias for the vserver and lowering the TTL of your DNS record. This enables you to abstract the vserver hostname from the clients (if that's required). Hope that gives you some ideas.

 

/Matt

If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.

Re: CIFS, SnapMirror and DR

Thanks for the reply

 

I like the idea of the second DR CIFS LIF.

 

The main issue, as far as I can tell, is the clients and DNS servers will hold the IP address (in cache) of the primary array even if the primary becomes unavailable. Lowering the TTL is an option, but I am still at the mercy of time, i.e. waiting for the DNS caches to time out. Is there a more sophisticated option other than wait?

 

Thanks

Re: CIFS, SnapMirror and DR

Hi,

 

The only other methods i'm aware of for clients to avoid having to wait for DNS updates after failover would be to use a Metrocluster or a layer 2 streched VLAN between sites and use onbox SVM DR but those may not be options depending on cost and complexity in your environment.

 

Whilst it's not the best option, you could tower the default TTL (60 minutes) of your DNS Cname to 5 minutes prior to failover (assuming it's a planned failover), wait an hour until clients clear thier local DNS Cache for the CName record, then invoke SVM failover and update the CName to re-direct clients to the DNS A Record of your DR SVM. This way the maximum time your clients will have to wait is 5 minutes. Keep in mind that would generate additional DNS traffic on your network.

 

/Matt

If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.

Re: CIFS, SnapMirror and DR

[ Edited ]

I've struggled with this one. I think the above approach suggested by Matt is the best one given your circumstances

 

Re: CIFS, SnapMirror and DR

It's a situation I was hoping to avoid, but I'm limited by the architecture, i.e. no streched VLAN

 

I understand that SVM-DR triggers all SnapMirrors concurrently. How can I tell if SVM-DR is suitable for my environment, expecially in relation to scaling the shares?

Re: CIFS, SnapMirror and DR

[ Edited ]

Hi,

 

Which version of ONTAP are you planning on deploying? Will the vserver allow protocols be restricted to CIFS only? Will the clients access the data using DFS? How many CIFS shares do you plan to provision? What FAS model are you using? As general guide you can check the minimum\maximum guides (mostly hardware model dependant).

 

In 9.3 you can select which volumes within your vserver will be replicated. For CIFS there are several options you might want to consider, volume count, volume capacity, file count, network bandwidth etc. I think it depends on your infrasturcutre, if you have a lot of data you might consider splitting the load amongst multiple vservers rather than a single vserver with a large number of volumes. In my experience the higher the volume count, the longer it will take to failover to DR as there are limits on concurrent volume snapmirror transfers. It really depends on your environment and your RTO\RPO, this is probably the most important point to consider.

 

/Matt

If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.

Re: CIFS, SnapMirror and DR

Thanks for sticking with me Matt, the information is really useful.