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:
may well work, but tbh I would suggest you get to the cause of your slow network copying. Are they connected via a switch? if so perhaps reset it to see if that helps. also try setting the cards in the servers to 100mb/fd, failing that update the NIC drivers, if you enable DFS and there are large changes you are going to get problems down the line.
 
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.
 
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?
 
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 :(
 
If they are in the same room could you not just attach a usb hard drive and copy the data across that way?
 
You are using a switch and not a hub?

As said above I don't think DFS is the problem the network is. You can always schedule DFS to replicate out of hours as well.



M.
 
I'm not sure about Xcopy, but for DFS not to need to replicate things again, all the file attributes must remain the same.

I would recommend robocopy to do this.

Or the easier solution is to run a windows backup of the desired data, move it to the new system then extract the backup to the relevant folder.

Good luck!
 
If you have VM capability available then i'd have set up two VMs and tested the scenario before attempting it in such a fixed time window. Too late for that now tho.
I'd re-copy the data using an external HDD (or indeed an internal one if you can take the server down?) and an app that preserves all the file atributes. Xcopy didn't work because the modified and created dates get messed up, If you check the modified dates on the new folders they're probably the date they were copied. hence DFS will be confused. Restoring from a ghost or something would be better and probably quicker than a straight copy. Something like windows backup or Undelete can take a snapshot of the desired folders and restore them from an image to a specified location.
The other way if they're in the same room would be the original DFS replication way only set secondary IPs on their NICs(add virtual nics should make a positive difference) then whack a crossover cable between them. The routing you have described is probably causing the slownes.
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.
Click to expand...
The router will only work like that if the two linux servers' NICs are on the same subnet. Else it WILL absorb the packet, do a routing lookup and spit it back out.
IF you dont' have a crossover cable. try a normal one, you never know the NICs might auto MDI-X and you'll be laughing. 20GB should take a 35mins in theory assuming you can get 10MB/s out of the NICs. Which on an uncontended crossover cable is a reasonable assumption.
 
Last edited:
DFSR works fine, we've used it to replicate 180GB file share over a 40mbit WAN link and it was fine.... MS have tested it upto 1TB shares. Small files won't be as quick as larger ones but I think it's your networking config as above.
 
You must log in or register to reply here.
Back
Top Bottom