ブランチキャッシュはDFS-Rの代替として検討する価値がありますか
現在、単一のサーバー2003ドメインコントローラーを備えた小さなスタブオフィスと、メインオフィスにあるファイルストアのDFS-Rコピーがあります。おそらく約100Gbのデータを複製します。両端で最大約20Gbがアクティブに使用されていると思います。サイト間のADSLリンクは（比較的）遅いです。
一部のレプリケートされたファイルのセキュリティを変更する場合を除いて、レプリケーションはほとんどの場合非常にうまく機能します。 -これにより、変更の膨大なバックログが発生し、クリアするのに数日かかるようです。私は他のいくつかを読んでいます 投稿 問題について、そしてWindows7とServer2008 R2が提供しなければならない新しいブランチキャッシュ機能についても読んでいます、そして私が理解しているように、賛否両論は次のとおりです：
ブランチキャッシュ
長所
- バージョンの競合はありません
- 後続のアクセスのための高速アクセス
短所
- 初めてのアクセスのための遅いアクセス
- 書き込みアクセスが遅い
[〜＃〜] dfsr [〜＃〜]
長所
- いつでもデータへの迅速な読み取り/書き込みアクセス
- 限られた量の追加データセキュリティ
短所
- バックログは非常に簡単に発生する可能性があります
- バージョンの競合はバックログの問題になる可能性があります
- レプリケーションには時間がかかりすぎる可能性があります。オフィス間のファイルへのリアルタイムアクセスには適していません。
誰かがブランチキャッシュをテストしましたか？ブランチキャッシュが現実の世界でどれだけうまく機能するか知っているかどうか疑問に思っていますか？私たちのセットアップでは、DFSRよりも優れているでしょうか？データのチャンクをプリフェッチできれば非常に便利だと思います（robocopyとdeleteを使用して手動でこれを実行できると思います！）。私が持っている唯一の懸念は、データの書き込みが遅くなるという事実です。
また、本社でSharePointを実装することも検討しています。これはブランチキャッシュを支持するだけかもしれないと思います。
明らかに、ブランチキャッシュを使用することにした場合は、テストに合格する必要がありますが、何らかの方法で私を説得する可能性のある他の長所または短所がないかどうかを知りたいだけですか？
ADで展開されたソフトウェアをDFS-Rの複製として保持し、ユーザー固有のデータ（ホームディレクトリやプロファイルなど）も保持する可能性があります。そうしないと、書き込みによってクライアントで遅延が発生しますか？
BranchCacheが適しているように思われますが、Server 2008およびServer 2008 R2で行われたDFS-Rのパフォーマンスの向上の恩恵を受けることもできます。
BranchCacheについて書かれたいくつかのケーススタディがあり、実際のBranchCacheのパフォーマンスについて詳しく説明している可能性があります。 「BranchCacheケーススタディ」を検索してください。
BranchCacheは、コンテンツ（ファイル、Webページなど）の最新のアクセス制御設定を常に尊重するように注意しています。クライアントPCがブランチオフィス（ホストされたキャッシュサーバーまたはピアのいずれか）のキャッシュからデータをダウンロードする前に、メインオフィスサーバーからコンテンツ識別子を取得する必要があります。クライアントにデータにアクセスする権限がない場合、メインオフィスサーバーは識別子を送信しません。これがbranchcache.comでどのように機能するかを説明するドキュメントがたくさんあります。
必要に応じて、ブランチ内のクライアントの1つ（または実際にホストされているキャッシュサーバー）に事前にデータにアクセスさせることで、BranchCacheキャッシュをプリロードできます。ワーカーが入る前にキャッシュをプリロードしたい場合、これはスクリプト可能な場合があります。
サーバーをブランチに保持し、R2にアップグレードする場合、BranchCacheとDFS-Rの組み合わせをデプロイできない理由はありません。 1つのボックスは、DFS-Rレプリケーションポイントとしても、ホストされたキャッシュサーバーとしても同時に機能できます。このようにして、SharepointとSMB最適化を取得できます。また、2つのテクノロジにデータを分散することにより、さまざまなカテゴリのデータに対してそれぞれの最適なプロパティを取得できます。
これがお役に立てば幸いです。 -タイラー