2つのLinuxサーバー間で数百万のファイルを同期する
[〜＃〜] nfs [〜＃〜]を介してローカルディスクからネットワーククライアントに約700万のファイル（主に画像）を含むディレクトリをエクスポートするサーバーがあります。
HAのために2つ目を追加し、最初の1つと同期を保ち、2つの間のデルタをできるだけ少なくする必要があります。
調査によると、これにはlsyncdまたは他のinotifyベースのソリューションを使用することが提案されていますが、作成するファイルの数を考えると、inotifyウォッチは永遠にかかります。 rsyncについても同様です。
他の可能な解決策はdrdb、またはクラスターファイルシステム（cephまたはglusterfsなど）のようですが、私にはありませんそれらの経験があり、どれがより適切であり、その多くのファイルにうまく対処し、それでもまともなパフォーマンスを提供するかがわかりません。
アクティビティはほとんど読み取りであり、書き込みはほとんど発生しないことに注意してください。
Drbdのように、データに依存しないレプリケーションを提案する傾向があります。多数のファイルにより、「ブロックストレージ」よりも高いレベルで実行されているものは、ツリーを歩くのに非常に長い時間を費やします。
それを裏付ける私の個人的な話の短いバージョン：私はCephを使用していませんが、Glusterとの類似性に基づいて、これが主要な市場ターゲットに含まれていないことは間違いありません。ただし、私は過去数年間、この種のソリューションをGlusterで実装しようとしています。メジャーバージョンの更新はいくつかありますが、ほとんどの時間は稼働していますが、問題はありませんでした。目標がパフォーマンスよりも冗長性である場合、Glusterは適切なソリューションではない可能性があります。特に、使用パターンに多くのstat（）呼び出しがある場合、Glusterはレプリケーションで実際にはうまく機能しません。これは、レプリケートされたボリュームへのstat呼び出しが、レプリケートされたすべてのノードに送信されるためです（実際には「ブリック」ですが、ホストごとに1つのブリックが必要になる可能性があります）。たとえば、双方向レプリカがある場合、クライアントからの各stat（）は、両方のブリックからの応答を待機して、現在のデータを使用していることを確認します。次に、冗長性のためにネイティブのglusterファイルシステムを使用している場合（NFSをプロトコルとしてバックエンドとしてGlusterを使用し、冗長性のためにオートマウンターを使用するのではなく）、Fuseのオーバーヘッドとキャッシュの欠如もありますが、それでもstat（）の理由で問題があります） 。ただし、Glusterは、複数のサーバーにデータを分散できる大きなファイルに非常に適しています。データストライピングと分散はうまく機能します。それがまさにその目的だからです。また、新しいRAID10タイプのレプリケーションは、以前のストレートレプリケートボリュームよりもパフォーマンスが向上します。しかし、私があなたの使用モデルであると私が推測していることに基づいて、私はそれに対して助言します。
おそらく、マシン間でマスター選挙を行う方法を見つけるか、分散ロックを実装する必要があることを覚えておいてください。共有ブロックデバイスソリューションは、マルチマスター対応のファイルシステム（GFSなど）を必要とするか、1つのノードのみがファイルシステムを読み書き可能でマウントすることを必要とします。一般に、ファイルシステムは、その下のブロックデバイスレベルでデータが変更されることを嫌います。つまり、クライアントはどちらがマスターであるかを識別し、そこに直接書き込み要求を送信できる必要があります。それは大きな迷惑になるかもしれません。 GFSとそのすべてのサポートインフラストラクチャがオプションである場合、マルチマスターモードのdrbd（「デュアルプライマリ」と呼ばれます）が適切に機能します。 https://www.drbd.org/en/doc/users-guide-83/s-dual-primary-mode 詳細については。
あなたが進む方向に関係なく、これはSAN会社にトラック一杯のお金を与えるだけでなく、リアルタイムで行うにはまだかなり大きな苦痛であることに気付く傾向があります。
Proxmox VEセットアップの助けを借りて、rsyncからcephに移行しました。
現在、ライブレプリケーションを使用して1つのクラスターで14TBを管理しています。ほぼ4年間。