Windows DFSR-複製されたディレクトリのアクセス許可を変更し、1週間以上にわたって350,000のバックログを保持
質問：この350,000ファイルのバックログをより速く完了する方法はありますか？ほとんどすべてのファイルで、唯一の変更は影響を受ける各ファイルのACLの変更でした。一部のファイルは内容が変更されていますが、この状況では一般的ではありません。
これは修正される可能性があります。このテキストを編集して、一定期間および検証後に成功/失敗を確認します。この質問文の終わりに向かって、それを修正した可能性のある最近行われた変更について詳しく説明しました。
約450,000ファイルのDFSRレプリケーショングループがあり、1.5 TBのスペースを使用しています。この状況では、約500マイル離れた2つのWindows Server 2008 R2サーバーがあります。他のサーバーがありますが、このレプリケーショングループには関与していません。サーバーアルファはメインサーバーであり、ほとんどのスタッフが使用しています。サーバーベータはリモートオフィスのサーバーであり、ビジー状態ではありません。
これは このレプリケーショングループのバックログのグラフ （GoogleドライブでホストされているPNG）で、同期の進行が遅いことを示しています。
そのレプリケーショングループのルートディレクトリにあるアクセス許可エントリを削除する必要がありました。もちろん、ほとんどのサブフォルダーに継承されています。この変更はサーバーALPHAで行いました。その直後、DFSRには350,000のファイルバックログがありました。 1週間以上経ち、現在は267,000に達しています。 （最初に）変更された唯一のことは、単一の許可の変更でした。
これは何が起こったかです（これは解決策ではなく、この問題の原因となったものの別の説明です）： http://blogs.technet.com/b/askds/archive/2012/04/14/saturday -mail-sack-because-it-turns-out-friday-night-was-alright-for-fighting.aspx＃dfsr
サーバーBETAで発生した変更は、その方向にバックログがないため、サーバーALPHAに非常に迅速に複製されます。ベータ版で変更されたファイルは、問題なくアルファ版に変換されます。
それは、一方の端の50Mbps接続を介して、もう一方の端の100Mbpsのファイバーにフルスピードで24時間年中無休で複製します。ステージング領域は、各サーバーで100GBです。イベントログには何も興味深いものはありません。この特定のレプリケーションにも、このALPHA/BETAサーバーペアにもない関連のないレプリケーショングループに表示される、関連のない高水準点イベントがあります。特に、最高水準点や接続エラーのイベントログエントリはありません。
ALPHAのレプリケーショングループのビュー：
帯域幅の節約：99.83％の削減（18.1 GBではなく30.85 MBの複製）
ALPHAとBETAでDFSRサービスを最後に再起動してから30.85MB/18.1GBが発生したと思います。もしそうなら、これは非常に長い時間がかかっていても（実際にかかるはずの時間よりも長い）、実際にはファイルの内容がネットワーク経由で転送されていないことを示しています。
複製されたフォルダー：1.46TB（実サイズ）、439,387（ファイル）、52,886（フォルダー）
競合して削除されたフォルダー：100.00GB（構成済みサイズ）、34.01GB（実際のサイズ）、19,620（ファイル）、2,393（フォルダー）
ステージングフォルダー：200.00GB（構成済みサイズ）、92.54GB（実際のサイズ）
ログ（5月14日午後7時）に1つの最高水準点エラーが発生したため、ステージングクォータを100GBから200GBに増やしました。マイクロソフトが承認したルートは20％増加することを知っていますが、これについては試していません。ステージングディスクアレイには、十分な空き容量があります。
すべてのサーバーでウイルス対策を無効にすることは役に立たなかったが、少しは役に立ったと思った。今のところ、ウイルス対策を再度有効にしていますが、方程式から変数を削除するために、レプリケーショングループのパスをスキャンから除外するように設定しています。
これをより速くする方法はありますか？私はサーバーBETAでもこの変更を行うだけですが、ALPHAで変更されたが、BETAにレプリケートされていないファイルがあり、BETAで継承されたアクセス許可の変更を行うと、プッシュ[〜＃〜 ] old [〜＃〜]ベータからアルファへのファイル（DFSRは衝突で勝ったファイルを比較するときにファイルのタイムスタンプを無視するように見えるため）。そして、それが起こるのはかなり悪いでしょう。
バックログはゆっくりと減少しています。とてもゆっくりと。しかし、それは進んでいます。しかし、このレートでは、完了するまでに数週間かかります。データセットのコピーを3TBドライブに押し込んでリモートオフィスに発送することを考えています。もっと良い方法はありますか？
5月16日午前4時米国PT：問題が修正された可能性があります（とにかく正直に修正されていると仮定します）：
DCに複数の変更を加えましたが、それはずっと前に行われるべきでした。問題は、このネットワークがおそらく他の誰かから継承された他の誰かから継承されたということです。問題が修正された変更を約束することはできません。ここにそれらは特定の順序ではありません：
- すべてのDCが "ドメインコントローラー" OUに含まれていませんでした。 DCが他の場所にあるWindowsドメインを見たことがありません。それらを元の場所に戻しました。以前は、各オフィスのある都市の名前で分離されたOUにありました。（それらを移動したので、対処する必要がある配管工事があるようですが、すべてのようです現在は大丈夫...）
- AVGアンチウイルスは、すべてのDCおよびDFSR参加サーバーで実行されています。レプリケートフォルダーとステージングフォルダーをアクティブ/オンアクセススキャンから除外しました。これで問題が解決したとは思わないので、後でこの問題をテストして、その変更を元に戻すとDFSRのレプリケーション速度が低下するかどうかを確認します。それは別の日の挑戦です。
- dcdiag.exeは、RODCに関するDNSの問題について不満を述べました。ドメインにRODCがまったくない場合でも、この問題を修正しました。私はこれが何かを修正したとは思いません。
- _ldap._tcp.domain.GUID._msdcs.DOMAIN.NET SRVレコードの1つがDCSの1つ（DFSRサーバーの1つではない）で欠落していたので、それを修正しました。これも役に立たなかったと思います。
- サーバーを再起動したときの1つとして、DFSRデータベースのシャットダウンに問題があることが報告され（イベント2212）、データベースの再構築に数時間かかりました。終了すると、イベント2214が報告され、終了したことがわかります。その後、レプリケーションは依然として非常にゆっくりと実行されていましたが、スタックされていたものは何でもはがすのに役立ちました。
- DCの1つは、インターフェイス構成でセカンダリDNSサーバーとして127.0.0.1を持っていませんでした。追加しました。これはDFSRサーバーの1つではなかったので、おそらくそれとは何の関係もありませんでした。
- 私は TechNetブログ：DFSRでのレプリケーションパフォーマンスのチューニング DFSRサーバーの推奨レジストリ設定に従いました。 AsyncIoMaxBufferSizeBytesが4194304、に設定されていることを除いて、「テスト済みの高性能値」の値をすべて使用しました。高い値。これは問題を解決できたかもしれません...または多分そうではありません。あまりにも多くの変数を変更したときにそれを区別することは困難です。
- dcdiag.exeは、ベータ版のRPCサービスとの通信に関する問題について不平を言いましたが、すでに上記の変更を行った後でのみです。これが最も起こりそうな問題であるように見えましたが、私がそれを修正するためにしたことは何もありませんでした。 VPNは適切に実行されており、ファイアウォールはそれをブロックしていませんでした。上記の項目のいずれかがRPCの問題の原因であり、それを修正した可能性があります。または、単純な偶然の一致であった可能性があります。現在ではなくそのエラーが発生しており、現在レプリケーションはスムーズに実行されています。
この話の教訓は、一度に1つずつ変更しないと、何が原因でそれが修正されたのかを実際に理解することができないということです。しかし、私は必死で、それを修正するための時間を使い果たしていたので、問題に対して大量の弾丸を発射しました。修正を特定した場合は、ここで報告します。ただし、絞り込みに頼らないでください。
EDIT 5/21/2012：昨日、リモートサーバーにスペアサーバー（GAMMA）を使って約7時間運転することでこれを解決しました。 GAMMAがプライマリローカルサーバーとして機能し、通常のサーバー（ベータ）がレプリケーションに追いつきます。私がそれを配置してから、サーバーは複製速度を約2倍にしています。これはVPN関連の問題である可能性があることを教えてくれますが、ALPHAからGAMMAにすべての新しい更新がレプリケートされているように思われるため、これは非常に迅速で順調です。
EDIT 5/22/2012：現在12000で、数時間で終了します。スロースタートからファーストフィニッシュまでの進行状況のナイスグラフを投稿します。問題は、実際に「修正」されたのはローカルサーバー接続だけであるということです。 VPNが問題の一部である可能性があると、私は現在考えています。そうだとすれば、この質問はまだ完全には答えられていないと思います。 VPNを介してどのように複製されているかを確認し、障害が発生していないことを確認するために、もう少し時間があったら、デバッグして進行状況を報告します。
何か変更があった場合は、ここで更新します。
特に編集を確認した後、非常に奇妙な問題。
ここにあるDFSRデバッグログを調べます。％systemroot％\ debugデフォルトでは、GZアーカイブされた以前の9つのログファイルと、現在書き込まれているログファイルが1つあります。
それをテキストファイルで開き、「警告」または「エラー」のテキストを検索します。デバッグログの詳細については、このブログシリーズをご覧ください。 http://blogs.technet.com/b/askds/archive/2009/03/23/understanding-dfsr-debug-logging- part-1-logging-levels-log-format-guid-s.aspx
その他の質問/提案：
リソースモニターを見ると、場所がずれていませんか？ベースライン外の過剰なハードドライブまたはCPUアクティビティ？
できればAlphaサーバーとBetaサーバーの両方を再起動します。それがあなたの問題を解決するならば、あなたは本当の問題が何であったか決してわからないかもしれませんが、これがすぐに解決されることが重要であるなら、それは試す価値があります。
質問の更新に基づいて編集
850 MBのファイルに関連する2つのエントリと、DFSRデバッグログ内のエラーについて言及しました。
ステージング場所を各サーバーの別のフォルダーまたはドライブに変更してみてください。現在ステージングされているファイルが破損しているか、なんらかの理由でレプリケーションがブロックされている場合。
レプリケーションスケジュールを微調整して、DFS-Rが営業時間外（または適切な場合は営業時間）にフルスピードでレプリケーションできるようにすることができます。
バックログされたサーバーのステージングサイズを増やすこともできます。この状況では、パフォーマンスが向上するはずです。
上限があるかどうかについては言及していませんが、WANを介したレプリケーションがあるためだと思います。
私の経験では、これはJust How It Worksです。
4つのDFSレプリケーショングループのかなり小さいコレクション（550 GBのデータ、58kファイル、合計3.4kフォルダー）のセキュリティを更新した後、私はこれに遭遇しました。実際にネットワークで送信されるデータは少ないため、セキュリティの変更だけでファイル全体を移動しているようには見えませんが、ディスクアクティビティは階層全体が再コピーされているように感じられます-60〜100 MB /秒の持続的なディスク転送速度、およびディスクキューSSDの階層型ストレージスペースで最大30、最大500。
私の考えでは、DFSのステージングおよびデステージングプロセスには多くのチャーンがあり、その結果、極端なディスクI/Oが発生します。 2つのギガビットLANに接続されたボックス間の最初の複製プロセスには、ボックス間でファイルを単にコピーした同じデータよりも数倍の時間がかかります。これは、複製されるバイトごとに複数バイトのディスクの読み取りと書き込みが必要であることを示しているようです。
セキュリティの更新には、2012年のクレームベースのセキュリティ（AFAICTはあまり使用されていません）の使用を禁止する特別なレプリケーションロジックがないため、データの変更に対して同じステージ/デステージチャーンが発生します。