[注 翻訳者。 この記事はWindows Server 2003 / 2003R2 / 2008 / 2008R2を対象としていますが、上記のほとんどはOSの新しいバージョンに適用されます]
ウォーレンは再びここにいます。 この記事は、DFSRが正しく機能するために必要な最小ステージングフォルダーサイズを正しく計算する方法に関するクイックリファレンスガイドです。 低い値を設定すると、レプリケーションが遅くなったり、停止することさえあります。 これらは最小値にすぎないことに注意してください。 中間フォルダーのサイズを決定するときは、次のことに注意してください。中間フォルダーのサイズが大きいほど、レプリケートフォルダー自体のサイズまでは良好です。 ステージングフォルダーの正しいサイズを使用することの重要性の詳細については、「ステージングフォルダーに問題があるかどうかを判断する方法」セクションおよびこの記事の最後にリンクされているブログ投稿を参照してください。
更新：ウォーレンは本当に説得する方法を知っています！ 現在、ステージングフォルダーのサイズを計算できる修正プログラムがあります。
https://support.microsoft.com/kb/2607047
経験則
Windows Server 2003 R2 —ステージングフォルダーのクォータは、レプリケートフォルダー内の最大9個のファイルの合計サイズと同じにする必要があります。
Windows Server 2008および2008 R2 —ステージングフォルダーのクォータは、レプリケートフォルダーの32個の最大ファイルの合計サイズと同じである必要があります[注 翻訳者。 この番号はWindows Server 2012 / 2012R2でも有効です ]
プライマリレプリケーションは、通常の毎日のレプリケーションよりも多くのスペースをステージングフォルダーで使用します。 ディスクスペースのサイズが許す場合、プライマリレプリケーションを開始する前に、必要な最小サイズを超えるサイズを設定することを強くお勧めします。
PowerShellはどこで入手できますか？
PowerShellはWindows 2008以降に含まれています。 Windows Server 2003にインストールする必要があります。 ここからWindows 2003用のPowerShellをダウンロードします 。
これらの最大のファイルを見つける方法は？
PowerShellスクリプトを使用して、32個または9個の最大ファイルを見つけ、それらが占めるギガバイト数を決定します（PowerShellコマンドのNed Pyleに感謝します）。 3つのPowerShellスクリプトを紹介します。 それぞれが独自の方法で有用ですが、3番目が最も有用です。
- 実行：
Get-ChildItem c:\temp -recurse | Sort-Object length -descending | select-object -first 32 | ft name,length -wrap -auto
このコマンドは、ファイル名とそのサイズをバイト単位で返します。 レプリケートフォルダーで最大の32個のファイルを見つけて、その所有者にアクセスすると便利です。
- 実行：
Get-ChildItem c:\temp -recurse | Sort-Object length -descending | select-object -first 32 | measure-object -property length –sum
このコマンドは、名前を指定せずに、フォルダー内の最大32個のファイルの合計バイト数を返します。
- 実行：
$big32 = Get-ChildItem c:\temp -recurse | Sort-Object length -descending | select-object -first 32 | measure-object -property length –sum $big32.sum /1gb
このコマンドは、フォルダー内の32個の最大ファイルの合計バイト数を取得し、数学的計算を使用してギガバイトに変換します。 このコマンドは、2行に分かれています。 PowerShellコマンドシェルに一度に貼り付けるか、順番に実行できます。
手動分析
プロセスを実証し、可能であれば、私たちが何をしているかについての理解を深めるために、各操作を経て、手動で実行します。
最初に実行するコマンドは、以下に示すような結果を返します。 簡潔にするため、この例では16個のファイルのみを使用します。 Windows 2008以降のオペレーティングシステムでは32ファイル、Windows 2003 R2では9ファイルを常に考慮してください。
PowerShellによって返されるサンプルデータ：
| お名前 | 長さ |
|---|---|
| File5.zip | 10286089216 |
| archive.zip | 6029853696 |
| BACKUP.zip | 5751522304 |
| file9.zip | 5472683008 |
| MENTOS.zip | 5241586688 |
| File7.zip | 4321264640 |
| file2.zip | 4176765952 |
| frd2.zip | 4176765952 |
| BACKUP.zip | 4078994432 |
| File44.zip | 4058424320 |
| file11.zip | 3858056192 |
| Backup2.zip | 3815138304 |
| BACKUP3.zip | 3815138304 |
| Current.zip | 3576931328 |
| Backup8.zip | 3307488256 |
| File999.zip | 3274982400 |
このデータを使用して、ステージングフォルダーの最小サイズを決定する方法：
- 名前=ファイル名
- 長さ=バイト単位のサイズ
- 1ギガバイト= 1073741824バイト
最初に、合計バイト数を計算する必要があります。 次に、結果の数値を1073741824で除算します。これらの計算に使用するExcelまたは別のスプレッドシートエディターを使用することをお勧めします。
例ベースの計算
上記の例では、合計バイト数は75241684992です。中間クォータの最小必要サイズを取得するには、75241684992を1073741824で割る必要があります。
75241684992/1073741824 = 70.07（GB）
データに基づいて、ステージングフォルダーのサイズを71 GBに設定し、整数に切り上げます。
実用化
手動分析は興味深いことですが、時間をかけるのは最善の方法ではありません。 プロセスを自動化するには、上記の例の3番目のコマンドを使用します。 結果は次のようになります。
3番目の例のコマンドを使用すると、d：\ docsフォルダーに6 GBの中間クォータが必要であると判断するために、計算なしで（丸めはカウントしません）可能です。
変更を適用するには、サーバーを再起動するか、サービスを再起動する必要がありますか？
ステージングフォルダーのクォータに加えられた変更を有効にするために、サーバーを再起動したり、サービスを再起動したりする必要はありません。 変更を適用するには、ADレプリケーションが完了するのを待ち、ADのDFSRオブジェクトのポーリングサイクルを待つ必要があります。
ステージングフォルダーの問題を識別する方法
中間フォルダーの問題は、DFSRサーバーログで特定のイベントコードを追跡することで検出されます。 これらのイベントのリストは次のとおりです。4202、4204、4206、4208、および4212。それらの説明を以下に示します。 イベント4202と4204、およびその他のイベントの違いを理解することが重要です。 イベント4202および4204は、通常の操作中に大量に記録できます。 イベント4202および4204は脈拍のようなものと考えてください。4206、4208、および4212は胸の痛みに似ています。 以下に、イベント4202および4204の解釈方法を説明します。
ステージングフォルダー関連のイベント
[注 翻訳者。 以下で説明するジャーナルイベントは、Windows Server 2012 R2のロシア語ローカリゼーションに存在する形式で表示されます。]
コード： 4202
レベル： 警告
DFSレプリケーションは、ローカルパス<パス>を持つレプリケートフォルダーが使用するステージングスペースが上限を超えていることを検出しました。 サービスは、最も古い中間ファイルを削除しようとします。 これはパフォーマンスに影響する場合があります。
コード： 4204
レベル： 情報
DFSレプリケーションサービスは、ローカルパス<パス>のレプリケートフォルダーの古い中間ファイルを正常に削除しました。 中間スペースが上限を下回りました。
コード： 4206
レベル： 警告
DFSレプリケーションサービスは、ローカルパス<パス>上のレプリケートフォルダーの古い中間ファイルをクリーンアップできませんでした。 サービスはいくつかの大きなファイルをレプリケートできない場合があり、レプリケートフォルダーが同期しなくなる場合があります。 サービスは、<X>分以内にステージング領域の再クリーニングを自動的に試行します。 いくつかの中間ファイルがロック解除されたことを検出すると、サービスはすぐにクリーニングを開始する場合があります。
コード： 4208
レベル： 警告
DFSレプリケーションは、ステージングスペースがローカルパス<パス>上のレプリケートフォルダーのステージングクォータを超えていることを検出しました。 一部の大きなファイルをレプリケートすると、レプリケートフォルダーが同期しなくなる場合があります。 サービスは、ステージング領域の再クリーニングを自動的に試行します。
コード： 4212
レベル： エラー
中間パスが無効またはアクセスできないため、DFSレプリケーションサービスは、ローカルパス<パス>でレプリケートフォルダーをレプリケートできませんでした。
イベント4202と4208の違いは何ですか？
イベント4202および4208にも同様の説明があります。 DFSRは、ステージングフォルダーが占めるサイズが制限を超えていることを検出します。 違いは、中間フォルダーのクリーニングプロセスが開始された直後にイベント4202がログに記録される一方で、中間クォータがまだ超過していることです。 イベント4202は通常の通常動作の兆候ですが、4208は標準からの逸脱を示しており、介入が必要です。
イベント4202および4204が大きすぎると見なされるイベントはいくつありますか？
この質問に対する単一の答えはありません。 常に悪いことを言い、アクションの必要性を示すイベント4206、4208、および4212とは対照的に、イベント4202および4204は通常の操作中にも発生します。 頻繁なイベント4202および4204 は問題を示している可能性があります。 考慮すべき事実：
- プライマリレプリケーション中にレプリケートフォルダー（RF）の4202イベントが記録されていますか？ その場合、イベント4202および4204は正常です。 初期同期中にこれらのイベントの数を最小限に抑えたい場合は、中間フォルダーのサイズを増やすことでこれを実現できます。
- 4202イベントの総数をカウントするだけでは十分ではありません。 それらの数が特定のRFに適用されることを知る必要があります。 24時間以内に、1つのフォルダーに関連するジャーナルに20個の4202イベントがあった場合、これは非常に多くなります。 しかし、レプリケートフォルダーが20個あり、それぞれに1つのイベントがある場合、すべてが正常に処理されます。
- 傾向を特定するには、数日間にわたって収集された情報を分析する必要があります。
通常、通常の運用中は、レプリケートフォルダーごとに1つの4202イベントしか許可しないことをお勧めします。 「通常」は、プライマリレプリケーションが発生しないことを意味します。 次の理由でこれを実証します：
- ステージングフォルダーをクリーンアップするのにかかる時間は、ファイル複製からかかる時間です。 ステージングフォルダーがクリーンアップされている間、レプリケーションは中断されます。
- DFSRは、 RDCおよびクロスファイルRDCに使用するだけでなく、他のレプリケーションメンバーに同一のファイルを複製するために十分なスペースが中間に割り当てられている場合、より効率的に機能します 。
- より多くのイベント4202および4204がログに記録されると、DFSRがステージングフォルダーをクリアできない、または途中でファイルを削除しなければならない状況が発生する可能性が高くなります。
- 私の経験では、イベント4206、4208、および4212は常に予想され、多数のイベント4202および4204が付随していました。
「各RFに対して1日あたり4202イベントを超えない」というルールに従うと、ステージングフォルダーでの問題の可能性が大幅に減少し、DFSRサーバーが目的のリソース（ファイル複製）をより効率的に使用できるようになります。
追加情報
https://blogs.technet.com/b/askds/archive/2010/03/31/tuning-replication-performance-in-dfsr-especially-on-win2008-r2.aspx
https://blogs.technet.com/b/askds/archive/2007/10/05/top-10-common-causes-of-slow-replication-with-dfsr.aspx
ウォーレン「ウードのクォータを超えて」ウィリアムズ