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

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.

share|improve this question
    
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 '12 at 19:12

3 Answers 3

up vote 4 down vote accepted

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.

share|improve this answer
    
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 '10 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 '10 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 '10 at 13:22
    
I understand. Many thanks for the clarification. –  CesarGon Mar 10 '10 at 13:32
    
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 '10 at 13:37

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.

share|improve this answer
    
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 '10 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 '10 at 13:27
    
Understood. Thanks for clarifying. –  CesarGon Mar 10 '10 at 13:33

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.

share|improve this answer
    
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 '10 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 '10 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 '10 at 19:42

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.