topic Re: Hosting SnapMirror Destination LUN on Windows 2008R2 in Network and Storage Protocols

Hosting SnapMirror Destination LUN on Windows 2008R2

DANT98_JHUAPL — Thu, 05 Jun 2025 06:28:30 GMT

We're trying to replace Windows DFS-R with SnapMirror for a remote site fail over. I'm testing on a FAS2040 with dual controllers. I have a Qtree containing a Windows LUN on the first controller and I've configured an asyncronous mirror to a volume on the other controller. Once I put each controllers IP in /etc/hosts SnapMirroring seems to work as expected. I mapped the source LUN on one windows server via Fiber Channel and mapped the destination LUN on a different server. The destination correctly shows as a read-only disk to the Windows Storage Manager, but I can't apparently configure mount points in the GUI on a read-only device, so I used Diskpart to mount the destination. What I expected to see what a read-only FS that updated whenever a SnapMirror cycle was completed. Instead, I see a read-only view of the data from the point in time when I assigned the drive letter. If I remove and re-assign the drive letter, then the changes show up.

I don't have SnapDrive licensed yet, so I don't know if this works differently using SnapDrive. Is there a way to always see the latest version? I'd like to use DFS to redirect my remote users to this read-only copy if the WAN connection is disrupted.

Thanks,

-Dan

Re: Hosting SnapMirror Destination LUN on Windows 2008R2

aborzenkov — Fri, 27 Apr 2012 07:22:07 GMT

No, that’s not possible with or without snapdrive. No filesystem driver can handle the case when data on underlying device is changed without its knowledge.

You would really need CIFS share for it, this could be replicated and you will always get the latest content.

Re: Hosting SnapMirror Destination LUN on Windows 2008R2

DANT98_JHUAPL — Fri, 27 Apr 2012 11:09:44 GMT

I was afraid something like that might be the case.

Due to strict compliance requirements, I'm trying to avoid exposing the NetApp directly to the network, which is why I went with direct attached to my Windows cluster.

I guess maybe what I could do is develop a script which would remount the drive communication with the source partner failed.