数十万の小さなファイルを持つサーバー間のリアルタイムファイル同期

数十万の小さなファイルを持つサーバー間のリアルタイムファイル同期

データベースだけでなくファイルも複製される 2 台の CentOS 7 サーバーを作成するというタスクを与えられました。問題は、数キロバイトから約 1 ギガバイトまでのさまざまなサイズのファイルが、おそらく 100 万個どころか数十万個あるということです。

私は読んだ

  • 刻印
  • 翻訳
  • git-annex
  • カイロンFS

これまでに使用したことのある方、または現在使用中の方に、これらのことについての体験談を伺いたいです。コピーや削除に関するファイルの変更のパフォーマンスはどうですか? rsync は、小さなファイルがたくさんあるとあまり速くないので、リアルタイムのファイル複製にはあまり使えないという経験から、使用を非常に恐れています。それとも、私が間違っているのでしょうか? 間違っていることを証明してください。:)

あるいは、ファイルサーバーとして 3 台目と 4 台目のサーバーが必要になるでしょうか? そうであれば、2 台のサーバー間でファイルをリアルタイムに複製するにはどうすればよいかという疑問が残ります。

乾杯!

答え1

サーバーが同じ LAN 上にある場合は、クラスター化されたファイルシステム (例: GlusterFS) または共有ストレージ ソリューション (例: NFS 経由) の方が適しています。

サーバーが別の場所にあり、WAN接続のみの場合、上記の解決策はうまく機能しません。この場合、一方向のレプリケーションのみが必要な場合(つまり、アクティブ サーバーからバックアップ サーバーへ) はlsyncd良い解決策です。別の解決策は ですcsync2。最後に、別の可能性は を使用することですDRBD + DRBD Proxy(プロキシ コンポーネントは商用プラグインであることに注意してください)。

最後に、サーバーがWAN接続のみで、双方向のレプリケーションが必要です(つまり、両方のサーバーが同時にアクティブになる)、基本的に特効薬は存在しません。いくつかの可能性を挙げますが、同様の設定を推奨するわけではありません。

  • unisonリアルタイムプラグイン
  • psyncは、私が同様の問題を解決するために書いたものです(ただし、独自の特異性があるため、サポートなしそれのための)
  • syncthingリアルタイムプラグインを使用(ただし、ACL やファイルの所有者/グループが保存されないという重大な制限があります)

答え2

私は ZFS ファイルシステムを使用し、zfs 送信/受信フレームワークを使用してブロックレベルのレプリケーションを活用します。

私は便利なスクリプトを使用していますシンコイド要件に応じて、15 秒から 1 時間ごと、または 1 日ごとの間隔でファイルシステムの定期的な同期を実行します。

あなたが言及しているデータセットの場合、ブロックレベルのレプリケーションは rsync よりもクリーンかつ正確になります。

答え3

私の経験から言うと、分散ファイル システムはアプリケーションに簡単なレプリケーション メカニズムを提供します。ただし、ディレクトリが非常に大きくなり、小さなファイルが多すぎると、特にパフォーマンスが低下します。複数の場所やマシンからのロックや共有アクセスを処理する必要があるため、これは予想どおりです。

Rsync のような方法は、場合によっては、多少の遅延はあるものの許容できるレプリケーションを提供します。レプリケートされたフォルダーの読み取り/書き込み中にアプリケーションのパフォーマンスに影響はありません。

より良い解決策は、1 台のサーバーからアクセス可能な共有ストレージ (手頃な価格の場合) を提供することだと思います。最初のサーバーがダウンしたときに、別のスタンバイ サーバーが共有フォルダーをマウントする準備ができています。サーバー間でデータを複製する必要はありません。

答え4

アイデアをありがとうございます。すべて確認してテストしましたが、lsyncd に固執することにしました。

理由:

  • 非常に簡単なインストール
  • 非常に簡単なセットアップ
  • 一方向と双方向のレプリケーションの両方をサポート

関連情報