DFS Replication - Help!

slylittlefox

slylittlefox

slylittlefox

Associate
Joined
24 Jun 2007
Posts
1,869
Location
Landan.
Hopefully we have a DFS guru in our midst...

We're setting up DFS replication of a folder between two servers (that share a 10/100 network), we've had it running all day but it's been stupidly slow - the folder is 20GB in size and 4.8GB has taken five hours or more.

Another problem cropped up (we ran out of disk space on the destination folder - don't ask :o) that meant we had to stop replication. We've now got two new disk drives and are xcopy'ing (with the /O switch) the data on both servers to entirely new drives. (So Server 1 D:\Share -> Server 1 E:\Share and Server 2 D:\Share -> Server 2 E:\Share)

Our hope is to be able to turn DFS back on, and because the ACL information is the same, DFS won't have to start again. From what I've read this should work fine.

However, because of the stupidly low copy speeds, we'll be here all night and possibly for the next couple of days (with staff turning up tomorrow morning with a half working network).

So my idea is this: copy the data from the master server to the slave DFS server using xcopy /o which should hopefully work at approx. 8MB/s (allowing for overheads and minimal other traffic), and then turn DFS on. DFS should then see that its got mirror images of the data, and will only have to do indexing etc instead of the actual copying.

Can anyone confirm this will actually work as expected, or am I sadly mistaken? :(

Thanks
icon14.gif
 
Last edited:
Thanks for the reply. It's an extremely wierd scenario, with doubtless many bottlenecks.

Windows Server A --> Linux Site Server A ----Live Interface----> Router <-----Live Interface----- Linux Site Server B <-- Windows Server B

All of that exists within the same room. Obviously the router in the middle is clever enough not to pass its traffic out to its gateway, and then back again; instead it goes from one port on the routers switch to the other.

Add to that the fact that the Win2K3 boxes are actually VMs on VMware Server 2 (I know, ESX should be being used).

Performance, in general, is terrible, as is the setup. But we've had little choice in how to do this job.

The Xcopy is now underway, and has managed to do 5.66GB from 21:53 to 23:23 - so 5.6GB in an hour and a half. At that rate, it will have finished just before 4AM. :-|

If the Xcopy and DFS doesn't work - we're ******, well and truly.
 
J.B said:
Doesnt sound like a problem with DFS, if i had to guess id say a problem with how VMware Server interfaces with the physical adaptor. do you have any other VMs on that machine? If so how is their network throughput?
Click to expand...

If copying a single 100MB file, speeds are as expected really (i.e. approx. 10MB/s (or 100Mb/s)). There are two other VMs on the metal; though their network usage is negligible (read: nil) at the moment.

I think the problem may be to do with the fact that there's tens of thousands of tiny files - if it were big files, I don't think there'd be such a problem.

For example, it's just copied 2GB in 18mins - the fastest lap time recorded so far :p 2MB/s :(

That's much better than the 0.53GB in 18mins between 23:05-23:23 (though each are equally dire).

We've just passed the halfway mark - 10GB :o :(
 
You must log in or register to reply here.
Back
Top Bottom