優先ローカリティを持つ地理的に分散したファイルシステム
WANを介していくつかのサイトに標準ファイルサーバーを配布する必要があるアプリケーションを構築しています。基本的に、各サイトはさまざまなサイズのその他のファイル（100 MBの範囲内で最も小さいもの）を大量に書き込む必要があり、衝突が問題にならないようにアプリケーションが書き込まれます。次の条件を満たすシステムをセットアップしたいと思います。 各サイトは、共有の「名前空間」にファイルを保存できます。つまり、すべてのファイルが同じファイルシステムに表示されます。 各サイトは、必要な場合を除き、WAN経由でデータを送信しません。つまり、WANの両側にローカルストレージがあり、同じ論理ファイルシステムに「マージ」されます。 Linux＆Free（$$$）はプラスです 基本的に、中央NFS共有のようなものはほとんどの要件を満たしますが、ローカルに書き込まれたデータをローカルに保持することはできません。WANのリモート側からのすべてのデータは、常にローカルにコピーされます。 Lustreを調べて、いくつかの成功したテストを実行しましたが、分散ストレージ全体にファイルをかなり均一に分散しているようです。ドキュメントを掘り下げましたが、リモートストレージよりもローカルストレージを自動的に「優先」するものは見つかりませんでした。レイテンシーが最小のストレージでも問題はありません。これはほとんどの場合機能し、このアプリケーションの要件を満たします。 以下に尋ねられるいくつかの質問に対するいくつかの回答： サーバーノード：開始する2または3。各サーバーには、多数の同時読み取り/書き込みクライアントが接続されます。 WANトポロジはフルメッシュで信頼性があります。（大企業、コストは赤字ほど制限されていません） クライアントフェールオーバー：実際には、クライアントのフェールオーバーについて考えていませんでした（主に、現在のアプリケーションでは1つのサイトでこれを行っていないためです）。実務上の答えは、地理的に分散した各サイトのサーバーは、それらがサービスを提供するクライアントの単一障害点であると予想されるということだと思いました。ただし、ここで何か特定のことを考えているのであれば、それは議論と非常に密接な関係があると思います。 Roll-my-own：rsync / unisonについて考えてきましたが、この作業の「動的」部分をシームレスに行うには、かなり高度なロジックが必要になります。つまり、ファイルはローカルにあるように見えますが、オンデマンドでのみ取得されます。 MS-DFS：それは確かに私が調べなければならないもののようです。私の主な問題は、接続するクライアントの多くがNFSクライアントであるため、WindowsでのNFSサーバーの構成/信頼性/パフォーマンスが不確かになる可能性があることです。