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.
-
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.
CesarGon : 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?TomTom : 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.CesarGon : Understood. Thanks for clarifying.From Dave M -
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.
CesarGon : 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 : 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...TomTom : 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.CesarGon : I understand. Many thanks for the clarification.TomTom : 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 ;)tony roth : 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.From TomTom -
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.
CesarGon : Yes, that scenario would be possible unless we explicitly prevent it. Thanks for pointing this out. How is this limitation usually addressed?Fred : 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.CesarGon : 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?From Fred -
Hi, I'd be very interested in how you found this to perform with large data sizes. I'm looking for a similar solution (with approx 10TB & 100MB L2 links) to replicate data from the East Coast to Europe. I've looked at several solutions but if it works as it should, the 'free' option (DFSR) should be good enough...I think. Or does anyone know a better product (ideally one that in some way does solve the problem of two simultaneous edits)? Thanks!
CesarGon : Hi Matt. We will be implementing DFSR across the 100 MB link shortly. I will let you know how it goes.From Matt
0 comments:
Post a Comment