老王前阵子有幸参与过一个银行的DFS咨询项目,也借机会入门学习下DFS,现将学习到的知识整理出来与大家分享,不对之处欢迎指正


DFS是微软Windows Server上面自带的分布式文件共享服务,通过使用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唯一更新编号,而实际的数据不会记录,这样也可以保持记录文件足够小,应用程序可以监视此USN日志的以获得NTFS文件系统更新。


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

fsutil usn readdata c:\usn\123.txt

2018-03-25_203709.png

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

2018-03-25_203847.png

当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

2018-03-25_214709.png

{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数据库+版本号构成

2018-03-25_215222.png

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

2018-03-25_215628.png

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


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

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

2018-03-25_220100.png

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


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

2018-03-25_221919.png


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


DFS复制建议,建议通过DFS进行复制的复制文件夹,始终只复制确认下来的结果集数据,举个例子,如果DFS复制目录里面有生产数据还有一个TEMP文件夹,TEMP文件夹会随着开发测试而不断的删除和修改,则DFS目录会因为里面的TEMP目录频繁修改而导致频繁复制,而且如果程序多次重复写入,或频繁从目录删除又添加文件,则该文件会被丢弃至Conflict and Deleted文件夹


DFS共享文件夹DfsrPrivate目录用途解答


Staging DFS复制临时存放文件夹,所有要被复制的文件都会被放置在这个文件夹,再推送给其它节点,建议设置暂存大小尽可能大一些

Conflict and Deleted 用于处理冲突时被丢弃一方的修改文件,例如一个文件,节点1和节点2同时修改,节点2最后修改,节点2修改的版本作为最新版本生效,节点1修改的版本则被丢弃至该文件夹,复制过程中删除的文件也会被放置在该文件夹下

Deleted:如果在成员身份下取消勾选将删除的文件移动到冲突和删除文件夹,deleted文件夹将生效,再删除的文件会被放置在deleted文件夹

Installing:当文件超过64KB时,并不会直接复制到对方节点上,要被复制的文件会经过RDC计算先放在staging floder,复制发生时首先会被拷贝至对方节点上Installing路径下,之后再放置到正确路径下

PreExisting :在初始化复制时,例如如果要从DFS01复制到DFS02,DFS02如果复制文件夹中已经存在文件,已存在的会被放置在PreExisting路径下,PreExisting路径中的文件夹不参与DFS复制

2018-03-26_093717.png


DFS监控维护


DFS支持通过CMD,Powershell,WMI,MMC管理,DFS的监控可以从事件管理器-应用程序和服务日志 DFS Replication,性能计数器,SCOM进行基本监控。


更深入的DFS也有类似于windos cluster log的详细排错日志,默认位于C:\Windows\debug目录下

2018-03-26_094856.png


DFS详细日志管理如下


设置:调试日志严重性

默认值:4 

范围:1-5 

WMIC语法:

wmic / namespace:\\ root \ microsoftdfs path dfsrmachineconfig set debuglogseverity = 5


设置:调试日志消息

默认值:200000 

范围:1000到4294967295(FFFFFFFF)

WMIC语法:

wmic / namespace:\\ root \ microsoftdfs path dfsrmachineconfig set maxdebuglogmessages = 500000


设置:调试日志文件

默认值:100 

范围:1到10000 

WMIC语法:

wmic / namespace:\\ root \ microsoftdfs path dfsrmachineconfig set maxdebuglogfiles = 200


设置:调试日志文件路径

默认值:%windir%\ debug 

WMIC语法:

wmic / namespace:\\ root \ microsoftdfs path dfsrmachineconfig set debuglogfilepath =“d:\ dfsrlogs”

注:路径必须手动创建; 如果不是,在服务重启时,将使用缺省值%windir%\ debug


设置:启用调试日志记录(默认启用调试日志记录)

默认值:TRUE 

范围:TRUE或FALSE 

WMIC语法:

wmic / namespace:\\ root \ microsoftdfs path dfsrmachineconfig set enabledebuglog = true



下为详细日志中一个受到更新的过程


20180326 09:52:25.365 2612 INCO  4825 InConnection::UpdateProcessed Received Update. updatesLeft:0 processed:1 failures:0 sessionId:3 open:0 updateType:0 processStatus:0 connId:{C05077DD-90EF-4059-A695-E5158F8E4DB5} csId:{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348} csName:doc update:

+present                         1

+nameConflict                    0

+attributes                      0x20

+ghostedHeader                   0

+data                            0

+gvsn                            {6B8002DE-784B-45AA-B566-9114DC96C959}-v13

+uid                             {8F3671EF-8AF6-4D15-B59B-B4BF3CB52DD7}-v11

+parent                          {41BBE4AC-6CE0-421A-AFE9-6E9420EA1348}-v1

+fence                           Default (3)

+clockDecrementedInDirtyShutdown 0

+clock                           20180326 01:52:25.258 GMT (0x1d3c4a516a7334d)

+createTime                      20180325 13:40:27.685 GMT

+csId                            {41BBE4AC-6CE0-421A-AFE9-6E9420EA1348}

+hash                            DB24292A-77575CB4-2B878C24-FC62C351

+similarity                      00000000-00000000-00000000-00000000

+name                            CC.txt

20180326 09:52:25.365 2612 INCO  5551 InConnection::CommitSession Connection in sync connId:{C05077DD-90EF-4059-A695-E5158F8E4DB5} csId:{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348} csName:doc commitedSessionsWithUpdateFailures:0

20180326 09:52:25.365 2612 IINC   392 IInConnectionCreditManager::ReturnCredits [CREDIT] Credits have been returned. creditsToReturn:1 totalConnectionCreditsGranted:0 totalGlobalCreditsGranted:0 csId:{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348} csName:doc connId:{C05077DD-90EF-4059-A695-E5158F8E4DB5} sessionTaskPtr:00000000004BF350

20180326 09:52:25.365 2612 UPMG   427 UpdateWorker::ConsumeUpdates No pending updates. connId:{C05077DD-90EF-4059-A695-E5158F8E4DB5} csName:doc csId:{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348}

20180326 09:52:25.365 2140 INCO  8561 InConnection::InConnectionContentSetContext::Hibernate Hibernating: connId:{C05077DD-90EF-4059-A695-E5158F8E4DB5} csId:{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348}

20180326 09:52:25.365 2140 UPMG   580 UpdateManager::FinalizeUpdateManager Finalizing UpdateManager connId:{C05077DD-90EF-4059-A695-E5158F8E4DB5} csName:doc csId:{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348}

20180326 09:52:25.381 2040 OUTC  2885 OutConnectionContentSetContext::TransportRequestVvUp Received request for VvUp csId:{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348} csName:doc connId:{FA4D1251-E628-47E5-8448-13905E9C9ECE} rgName:doc  ptr:00000000004BEF20

20180326 09:52:25.381 2040 SRTR  2242 SERVER_RequestVersionVector Sent requested version vector. connId:{FA4D1251-E628-47E5-8448-13905E9C9ECE} csId:{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348} seqNumber:6 requestType:REQUEST_NORMAL_SYNC changeType:all

20180326 09:52:25.381 2040 SRTR  2331 SERVER_AsyncPoll Processing AsyncPoll call. connId:{FA4D1251-E628-47E5-8448-13905E9C9ECE}

20180326 09:52:25.381 2040 OUTC  2885 OutConnectionContentSetContext::TransportRequestVvUp Received request for VvUp csId:{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348} csName:doc connId:{FA4D1251-E628-47E5-8448-13905E9C9ECE} rgName:doc  ptr:00000000004BEF20

20180326 09:52:25.381 2040 SRTR  2242 SERVER_RequestVersionVector Sent requested version vector. connId:{FA4D1251-E628-47E5-8448-13905E9C9ECE} csId:{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348} seqNumber:7 requestType:REQUEST_NORMAL_SYNC changeType:notify

20180326 09:52:25.397 2040 SRTR  2331 SERVER_AsyncPoll Processing AsyncPoll call. connId:{FA4D1251-E628-47E5-8448-13905E9C9ECE}

2018-03-26_095524.png

常用参数介绍

参数

描述

当前案例

CSID

复制文件夹GUID

{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348}

ConnID

复制链接GUID

{C05077DD-90EF-4059-A695-E5158F8E4DB5} 

Parent

复制文件所在文件夹ID

{41BBE4AC-6CE0-421A-AFE9-6E9420EA1348}-v1

UID

原始文件记录

{8F3671EF-8AF6-4D15-B59B-B4BF3CB52DD7}-v11

GVSN

修改文件记录

{6B8002DE-784B-45AA-B566-9114DC96C959}-v13


DFS其它诊断工具


dfsdiag,主要用于DFSN功能,帮助测试到AD的连接,以及DFS的配置

dfsrdiag,用于诊断排查DFSR复制

DFS诊断报告,用于管理员通过图形化界面显示复制报告

2018-03-26_100921.png

2018-03-26_101017.png

不建议对DFS执行系统克隆,建议使用标准的备份方案对DFS服务器进行磁盘备份或裸机备份