微軟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命名空間訪問文件夾的流程如下
獨立根命名空間
客戶端輸入\\08server1\share\docs 訪問請求
客戶端DFS client發送一個查詢請求，查詢\\08server1\share根目標，請求發送至08server1
08server1返回根目標地址
客戶端像根目標服務器查詢docs目標服務器
根目標服務器根據目標選擇算法，為客戶端提供文件夾目標列表
客戶端向列表第一位文件目標服務器發送請求
域命名空間
客戶端輸入\\contoso.com\share\docs 訪問請求
客戶端向DC服務器發送請求查詢根目標服務器地址
DC服務器查詢AD數據庫，返回根目標服務器地址列表
客戶端選擇第一個根目標，向根服務器發送到文件夾目標的請求
根目標服務器根據目標選擇算法，為客戶端提供文件夾目標列表
客戶端向列表第一位文件目標服務器發送請求
當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，就不支持其它平臺了，使用復制組的流程如下
選擇要參與復制的目標服務器
選擇要目標服務器上要復制的文件夾
選擇復制拓撲，集散，交錯，或無拓撲，交錯即各節點互相復制，集散即各節點之間不復制，都與一個主節點復制，無拓撲即事後配置拓撲
配置復制帶寬，復制時間，復制文件篩選器
配置首次復制時主服務器
配置了復制組後，並不會因為配置了復制組而導致只有一個目標服務器提供服務，相反，復制組的所有目標服務器默認都可以對外提供讀寫功能，例如站點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基礎知識及復制原理