7

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.

Improve this question
4
  • 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, 2011 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, 2011 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, 2011 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, 2011 at 19:52

3 Answers 3

Reset to default
5

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

Improve this answer
5
  • 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, 2011 at 20:20
  • @chris How can it be cluster aware if you require cluster services?
    – johnny
    Jul 28, 2011 at 20:41
  • 5
    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, 2011 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, 2011 at 21:03
  • 1
    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, 2011 at 21:21
19

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.

Improve this answer
6
  • 3
    +1, it really, really is the only option here.
    – sysadmin1138 ♦
    Jul 28, 2011 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, 2011 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, 2011 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, 2011 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, 2011 at 21:00
3

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .