標題會有個問號是有點不明白問題出在哪
有兩台windows server 2016 跑file server
A : 192.168.0.1
B : 192.168.0.2
二台主機都有同樣名稱的資料夾叫DATA , 分別開共享\A\DATA;\B\DATA
現在出現的狀況是A主機使用\A\DATA 或\B\DATA 都可以正確的看到A和B裡的檔案.
但B主機使用\A\DATA 看到的卻是B的檔案 ; 使用\B\DATA 裡看到卻是A的檔案
二台主機 ping A 或 B 的ip 都正確.
網域內其它電腦使用\A\DATA 或\B\DATA 指向的主機有可能是A或B , 完全迷路了.
有可能的問題出在哪??
已邀請的邦友 {{ invite_list.length }}/5
你有開 DFSR 就不應該直接存取底下的 Share, 只能存取 DFS Name Space 上面的 Share, DFS 會自動分配, 何時該給 A 或是 B 的 Share? Client 不應該自己選擇....
對 DFS 來說, A 或 B 裡面的資料應該是一致的, 所以給 A or B 原本對 Client 應該沒有差別; 但是萬一要存取的某個檔案, 正好複寫到一半的時候, 此時 A 或 B 誰才是 Master 就很重要, 而只有 DFS 自己知道目前該給你 A 還是 B? 所以 Client 千萬不要自己去選....
此外, Client 直接寫 A or B Share, 會在 File system 裡面留下 file lock 信號, 但是 DFS Share 本身是不會做 lock propagation 的; 這往往會造成 DFS 要複寫的時候, 因為遇到 lock 信號而失效, 或是 A/B 兩邊的 lock 不一致.....
如果開了 DFS Share 又跑去存取底層的 Share, 可能會造成 DFSR 的複寫錯亂或失敗, 最後自動停止雙邊複寫....
最初的設計也是讓user掛載dfs namespace share的路徑,
但由於同步不一致, 導致user可能隔天掛載的是不同的主機, user反應檔案掉了或檔案不同.
至於2台的同步為什麼會不一致, 這我要先去了解, 最早同步不一致是因有超大檔數g一直卡住, 讓後面的檔無法進入複寫, 後來把大檔先排除後, 複寫才接近一致, 目前看起來複寫還沒完全一致,這我去找出問題.
再請問, 所以這二台主機做複寫的資料夾, 不能直接操作? 只能透過dfs namespace的路徑?
因為我是中間開始接維護, 不清楚一開始要導入user原來的檔案是透過直接操作還是namespace 路徑.
謝雷神大大
對, 其實只要在 File system 上層另外再蓋出來的 Replication 機制, 都不應該直接去操作底層, 不只 DFS 這樣, 像 Gluster FS 也是這樣, 而且他們都沒有防呆機制, 不會發現你自己違規跑去底層存取, 就很好心的警告或阻止你, 因為它們都假設管理者已經有這樣的認知, 不會犯規...
Gluster 如果被動過底層, 他有指令可以檢查出那一個版本的底層比較新, 然後通知上層的 GFS 重掃一次, 重建所有 metadata....但是 DFS 沒有手動強制重掃的機制, 就只能聽天命.....我最常做的就是: 砍掉整個 Name space 重建, 重新複寫一次....
檔案太大卡住複寫是 DFS 的老問題, 他有一個計算公式讓你可以預先保留一定容量的比例來做複寫用, 我忘了實際的數字, 不過大概是:
找出資料夾中, size 最大的 32 個檔案, 把總數相加, 得到的容量 x2 = 該磁碟中至少應該要保留的 Free Space.
如果磁碟的 Free space 不夠多, 就會發生複寫自動終止的問題 (即使還沒寫滿也會終止). 這個問題從 2008 R2 版本一直到現在都還存在, 似乎微軟沒有打算改進這個功能....
我後來都懶得算, 就給他一顆超級大的硬碟, 然後保持不要使用超過 70% 以上的容量.....
你能做的, 大概就是每天跑一次 DFS 健康報表, 看看有沒有東西被卡住? 然後盡快將他排除掉.....
DFS 唯一可以存取底層的時機, 是在第一次複寫之前, 要做大量 File Seeding 的時候, 可以手動從 Master 拷貝到 Slave 去, 但一旦啟動複寫, 就不能再去動底層, 會亂...
iThome鐵人賽
看影片追技術