微軟DFS基礎知識及復制原理

老王前陣子有幸參與過一個銀行的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

如果我們對文件進行修改，再次查看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復制目錄里面有生產數據還有一個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復制

DFS監控維護

DFS支持通過CMD，Powershell，WMI，MMC管理，DFS的監控可以從事件管理器-應用程序和服務日志 DFS Replication，性能計數器，SCOM進行基本監控。

更深入的DFS也有類似于windos cluster log的詳細排錯日志，默認位于C:\Windows\debug目錄下

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}

常用參數介紹

DFS其它診斷工具

dfsdiag，主要用于DFSN功能，幫助測試到AD的連接，以及DFS的配置

dfsrdiag，用于診斷排查DFSR復制

DFS診斷報告，用于管理員通過圖形化界面顯示復制報告

不建議對DFS執行系統克隆，建議使用標準的備份方案對DFS服務器進行磁盤備份或裸機備份