100万個のファイルをリモートサーバーと効率的に同期するオプションはありますか？

私が働いている会社には、「プレイリスト」と呼ばれるものがあります。これは、それぞれ100〜300バイトの小さなファイルです。それらの約百万があります。それらの約100,000は1時間ごとに変更されます。これらのプレイリストは、異なる大陸にある他の10台のリモートサーバーに1時間ごとにアップロードする必要があり、理想的には2分以内にすばやく実行する必要があります。マスターで削除されたファイルは、すべてのレプリカでも削除されることが非常に重要です。現在、インフラストラクチャにLinuxを使用しています。

内容を比較せずにファイル全体をコピーするために、-Wオプションでrsyncを試すことを考えていました。まだ試していませんが、rsyncの経験が豊富な人なら、それが実行可能なオプションかどうかを教えてくれるでしょうか？

他にどのようなオプションを検討する価値がありますか？

更新： lsyncdオプションを回答として選択しましたが、これは最も人気があったためです。その他の推奨代替案も独自の方法で有効です。

インスタント更新も許容されるため、lsyncdを使用できます。
ディレクトリを監視し（inotify）、rsyncスレーブに変更します。
起動時に完全rsyncに実行されるため、しばらく時間がかかりますが、その後は変更のみが送信されます。
ディレクトリの再帰的な監視が可能です。スレーブサーバーがダウンしている場合、同期が戻るまで同期が再試行されます。

これがすべて単一のディレクトリ（またはディレクトリの静的リスト）にある場合は、incronも使用できます。
欠点は、フォルダーを再帰的に監視できないため、同期機能を自分で実装する必要があることです。

GlusterFSなどの分散ファイルシステムの使用を検討してください。レプリケーションと並列処理を念頭に置いて設計されているため、GlusterFSはinotifyおよびを含むアドホックソリューションよりもはるかにスムーズに最大10台のサーバーに拡張できますrsync。

この特定のユースケースでは、10レプリカの10サーバーGlusterFSボリューム（つまり、サーバーごとに1レプリカ/ブリック）を構築し、各レプリカがボリューム内の他のすべてのレプリカの正確なミラーになるようにします。GlusterFSは、ファイルシステムの更新をすべてのレプリカに自動的に伝播します。

各場所のクライアントはローカルサーバーに接続するため、ファイルへの読み取りアクセスは高速になります。重要な質問は、書き込みレイテンシを許容できるほど低く保つことができるかどうかです。答える唯一の方法は、それを試すことです。

私は疑うrsync百万のファイルをスキャンし、リモートシステムに10回、それを比較すると、longにかかるので、通常の方法で、このために働くだろう。inotify変更されたファイルのリストを保持し、それらをリモートサーバーにプッシュするようなものでシステムを実装しようとします（これらの変更が別の方法で記録されない場合）。次に、このリストを使用して、転送する必要があるファイルをすばやく特定できます。rsync（またはそれ以上の10個の並列インスタンス）を使用してもかまいません。

編集：少しの作業で、このinotify / log watchアプローチを使用して、変更が発生したらすぐにファイルをコピーすることもできます。

さらにいくつかの選択肢：

• RabbitMQまたはGearmanにジョブを挿入して、プライマリサーバーでファイルを削除または追加するたびに非同期ですべてのリモートサーバーで同じファイルを削除（または追加）します。
• ファイルをデータベースに保存し、レプリケーションを使用してリモートサーバーの同期を維持します。
• ZFSがある場合は、 ZFSレプリケーションを使用できます。
• 一部のSANにはファイル複製があります。これがインターネット上で使用できるかどうかはわかりません。

これは、MongoDBおよびおそらくGridFSの理想的なストーリーブックのユースケースのようです。ファイルは比較的小さいため、MongoDBだけで十分ですが、GridFS APIを使用すると便利な場合があります。

MongoDBはnosqlデータベースであり、GridFSはその上に構築されたファイルストレージです。MongoDBには、レプリケーションとシャーディングに関する多くのオプションが組み込まれているため、ユースケースで非常に適切に拡張する必要があります。

おそらく、プライマリデータセンターにあるマスター（同じ場所にフェールオーバーする場合は2番目のマスター）と、世界中に分散している10個の "スレーブ"で構成されるレプリカセットから開始するでしょう。次に、負荷テストを行って、書き込みパフォーマンスが十分かどうかを確認し、ノードへのレプリケーション時間を確認します。さらにパフォーマンスが必要な場合は、セットアップをシャードに変更できます（ほとんどの場合、書き込み負荷をより多くのサーバーに分散させるため）。MongoDBは、「安い」ハードウェアを使用して巨大なセットアップをスケールアップするように設計されているため、安価なサーバーのバッチを投入してパフォーマンスを向上させることができます。

私はS3バックエンドを使用し、必要なすべてのサーバーにそれをマウントするだけです-そうすれば、とにかく誰もがすぐに同期します

まだ言及されていないように見えるオプションは、すべてのファイルを1つの圧縮ファイルにアーカイブすることです。これにより、合計サイズが大幅に削減され、数百万の個々のファイルを処理することによって生じるオーバーヘッドがすべて削除されます。1つの大きな更新でファイルのセット全体を置き換えることにより、削除されたファイルがレプリカで削除されることを保証できます。

欠点は、もちろん、不必要に多くのファイルを転送していることです。これは、圧縮のおかげでサイズが小さくなったため、バランスが取れている場合とない場合があります。また、その数のファイルを圧縮するのにどれくらい時間がかかるかわかりません。