約700万のファイル（主にイメージ）を含むディレクトリをローカルディスクからネットワーククライアントにエクスポートするサーバーがあります。ネットワークファイルシステム。
HAの場合は、2番目のエントリを追加し、2つの間のデルタをできるだけ小さく保ちながら、最初のエントリと同期を維持する必要があります。
研究では、以下を使用することをお勧めします。同期または他の人inotifyこれに基づいて生成されたファイル数を考慮したソリューションinotify時計は時代を超えなければなりません。同じこと同期。
他の考えられる解決策は次のとおりです。データデータベースまたはクラスタファイルシステム例えばセファロスポリンまたはグロスターファイルシステムしかし、私はこれについての経験がなく、どちらがより適切で、多くのファイルをうまく処理でき、まだまともなパフォーマンスを提供しているかわかりません。
アクティビティはほとんど読み込み、書き込みはほとんど発生しません。
ベストアンサー1
私はdrbdのようなデータに拘束されない複製を提案したいと思います。ファイル数が多いと、Block Storageよりも高いレベルで実行されているすべてのアイテムがツリーを巡回するのに過度の時間を費やします。これは、rsync を使用したり、inotify ウォッチを生成する過程でわかるように発生します。
私の個人的なストーリーの短いバージョンはこれを裏付けています。私はCephを使用していませんが、Glusterに似ているので、Cephは主な市場目標ではないと確信しています。しかし、私は過去数年間、Glusterを使用してこのソリューションを実装しようとしてきました。いくつかのメジャーバージョンのアップデートがありましたが、ほとんどの時間実行されましたが、無限の問題に直面しています。パフォーマンスよりも冗長性を高めることが目標であれば、Glusterは良い解決策ではないかもしれません。特に、使用パターンにstat()呼び出しが多い場合、Glusterはレプリケーションのパフォーマンスを正しく発揮できません。これは、レプリケートされたボリュームへの統計呼び出しがすべてのレプリケートされたノード（実際には「ブロック」ですが、ホストごとに1つのブロックしかありません）に送信されるためです。たとえば、双方向レプリカがある場合、クライアントの各stat（）は現在のデータを使用していることを確認するために2つの応答チャンクを待ちます。その後、冗長性のためにデフォルトのGlusterファイルシステムを使用する場合（Glusterをバックエンドとして使用し、NFSを冗長性のためのプロトコルと自動マウントとして使用するのではなく、stat（）の理由によりまだ悪い）、FUSEオーバーヘッドとキャッシュ不足も発生しますします。 。 Glusterは大量のファイル操作に適しており、複数のサーバーにデータを配布できます。これは、データストライピングとデプロイが正しく機能するためです。最新のRAID10タイプのレプリケーションは、以前のダイレクトコピーボリュームよりも優れています。しかし、あなたの使用モデルについて私が推測したところによると、それに反対することをお勧めします。
マシン間でマスター選択を実行する方法を見つけるか、分散ロックを実装する必要があるかもしれません。共有ブロックデバイスソリューションには、マルチマスターデバイス（GFSなど）をサポートするファイルシステムが必要な場合、または1つのノードのみを読み書きモードでファイルシステムをマウントする必要があります。ファイルシステムは通常、その下のブロックデバイスレベルでデータが変更されることを好まない。これは、クライアントがどのサーバーがマスターサーバーであるかを識別し、そこから直接書き込み要求を実行できることを意味します。これは大きな面倒になる可能性があります。マルチマスターモード（「デュアルマスター」と呼ばれる）のDrbdは、GFSおよびすべてのサポートインフラストラクチャオプションがある場合はうまく機能します。 https://www.drbd.org/en/doc/users-guide-83/s-dual-primary-modeこれについて詳しく学んでください。
どの方向を選択しても、SAN会社に多くのお金を払わずにリアルタイムで実装することは依然としてかなりの痛みであることがわかります。