2

I'm currently consulting for a small engineering firm that has been using a single server for all their domain needs and their management has got sick of not being able to access networked shares from the server when the ageing hardware fails

I've procured two new HP ProLiant servers for file serving purposes running Server 2008 R2 Standard, and reconditioned their old hardware to 2 SAN boxes using FreeNAS.

Originally while trialling a solution, I was running a DFS namespace with both servers as nodes. The primary server is connected to the SAN via iSCSI and then the replication service copies the files onto the secondary server (to local drives).

Obviously it wouldn't be possible (or not recommended) to connect the second server to the same iSCSI volume as the primary server because of split brain etc. It seems pointless to use the SAN in the first place if the primary server replicates data onto the secondary servers local disks, and I can't share the iSCSI target to share the data between servers.

I figured using a NAS protocol to connect the two servers to the FreeNAS box at the file level, and configure DFS on the servers to only use the secondary server if the primary server is unavailable. Instead of the servers seeing the drives as local disks (as they would using iSCSI), I was planning to map them as networked drives. Doing this at the file level seems to alleviate the issues with sharing an iSCSI target between two servers.

I'm no stranger to SAN/NAS devices and FreeNAS in particular, but using it in a deployment like this is something new to me so I'm not entirely sure if this would work, or how it would perform etc.

Is this the correct way to go about this?

All the guides for this I can find on the internet are for Virtual Machines, and have some sort of failover manager, so I'm not too confident about following those ideas without having failover management.

Thanks!

5
  • A lot of things going on in this question from my perspective, unless I'm misunderstanding what you're saying. Distributed File Systems, Clustered File Systems and Clustered File Servers are three different things. It seems like you're throwing them all together in this question. How about creating a second LUN/iSCSI target on the FreeNAS SAN for the second server and using DFS?
    – joeqwerty
    Aug 14, 2013 at 23:29
  • The two Windows servers are running the File Services roles, and providing a DFS Namespace (\\corp.contoso.com for example). Within that DFS namespace are all the mission critical file shares (\\corp.contoso.com\accounts). We have a sizable SAN in the environment that hosts all the data for these shares, and the Windows File Servers are acting as endpoints for clients to access these shares. What im trying to do is failover these two file servers, still retaining the SAN as the data store transparently. Aug 14, 2013 at 23:44
  • Maybe I'm confused. One LUN/target for serverA and another LUN/target for serverB. DFS Namespace. DFS Folder Targets. DFS Replication. If one server fails DFS will "direct" client connections to the other server. Done. What Am I missing?
    – joeqwerty
    Aug 14, 2013 at 23:58
  • 1
    @joeqwerty I think he wanted to do this without actually having a second copy of the DFS-R data, and without using failover clustering. He was trying to figure out a way to use both file servers as an entry point into a single LUN or set of LUNs on a back-end SAN.
    – MDMarra
    Aug 15, 2013 at 0:03
  • @MDMarra Thats correct, trying to make the best of a less than ideal situation. Aug 15, 2013 at 0:04

1 Answer 1

2

You can present the same iSCSI LUN to multiple file servers if you've properly configured a Windows Failover Cluster for file services. In this case you'd not use DFS replication, though a DFS Namespace would still provide value.

You can also get rid of shared storage all together and do DFS-R with local disks and put both members of the replication group behind a DFS Namespace.

I'm not sure why you're trying to do some trickery here to make both DFS-N targets use the same shared storage. If you want to use the shared storage, just configure a failover cluster for file services and have them share the LUN.


Edit: Since you're stuck on 2008 R2 Standard, you're going to have a bad time. Upgrade to 2008 R2 Enterprise and do failover clustering, or (even better) use Server 2012 where there are vast improvements to both file services and clustering, and where clustering is available in both versions (standard and datacenter).

4
  • This is what I would normally do, however the client is only licensed for Server 2008 R2 Standard, and to my knowledge Failover Cluster for FS is only available on Enterprise and above. The lack of Failover Cluster is where I am stumbling, trying to prevent split-brain using the same iSCSI LUN on the two servers. Aug 14, 2013 at 23:48
  • In that case, you're going to have a bad time. There's really no way around this that I'm aware of. If you must use the same LUN(s) you must use a failover cluster. If you cannot do this, then you'll need additional LUN(s) for each server in the replication group. Each DFS-R member in a replication group keeps a jet database in the replication group's folder to keep track of replication and other filesystem data related to DFS. It is not possible to use some kind of trickery to circumvent this limitation and still have working DFS.
    – MDMarra
    Aug 14, 2013 at 23:54
  • Of course, if you have two LUNs in the same storage pool for DFS and you have dedupe available, you just dedupe it and have no additional space eaten up. But, of course, this isn't elegant. The "right" solution here is to purchase Enterprise licenses (or 2012 licensing) and cluster your file servers.
    – MDMarra
    Aug 14, 2013 at 23:55
  • Thats the answer I was afraid of! I'll have to convince them the step up to Enterprise is worth it. Do you want to put that in as an answer and I'll mark it for you, thanks! Aug 14, 2013 at 23:56

You must log in to answer this question.

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