了解 DFSR 中 (缺乏) 分散式檔案鎖定

本文討論 Windows 內沒有多主機分散式檔案鎖定機制，特別是在 DFSR 所複寫的資料夾內。

某些背景

• 分散式檔案鎖定 – 這是指在數部電腦上有多個檔案複本的概念，以及開啟一個檔案以供寫入時，所有其他複本都會鎖定。 這可防止多個使用者同時在多部伺服器上修改檔案。
• 分散式檔案系統複寫 – DFSR 會在多宿主狀態型設計中運作。 在狀態型複寫中，多宿主系統中的每部伺服器會在複本送達時套用更新，而不交換記錄檔（而是使用版本向量來維護「最新」資訊）。 初始同步處理之後，沒有任何一部伺服器任意授權，因此在各種網路拓撲上具有高可用性且非常有彈性。
• 伺服器訊息區 - SMB 是 Windows 中用來透過網路存取檔案的通用通訊協定。 在簡化的詞彙中，它是一種用戶端-伺服器通訊協定，利用重新導向器讓遠端檔案系統似乎是本機檔案系統。 這不是 Windows 特有的，而且相當常見 – 已知的非 Microsoft 範例是 Samba，可讓 Linux、Mac 和其他作業系統作為 SMB 用戶端/伺服器並參與 Windows 網路。

請務必清楚描述 DFSR 和 SMB 存在於複寫的資料環境中的位置。 SMB 可讓使用者存取其檔案，且無法察覺 DFSR。 同樣地，DFSR（使用 RPC 通訊協定）會讓伺服器之間的檔案保持同步，且無法察覺 SMB。 請勿混淆此文章 和機會鎖定中所定義的分散式鎖定 。

因此，正如英國人所說，這裡有東西可以去梨形的地方。

由於使用者可以在多部伺服器上修改資料，而且因為每個 Windows 伺服器都只知道本身的檔案鎖定， 而且 由於 DFSR 對其他伺服器上的 這些鎖定沒有任何瞭解，因此使用者可能會覆寫彼此的變更。 DFSR 會使用「最後一個寫入器獲勝」衝突演算法，因此有人必須遺失，而且要儲存最後一個的人才能保留變更。 遺失的檔案複本會擷取到 ConflictAndDeleted 資料夾中。

現在，這遠 不 如人們喜歡相信。 一般而言，真正的共用檔案會在本機環境中修改;在分公司或同一列的隔間中。 他們通常會由同一個小組的人員處理，因此人們通常會知道同事修改資料。 而且，由於它們通常位於相同網站中，因此所有在共用檔上工作的使用者都會使用相同的伺服器的可能性要高得多。 Windows SMB 會處理此處的情況。 當使用者鎖定檔案以進行修改，且同事嘗試編輯它時，其他使用者將會收到如下的錯誤：

如果開啟檔案的應用程式非常聰明，例如 Word 2007，它可能會為您提供：

DFSR 確實有鎖定檔案的機制，但它只位於伺服器自己的內容內。 如果檔案的本機複本具有獨佔鎖定，DFSR 將不會複寫檔案。 但這不會防止另一部伺服器上的任何人修改檔案。

回到主題，在地理上 修改共用資料的問題確實存在 ，而且對於某些人來說，這相當喋喋不已。 我們偶爾會問為什麼 DFSR 不會處理這個鎖定，並採取一波魔杖的一切。 事實證明，對於多宿主複寫系統來說，這是一個有趣且困難的案例。 讓我們開始探索吧。

協力廠商解決方案

有一些廠商解決方案會處理此問題，這些解決方案通常會透過下列一或多個方法處理*：

• 使用訊息代理程式機制

擁有中央「流量員警」可讓一部伺服器知道所有其他伺服器，以及使用者鎖定的檔案。 不幸的是，這也表示分散式鎖定系統中通常會有單一失敗點。

• 完整路由網路的需求

由於中央代理程式必須能夠與參與檔案複寫的所有伺服器通訊，因此這可移除處理複雜網路拓撲的能力。 通道拓撲和多中樞和輪輻拓撲通常是不可能的。 在非完全路由的網路中，某些伺服器可能無法直接連絡對方或訊息代理程式，而且只能與自己可以與另一部伺服器通訊的合作夥伴交談，依此等方式。 這在多主控環境中很好，但不適用於代理機制。

• 限制為一組伺服器

某些解決方案會將拓撲限制為一對伺服器，以簡化其分散式鎖定機制。 對於較大的環境，這可能不可行。

• 在用戶端和伺服器上使用代理程式
• 請勿使用多宿主複寫
• 請勿使用 MS 叢集
• 使用特殊設備

* 請注意，我通常會說！ 請不要張貼死亡威脅，因為您有一個解決方案，但無法實作一或多個這些方法！

更深入的想法

當您進一步思考這個問題時，一些基本問題會開始出現。 例如，如果我們有四部伺服器，且有四個月臺中使用者可以修改的資料，且其中一個網站的 WAN 連線會離線，我們該怎麼做？ 使用者仍然可以存取其個別伺服器，但我們應該讓他們嗎？ 我們不希望他們改變這種衝突，但我們絕對希望他們繼續工作，賺我們的公司錢。 如果我們在該時間點任意封鎖變更，即使實際上沒有任何衝突發生，使用者也無法運作！ 無法告訴其他伺服器檔案正在使用中，而您又回到正方形。

接著有 SMB 本身和報告鎖定的錯誤處理。 我們無法真正變更 SMB 報告共用違規的方式，因為我們中斷了一噸的應用程式和用戶端無論如何都不會瞭解新的擴充錯誤訊息。 Word 2007 之類的應用程式會進行一些臥底技巧來找出誰正在鎖定檔案，但絕大多數應用程式不知道誰有使用中的檔案（或甚至 SMB 存在）。真的。。 因此，當使用者收到「此檔案正在使用中」訊息時，它並不特別可採取動作，他們是否都應該呼叫技術支援中心？ 技術支援中心是否可存取所有檔案伺服器，以查看哪些使用者正在存取檔案？ 混亂。

由於我們想要多宿主來取得高可用性，因此訊息代理程式系統較不理想：我們可能必須在所有伺服器上執行某些專案，讓所有伺服器都能夠透過非完全路由的網路進行通訊。 這需要非常複雜的同步處理技術。 這將增加網路上的一些額外負荷（雖然可能不多），它需要閃電快速，以確保我們不會在他們的工作中保持使用者：它必須執行檔案複寫本身 - 事實上，它可能需要以某種方式系結至複寫。 它也必須考慮與網路相關的伺服器中斷，而不是伺服器當機，不知何故。

然後，我們回到此案例的特殊用戶端軟體，以進一步瞭解鎖定，並可以為使用者提供一些有用的資訊（「在會計中呼叫 Susie 並告訴她釋放該檔」、「很抱歉，檔案鎖定拓撲已中斷，而您的系統管理員正阻止您開啟此檔案，直到修正」， 等等。 讓這個功能與在 Windows 中執行的數百萬個應用程式搭配使用，一定會很有趣。 有許多作業系統不受支援或取得軟體 – Windows 2000 已脫離主流支援，XP 即將推出。 Linux 和 Mac 用戶端在覺得這一點很重要之前，不會有此軟體，因此客戶必須希望其廠商製作類似的東西。

其他相關資訊

現在，在 DFSR 中控制這種情況的最簡單方式是使用 DFS 命名空間，引導使用者使用一致的命名空間來預測位置。 藉由正確設定 DFSN 月臺拓撲和伺服器連結，您可以強制使用者共用相同的本機伺服器，並只允許使用者在「主要」伺服器關閉時存取遠端電腦。 對於大部分的環境而言，這運作效果相當不錯。 除了 DFSR，SharePoint 是一個選項，因為它的簽出/簽入系統。 BranchCache （即將在 Windows Server 2008 R2 和 Windows 7 中推出）可能是一個選項，因為它的設計是為了緩和分支案例中檔案的讀取，但最終授權資料仍會只存在於一部伺服器上，在此 提供更多功能。 同樣地，這些廠商也有其解決方案。