ブランチキャッシュはDFS-Rの代替として検討する価値がありますか

現在、単一のサーバー2003ドメインコントローラーを備えた小さなスタブオフィスと、本社に保持されているファイルストアのDFS-Rコピーがあります。おそらく約100Gbのデータを複製します。両端で最大約20Gbがアクティブに使用されていると思います。サイト間には（比較的）遅いADSLリンクがあります。

レプリケーションは、一部のレプリケートされたファイルのセキュリティに変更を加える場合を除いて、ほとんど問題なく機能します。-これにより、変更の巨大なバックログが発生し、クリアに数日かかるようです。私は他のいくつかの問題についての記事、およびWindows 7＆Server 2008 R2が提供する必要がある新しいブランチキャッシュ機能についても読んでいます。私が理解しているように、長所と短所は次のとおりです。

ブランチキャッシュ

長所

• バージョンの競合はありません
• その後のアクセスのための高速アクセス

短所

• 初回アクセスのアクセスが遅い
• 遅い書き込みアクセス

DFSR

長所

• 常にデータへの迅速な読み取り/書き込みアクセス
• 限られた量の追加のデータセキュリティ

短所

• バックログは非常に簡単に発生する可能性があります
• バージョンの競合はバックログの問題になる可能性があります
• レプリケーションには時間がかかりすぎる可能性があります-オフィス間のファイルへのリアルタイムアクセスには適していません。

誰かがブランチキャッシュをテストしましたか？実世界でブランチキャッシュがどの程度適切に機能するか知っていますか。私たちのセットアップではDFSRよりも良いでしょうか？データのチャンクをプリフェッチできれば非常に便利だと思います（robocopyとdeleteを使用してこれを手動で実行できると思います）。私の唯一の懸念は、データの書き込みが遅いという事実です。

また、本社でのSharePointの実装も検討しています。これはブランチキャッシュに有利に振る舞うかもしれません。

明らかに、ブランチキャッシュを使用することにした場合は、テストに合格する必要がありますが、何らかの方法で私を説得する可能性のある他の長所や短所がないかどうか知りたいだけですか？

おそらく、DFS-RがレプリケートされるときにAD展開ソフトウェアを維持し、ユーザー固有のデータ（ホームディレクトリやプロファイルなど）を維持することになります。

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つのテクノロジにデータを分散させることにより、さまざまなカテゴリのデータに対してそれぞれの最適なプロパティを取得できます。

これが役に立てば幸いです！-タイラー