Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I know you can't use multiples NTFS machines/servers with the same SAN iSCSI target without corruption. I have multiple servers, however, that need access to the same data on the same SAN.

I do not have Microsoft Clustering Services nor can I use it (policy and money)

Windows 2008 Server is the OS.

Do not want to open the target on one machine, share it, and have the others pointed to that machine that has the iSCSI target, as it is not redundant.

I saw MetaSan. What would you recommend? Thanks.

share|improve this question
    
I'm not seeing why you couldn't open the iscsi target on one machine and share it. It doesn't look like you're requesting any kind of redundancy in your question. –  ErnieTheGeek Jul 28 '11 at 19:07
2  
If this objective has monetary value, justifying spending the cash to upgrade to Enterprise and uses MS Cluster Services is probably easy. Installing 3rd party software, possibly poorly supported or unreliable, makes little sense. –  Chris S Jul 28 '11 at 19:09
    
In the event of a failure do you want to be able to connect the from the other machine? Perhaps you need to setup a share, and then setup a DFS name-space on top of that. That way your clients will only see the DFS name-space and not the actual server it was shared from. If you have to switch over to the other machine you just change the DFS target. –  Zoredache Jul 28 '11 at 19:51
    
Please provide more background about why you can't share it, or why the different computers need direct access to the data? Perhaps you are looking at the wrong technology. Perhaps you need replication or something. –  Zoredache Jul 28 '11 at 19:52

3 Answers 3

up vote 4 down vote accepted

You can't do it with NTFS as isn't a cluster aware file system. MetaSAN and StorNEXT are cluster file systems that can be used with Windows, StorNext was OEM'd by Apple as XSAN.

I would suggest wikipedia for further reading

share|improve this answer
1  
NTFS is actually a Cluster aware file system. Microsoft's Cluster Service (Server 2008 R2 Ent and DC) is necessary to coordinate access however. –  Chris S Jul 28 '11 at 20:20
    
@chris How can it be cluster aware if you require cluster services? –  johnny Jul 28 '11 at 20:41
4  
The filesystem itself is not cluster aware. That implies multi-mount capabilities. What MSCS does it coordinate things so that only one system at a time actually performs the mount. If that was all it took to be considered "cluster-aware", FAT32 would fit the bill. –  MikeyB Jul 28 '11 at 20:53
    
@ChrisS is saying that it is technically possible for more than one computer to talk to a single NTFS volume -- NTFS has the capability to lock itself well enough to allow write access from only one node -- but Cluster Service is the software that actually enables that feature within Windows. A regular disk mount will not do it. –  jimbobmcgee Jul 28 '11 at 21:03
    
All cluster file systems require some method of coordination. Something external to the file system itself. This can be implemented through the storage medium, but that introduces certain limitations. Most cluster file system use an external program to coordinate concurrent access (ex GFS uses DLM to coordinate). –  Chris S Jul 28 '11 at 21:21

NTFS just can't be accessed by more than one machine at the same time; even when you use Windows' Failover Clustering, only one node has real access to the volume at any given time, the other one is blocked from accessing it by the cluster subsystem.

Accessing the volume from one server and sharing it out is really your only option here.

share|improve this answer
3  
+1, it really, really is the only option here. –  sysadmin1138 Jul 28 '11 at 19:27
    
He might want to put a DFS namespace in front of the share to make it easy to switch over to the other box if he is simply trying be able to get back running somewhat quickly in the event of a failure of the server doing the sharing. –  Zoredache Jul 28 '11 at 19:54
1  
All the members of the cluster really access the iSCSI target directly (with some caveats). Only one coordinates which sectors each node are allowed to access; this node "owns" the cluster resource. If nodes lose direct access to the resource, they will attempt indirect access via the owner node. If the owner node fails then another node may take over as owner (depends on how the cluster is setup). –  Chris S Jul 28 '11 at 19:58
    
@massimo I really don't understand. If I have iSCSI on my SAN and I have that target on three different Windows Servers, if I write to it with one server and then try to with another, it will corrupt the san. I do not want that. –  johnny Jul 28 '11 at 20:41
1  
As I think @ChrisS is saying, Windows needs a clustering service you to communicate with all the other connected servers. All of the interconnected servers should be able to read but must agree between them which one can actually write to the LUN at any one time. But you are asking how to do this without a clustering service to broker the write access. You can't. Otherwise, yes, you will corrupt your NTFS pretty quickly. –  jimbobmcgee Jul 28 '11 at 21:00

As the others have said, you're going to have trouble here. NTFS just can't.

  • There are paid options for alternatives: Melio Enterprise is one (never tried it, not affiliated)
  • Linux claims to have a few open source filesystems that you may be able to wrap SAMBA over the top to create a fault-tolerant Windows-accessible share: Luster, Gluster, Fraunhofer

But, if you're stuck with free tools and stuck with NTFS, the best you can do is a DFS-replicated share:

  • Drop the LUN and split it into two or more
  • Assign a LUN to each server
  • Use the File Server Manager tool to set up DFS-replication in Windows
  • Publish the replicated share to Active Directory, so it is accessible via \YOUR_DOMAIN\ShareName.

AD will take care of getting your users to one of the servers, while DFSR will eventually keep the servers in sync. As with all merge-replicated systems, there will be latency between a file changing on one server and it updating on another; so there may be conflicts, which you will have to manage with the DFSR Reporting tools.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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