2

We have just set up a WAN link that connects two buildings in our organisation. The link is provided by a 100-Mbps point to point line. We have a Windows Server 2008 R2 domain controller on each side of the link.

Now we are planning to set up DFS for file services across the organisation. The estimated data volume is over 2 TB, and will grow at approximately 20% annually. My idea is to set up a file server in each building and install DFS so that all the contents stay replicated over the 100-Mbps link. I hope that this will ensure that any user will be directed to the closest (and fastest) server when requesting a file from the DFS folders.

My concern is whether a 100-Mbps WAN link is good enough to guarantee DFS replication. I've no experience with DFS, so any solid advice is welcome. The line is reliable (i.e. it doesn't crash often) and our data transfer tests show that a 5 MB/sec transfer rate is easily achieved. This is approximately 40% of the nominal bandwidth.

I am also concerned about the latency. I mean, how long will users need to wait to see one change on one side of the link after the change has been made on the other side.

My questions are: Is this link between networks a reliable infrastructure on which to set up DFS replication? What latency times would be typical (seconds, minutes, hours, days)? Would you recommend that we go for DFS in this scenario, or is there a better alternative? Many thanks.

1
  • How did you get on with the implementation. Have you investigated other 3rd party solitions. Looking to do something very similar and would appreciate your feedback. Thanks.
    – user129534
    Jul 24, 2012 at 19:12

3 Answers 3

4

DFS... like the old or the new replication mechanism?

The old one - not feasible at all, not evne over LAN link... i twas unreliable for larger scenarios.

The new one (DFS Replication) - yes, sure. Works perfectly. It is very reliable, it will queue as it needs. As long as your link has enough bandwith overall tings will eventually work. I am keeping up a number of links over 512kbit and sometimes queue 20gb for transfer.... Takes some days, but it works.

6
  • Well, we are using Windows Server 2008 R2, as I say in the original post, so I am talking about the "new mechanism" I guess. :-)
    – CesarGon
    Mar 10, 2010 at 13:17
  • When you say that it takes some days, do you mean that a change made on one side of the link would take days before it is relpicated to the other side? That would make DFS replication unsuitable for us...
    – CesarGon
    Mar 10, 2010 at 13:18
  • What I said is that transferring MY 20gb change over MY 512kb link takes some days. now think about why ;) naturally if you change more data than the pipe can handle in reasonable time - with compression - no replication software will magically make it appear. If you need to transfer 2000gb daily, 100mbit may simlpy not be enough. Depends how many changes yo uhave. I merely showed reliability over small pipes with tons of data.
    – TomTom
    Mar 10, 2010 at 13:22
  • Just as end note - check whether it works for you. if it does NOT - it is not the technology, it is either the requirements OR... the link is simply not enough. DFS replication is very well made. Acutally... update your sysvol replication to it ;)
    – TomTom
    Mar 10, 2010 at 13:37
  • not sure if this has been mentioned but you can use windows backup to prestage a local server then move the entire server or just drives to the remote site.
    – tony roth
    Jun 16, 2010 at 21:04
2

It should work well on your link. We do it across much slower links and it works. We configure the replication so the highest bandwidth is used during off hours. I assumed you meant the new DFSR rather than the older version.

2
  • Thanks Dave. What's the latency? I mean, how much do you typically need to wait to see an update on one side after a change has been made on the other side?
    – CesarGon
    Mar 10, 2010 at 13:06
  • Depends on the change. The change is analysed and compressed, then queued for transfer. Normally (small files, free bandwidth) not more than 30 seconds or so. Dump a DVD in and that one will take some minutes, because compressing it first takes time, as does decompressing on the receiving end.
    – TomTom
    Mar 10, 2010 at 13:27
1

Is there a chance that the same file will be edited by two different users simultaneously on the two replicas? DFS doesn't provide a distributed locking mechanism to protect from this.

3
  • Yes, that scenario would be possible unless we explicitly prevent it. Thanks for pointing this out. How is this limitation usually addressed?
    – CesarGon
    Mar 10, 2010 at 14:28
  • Sadly, there's no silver bullet. Depending on geographic locations of your users, it might be that their work hours don't overlap and thus edits won't collide. Can you carve up the data set so that files are located close to the users who need them the most? That way you have a single copy of the data and normal Windows locking helps with the collision issue. If you really want simultaneous bi-directional replication, DFS-R may not suffice for your use-case.
    – Fred
    Mar 11, 2010 at 18:41
  • All users are within the same time zone, unfortunately. I could split the data set into two halves and put each half closest to the users who need it the most, and replicate it to the other side in a read-only fashion. Is that a good solution?
    – CesarGon
    Mar 11, 2010 at 19:42

You must log in to answer this question.

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