asked on
Can I use DFS to replicate frequently accessed files?
I have been using DFS for a few months, and although the concept is great, using it to access frequently accessed or opened and locked files has proven to be the wrong thing to do. Although Microsoft has documented that you should not place Roaming Profiles on a DFS, they do not go into detail regarding other files that should not be placed on DFS.
My question is this: Knowing certain files do not work well in DFS, could I use one of my DFS servers as a "central repository" by mapping drives to the shares of the server, and use DFS to replicate the information from this server to other DFS replicas? My theory is, while a user or users would be accessing the files directly from the server, DFS would replicate any changes from that server to the others on the DFS.
I have provided a simple diagram to illustrate my thoughts:
SERVER1 SERVER2
Share A (DFS REPLICA) Share A (DFS REPLICA)
Share B (DFS REPLICA) Share B (DFS REPLICA)
User has Z: mapped to Share A on SERVER1. Any changes made are direct to SERVER1. DFS replicates changes from SERVER1 to SERVER2, eliminating confusion of which server has the most current copy of the file since the file is being accessed directly from SERVER1.
Thanks for your assistance.
David
My question is this: Knowing certain files do not work well in DFS, could I use one of my DFS servers as a "central repository" by mapping drives to the shares of the server, and use DFS to replicate the information from this server to other DFS replicas? My theory is, while a user or users would be accessing the files directly from the server, DFS would replicate any changes from that server to the others on the DFS.
I have provided a simple diagram to illustrate my thoughts:
SERVER1 SERVER2
Share A (DFS REPLICA) Share A (DFS REPLICA)
Share B (DFS REPLICA) Share B (DFS REPLICA)
User has Z: mapped to Share A on SERVER1. Any changes made are direct to SERVER1. DFS replicates changes from SERVER1 to SERVER2, eliminating confusion of which server has the most current copy of the file since the file is being accessed directly from SERVER1.
Thanks for your assistance.
David
Windows 2000
Last Comment
uxphreak
look into Unix based servers Digital UNIX V4.0F that we use on our campus and when you try to acces the main server it routes to one of the servers find out about Linux Redhat www.redhat.com and check out how to setup NFS servers Microsoft blows!
This would work, in that changes are made on server 1 then replicated to server2. You need to ensure server 2 is not updated.
Is this being done for disaster recover??
Is this being done for disaster recover??
ASKER
TFL - This is more for "On-site" Disaster Recovery, in case our primary file server goes down I can switch our users to the other server and theoretically not lose a lot of data between fail-over. My biggest concern is making sure the Primary server has the most current information, while the replica server has as much up-to-date data from the primary as possible.
What DFS has done to me in the past is you don't know which server has the most current information until FRS has completed it's replication. If I'm pointing to one server to get my information, then DFS and FRS can do whatever they want without impacting the integrity of the information.
Thanks for your input.
David.
What DFS has done to me in the past is you don't know which server has the most current information until FRS has completed it's replication. If I'm pointing to one server to get my information, then DFS and FRS can do whatever they want without impacting the integrity of the information.
Thanks for your input.
David.
The only way I made it work properly is to have the user environment completely uning DFS paths only. This is because DFS keeps track of changes and knows which version is "up-to-date" at that moment, and redirects the clients to that replica. (works 9 times out of 10 I believe, unless you decrease the time clients remember the redirection). That way you can use the same URL's accross your sites, like:
\\domain.com\company\Accou
and clients will always connect to the nearest or most up-to-date one seamlessly. Also you can control the amount of changes that occur before FRS starts syncronizing the replica's.
After you set up your domain like this, server-names are not really important anymore. You can easily move shares from server to server, whithout having to change the user-environment/login-scr
I have replicated about 6Gb across 5 sites, including RIS image, profiles, homedirectories etc. without too many problems. But the users are very happy with the gratly reduced response time. Can't do it with directories containing databases (obviously), and I've had some version conflicts when users don't log off at one site and then login at another site. But that was solved with some user-education.
\\domain.com\company\Accou
and clients will always connect to the nearest or most up-to-date one seamlessly. Also you can control the amount of changes that occur before FRS starts syncronizing the replica's.
After you set up your domain like this, server-names are not really important anymore. You can easily move shares from server to server, whithout having to change the user-environment/login-scr
I have replicated about 6Gb across 5 sites, including RIS image, profiles, homedirectories etc. without too many problems. But the users are very happy with the gratly reduced response time. Can't do it with directories containing databases (obviously), and I've had some version conflicts when users don't log off at one site and then login at another site. But that was solved with some user-education.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Thanks to everyone for their input. It's greatly appreciated.
David
David