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

Question

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

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

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

pdate：答えとしてlsyncdオプションを選択しましたが、それが最も人気があったからです。他の提案された代替案も独自の方法で有効です。

faker · Accepted Answer

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

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

Steven Monday · Answer

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

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

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

Sven · Answer

100万個のファイルをスキャンしてリモートシステムと10回比較すると時間がかかるため、rsyncが通常の方法で機能するとは思えません。変更されたファイルのリストを保持し、それらをリモートサーバーにプッシュするinotifyのようなシステムを実装しようとします（これらの変更が別の方法でログに記録されない場合）。次に、このリストを使用して、転送が必要なファイルをすばやく識別できます。rsync（またはその10個の並列インスタンス）を使用した場合でも同様です。

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

Ladadadada · Answer

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

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

neovatar · Answer

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

MongoDBはnosqlデータベースであり、GridFSはその上に構築されたファイルストレージです。 MongoDBには replication と sharding の多くの組み込みオプションがあるので、ユースケースで非常によくスケーリングするはずです。

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

Mister IT Guru · Answer

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

Supr · Answer

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

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