2009-08-16 09:46 AM
I currently have 2 Netapp SAN's. One at production (netappa) and one at my dr site (netappdr). I snapmirror between these two (vmware and CIFS volumes). My question revolves around CIFS. Netappa hosts all of my productoin CIFS shares. The volume on netappa that hosts these shares gets replicated hourly on the hour to netappdr. This weekend we went to perform a DR failover test. The test went as follows.
I quiesed and broke all the snapmirrors between netappa and netappdr.
I moved netappdr and associated ESX host into a new non routeable vlan away from my production network.
I mapped my VMWare luns to the ESX host and brought up active directory (again in the non routeable vlan away from production)
At this point I have a fully functional AD domain identical to the last replication as well as my exchange and other app servers working.
Now in light of getting the CIFS shares up I went into my DNS and changed netappa from pointing to the production netappa IP to the netappdr IP. Verified that when I ping netappa i get the ip of netappdr. However, when I attempted to browse to netappa it appears netappdr would still activly refuse it.
To resolve this I tried the following:
Added a NetBIOS Alias of netapp a on the netappdr san. (no luck)
I then went into DNS and added a new entry for drsan and pointed it to the IP of netappdr. Sure enough this worked just fine. So the netappdr SAN would answer to request to it from drsan but not netappa.
The only thing I can think of at this point is that it had a broken snapmirror relationship with netappa and I'm assuming this is why it wouldn't answer to request to it coming to netappa?
My goal is simply to be able to failover all of my cifs shares from the production SAN (netappa) to the DR san (netappdr) and have it respond to the request for netappa as I have many applications in my environement that point to it for data and I'd rather not have to reconfigure them all in a DR situation.
Sorry this is so long but I hope i've given all the necesarry information.
2009-08-16 06:04 PM
In your scenario would it not be an issue to simply take the IP of a hostname and point it to the a different hostname? Does AD and DNS just
replace hostnames like that? what about cache and propagation into the domain? I am not a windows person as you can guess.
I am not aware of a scenario where hosts would not have to remap in a DR scenario as CIFS is a stateful protocol.
I may be able to help in describing a scenario where I have seen it work in the past. Picture the scenario below, similar to yours: source controller
snapmirrors to dr site where volume names are similar in both sites.
vol01 > vol01
vol02 > vol02
vol03 > vol03
vol04 > vol04
You would have to snapmirror update (to push latest data across), snapmirror quiesce, snapmirror break and then point your hosts to the DR controller.
Given that in the scenario above we have used the same volume names on both controllers this will be easier. its probably not what you want to do though.
The only thing I could add to your description is run "cifs terminate" on source controller and see what that does?
what was the error message you got? Based on your description of the problem ( you had sucess using IP) it does seem like you are close to being in
a good configuration.
2009-08-16 07:48 PM
MultiStore is a very elegant solution that can automate this. Using "vfiler dr activate" you can bring up the dr site. All mirrors are quiesced and broken automatically. Additionally, all cifs shares on the source are replicated to the dr site since the virtual filer (vfiler) configuration (vfiler root /etc) is replicated with the volumes. It's nice not to have to break all the mirrors manually and ensure all shares/exports are created on the dr site. To go back to produciton another single command "vfiler dr resync" which takes care of all the mirrors for all volumes in the virtual filer. All source configuration is maintained but you can modify the IPs, DNS and NIS on the target as a part of the dr configuration...so no need to change at the dr event since you can pre-set the information if different at the dr site. You need to add a multistore license and configure the existing resources into a virtual filer which will be minimal network downtime.