私は、ローカルディスクからネットワーククライアントに約700万個のファイル（主に画像）を含むディレクトリをエクスポートするサーバーを持っています。NFS。
HA のために 2 つ目を追加し、2 つの間の差分をできるだけ少なくして最初のものと同期させる必要があります。
研究によると、lsyncdまたはその他通知ベースのソリューションがありますが、通知時計は永遠にかかる。rsync。
他の解決策としては、drdb、またはクラスターファイルシステムのようなセフまたはグラスターしかし、私はそれらの使用経験がないので、どれがより適切で、これほど多くのファイルをうまく処理し、適切なパフォーマンスを提供できるのかはわかりません。
アクティビティは主に読み取りであり、書き込みはほとんど行われないことに注意してください。
答え1
私は、drbd のような、データに依存しないレプリケーションを提案したいと思っています。ファイルの数が多いと、「ブロック ストレージ」よりも高いレベルで実行されるものは、rsync を使用したり、inotify ウォッチを作成したりしたときにわかるように、ツリーをたどるのに膨大な時間を費やすことになります。
それを裏付ける私の個人的な話の短いバージョン: 私は Ceph を使ったことがありませんが、Gluster との類似性から、これが彼らの主要な市場ターゲットではないことはほぼ確実です。ただし、私は過去数年間、この種のソリューションを Gluster で実装しようとしてきました。その間、いくつかのメジャー バージョン アップデートを経て、ほとんどの期間稼働していましたが、問題は尽きることがありません。パフォーマンスよりも冗長性が目標である場合、Gluster は適切なソリューションではない可能性があります。特に、使用パターンに stat() 呼び出しが多い場合、Gluster はレプリケーションではあまりうまく機能しません。これは、レプリケートされたボリュームへの stat 呼び出しが、レプリケートされたすべてのノード (実際には「ブリック」ですが、おそらくホストごとに 1 つのブリックだけになるでしょう) に送信されるためです。たとえば、双方向レプリカがある場合、クライアントからの各 stat() は、両方のブリックからの応答を待機して、最新のデータを使用していることを確認します。また、冗長性のためにネイティブの Gluster ファイルシステムを使用している場合は、FUSE のオーバーヘッドとキャッシュの欠如も発生します (冗長性のためにプロトコルとして NFS と自動マウント機能を備えたバックエンドとして Gluster を使用するのではなく、それでも stat() の理由で不十分です)。ただし、Gluster は、複数のサーバーにデータを分散できる大きなファイルでは非常にうまく機能します。データのストライピングと分散はうまく機能します。それが本来の目的です。また、新しい RAID10 タイプのレプリケーションは、古いストレート レプリケート ボリュームよりもパフォーマンスが優れています。ただし、使用モデルを推測すると、これはお勧めしません。
マシン間でマスターを選出する方法を見つけるか、分散ロックを実装する必要があることを念頭に置いてください。共有ブロック デバイス ソリューションには、マルチマスター対応のファイル システム (GFS など) が必要です。または、1 つのノードのみがファイル システムを読み取り/書き込み可能にマウントする必要があります。一般的に、ファイル システムは、その下にあるブロック デバイス レベルでデータが変更されることを嫌います。つまり、クライアントはマスターがどれであるかを識別し、そこに書き込み要求を送信できる必要があります。これは大きな問題になる可能性があります。GFS とそのサポート インフラストラクチャがすべてオプションである場合、マルチマスター モード (「デュアル プライマリ」と呼ばれます) の drbd はうまく機能します。 https://www.drbd.org/en/doc/users-guide-83/s-デュアルプライマリモード詳細については、こちらをご覧ください。
どちらの方向に進むにしても、SAN 企業に多額の資金を提供しなければ、リアルタイムでこれを実行するのはかなり面倒な作業であることに気づくでしょう。
答え2
Proxmox VE セットアップの助けを借りて、rsync から ceph に移行しました。
現在、ライブ レプリケーションを使用して 1 つのクラスターで 14 TB を管理しています。ほぼ 4 年間です。