up vote 2 down vote favorite
share [g+] share [fb]

I have two windows 2008R2 servers. Both are pointing to the same iSCSI drive on our SAN, but both servers don't see the same data.

Server 1 can write data to the SAN, and can immediately see what it wrote. Server 2, can NOT see what server 1 wrote after the last time server 2 was rebooted.

The OS doesn't seem to be an issue here. I have Win2K3 servers, Win2008 servers, and 2008R2 systems, all with the same problems.

Only the one that writes can read that data until the other one is rebooted.

Where can I start looking to try and resolve this problem?

I thought the whole point of clustering ( not what I am doing, but still ), was to have two systems point to the same SAN drive, and share common data. That leads me to believe that I should be able to read and write between the two systems sharing the same drive.

What am I missing here?

link|improve this question
100% accept rate
feedback

1 Answer

up vote 14 down vote accepted

iSCSI presents block based storage to the Servers. In most scenarios the servers mount this storage with a filesystem (such as NTFS) that is owned and managed by one server only. NTFS (which is what you are probably using here) is not normally a cluster aware file system so if secondary hosts have visibility to the same volume they will either be locked out (hopefully) or will corrupt the volume.

For two separate machines to share an iSCSI volume concurrently you need to have a cluster aware file system that supports this. VMware's VMFS does this as does the Cluster Shared Volumes (CSV) clustered file system available in W2K8 R2 Hyper-V.

The simplest solution for you is to present the storage to one server and share that volume so that the second server can map to it using SMB.

Edited to add:
There's no real way around the double network hop if you opt for sharing out the volume via Windows but for most server applications you should be able to specify a UNC Path (\\Server\sharename) rather than a mapped drive letter. This will work if the service is running under an account that has rights to the share.

You don't say what sort of iSCSI target you have - it may be possible to configure it to act as (say) an SMB or NFS share directly. Windows Server 2008 R2 supports the Unix Interoperability components which includes an NFS client. This may provide you with a mechanism that avoids the double network hop but I can't comment on the performance, it might not be any better than the SMB share.

link|improve this answer
3  
+1 don't do that. The reason why the second machine can't see the first machine's writes is because the second machine is maintaining its own cache of what's going on. Sharing iSCSI LUNs RW is a good way to corrupt things. iSCSI isn't for file sharing. – David Mackintosh Oct 30 '09 at 14:05
Or use a cluster-aware file system such as Veritas Storage Manager for Windows. – Chopper3 Oct 30 '09 at 14:20
I am hopping to avoid having map the drive from one of the servers. This results in two trips over the network, which is annoying, but the show stopper is that the mapped drive is only available when I am logged in. – Russ Oct 30 '09 at 14:40
+1 for CSV.. note that as far as I recall this is only supported for shared storage of hyper-v virtual machines right now - and is extremely basic (though working for this intended task) ^^ – Oskar Duveborn Oct 30 '09 at 14:42
@Oskar - you're 100% right there - CSV's are only used for Hyper-V sharing and can't be considered general purpose file systems in any sense. There's quite a good article about CSV's here: vcritical.com/2009/09/hands-off-that-csv . The backup problem is pretty serious but DPM 2010 is supposed to resolve that. – Helvick Oct 30 '09 at 20:58
show 1 more comment
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.