2つのLinuxサーバー間で数百万のファイルを同期する

ローカルディスクからNFSを介してネットワーククライアントに約700万のファイル（主に画像）を含むディレクトリをエクスポートするサーバーがあります。

HAのために2つ目を追加する必要があり、2つ目間のデルタができるだけ少なくなるように、1つ目と同期させる必要があります。

調査では、lsyncdまたは他のinotifyベースのソリューションを使用することを提案していますが、inotifyウォッチを作成するファイルの数を考えると、永遠にかかります。rsyncについても同様です。

他の可能な解決策があるように思わDRDB、またはクラスタファイルシステムなどのCEPHやglusterfsが、私はそれらの経験がない、もう1つは、より適切であるかを知ると、その多くのファイルとよく対応し、まだまともなパフォーマンスを提供していません。

アクティビティはほとんど読み取られ、書き込みはほとんど発生しないことに注意してください。

drbdのように、データに依存しないレプリケーションを提案する傾向があります。rsyncを使用したり、inotifyウォッチを作成したりして見つけたように、ファイルの数が多いと、「ブロックストレージ」よりも高いレベルで実行されているものは、ツリーを歩くのに膨大な時間を費やすことになります。

それを裏付ける私の個人的なストーリーの短いバージョン：私はCephを使用していませんが、Glusterとの類似性に基づいて、これは彼らの主要な市場目標に含まれていないと確信しています。しかし、私は過去数年間、Glusterでこの種のソリューションを実装しようとしてきました。メジャーバージョンの更新はいくつかありますが、ほとんどの時間は稼働していますが、問題はありませんでした。パフォーマンスよりも冗長性を目標とする場合、Glusterは適切なソリューションではない可能性があります。特に、使用パターンに多数のstat（）呼び出しがある場合、Glusterはレプリケーションでうまく機能しません。これは、レプリケートされたボリュームへのstat呼び出しがすべてのレプリケートされたノードに送られるためです（実際には「ブリック」ですが、ホストごとに1つのブリックがあるだけです）。たとえば、双方向のレプリカがある場合、クライアントからの各stat（）は、両方のブリックからの応答を待って、現在のデータを使用していることを確認します。次に、冗長性のためにネイティブのglusterファイルシステムを使用している場合は、FUSEオーバーヘッドがあり、キャッシュが不足します（Glusterをバックエンドとして使用し、NFSをプロトコルとして使用し、冗長性のために自動マウンターを使用するのではなく、stat（）の理由が原因です） 。Glusterは、複数のサーバーにデータを分散できる大きなファイルでも非常にうまく機能します。データのストライピングと分散がうまく機能します。これがまさにそのためです。また、新しいRAID10タイプのレプリケーションは、古いストレートレプリケートボリュームよりもパフォーマンスが向上します。しかし、私があなたの使用モデルであると私が推測していることに基づいて、私はそれに対して助言します。次に、冗長性のためにネイティブのglusterファイルシステムを使用している場合は、FUSEオーバーヘッドがあり、キャッシュが不足します（Glusterをバックエンドとして使用し、NFSをプロトコルとして使用し、冗長性のために自動マウンターを使用するのではなく、stat（）の理由が原因です） 。Glusterは、複数のサーバーにデータを分散できる大きなファイルでも非常にうまく機能します。データのストライピングと分散がうまく機能します。これがまさにそのためです。また、新しいRAID10タイプのレプリケーションは、古いストレートレプリケートボリュームよりもパフォーマンスが向上します。しかし、私があなたの使用モデルであると私が推測していることに基づいて、私はそれに対して助言します。次に、冗長性のためにネイティブのglusterファイルシステムを使用している場合は、FUSEオーバーヘッドがあり、キャッシュが不足します（Glusterをバックエンドとして使用し、NFSをプロトコルとして使用し、冗長性のために自動マウンターを使用するのではなく、stat（）の理由が原因です） 。Glusterは、複数のサーバーにデータを分散できる大きなファイルでも非常にうまく機能します。データのストライピングと分散がうまく機能します。これがまさにそのためです。また、新しいRAID10タイプのレプリケーションは、古いストレートレプリケートボリュームよりもパフォーマンスが向上します。しかし、私があなたの使用モデルであると私が推測していることに基づいて、私はそれに対して助言します。これは、まだstat（）の理由で問題があります）。Glusterは、複数のサーバーにデータを分散できる大きなファイルでも非常にうまく機能します。データのストライピングと分散がうまく機能します。これがまさにそのためです。また、新しいRAID10タイプのレプリケーションは、古いストレートレプリケートボリュームよりもパフォーマンスが向上します。しかし、私があなたの使用モデルであると私が推測していることに基づいて、私はそれに対して助言します。これは、まだ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年間。