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

本文討論 Windows 內沒有多宿主分散式檔案鎖定機制,尤其是在 DFSR 複寫的資料夾內。

部分背景

  • 分散式檔案鎖定 – 指的是在數部電腦上擁有多個檔案複本的概念,而開啟一個檔案進行寫入時,會鎖定所有其他複本。 這可防止多個使用者同時在多部伺服器上修改檔案。
  • 分散式檔案系統複寫 ––會在以狀態為基礎的多宿主設計中運作。 在以狀態為基礎的複寫中,多宿主系統中的每部伺服器都會在其到達時套用更新,而不會交換記錄檔 (它會改為使用版本向量來維護 “ 最新的 ” 資訊) 。 初始同步處理之後,沒有任何一部伺服器會有任何授權,因此在各種網路拓撲上都具有高度可用性和彈性。
  • 伺服器訊息區- SMB是 Windows 中用來透過網路存取檔案的常見通訊協定。 簡單來說,它是一種用戶端-伺服器通訊協定,利用重新導向器讓遠端檔案系統看起來就是本機檔案系統。 這並不是 Windows 特有,而且很常見 – 的非 Microsoft 範例是 Samba,可讓 Linux、Mac 和其他作業系統作為 SMB 用戶端/伺服器,並參與 Windows 網路。

很重要的是,請務必清楚略圖在複寫的資料環境中,DFSR 和 SMB 的存留處。 SMB 可讓使用者存取他們的檔案,而且不知道 DFSR。 同樣地,使用 RPC 通訊協定的 DFSR () 會讓伺服器之間的檔案保持同步,而且不會察覺到 SMB。 請勿將分散式鎖定與此 post 和隨機 鎖定中所定義的混淆。

這就是 Brits 所說的東西。

由於使用者可以修改多部伺服器上的資料,因為每一部 Windows 伺服器本身只知道檔案鎖定,而且因為DFSR 不知道其他伺服器上的任何鎖定,所以使用者可能會覆寫彼此的變更。 DFSR 使用「 “ 最後寫入者獲勝」 ” 衝突演算法,所以某人必須遺失,且要儲存最後一個的人才能繼續進行變更。 遺失的檔案複本會 chucked 至 ConflictAndDeleted 資料夾。

現在,這遠比大家覺得 更不 常見。 一般來說,在本機環境中會修改真正的共用檔案;在分公司或同一個資料列中。 它們通常會由相同小組的人員來處理,因此人們通常會察覺修改資料的同事。 因為它們通常位於相同的網站上,所以在共用檔上工作的所有使用者都將使用相同的伺服器。 Windows SMB 在此處理這種情況。 當使用者已鎖定檔案進行修改,而他的同事嘗試編輯該檔案時,其他使用者將會收到如下的錯誤:

Screenshot of the File In Use dialog box showing an error message that says This action can't be completed because the file is open in another program.

如果開啟檔案的應用程式真的很聰明(像是 Word 2007),它可能會提供您:

Screenshot of the File In Use dialog box showing three actions you can take when a file is locked by another user.

DFSR 具有鎖定檔案的機制,但它只在伺服器本身的內容中。 如果它的本機複本具有獨佔鎖定,DFSR 就不會將檔案複製到其中或從中取出。 但這並不會防止其他伺服器上的任何人修改檔案。

回到主題, 在地理位置 修改的共用資料有問題存在,而針對某些人來說,這是相當複雜的問題。 我們偶爾會詢問 DFSR 為何無法處理這項鎖定,並以魔術棒的浪潮來處理所有事物。 其實這是一個有趣且困難的案例,可解決多宿主複寫系統。 讓我們開始探索吧。

協力廠商解決方案

有一些廠商解決方案會採取這個問題,而這些解決方案通常會透過下列一或多種方法來解決 *:

  • 使用訊息代理程式機制

讓中央 ‘ 流量 cop」可讓一部伺服器知道所有其他伺服器,以及使用者已鎖定的檔案。 可惜的是,這也表示分散式鎖定系統中通常會有單一失敗點。

Diagram showing the use of a broker mechanism.

  • 完全路由網路的需求

因為中央訊息代理程式必須能夠與所有參與檔案複寫的伺服器通訊,所以這會移除處理複雜網路拓撲的能力。 通常不可能進行環狀拓撲和多中樞和輪輻拓撲。 在非完全路由的網路中,某些伺服器可能無法直接聯繫彼此或訊息代理程式,而且只能與本身可以與其他伺服器通訊的夥伴溝通 – 。 這在多主控環境中是正常的,但無法使用代理機制。

Diagram showing the requirement for a fully routed network.

  • 受限於一對伺服器

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

  • 利用用戶端和伺服器上的代理程式
  • 請勿使用多重主要複寫
  • 請勿利用 MS 叢集
  • 利用專長設備

* 請注意,我通常會說! 請勿張貼死亡威脅,因為您的解決方案不會執行一或多個這些方法!

更深入的想法

當您進一步考慮此問題時,會開始進行一些基本的問題。 比方說,如果我們有四部具有可由使用者在四個網站中修改之資料的伺服器,且其中一個的 WAN 連線離線,該怎麼辦? 使用者仍然可以存取其個別的伺服器, – 但我們應該讓他們能夠存取它們嗎? 我們不希望它們進行衝突的變更,但我們一定希望它們保持運作,並讓公司成為金錢。 如果我們在該時間點隨意封鎖變更,即使沒有發生任何衝突,使用者也不會有任何作用! 沒有任何方法可告訴其他伺服器正在使用該檔案,而您又回到第一部伺服器。

Diagram showing the results of a partial network outage.

然後是 SMB 本身和報告鎖定的錯誤處理。 我們無法真的改變 SMB 報告共用違規的方式,因為我們會打破大量的應用程式,而且用戶端也不會瞭解新的擴充錯誤訊息。 像 Word 2007 的應用程式會執行一些 undercover 的 trickery,以找出正在鎖定檔案的物件,但大部分的應用程式並不知道誰有使用檔案 (或甚至是 SMB 存在。 其實 ) 。 因此,當使用者取得此檔案正在使用中的訊息時,如果 ‘– 他們呼叫技術支援中心,它就不會特別可行? 技術支援中心是否可存取所有檔案伺服器,以查看哪些使用者正在存取檔案? 混亂。

因為我們想要多宿主的高可用性,所以不需要 broker 系統;我們可能需要在所有伺服器上執行某些專案,讓它們可以透過非完全路由網路進行通訊。 這需要非常複雜的同步處理技術。 它會在網路上增加一些額外負荷 (雖然可能不會) ,而且必須快速快速,以確定我們不會讓使用者在工作中執行;它本身需要 outrun 檔案複寫,事實上,它可能需要以某種方式與複寫系結。 此外,它也必須考慮與網路相關的伺服器中斷,且不會發生伺服器損毀的情況。

Diagram showing Locking and Replication across five servers.

然後再回到特別的用戶端軟體,以瞭解鎖定,並可讓使用者在 Susie 中提供一些有用的資訊 “ , (Go 通話,並告知她釋出該檔 ” , “ 抱歉,檔案鎖定拓撲已中斷,且您的系統管理員在修正之前,無法開啟此檔案。 ” 等) 。 在 Windows 中執行數百萬個應用程式時,一定會有興趣。 有許多作業系統不受支援,或取得軟體 – Windows 2000 不是主流支援,而 XP 很快就會推出。 Linux 和 Mac 用戶端在認為很重要的情況下不會有此軟體,因此客戶必須希望其廠商建立類似的內容。

其他資訊

現在最簡單的方式是在 DFSR 中控制這種情況,就是使用 DFS 命名空間來引導使用者使用一致的命名空間,以提供可預測的位置。 藉由正確設定您的 DFSN 網站拓撲和伺服器連結,您可以強制使用者全都共用相同的本機伺服器,而且只有在 ‘ 主要的伺服器關閉時,才允許他們存取遠端電腦。 在大部分的環境中,這種方式的效果很好。 除了 DFSR 之外,SharePoint 是因為其簽出/簽入系統的選項。 適用于 Windows Server 2008 R2 和 Windows 7) 的 BranchCache (可能是您的選擇,因為它是為了簡化分支案例中的檔案讀取而設計,但在最後,授權資料仍會存留在一部伺服器上 – 。 – 同樣地,這些廠商都有自己的解決方案。