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:

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

また、{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 のバージョンの違いにより出力内容に若干差異がある可能性がありますので、ご了承ください。

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


Comments (0)

Skip to main content