DFSR で競合発生！…ところで競合って？

こんにちは。Windows プラットフォームサポート担当の比留間です。

DFS レプリケーション (DFSR) を構成したファイルサーバーを運用されている管理者の方であれば、一度はDFSRの「競合」発生イベントを目にしたことがあるのではないでしょうか。

DFSR は単純なバックアップソリューションではなく、「マルチマスタの構成による相互レプリケーションを前提としたテクノロジー」と位置づけられています。

つまり、どのサーバーで更新した内容も対等な立場として扱われるので、使用状況によっては常に更新内容の「競合」が発生し得るテクノロジーとも言えます。

これは、例えば、DFSR のレプリケーションに参加しているサーバー間で、同時にファイルを更新した場合、更新の競合が発生することになります。

競合が発生すると、一定の競合解決のルールに従い、勝者と敗者が決まります。勝者となったファイルはレプリケーショングループ内で複製されますが、敗者となったファイルは ConflictAndDeleted フォルダに移動されます。

今回は、US Directory Service Team の Blog ポストを参考に、DFSR の競合解決のルールを整理してみたいと思います。

https://blogs.technet.com/b/askds/archive/2010/01/05/understanding-dfsr-conflict-algorithms-and-doing-something-about-conflicts.aspx

競合解決のパターンには以下の 3つがあります。

シナリオ1．初期複製の場合

A と B の2つのサーバーがあります。
双方のサーバーに、c:\rfdata というフォルダがあります。
フォルダの中には “販売計画.pptx” というファイルがあります。
サーバーA の “販売計画.pptx” の日付は 2009年 7月です。一方、サーバーBの“販売計画.pptx” の日付は2009年 10月で、最近になってユーザーによる更新が行われています。

新しいレプリケーショングループを作成します。
C:\rfdata をレプリケートフォルダとして指定します。
サーバーAをプライマリサーバーとします。

結果： 2009年 7月版の“販売計画.pptx”が双方のサーバーに配置されます。2009年10月版はサーバーBで競合しますが、競合解決の結果排除されます。

理由： サーバーをプライマリに指定した場合、そのサーバー上のデータが必ず競合解決で優位になります。これがいわゆる「初期複製の競合解決アルゴリズム」です。

シナリオ2. 既に複製を実施済みの既存のファイル。これに双方のサーバーで更新を加えた場合は？

A と B の2つのサーバーがあります。
双方のサーバーは既存のレプリケーショングループのメンバーです。初期複製は実施済みです。レプリケートフォルダとして、c:\rfdataが指定されています。
フォルダの中には “販売計画.pptx” というファイルがあります。
この状況で、現在複製が遅延している状態です。（とりあえずここではサーバーAからネットワークケーブルを引き抜いた場合で考えます。）

まず、双方のサーバーで “販売計画.pptx” を更新します。更新の順番は、サーバー B、サーバー A の順番です。
引き抜いていたネットワークケーブルを接続します。

結果： 最後に更新したサーバー A の内容が、サーバー B に複製されます。（つまり、UTC での更新タイムスタンプが新しい方が反映される。）サーバー B の内容は競合解決に負けて、ConflictAndDeleted フォルダに移動されます。

説明： これは典型的な “ Last writer win” （最後に書いたもの勝ち）アルゴリズムによる競合解決の結果によります。DFSRは一般的にこのアルゴリズムにより競合を解決します。

シナリオ3．レプリケートフォルダ上に新しくファイルを追加した場合は？

A と B の2つのサーバーがあります。
双方のサーバーは既存のレプリケーショングループのメンバーです。初期複製は実施済みです。レプリケートフォルダとして、c:\rfdataが指定されています。
この状況で、現在複製が遅延している状態です。（とりあえずここではサーバーAからネットワークケーブルを引き抜いた場合で考えます。）

まず、同じ内容のファイルを、サーバーA 、サーバー Bの順に配置します。DFSR から見ると、これらは「新しく追加された」ファイルになります。
サーバー B 上でこのファイルを更新します。
引き抜いていたネットワークケーブルを接続します。

結果： サーバー A のファイルが競合解決に勝ち、サーバー B に複製されます。

説明： このパターンが、古いファイルが競合に勝つ唯一のパターンです。いわゆる “First creator win” （最初に作ったもの勝ち）アルゴリズムです。

二つのファイルがほぼ同時にレプリケートフォルダに追加されるような場面では、最も長期間存在するファイル（つまりタイムスタンプが古いファイル）の方がより重要な内容を含んでいるという仮説に基づく実装となります。

仕組みは分かったけど、「間違った」ファイルが競合に勝ってしまった場合、どうやって復元すれば良いの？

いくつか方法がありますが、基本的に事前に適切なバックアップ処理を実施しておくことが前提となります。

DPMを使う – Data Protection Manager は、即時バックアップ・リストアの機能を提供をしています。そのため、DPM を使用する方法が最も確実に最新版のファイルを復元できる手段となります。

Volume Shadow Copy を使う － Volume Shadow Copy を使用することで、DFSR サーバー上で自動バックアップを構成することができます。この方法を使えば、ユーザーが誤ってファイルを削除してしまったり、ファイルの競合が発生したとしても、簡単な操作で復元が行えます。少し操作に慣れればユーザーは自分自身でファイルを復元できるようになるので、ヘルプデスクに対する問い合わせも減るかもしれません。クライアントが Windows XP または（そろそろサポート期限が切れてしまいますが）Windows 2000 の場合、クライアントをインストールする必要があります。

Volume Shadow Copyについては、Windows ヘルプや、Technet の記事を参照の上、ベストプラクティスをよくご検討ください。ただし、Volume Shadow Copy があれば通常のバックアップが不要になるというわけではありませんので、ご注意を！

バックアップデータから復元する – Windows Server Backup または NTBackup (Windows Server 2003 R2 の場合)、あるいはサードパーティ製のソフトウェアを使用して日次バックアップを構成しておきます。この方法であれば、少なくとも前日時点でのファイルは最低限復元することができます。

最後の手段Restoredfsr.vbs －この方法はサポートの対象外となりますので、お客様自身で十分に検証を行った上でご使用下さい。もしも適切なバックアップデータがない場合、このスクリプトが最後の手段となります。このスクリプトは ConflictAndDeleted フォルダに移動されたファイルを強制的に元のファイルパスに復元する処理を実行します。ご利用の環境に合わせて一部の内容を書き換える必要がありますので、使用にあたってはドキュメントをよくお読み下さい。スクリプトは、下記のBlogポストより入手できます。

https://blogs.technet.com/b/askds/archive/2010/01/05/understanding-dfsr-conflict-algorithms-and-doing-something-about-conflicts.aspx

あとは、サポート担当としての経験から申しますと、DFSR にはリリース後、残念ながらいくつかの不具合が確認されております。

Windows Server 2003 R2 の話になりますが、不具合のひとつに、ウィルススキャンが実行されるタイミングで、ユーザーがファイルを更新した覚えのないタイミングで複製が実行されてしまうというものがあり、これが競合発生の原因となっている場合もあるようです。

Distributed File System Replication in Windows Server 2003 R2 performs unnecessary replication when an antivirus application is installed

https://support.microsoft.com/kb/944804/

https://support.microsoft.com/kb/944804/ja （日本語機械翻訳版）

こうした現象を未然に防ぐ意味でも、「おかしいな？」と感じたら、まずは DFSR に関する最新の修正プログラムを適用してみることをお勧めいたします。