First thing is to understand that the DFS name space is independent of the DFSR
replication. If you have two or more root servers then replication is done for
the root name servers. This replication includes all the folder and links that
are physically stored in the DFS Root folders. This is replication of the name
space definition. The target (where the date usually is) are not part of this.
So if I set up a dfs root server and create a root folder "dfsroot" and then add
some folders to it say Data, Home, Stuff. Now add links in these folders, say in
Home: Group1;Group2 etc. Now add links to the Group folders pointing to the UNC
shares say \\SRV1\Home, \\SRV2\Home. The users can reach their home folders via
\\srv1\home or via \\dfsroot\home\group1 etc.
Now I add a second DFS root server and DFS replicates all the above structure to
the DFSroot folder and the new DFS server. You client can now use either DFS
root server to resolve where the DFS Name/Link should end up, Srv1\home or
SRV2\home. Whichever server resolves the redirection you end up at the same
share. Hence you have a fault tolerant Name space.
BUT only one copy of the data to which both server point. Now if you want to
have redundant data you need to set up DFSR replication (this is done for you if
you want when you set up a second link target. This is just a convenience
though. Say all your data (data, home and stuff) are all on the same disk in
D:\somefolder,. You could have a replication group that replicated D:\somefolder
to X:\someotherfolder on a different server. Then once replication had completer
you could share the subfolder of X:\someotherfolder and then point the second
links to these folders. Thus you have one replication group but many DFS name
space links pointing at subfolders within the replication group.
It would be more normal to have a one to one relationship for Links and
replication groups but you do not have to.
On Tue, 14 Oct 2008 08:36:01 -0700, Jim Shilliday <jshilliday-at-ejcenter.org>
wrote:
>Hello all --
>
>I'm having a similar problem to the one described in a post of 9/24. I have
>a dfs operating over two sites with one or more PDC's in each site. When
>site B becomes unavailable, users in site A lose all dfs connectivity, even
>though they are (or should be) being referred to a server in their own site.
>Site B users have normal dfs services during the outage. When we have full
>connectivity, site A users are referred correctly to the site A dfs shares.
>In other words, site A's dfs access depends critically on full connectivity
>to site B.
>
>Investigation reveals that the dfs share on the site B server has a full set
>of subfolders, but the one on the site A server is empty. That looks like a
>candidate for the problem. Can someone advise me whether I can delete and
>re-add the site A server to the dfs namespace without creating a mess
>(permanently losing files or triggering a full (140GB) replication over the
>WAN link). Or can I just copy the contents of the dfs share on server B to
>server A? In case it's not obvious, I don't fully understand the
>relationship between the dfs server shares and their targets. Any thoughts
>appreciated.
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
|