Windows 2003 Server R2 DFS-R A little help

[fizzwheel]

Be handy to get some thoughts from those in the know on here.

OK first off, what I can't do

Windows 2008 Server
Any other form of OS ( Unix, Linux etc etc )
Any form of applicance, netapp filer etc

I dont have budget to do any of this, so they are no starters.

I have 200gb ish of data that I would like to re organise, its mainly transient data that doesnt hang along round, that doesnt need to be secure, it isnt PCI sensitive or confidential in nature.

I need to replicate the data between two seperate physical data centres.

I have 1 x Windows 2003 Server with R2 on it setup and configured in both datacentres.

I want to remove the data from our existing file server structure as to be frank its poorly structured / organised and I want to start again with a clean sheet.

I want to break the dependance on the file server hosting the data's host name always being the same and I'd like to in the future to be abe to replicate / host on a 3rd node.

Been doing some reading and looks like DFS-R would do what I want, the data I have is within the Microsoft guidelines in terms of size.

I like the repilcation alogorhytm and the fact I can limit the amount of bandwidth its using to replicate.

What I'm trying to work out is there any and if so any idea how much additional load likely to be placed on our existing AD infrastructure, i.e. increased calls to Domain Controllers, i/o reads etc etc.

I know that I will need to pay attention to the staging area on each of the file servers, in terms of size.

My colleague thinks that there is, but when asked to justify it / produce evidence is unable to.

We are already using successfully DFS-R in another environment for a similar setup, albeit with a much smaller amount of data.

Any ideas or links to stuff to read would be useful, in the meantime I'lll keep googling.

I know I should ask this on a specific IT forum, but theres loads of knowledge on here and I'd appreciate a bit of help

[SoulKiss]

Originally Posted by fizzwheel

Be handy to get some thoughts from those in the know on here.

OK first off, what I can't do

Any other form of OS ( Unix, Linux etc etc )

And for that reason, I'm out.

Sorry Fizz, just don't do/know Windows in that kind of environment,and know you dont want to hear how much easier it would be to do otherwise.

[fizzwheel]

I'd quite happily look at other solutions, but the moneys not there for it in order to do it. We have a large solaris estate so we could do something with that, if one of the Unix administrators was up for diong something with it, which they are not. The mere suggestion of creating a Samba share to host a few spreadsheets on brought down mighty vengence upon me. Let alone 200gb worth of files etc etc.

[andrewsmith]

Thats what Samba is good at.
one way would to be create a separate RAID Server, set up the drive('s) file structure
and apply the system Architecture you want.

With loading the Server team should be able to give a rough level of the load thats presently on and the expected load the proposed should have at peak. Depending upon the way the system set up at the switch room (no of switches and amount of PC and terminals on each) the switches may be under capacity unless rationalisation has been undertaken.

Is the 3rd node hosting as a fail safe measure if the main server fails?


For the record Fizz I aint a networks expert but have basic experience of switching from a previous job

[fizzwheel]

Originally Posted by andrewsmith

Thats what Samba is good at.

I know, but I work with a team of people who arent very good about thinking around problems or outside of the box. I'd be happy to put it on samba, but they Unix team wont be.

I'm not worried about the network / or loading, As the data already exists on the servers I am looking to use to do this with, I just want to move it into a different folder and change the way the users access it, so rather than

mapping a drive to \\server1\share1

They access it via \\domainname\dfsroot\dfs targetname

Because that way removes the server name from the equation which means I can move the data around and it doesnt disrupt the users. What I am getting at is that the server thats hosting this might not always be the same one.

I have two servers hosting the data now and am using some third party software to replicate between to two. I want to ditch the third party software because its not particualrly good and then use DFS-R to replicate between the two servers. ( It can do this ) and then what I want to be able to do is add a third node at a later date, in a new data centre, replicate to that, then remove the node from the equation thats in the data centre that i am currently trying to shut.

If all this is hidden behind a dfs target that users shoudlnt notice anything.

My problem is, that the person who looks after AD, is throwing a hissy fit about extra load on the domain controllers, because they are telling me it'll create extra reads or lookups within ad each time somebody goes to lookup where the DFS target points to.

Remember I'm on about using DFS-R, not DFS or FRS and that the data isnt hosted on the domain controllers themselves neither will the domain controllers as I understand do the actual file replication, they'll just again if I have understood it properly, hold a pointer to the data.

Originally Posted by fizzwheel

My problem is, that the person who looks after AD, is throwing a hissy fit about extra load on the domain controllers, because they are telling me it'll create extra reads or lookups within ad each time somebody goes to lookup where the DFS target points to

There would be additional load, I've no idea what that load would be, but I've never seen a problem with DFS hammering a DC to the point of having performance issues.

How many users are we talking and how often is this data accessed?

Your colleagues will have read something somewhere. The problem with the best practice info that MS pump out is that they all assume your network is getting hammered and you have to have it tuned for best performance otherwise you will have performance problems, and it assumes that a 5 or 10% performance hit will be an issue for you, but in reality what is the current utilisation of your AD servers? 10-20%?

Have you got access to a virtual platform? Set up a PoC with pair of file servers on VM's with DFS configured, switch over a copy of the production data over a weekend, and switch your login scripts to point at the DFS shares on the Monday morning. Everyone will come in and log on, and connect their mapped drives, and you can log perfmon on the AD servers for the day whilst the data is being used. If it is fine leave the PoC for a week, if it's still fine you can leave it for a month, then you will have proved it. If it's not fine then you can switch back the login scripts at any point. If you're confident that your WAN links have the bandwidth and stability for the replication traffic (which is the biggest pain point with DFS) then you can have to have the two PoC file servers on the same loacl network, as it's only impact on the DC's that you are trying to prove.

Originally Posted by fizzwheel

My problem is, that the person who looks after AD, is throwing a hissy fit about extra load on the domain controllers, because they are telling me it'll create extra reads or lookups within ad each time somebody goes to lookup where the DFS target points to

There would be additional load, I've no idea what that load would be, but I've never seen a problem with DFS hammering a DC to the point of having performance issues.

How many users are we talking and how often is this data accessed?

Your colleagues will have read something somewhere. The problem with the best practice info that MS pump out is that they all assume your network is getting hammered and you have to have it tuned for best performance otherwise you will have performance problems, and it assumes that a 5 or 10% performance hit will be an issue for you, but in reality what is the current utilisation of your AD servers? 10-20%?

Have you got access to a virtual platform? Set up a PoC with pair of file servers on VM's with DFS configured, switch over a copy of the production data over a weekend, and switch your login scripts to point at the DFS shares on the Monday morning. Everyone will come in and log on, and connect their mapped drives, and you can log perfmon on the AD servers for the day whilst the data is being used. If it is fine leave the PoC for a week, if it's still fine you can leave it for a month, then you will have proved it. If it's not fine then you can switch back the login scripts at any point. If you're confident that your WAN links have the bandwidth and stability for the replication traffic (which is the biggest pain point with DFS) then you can have to have the two PoC file servers on the same local network, as it's only impact on the DC's that you are trying to prove.

Obviously remember to perfmon AD before you start so you have something to compare your PoC data against, and if your AD servers are already at 60% you know you probably shouldn't do it, without upgrading your AD infrastructure first.

[fizzwheel]

AD - I'd need to check, but IIRC they arent anywhere near being remotely over loaded.

WAN isnt a problem for replication as its going over a DWDM ( 2 x 1gb links ) low level of latency and not where near capacity, some of the rep traffic thats already going over that link is the file serving replication traffic that I am looking to change to use DFS-R with.

I do have Vmware, my trouble is the 200gb worth of data that I want to shift is buried into a right old mess and mis match of structure. Which I want to unpick. So thats a little more tricky to do with regard to building a POC and then pointing the users at it. Also the data isnt being managed so most of it is dormant and needs archving, which is another problem I need to sort.

I was thinking of setting the DFS-R up and then migrating anything thats been touched within the last 6 months and then ditching the older data anyway... so the intial load is probably going to be small.

Bear in mind we already have DFS-R running already on a different pair of servers, and thats running with on trouble at all, no network, no ad problems after we deployed it.

I'm assuming it is just the read from AD that puts the load on, and that the amount of load on AD has nothing whatsoever to do with the amount of data that DFS-R is sitting in front of ?

[fizzwheel]

Oh -Ralph- another question if you dont mind.

Am I re-inventing the wheel here ? or going off at a tanget, is this the sort of setup that you have see in any other companies ?

From the reading I have done I would say I'm probably not, but it would be useful to know if this is "best practise" or not...

[flymo]

We operate a very large deployment of DFS replicas (around 1500 servers), its extremely reliable.

You didnt mention wether or not the hosting servers were themselves domain controllers, they dont necessarily need to be. Ideally not so as to ensure DFS load is seperate, especially in large data environments like we host.

There is very little if any additional load on AD itself, the same replication engine is used but if these servers are not DCs then thats not an issue.

Calls to AD from clients are no more than would be necessary with simple domain joined file servers, once the client has the relevant access token then thats that.

When deciding which replica to access, a client will query based on the AD site information and will be referred to its nearest site in the site topology. These are simple DNS queries and introduce very little additional load in the scheme of things.