DFS Replication の初期複製を高速化するには？
こんにちは。Windows プラットフォームサポートの比留間です。
DFS Replication （以下 DFSR） のレプリケーション グループにファイル サーバーを参加させると、他のメンバー サーバーとの間でレプリケート フォルダーの初期状態の同期をとるための「初期複製 (Initial Sync)」と呼ばれる処理が実行されます。
しかしながら、ファイル サーバーに格納されているファイル サイズが非常に大きい場合、初期複製の完了までに時間がかかってしまう場合があります。
この点を解決するため、DFSR では、新しくレプリケーション グループに参加させるファイル サーバー上に、あらかじめレプリケーション対象となるファイルを配置しておくことで、DFSR による 初期複製に要する時間を短縮する展開方法が用意されています。
この手法はよく、「プレステージング」と呼ばれています。
しかし、プレステージングを効果的に行うためにはいくつか考慮しなければならない点があります。
今回は、米国マイクロソフトの Directory Service サポート チームが作成した以下の Blog 記事を元に、プレステージング時に考慮するべき点について確認してみましょう。
Get out and push! Getting the most out of DFSR pre-staging
■プレステージングとは？
プレステージングは複製対象となるファイルの最新版を、DFSR のダウンストリーム サーバーとして追加する前に「あらかじめ」レプリケート フォルダ上に配置しておくことを指します。これにより初期複製時にネットワーク上で転送される情報量が削減され、DFSR サービスが全てのファイルをコピーするよりは早期に初期複製が完了する、という効果が期待できます。このときに NTBackup や Robocopy といったツールがよく使用されます。
■初期複製の動作
プレステージングの議論に入る前に、初期複製が実際にどのような動きをするものなのか理解する必要があります。下の図は大幅に簡略化されたものではありますが、処理全体の概要を示しています。
図を良く見て、プレステージングのパフォーマンス上、問題となりそうな点がないかどうか確認してみてください。何かお気づきでしょうか？
ステップ 6 でダウンストリーム サーバーが、ファイル全体が必要なのか、ファイルの一部が必要なのか、それとも（両者のサーバーが完全に同じファイルを保持しているので）ファイルを必要としていないかを判断する「前」に、アップストリーム サーバー側でファイルをステージング フォルダに配置しなくてはなりません。
たとえ、両者のサーバーで完全に同一のファイルを保持している場合であっても、ファイルのどの部分を転送するかを判断するために、アップストリーム サーバー側では全てのファイルについてステージング処理を行う必要があるのです。
そのため、ネットワーク上では極めて少量のデータを転送すれば済む場合であっても、ダウンストリーム サーバー側でファイルのどのような情報を必要としているかを判断する処理をアップストリーム サーバー側で行うため、最初のパートナー間での初期複製に予想以上に時間がかかるといった現象が発生する可能性があります。
では、この点をどのように改善すれば良いのでしょうか？
■プレステージングした場合の初期複製の動作
まずは、レプリケーション グループに 3台目のサーバーを追加した時にどのような動作になるかを見てみましょう。
アップストリーム サーバーのステージング フォルダーには既にファイルが配置されていますので、手順は大幅に省略されて、各サーバーはファイルのデータの移動やハッシュの交換に専念することができます。つまり、格段に処理が早い、ということになります。（ただし、ステージング フォルダーはあくまでもキャッシュであり、時間が経てば新しいもので上書きされてしまう可能性がある点に留意する必要があります。）
私たちの検証環境では以下のような結果となりました。
環境 :
Virtual Server 2005 の仮想マシン上で実行される Windows Server 2003 Enterprise R2 SP2 を仮想プライベート ネットワークで接続して検証。
各サーバーのステージング領域は 4GB (既定値)。
アップストリーム側のボリュームに 5.7GB のデータを配置。
レプリケーションに要した時間の測定には、DFSR イベントログの ID 4102 と ID4104 を使用。
検証結果 :
検証1：
新しいレプリケーション グループをプレステージングなしで作成した場合
初期複製の所要時間： 28 秒 （これをベースライン値とします）
検証2：
上記とは別の環境で、新しいレプリケーション グループを作成。
ただし、データはダウンストリームサーバーに事前に NTBACKUP を使用してプレステージング。
（ファイル本体のレプリケーションが省略される分、高速化が期待できます）
初期複製の所要時間： 24 秒 （ベースライン値より 15% 高速化）
検証3：
検証2 で作成したレプリケーション グループに 3 台目のサーバーを追加。
3台目のサーバーには事前に NTBACKUP を使用してプレステージング。
（アップストリームサーバーでのステージング処理および、ファイル本体のレプリケーションが省略される分、高速化が期待できます）
初期複製の所要時間： 13 秒 （ベースライン値より 55% 高速化）
55% の高速化では、あまり驚かれないかもしれません。しかし、これはあくまでも少量のデータを転送した際の結果です。もしも大量のデータと極めて低速な回線で接続された環境で初期複製に2週間かかるものと仮定し、ステージングとハッシュの計算にそのうち 2 時間が使用され、残りの時間はネットワーク上のデータ転送にかかる場合を考えてみてください。この場合ですと、（1週間 - 2時間） / 1 週間 という計算より、理論上は 99% の高速化が実現できることになります。
以上のとおり、アップストリーム サーバー上に既にステージングされたデータが存在する状況であれば、ステージング フォルダーの操作にかかる時間が短縮され、サーバー間の同期状態の検証にもほとんど時間がかからないことがわかります。
■プレステージングの最適化
以下の点を確認することで、ステージング フォルダーの操作時間の短縮と、ファイルの同期処理の効率化が行われ、プレステージングの恩恵を最大化することができます。
・レプリケーションのハブとなるサーバーで、ステージング フォルダーの制限サイズを、極力実際のデータ総量のサイズに近づけます。通常、ハブ サーバーには他のブランチとなるサーバーよりも性能が充実した機材を選定することと思いますので、この点については管理上もあまり問題にならいないのではないでしょうか。もしもディスクの空き容量が余っているのであれば、ステージング フォルダーの制限サイズを実際のデータ サイズと等しくすることで、最善の結果を得ることができます。
・プレステージングを行う際には、必ず最新のバックアップ データを使用して、業務時間外のプレステージングの実施を行いましょう。初期レプリケーション中のステージング フォルダーへの変更が少なければ少ないほど、良い結果が得られます。
・最新のファームウェア、チップセット ドライバー、ネットワーク アダプターのドライバー、ディスク ドライバーをハードウェア ベンダーから入手しておきましょう。DFSR に限らず、サーバー全体のパフォーマンスの向上が見込めます。
■ツールについてのテクニカル ノート
具体的な方法については、 こちら に新たな情報を掲載いたしました。(2011/04/05)
1. Robocopy
プレステージングに Robocopy.exe を使用する場合、レプリケート フォルダーのルート階層（例えば c:\my_replicated_folder） に、あらかじめ各サーバー間で「完全に同一な」アクセス権設定をしておきましょう。こうしておかないと、Robocopy でファイルのミラーリングを行い、アクセス権の設定をコピーする際に、余計な 4412 イベント （競合を示すイベントです）と、不要な複製処理が実行されることがあります。これは、Robocopy がルート フォルダーからのアクセス権の継承を処理する際の動きと、各ファイルのハッシュを変更する際の動きに関連しており、ファイルのアクセス権に差異がある場合、ファイルハッシュの計算結果に影響を及ぼすためです。そのため、各サーバー間でアクセス権が「完全に同一」 であれば、/COPYALL /MIR /Z /R:0 オプションで Robocopy を実行することについては何の問題もありません。Robocopy でプレステージングを実施した後は、必要に応じて、ICACLS.EXE で、アクセス権の照合と同期を行うことが出来ます。
2. NTBACKUP （Windows Server 2003 R2）
既に DFSR のデータをホストしているサーバー上の同一のボリュームで NTBACKUP によるプレステージングを行おうとしている場合（例えば、他のデータのレプリケーションを E: ドライブ上で既に行っている状態で、新たなレプリケート フォルダーを E: ドライブ上に構築しようとしているような場合）、なおかつ、完全ディスク バックアップからのリストアを計画している場合、NTBACKUP の重要な挙動について理解しておく必要があります。
NTBACKUP は DFSR に対応していますが、NTBACKUP は DFSR サービスのレジストリ キー (HKLM\System\CurrentControlSet\Services\DFSR\Restore\<日時> ) にリストア キーを設定し、DFSR サービスに「権威のないリストア状態」フラグを設定します。これにより DFSR サービスは再起動され、リストア対象のボリュームは権威のない同期処理を開始します。これによってデータそのものが破壊されることはありませんが、同期が実行されている間の数十分から数時間にかけて、ダウンストリーム側のサーバーが応答しない状態になる場合があります。
DFSR が実装された際の構想では、NTBACKUP は障害回復用のツールとして想定されており、データと DFSR Jet データベースの健全性に疑義がある状態であるため、リストア時に整合性を取るための同期処理が必要なものと判断されたためです。
なお、Windows Server 2008 ではバックアップとリストアに完全に新規のメカニズムが採用されており、上記の挙動は該当しません。
3. XCOPY
XCOPY /O コマンドを使用すれば、アクセス権の移行は行えますが、コピー処理に伴いファイルハッシュが変更されてしまう場合があります。また、他の観点でも、Robocopy に比べると、処理が洗練されておらず堅牢性の面でも見劣りがします。つまり、多くの場合、XCOPY よりも Robocopy を使用することが推奨されます。
4. サードパーティー製のツール、ソリューション
サードパーティー製のツールを大規模なプレステージングに使用する際には、事前に慎重に検証をされることをお勧めします。留意しなくてはならないのは、「ファイル ハッシュが全て」、という点です。DFSR がアップストリーム側とダウンストリーム側のハッシュの同一性がないと判断した場合、初期複製においてファイルのレプリケーションが行われます。ハッシュの対象となるのはセキュリティACL などのメタデータも含まれます（ファイルのチェックサムを計算するツールなどでは、この部分は計算対象にならないデータです）。なお、Windows Server 2008 R2 では DfsrDiag ツールにファイル ハッシュを計算する機能 （FileHash オプション）が含まれています。
「コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。」