微软DFS基础知识及复制原理

标签：微软DFS复制原理   DFS同步原理   DFS复制   

DFS的主要功能分为两大块 为客户端提供统一的入口，实现不同文件服务器文件夹的复制，两大块功能分别由两个组件实现

DFS命名空间：可以安装在单独的成员服务器或域控，命名空间顾名思义，为用户提供一个逻辑的访问路径，例如，企业中有很多台windows共享服务器，很多NAS共享，linux共享，用户需要一个一个记住很不方便，这时候就可以通过命名空间服务器，提供一个统一的访问名称，把企业的共享服务器都发布到这个访问名称下，用户只需要记住这个名称，就可以浏览企业里面所有的共享文件夹

DFS命名空间分为独立命名空间和域命名空间，独立命名空间即单独找一个服务器，以这台服务器的名称作为DFS对外访问，导致的结果就是一个这台服务器宕机，则用户无法访问，但是可以把独立命名空间部署为群集角色以获得AP模式的高可用，另外一种是域命名空间，这种部署模型部署出来之后，用户访问时会是\\domainname\dfsrootname这种方式访问，好处是通过域命名部署，可以把访问名称，命名空间服务器，由命名空间连接到的文件夹，文件夹目标，这些元数据信息都会存放在AD里面，实际上就在活动目录数据库的这个位置一份

CN=<Namespace>,CN=Dfs-Configuration,CN=System,DC=Contoso,DC=Com

这样做了之后，用户的命名空间服务器就可以注册多个，例如可以有两台命名空间服务器，共同支持\\domainname\dfsrootname这个DFS根路径，一旦一台服务器坏了，下次客户端查询时DC会返回给客户端可用的地址，始终确保命名空间的访问可以正常

DFS客户端从DFS命名空间访问文件夹的流程如下

独立根命名空间

1. 客户端输入\\08server1\share\docs 访问请求

2. 客户端DFS client发送一个查询请求，查询\\08server1\share根目标，请求发送至08server1

3. 08server1返回根目标地址

4. 客户端像根目标服务器查询docs目标服务器

5. 根目标服务器根据目标选择算法，为客户端提供文件夹目标列表

6. 客户端向列表第一位文件目标服务器发送请求

域命名空间

1. 客户端输入\\contoso.com\share\docs 访问请求

2. 客户端向DC服务器发送请求查询根目标服务器地址
   

3. DC服务器查询AD数据库，返回根目标服务器地址列表

4. 客户端选择第一个根目标，向根服务器发送到文件夹目标的请求

5. 根目标服务器根据目标选择算法，为客户端提供文件夹目标列表

6. 客户端向列表第一位文件目标服务器发送请求
   

当DC或独立命名空间对客户端返回根目标服务器地址后，默认情况下会被缓存在客户端，独立命名空间为300秒，域命名空间为1800秒，在秒数内不会再次请求根目标服务器地址

通常情况下如果DFS使用量较大，建议单独部署DFS命名空间服务器，如果请求不多，可以和DFS复制服务器放在一起，让DFS复制服务器既承担复制功能，也承担命名空间提供功能

如果只部署一台命名空间服务器，当命名空间服务器宕机后，客户端将无法通过路径范围访问共享，回退至访问单台服务器模型

如果命名空间部署到域控服务器，容易引发访问名称不一致问题，例如，客户端1指向域控1，客户端2指向域控2，域控1部署了命名空间服务器，域控2部署没有部署，那么指向域控2的客户端将没法访问到DFS根目标名称，

DFS的默认目标选择算法如下

1.从同一站点目标服务器随机排列在列表顶部

2.客户外部站点目标按AD站点Cost最低到最高的顺序列出

3.相同Cost的推荐被分组在一起

4.在每个组中目标按随机顺序列出

管理员也可以通过DFS管理单元手动修改目标选择算法，例如修改为最低Cost为首选提供

DFS目标服务器启动时会检测当前DC是否为多站点架构，如果是，我应该归于哪个站点，当客户端对DFS命名空间服务器发送请求时，命名空间会根据上述目标选择算法，为客户端提供经过排序的目标服务器列表

如果都是同站点内，则客户端将随机选择目标服务器

在Windows Server中添加角色和功能时DFS分为两个，一个为DFS命名空间，一个是DFS复制组

在命名空间看来，主要分为命名空间服务器和目标服务器，除了命名空间服务器外，所有的文件夹目标都是目标服务器，你们进入了我的逻辑区域，我会在我的命名空间为你们创建link

复制组的引入，让DFS不仅从一个提供便捷访问的平台，也可以支持文件级别的自动复制容错，通过配置复制组，可以让之间目标服务器相互复制文件夹，以实现容错，引入复制组概念后，每台目标服务器变成一个复制成员服务器，复制组成员服务器仅支持微软windows server，就不支持其它平台了，使用复制组的流程如下

1. 选择要参与复制的目标服务器

2. 选择要目标服务器上要复制的文件夹

3. 选择复制拓扑，集散，交错，或无拓扑，交错即各节点互相复制，集散即各节点之间不复制，都与一个主节点复制，无拓扑即事后配置拓扑
   

4. 配置复制带宽，复制时间，复制文件筛选器

5. 配置首次复制时主服务器

配置了复制组后，并不会因为配置了复制组而导致只有一个目标服务器提供服务，相反，复制组的所有目标服务器默认都可以对外提供读写功能，例如站点A有目标服务器A，站点B有目标服务器B，两个目标服务器配置了复制，文件夹中的数据会在两个站点间进行同步，站点A客户端访问会是目标服务器A响应，站点B客户端访问会是目标服务器B响应，一旦其中一台服务器宕机，会从命名空间服务器给出的算法中选择下一个目标服务器，如果没有配置复制组的情况下，也是类似的，只不过各自访问各自的文件，没有复制机制。

默认情况下各个复制组成员服务器是多主同步机制，即每个节点都可以修改文件夹数据，2008开始支持配置只读复制组成员，只读复制组成员只可以执行读操作，不能写入。适用于分支机构，不需要写入只要读取的场景

DFS复制组配置好了之后，2008开始走RDC远程压缩算法复制机制，即每次复制仅复制修改过的数据，DFS复制仅支持复制关闭的文件，例如office文件，图片文件等，用户上传完就关闭，不会一直打开的，如果是VHDX或SQL MDF这类始终打开不会被关闭的文件，则不适用DFS，它们始终不会被复制，DFS复制不具备版本控制能力，如果一个文件同时在两方打开，将以关闭文件一方为准。

DFS复制默认情况下使用135端口及RPC动态端口，可通过以下命令固定DFS复制RPC端口

dfsrdiag staticrpc /port:55555 /mem:dfs01

dfsrdiag staticrpc /port:55555 /mem:dfs02

接下来我们再来看下DFS复制的工作机制

涉及到的组件

GUID：DFS复制使用GUID作为标识，每一个复制组，复制文件夹，每个复制组成员，每个复制文件夹卷的DFSR数据库，都将被分配一个GUID

USN Journal日志：DFSR通过NTFS的USN日志监测文件变化，关于USN Journal简单来说，它是一种被定义为NTFS 规范之一的循环日志，NTFS 卷上文件和文件夹的变化，都会自动追加USN唯一更新编号，应用程序可以监视此USN日志的更新

NTFS中每一个文件都可以查询到它的USN日志，查询命令如下

fsutil usn readdata c:\usn\123.txt

如果我们对文件进行修改，再次查看USN日志，可以看到，USN编号发生变化，作为NTFS 上的文件ID的“文件参考号”和指示父文件夹的“父文件参考号”没有改变

当DFSR 检测到为复制文件夹中的文件添加了USN 日志时，它会将该文件的更新添加到由 DFSR 管理的数据库

DFSR服务在承载复制文件夹的卷上为每个卷维护一个ESE数据库。DFSR使用此数据库存储有关复制文件夹中每个文件和文件夹的元数据

在DFSR数据库中，以下信息相关联，如果调试日志DFSR 跟踪的复制状态时，这五个编号你会经常看见

o    UID

o    GVSN

o    文件名称

o    NTFS文件ID

o    父文件夹的UID

DFSR 使用UID（唯一标识符）和GVSN（全球版本序列号）两个不同的ID跟踪复制的状态。

UID 基于数据库GUID（复制文件夹所在卷）和当前数据库版本号进行修改而构造，是唯一分配给文件和文件夹的ID ，分配给每个复制文件和复制文件夹，一旦分配，UID 将不会被更改，直到文件或文件夹被删除

GVSN 基于数据库GUID（复制文件夹所在卷）和当前数据库版本号进行修改而构造，分配给每个复制文件和复制文件夹，每次文件或文件夹发生更新，都会分配一个新的GVSN 

UID 和GVSN 都采用以下格式编写。

{DB GUID} - 版本

实际的形式如下

{0440DC0A-B3D0-49EC-AD01-B5A236AAF788}-v12

第一半{0440DC0A-B3D0-49EC-AD01-B5A236AAF788} 的部分，是基于复制文件夹所在卷DFSR数据库的GUID ，V12的部分是DFSR已经认识到更新的序列号。通过结合这两个信息，我们可以得到一个唯一的ID。

UID和GVSN只有在文件或文件夹初始化创建时才保持一致，一旦文件或文件夹发生变化，则GVSN改变，UID不变。

实验验证DFS复制时UID GVSN的改变

环境介绍

一台DC，两台DFS server，各自承载DFS命名空间与DFS复制组角色

复制组名称\\oa.com\share\doc

存在于DFS01和DFS02 C盘的doc目录被指定为复制文件夹

当前在DFS01服务器doc目录创建一个cc.txt文件

使用以下命令可以查询出当前DFS复制文件夹的UID与GVSN

wmic /namespace:\\root\microsoftdfs path DfsrIdRecordInfo where "filename like '%cc.txt%'" get * /format:textvaluelist

{8F3671EF-8AF6-4D15-B59B-B4BF3CB52DD7} 是DFS01 DFSR数据库GUID ，可以看到在初始化期间UID和GUID保持一致

可以通过DFSRDIAG Guid2name命令看到

dfsrdiag guid2name /RGName:doc /guid:{8F3671EF-8AF6-4D15-B59B-B4BF3CB52DD7}

UID GVSN的编号正是由复制文件夹所在卷DFSR数据库+版本号构成

接下来在DFS02编辑修改CC.TXT后再次在DFS02服务器查看UID GVSN，可以看到UID并没有发生改变，但GVSN发生改变

我们再次使用dfsrdiag guid2name 命令检查DB GUID 

dfsrdiag guid2name /RGName:doc /guid:{6B8002DE-784B-45AA-B566-9114DC96C959}

可以看到当前复制组GVSN正是DFS02的DFSR数据库，CC.txt最后是在DFS02更新。

DFSR收到GVSN发生变化后，通知其它节点与其更新，通过RDC传输增量数据

如果这时DFS01再次更新内容，则DFS01的DFSR数据库复制组ID将再次变成GVSN，但版本号增加

由此我们可以简单总结下DFS复制的原理，当一个文件或文件夹发生更改操作时，NTFS USN会记录更改，更新USN编号，下次DFS从NTFS查询USN日志时可以看到更新，随即更新成员复制文件夹所在卷的DFSR数据库ID，并将数据库ID更新至DFSR复制组GVSN，DFSR得知文件或文件夹在这个服务器上发生了更改，通知其它节点使用RDC与其进行复制增量内容，并维护各节点DFS版本向量表更新一致。

微软DFS基础知识及复制原理

标签：微软DFS复制原理   DFS同步原理   DFS复制   

原文地址：http://blog.51cto.com/wzde2012/2090984