DFSRの複製の仕組みを理解する（前編）

こんにちは。サポート担当の比留間です。
今回は、DFSR の複製の仕組みについて見て行きたいと思います。

DFSR の複製の仕組みは非常に複雑で、実装されている内容を限られたスペースでご説明するのは残念ながら困難です。
しかしながら、DFSR に関するトラブルシューティングのために基本的な仕組みを理解する、という目的であれば、DFSR の複製について以下のようなステップに分類して考えることで比較的容易に全体像を把握することができます。

1. ファイルやフォルダの更新を検出する

2. 他のサーバーに更新があったことを通知する

3. 他のサーバーが自分のレプリケートフォルダに更新内容を複製する

まず、DFSR がどのようにファイルやフォルダの更新を検出しているのかについて見て行きます。

■ ファイル更新の検出の仕組み

DFSR では、NTFS の USN ジャーナル を監視することで、レプリケートフォルダ内の変更内容を監視しています。

USN ジャーナル について簡単にご説明すると、NTFS の仕様のひとつとして定義されている循環ログの一種です。NTFS ボリューム上でファイルやフォルダの変更があると、一意の更新番号（USN : Update Sequence Number）と更新日時、更新のあったファイル名、更新の種類が自動的に追記されて行きます。

この USN ジャーナルの情報を上手く使うと、例えばアプリケーションでディスクをフルスキャンしなくても「この日付からこの日付までの間に更新があったファイルを抽出する」といった操作ができるようになります。DFSR では、このUSN ジャーナルの更新を監視しています。

普段の PC の操作で何気なく作成したり編集したファイルにも、実は知らず知らずのうちに USN が割り振られています。現時点でファイルに割り振られた最新の USN は以下のように、fsutil usn コマンドで確認できます。

c:\>fsutil usn readdata c:\temp\usntest.txt メジャー バージョン   : 0x2 マイナー バージョン : 0x0 ファイルの参照番号 : 0x004e0000000357dc 親ファイルの参照番号 : 0x002c00000000eb44 USN : 0x00000001b441c480 タイム スタンプ : 0x0000000000000000 0:00:00 1601/01/01 理由 : 0x0 ソース情報 : 0x0 セキュリティ ID : 0x0 ファイル属性 : 0x20 ファイル名の長さ : 0x16 ファイル名オフセット : 0x3c ファイル名 : usntest.txt

このファイルを更新すると、以下のように、USNが書き換わることに注目して下さい。一方で、NTFS 上のファイルIDである、「ファイルの参照番号」や、親フォルダを示す「親ファイルの参照番号」は書き変わっていません。

c:\>echo aaaa > c:\temp\usntest.txt c:\>fsutil usn readdata c:\temp\usntest.txt メジャー バージョン   : 0x2 マイナー バージョン : 0x0 ファイルの参照番号 : 0x004e0000000357dc 親ファイルの参照番号 : 0x002c00000000eb44 USN : 0x00000001b4422880 タイム スタンプ : 0x0000000000000000 0:00:00 1601/01/01 理由 : 0x0 ソース情報 : 0x0 セキュリティ ID : 0x0 ファイル属性 : 0x20 ファイル名の長さ : 0x16 ファイル名オフセット : 0x3c ファイル名 : usntest.txt

 

■ DFSR の データベースに登録する

DFSR はレプリケートフォルダ内のファイルについて USN ジャーナルの追加を検出すると、そのファイルの更新を DFSR が管理しているデータベースに追加します。

データベースの中では以下のような情報が関連付けられます。

o UID

o GVSN

o 親フォルダの UID

o ファイル名

o NTFS ファイルID

デバッグログなどから DFSR の複製の状態を追跡するためには、上記の 5 つの情報を追跡していく必要があります。

 

■ UID と GVSN

DFSRでは、UID (Unique IDentifier) と GVSN (Global Version Sequence Number)という2つの ID を使用して複製の状況を追跡しています。

UID は ファイルおよびフォルダに対して一意に割り振られる ID です。UIDは、一度割り振られると、そのファイルまたはフォルダが削除されるまで、変更されることはありません。

一方、GVSN は、ファイルではなく更新に対して割り当てられる ID です。同じファイルまたはフォルダであっても、名前が変更されたり内容が上書きされたりするごとに新しい GVSN が割り当てられます。

UID と GVSN はいずれも以下のような形式で表記されます。

{DB GUID}-Version

…これだけ見せられても、なんのことやらさっぱりですね。

実際の例を挙げると以下のような形式になっています。

{9EFED9E2-F496-4BE2-A17B-73D22B1AD383}-v11

前半の {9EFED9E2-F496-4BE2-A17B-73D22B1AD383} の部分は、レプリケートフォルダが配置されているドライブごとに DFSR が作成する データベース の GUIDです。ファイルまたはフォルダが作成されたり更新されたドライブにあるデータベースの GUID が使用されます。また、v11 の部分はそのドライブにおいて DFSR が認識した更新の通し番号です。この2つの情報を結合することで、一意の ID を作り出しています。

 

■実験

では実際にファイルの更新に伴う UID と GVSN の動きを見てみましょう。

検証環境は以下のような環境です。

o レプリケーショングループ名： testdfsr.local\public\repl

o レプリケーショングループには、TEST-DFSR1 と TEST-DFSR2 というサーバーが参加しています。

o レプリケートフォルダ名： repl

o TEST-DFSR1 と TEST-DFSR2 にそれぞれ存在する c:\repl というフォルダをレプリケートフォルダとして指定しています。

まず、TEST-DFSR1 のレプリケートフォルダ内に、testfile.txt というファイルを新規作成してみます。

DFSR でこのファイルの新規作成操作がどのように管理されているかは、WMI の DfsrIdRecordInfo クラスのインスタンスの情報を取得することで確認することができます。

C:\Users\Administrator>wmic /namespace:\\root\microsoftdfs path DfsrIdRecordInfo where "filename like '%testfile.txt%'" get * /format:textvaluelist Attributes=32 Clock=20100622044545.161492-000 CreateTime=20100622044545.161492-000 Fence=3 Fid=562949953438730 FileHash=37285c5ab7618e5f c48ae9f7f09c7ba8 FileName=testfile.txt Flags=5 GVsn={9EFED9E2-F496-4BE2-A17B-73D22B1AD383}-v16 Index=4 ParentUid={9EFED9E2-F496-4BE2-A17B-73D22B1AD383}-v14 ReplicatedFolderGuid=7BD16799-5FAA-4B72-9B04-82807A6832BF Uid={9EFED9E2-F496-4BE2-A17B-73D22B1AD383}-v16 UpdateTime=20100622044545.161492-000 Usn=69270032 Volume=\\.\C:

UIDとGVSN の値がともに  {9EFED9E2-F496-4BE2-A17B-73D22B1AD383}-v16 となっていることに注目してください。ファイルやフォルダを新規に作成した場合は、UIDとGVSN が同じ値になります。

また、{9EFED9E2-F496-4BE2-A17B-73D22B1AD383} が  TEST-DFSR1 上の データベース GUID を表していることは、dfsrdiag guid2name コマンドで確認することができます。

C:\Users\Administrator>dfsrdiag guid2name /RGName:testdfsr.local\public\repl /guid:{9EFED9E2-F496-4BE2-A17B-73D22B1AD383}    Object Type : DfsrVolumeInfo    Computer : TEST-DFSR1.testdfsr.local    Volume Guid : 8EAC7A11-7D09-11DF-B8BE-806E6F6E6963    Volume Path : C:    Volume SN : 1821612555 DB Guid : 9EFED9E2-F496-4BE2-A17B-73D22B1AD383

このように、DFSR で管理している情報の上でも TEST-DFSR1 の C ドライブ上の更新として認識されていることが確認できます。

次に、もう一方のサーバー TEST-DFSR2 上で、レプリケートされた testfile.txt を編集しましたとします。

編集された内容が TEST-DFSR1 側にレプリケートされたのを確認したら再度、TEST-DFSR1 上で DfsrIdRecordInfo クラスのインスタンスの情報を確認してみます。

C:\Users\Administrator>wmic /namespace:\\root\microsoftdfs path DfsrIdRecordInfo where "filename like '%testfile.txt%'" get * /format:textvaluelist Attributes=32 Clock=20100622052014.892869-000 CreateTime=20100622044545.161492-000 Fence=3 Fid=1125899906860027 FileHash=ffec6a6197bae5c7 0e2cf2994a2e13dd FileName=testfile.txt Flags=5 GVsn={5A12E953-1D01-4B46-AE6D-D31AFBB026CA}-v12 Index=4 ParentUid={9EFED9E2-F496-4BE2-A17B-73D22B1AD383}-v14 ReplicatedFolderGuid=7BD16799-5FAA-4B72-9B04-82807A6832BF Uid={9EFED9E2-F496-4BE2-A17B-73D22B1AD383}-v16 UpdateTime=20100622052014.906698-000 Usn=70118496 Volume=\\.\C:

 

UID の値は書き換わっていませんが、GVSN の値が書き換わっていることがわかります。再度 dfsrdiag guid2name コマンドで、DB GUID の部分{5A12E953-1D01-4B46-AE6D-D31AFBB026CA} を確認してみましょう。

C:\Users\Administrator>dfsrdiag guid2name /RGName:testdfsr.local\public\repl /guid:{5A12E953-1D01-4B46-AE6D-D31AFBB026CA}    Object Type : DfsrVolumeInfo Computer : TEST-DFSR2.testdfsr.local    Volume Guid : 8FE73079-7D09-11DF-B87E-806E6F6E6963 Volume Path : C:    Volume SN : 1821612555 DB Guid : 5A12E953-1D01-4B46-AE6D-D31AFBB026CA

DB GUIDは TEST-DFSR2 のものとなっています。このことから、testfile.txt が最後に更新されたのが TEST-DFSR2 上であることが分かります。

では、ちょっとしつこいですが、この状態から同じファイルをさらに TEST-DFSR1 側で更新するとどうなるでしょうか。

C:\Users\Administrator>wmic /namespace:\\root\microsoftdfs path DfsrIdRecordInfo where "filename like '%testfile.txt%'" get * /format:textvaluelist Attributes=32 Clock=20100622083539.978617-000 CreateTime=20100622044545.161492-000 Fence=3 Fid=1125899906860027 FileHash=c5acdc045256cde3 051d6dab371dfb5c FileName=testfile.txt Flags=5 GVsn={9EFED9E2-F496-4BE2-A17B-73D22B1AD383}-v17 Index=4 ParentUid={9EFED9E2-F496-4BE2-A17B-73D22B1AD383}-v14 ReplicatedFolderGuid=7BD16799-5FAA-4B72-9B04-82807A6832BF Uid={9EFED9E2-F496-4BE2-A17B-73D22B1AD383}-v16 UpdateTime=20100622083539.978617-000 Usn=71722840 Volume=\\.\C:

GVSN の DB GUIDは、再び TEST-DFSR1 のものになっていますが、Version の部分が v17 に繰り上がっているのがお分かりいただけると思います。

次回は、DFSR のデバッグログを題材に、ファイルの更新を検出してから、他のサーバーにその内容が複製されるまでの流れを追って行きたいと思います。

注：この記事のコマンド実行結果などは、Windows Server 2008 SP2 を基準としております。OS のバージョンの違いにより出力内容に若干差異がある可能性がありますので、ご了承ください。

「コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。」