この記事では、Windows 内、特に DFSR によってレプリケートされたフォルダー内にマルチホスト分散ファイル ロック メカニズムが存在しないことについて説明します。
いくつかの背景
- 分散ファイル ロック: これは、複数のコンピューター上にファイルのコピーが複数あり、1つのファイルが書き込み用に開かれると、他のすべてのコピーがロックされるという概念を指します。 これにより、複数のユーザーが同時に複数のサーバーでファイルを変更することを防ぎます。
- 分散ファイル システム レプリケーション (DFSR): これは、マルチマスターの状態ベースの設計で動作します。 状態ベースのレプリケーションでは、マルチマスター システム内の各サーバーは、ログ ファイルを交換せずに、到着時にレプリカに更新プログラムを適用します (代わりに、バージョン ベクトルを使用して "最新の" 情報を維持します)。 初期同期後に任意に権限を持つサーバーは 1 つもないので、さまざまなネットワークトポロジで可用性と柔軟性が高くなります。
- サーバー メッセージ ブロック (SMB): これは、ネットワーク経由でファイルにアクセスために Windows で使用される一般的なプロトコルです。 簡単に言うと、リモート ファイル システムをローカル ファイル システムのように見せるためにリダイレクタを使用するクライアントサーバー プロトコルです。 これは Windows に固有ではなく、非常に一般的です。よく知られている Microsoft 以外の例は、Linux、Mac、その他のオペレーティング システムが SMB クライアント/サーバーとして機能し、Windows ネットワークに参加できる Samba です。
レプリケートされたデータ環境で DFSR と SMB がどこに存在しているかを明確に示すことが重要です。 SMB を使用すると、ユーザーは自分のファイルにアクセスできます。また、DFSR を認識する必要はありません。 同様に、DFSR (RPC プロトコルを使用) はサーバー間でファイルの同期を維持し、SMB を認識しません。 この投稿で定義されている分散ロックと便宜的ロックを混同しないでください。
Brits が言うように、ここで上手くいかなくなります。
ユーザーは複数のサーバー上のデータを変更でき、各 Windows サーバーはそれ自体のファイル ロックについてのみ知っているため、そしてDFSR は他のサーバー上のそれらのロックについて何も知らないため、ユーザーが互いの変更を上書きできるようになります。 DFSR は "最後のライターが優先される" 競合アルゴリズムを使用します。そのため、誰かが負ける必要があり、最後に保存する人が変更を保持するようになります。 失われたファイルのコピーは ConflictAndDeleted フォルダーに格納 されます。
現在、これはユーザーが思っているほど一般的ではありません。 通常、真の共有ファイルはローカル環境で変更されます。ブランチ オフィスまたは同じ列のキュービクルにあります。 通常、同じチームのユーザーが作業を行うので、一般的に、同僚がデータを変更していることを認識しています。 また、通常は同じサイトにいるため、共有ドキュメントで作業しているすべてのユーザーが同じサーバーを使用する可能性がはるかに高くなります。 Windows SMB ではこの状況が処理されます。 ユーザーが変更のためにファイルをロックして、同僚が編集しようとすると、他のユーザーには次のようなエラーが表示されます。
また、Word 2007 のように、ファイルを開くアプリケーションが本当に巧妙な場合は、次のようになります。
DFSR にはロックされたファイルのメカニズムがありますが、それはサーバー自体のコンテキスト内にしか存在しません。 ローカル コピーに排他ロックがある場合、DFSR はファイルを内外にレプリケートしません。 ただし、これは別のサーバー上のユーザーがファイルを変更することを妨げるものではありません。
トピックに戻ると、共有データが地理的に変更されるという問題は存在します。一部のユーザーにとってはかなり厄介です。 DFSR がこのロックを処理せずに、魔法の杖を振ってすべてを解決させる理由を時々尋ねられます。 これは、マルチマスター レプリケーション システムで解決する場合、面白いけれども困難なシナリオがあることが判明しました。 確認してみましょう。
サードパーティ ソリューション
この問題に対処するベンダー ソリューションがいくつかあり、通常、次の 1 つ以上の方法で対処します*。
- ブローカー メカニズムの使用
中央に「交通警官」を持つことで、1 つのサーバーが他のすべてのサーバーと、ユーザーによってロックされているファイルを認識できるようになります。 残念ながら、これは、分散ロック システムに単一障害点があることが多いことも意味します。
- 完全にルーティングされたネットワークの要件
中央ブローカーはファイル レプリケーションに参加しているすべてのサーバーと通信できる必要があるため、これにより複雑なネットワーク トポロジを処理する機能が失われます。 リング トポロジとマルチ ハブ アンド スポーク トポロジは通常は使用できません。 完全にルーティングされていないネットワークの場合、一部のサーバーは相互に直接接続できない場合やブローカーに接続できない場合があり、自身が別のサーバーと通信できるパートナーとしか通信できない場合があります。 これはマルチマスター環境では問題ありませんが、ブローカー メカニズムでは問題があります。
- サーバーのペアに制限されます
一部のソリューションでは、分散ロック メカニズムを簡素化するために、トポロジをサーバーのペアに制限しています。 大規模な環境では、これは実現できない場合があります。
- クライアントとサーバーでエージェントを使用する
- マルチマスター レプリケーションを使用しない
- MS クラスタリングを使用しない
- 特殊なアプライアンスを使用する
* 一般論を述べているので注意してください。 これらのメソッドの 1 つ以上を実装するまたは実装しないソリューションがあるため、殺害の脅迫を投稿しないでください。
より深い考え
この問題についてさらに考えると、いくつかの基本的な問題が発生し始めます。 たとえば、4 つのサイトのユーザーが変更できるデータを備えた 4 つのサーバーがあり、そのうちの 1 つへの WAN 接続がオフラインになった場合、どうすればよいでしょうか。 ユーザーは引き続き個々のサーバーにアクセスできますが、許可する必要がありますか? 競合するような変更を加えてほしくないのですが、ユーザーには常に働き続けて会社の利益を上げてほしいのです。 この時点で任意に変更をブロックすると、実際には競合が発生していなくても、ユーザーは作業できなくなります。 ファイルが使用中であり、最初の状態に戻ったことを他のサーバーに通知する方法はありません。
次に、SMB 自体とレポート ロックのエラー処理があります。 大量のアプリケーションを壊し、クライアントが新しい拡張エラー メッセージを理解できないため、SMB が共有違反を報告する方法を実際に変更することはできません。 Word 2007 のようなアプリケーションは、ファイルをロックしているユーザーを把握するために何らかの複雑な処理を行いますが、ほとんどのアプリケーションは、ファイルを使用しているユーザー (または SMB が存在するのかさえも) がわかりません。 そのため、ユーザーが「このファイルは使用中です」というメッセージを受け取った場合、それは特に操作可能ではありません。すべてのユーザーがヘルプデスクに電話する必要がありますか? ヘルプ デスクはすべてのファイル サーバーにアクセスして、どのユーザーがファイルにアクセスしているかを確認しますか? それは面倒なことです。
高可用性のためにマルチマスターが必要なため、ブローカー システムはあまり望ましくありません。 完全にルーティングされていないネットワークを介してもすべてのサーバーが通信できるように、すべてのサーバーで何らかの操作を実行する必要がある場合があります。 これには、非常に複雑な同期の手法が必要です。 これにより、ネットワークにいくらかのオーバーヘッドが発生する可能性があり (おそらくそれほど多くはありませんが)、ユーザーの作業を妨げないようにするために、非常に高速である必要があります。 ファイル レプリケーション自体より速く処理必要があります。実際には何らかの方法でレプリケーションに関連付ける必要があるかもしれません。 また、何らかの方法で、ネットワークに関連し、サーバーのクラッシュではないサーバーの停止を考慮する必要があります。
次に、このシナリオの特殊なクライアント ソフトウェアに戻ります。このソフトウェアは、ロックをよりよく理解し、ユーザーに役立つ情報を提供できます (「経理担当の Susie に電話して、そのドキュメントをリリースするように伝えてください」、「申し訳ありませんが、ファイル ロック トポロジは壊れていて、修正されるまで管理者がこのファイルを開くことを妨げています」など)。 これを Windows で実行されている何百万ものアプリケーションとうまく連携させることは、間違いなく興味深いことです。 サポートされていない、またはソフトウェアを入手できない OS はたくさんあります。Windows 2000 は主流のサポートから外れ、XP はまもなくサポートがなくなります。 Linux と Mac のクライアントは、それが重要であると感じるまでこのソフトウェアを持っていなかったので、顧客はベンダーが何か類似したものを作ってくれることを期待しなければなりませんでした。
詳細情報
現在、DFSR でこの状況を制御する最も簡単な方法は、DFS 名前空間を使用して、一貫した名前空間でユーザーを予測可能な場所に誘導することです。 DFSN サイト トポロジとサーバー リンクを正しく構成することにより、ユーザーにすべて同じローカル サーバーを共有させ、「メイン」サーバーがダウンしている場合にのみリモート コンピューターへのアクセスを許可します。 ほとんどの環境では、これは非常にうまく機能します。 DFSR の代わりとなるオプションが SharePoint ですが、これはチェックアウト/チェックイン システムだからです。 BranchCache (Windows Server 2008 R2 および Windows 7で提供) は、ブランチ シナリオでファイルの読み取りを容易にするように設計されているためオプションになる場合がありますが、最終的には、信頼できるデータは 1 台のサーバーにのみ存在します。詳細については、こちらを参照してください。 繰り返しになりますが、これらのベンダーにはソリューションがあります。