優先ローカリティを持つ地理的に分散したファイルシステム

WANを介していくつかのサイトに標準ファイルサーバーを配布する必要があるアプリケーションを構築しています。基本的に、各サイトはさまざまなサイズのその他のファイル（100 MBの範囲内で最も小さいもの）を大量に書き込む必要があり、衝突が問題にならないようにアプリケーションが書き込まれます。次の条件を満たすシステムをセットアップしたいと思います。

1. 各サイトは、共有の「名前空間」にファイルを保存できます。つまり、すべてのファイルが同じファイルシステムに表示されます。
2. 各サイトは、必要な場合を除き、WAN経由でデータを送信しません。つまり、WANの両側にローカルストレージがあり、同じ論理ファイルシステムに「マージ」されます。
3. Linux＆Free（$$$）はプラスです

基本的に、中央NFS共有のようなものはほとんどの要件を満たしますが、ローカルに書き込まれたデータをローカルに保持することはできません。WANのリモート側からのすべてのデータは、常にローカルにコピーされます。

Lustreを調べて、いくつかの成功したテストを実行しましたが、分散ストレージ全体にファイルをかなり均一に分散しているようです。ドキュメントを掘り下げましたが、リモートストレージよりもローカルストレージを自動的に「優先」するものは見つかりませんでした。レイテンシーが最小のストレージでも問題はありません。これはほとんどの場合機能し、このアプリケーションの要件を満たします。

以下に尋ねられるいくつかの質問に対するいくつかの回答：

• サーバーノード：開始する2または3。各サーバーには、多数の同時読み取り/書き込みクライアントが接続されます。
• WANトポロジはフルメッシュで信頼性があります。（大企業、コストは赤字ほど制限されていません）
• クライアントフェールオーバー：実際には、クライアントのフェールオーバーについて考えていませんでした（主に、現在のアプリケーションでは1つのサイトでこれを行っていないためです）。実務上の答えは、地理的に分散した各サイトのサーバーは、それらがサービスを提供するクライアントの単一障害点であると予想されるということだと思いました。ただし、ここで何か特定のことを考えているのであれば、それは議論と非常に密接な関係があると思います。
• Roll-my-own：rsync / unisonについて考えてきましたが、この作業の「動的」部分をシームレスに行うには、かなり高度なロジックが必要になります。つまり、ファイルはローカルにあるように見えますが、オンデマンドでのみ取得されます。
• MS-DFS：それは確かに私が調べなければならないもののようです。私の主な問題は、接続するクライアントの多くがNFSクライアントであるため、WindowsでのNFSサーバーの構成/信頼性/パフォーマンスが不確かになる可能性があることです。

Linuxの要件に関する恥。これはまさにWindows DFSが行うことです。2003 R2以降、ブロックレベルでも実行されます。

いくつかの質問：

• このことに参加することを考えている「サーバー」ノードはいくつありますか？

• ハブアンドスポーク、フルメッシュのようなWAN接続トポロジとは何ですか？信頼性はどのくらいですか？

• ローカルサーバーに障害が発生した場合、クライアントは地理的に非ローカルのサーバーにフェールオーバーすることを期待していますか？

Windows DFS-Rは、かなりのライセンス費用がかかる可能性がありますが、確かに探しているものです。

衝突は問題ではなく、分散ロックマネージャーは必要ないと言うので、rsyncやUnisonなどのユーザーランドツールを使用してこれを実行し、結果のファイルのコーパスをNFSでローカルクライアントにエクスポートできます。replicationいし、レプリケーショントポロジの生成と実際のユーザーランドツールの実行を処理するために、何らかのシステムを組み合わせて処理する必要がありますが、ライセンスコストがかかるため、確かに安価です。

AFSを検討しましたか？

Andrew File System（AFS）は、信頼できるサーバーのセットを使用して、すべてのクライアントワークステーションに同種のロケーション透過ファイル名スペースを提供する、分散ネットワークファイルシステムです。

私が理解しているように、最近の開発の大部分はOpenAFSプロジェクトの背後にあります。

「優先地域」機能が利用可能かどうかを知るために、プロジェクトに十分に精通しているふりをすることはできませんが、それ以外の場合は適切に聞こえます。

ルストレのOSTプールを見たことがありますか？

自動ではありませんが、OSTプールを使用すると、ディレクトリ/ファイルを特定のOST / OSSに割り当てることができます。基本的には、OST間のデフォルトのラウンドロビン/ストライピングではなく、ポリシーベースのストレージ割り当てです。

そのため、サイトごとにディレクトリを設定し、そのディレクトリをそのサイトのローカルOSTに割り当てると、すべてのI / OがローカルOSTに転送されます。それはまだグローバルな名前空間です。

WAN接続（ローカルキャッシングサーバーなど）を介したLustreの改善には、多くの作業がありますが、それでもすべての開発が大いに行われています。

NFSかもしれませんが、アプリケーションサーバーでCachefsを使用すると、目標の一部を達成できます。私が理解したように、書き込まれたものはすべて中央サーバーに送られますが、少なくとも読み取りはローカルにキャッシュされる可能性があります。これにより、使用パターンによっては読み取りの遅延が大幅に短縮される可能性があります。

また、mabye UnionFSは検討する価値があります。これにより、各場所がNFSエクスポートになり、各場所でUnionFSを使用して、その場所から他のすべてのNFSマウントを1つのファイルシステムとして表示できるようになります。私はこれを経験していません。

DRBDを調べてディスクを複製できます。http://www.drbd.org/。これは、Linux High Availabilityソリューションであり、カーネルに組み込まれました。

ただし、これにはいくつかの制限があります。

1. 2つのノードのみをセットアップできます
2. WANは信頼性が低く、DRBDを堅牢に保つことができない場合があります。

シンプルに保ちたい場合は、rsyncを見て、多くの問題を解決し、スクリプト化できます。

chironfsを確認してください。

たぶん、ファイルシステムベースであなたが望むことをすることができます。

Btsyncは、私が経験したもう1つのソリューションです。BitTorrentプロトコルを使用してファイルを転送するため、サーバーが多いほど、新しいファイルを同期するのが速くなります。

rsyncベースのソリューションとは異なり、ファイル/フォルダの名前を変更したときにそれを検出し、削除/コピーの代わりにすべてのノードでそれらの名前を変更します。

その後、btsyncクライアントはローカルネットワーク上のフォルダーを共有できます。

（MS DFSと比較して）私が見つけた唯一の欠点は、ローカルファイルのコピーが検出されないことです。代わりに、すべてのピアにアップロードされた新しいファイルとして解釈します。

これまでのところ、btsyncは最高の同期ソリューションであるようで、Windows、Linux、Android、およびARMデバイス（NASなど）にインストールできます。