Windows DFSの制限
これまで、私は パフォーマンスとスケーラビリティに関する記事 を見て、主に新しいリンクを追加するのにかかる時間に焦点を当ててきました。しかし、ファイル数、フォルダ数、合計サイズなどに関する制限についての情報はありますか？
現在、何百万ものJPG（約45 TB価値））を備えた単一のファイルサーバーがあり、これらはいくつかの標準的なファイル共有を通じてネットワーク上で共有されています。DFS名前空間を作成し、これらすべてを複製する予定ですを高可用性の目的で別のサーバーに送信します。通常のファイル共有では発生しない、DFSの追加の問題が発生しますか？これらの数百万のファイルを複製してネットワークで利用できるようにするための、より推奨される方法はありますか？
編集2：
通常、すべてのファイルは一度ディスクに書き込まれ、その後変更されることはありません。変更されるのは、それらが最終的に削除されるときだけです。おそらく数年後に削除されます。したがって、すべてがかなり静的です。
編集：
私は自分で実験してブログ投稿を書いていますが、2台目のサーバーのハードウェアはまだありません。購入する前に情報を収集したい45 TBハードドライブ容量...
現在、2008 R2 DFSRを57 TB=の複製ファイル（160万）で使用しており、全体のボリュームサイズは90 TBを超えていますが、問題はありません。
そのため、MSでテストされた制限はこの点で少しナイーブであり、IMHOはさらにディスク容量を購入して、さらにテストを行う必要があります。最初の同期でタイムクリティカルでない場合は、DFSRもそれを行うことができます。特に気に入らないのは、同じファイルを複数のホストで変更することです。これは、保持するアービトレーションを行う必要があるためです。
45TBのデータを使用すると、サーバー2008でのDFS-Rのテスト済みの制限を上回ります。
サーバー上のすべての複製ファイルのサイズ：10テラバイト。
ボリューム上の複製ファイルの数：800万。
最大ファイルサイズ：64ギガバイト。
編集：
ファイルが変更されない可能性が高い場合は、DFSの名前空間部分を利用して、共有用の仮想化パスを作成できます。次に、スケジュールされたタスクでrobocopyを実行してサーバーを同期できます。 DFS-Rを使用する場合でも、最初の同期にはrobocopyなどを使用する必要があります。
「これらの数百万のファイルを複製してネットワーク上で利用できるようにするための、より推奨される方法はありますか？」うん-SANまたはNASデバイスを集中管理するためのデバイス、またはIsilon、Glusterなどの分散ストレージ）。DFSは素晴らしいですが、すべてのサーバーがすべての完全なコピーを持っているので、より大きなスケーリングが必要な場合、これは良いアーキテクチャではありません。
また、いずれにしても、アーキテクチャのスケーリングが難しい場合があります。ファイルとして保存しないいくつかの大きな画像システムを見てきました-それらは画像のメタデータとバイトオフセットを保存するデータベースを持ち、それらを大きなバイナリファイルにロールアップして、簡単な方法で配布されますディスクとファイルシステム。画像が必要です。これにより、blobファイルが検索され、開始バイトと終了バイトで画像が取り出されます。