GlusterFSは、Webサーバーの同期を維持するための良い選択ですか？
私は2つのWebサーバーを持っていますが、途中でサーバーを追加する必要があります。現在、lsyncd + csync2を使用してこれらのサーバーの同期を維持しています。すべてのファイルが両方のサーバー上にあるため（ファイルをローカルで開くためにネットワークアクセスは必要ありません）、パフォーマンス的にはうまく機能しますが、それ以外の場合はあまりうまくいきません。
この一例は、サーバー1のファイルを削除し、すぐに同じ名前の新しいファイルをサーバー1にアップロードする場合です。その後、ファイルはサーバー2から削除され、サーバー2がサーバー1に削除イベントを送信して「更新サークル」を完了すると、サーバー1に新しくアップロードされたファイルが削除されます。
サーバーの同期を維持するためのより良い方法があるはずだと考えずにはいられません。私はGlusterFSを見てきましたが、すべてのファイルがすべてのサーバーに複製されるセットアップは推奨されていません。ただし、これらのサーバーでDrupalのようなCMSシステムを実行しています。このようなCMSシステムは多くの場合、かなりの数のファイルを開きます。これらのファイルを取得するにはネットワークトラフィックが多すぎるのではないかと心配しています。リクエストの速度を落とします。
Lsyncd + csync2を、すべてのファイルをすべてのノードに複製するように設定されたGlusterFSに置き換えることを検討するのは考えですか、それとも悪い考えですか？
BitTorrent Syncが代わりに行います。私はそれを使って家のいくつかの内部サーバー間でファイルの同期を維持していて、それは素晴らしい仕事をしています。アプリがCMSを使用する場合、もう1つ考慮する必要があるのはバックエンドデータベースです。 MySQLレプリケーションが行われていること、またはそのようなものがあることを確認してください。
GlusterFSはデプロイが困難です。 Webデータの場合、 nison のようなファイル同期レベルは、展開と保守がはるかに簡単です。
[〜＃〜] drbd [〜＃〜] は、ブロックレベルでデータの同期を維持するための完璧なソリューションです。ただし、OCFS2などの特別な形式にフォーマットする必要があります。
Glusterは、ロックを保持し、変更を伝達できるため、問題を解決します。他のすべてのノードでファイルを削除しますが、Webサーバーで問題になる可能性のあるレイテンシが追加される可能性があります。次の選択肢はDRBD + OCFS2またはGFSですが、基盤となるファイルシステムを使用しているglusterの場合と同様に、おそらくより複雑です。ブロックレベルでは動作しないため、サーバーが同期していない場合でも、修正するのはそれほど難しくありません。スプリットブレインなどで簡単に破損することはありません...
私たちはそれをメールサーバーに使用していますが、ファイルの多いディレクトリではかなり遅いです。デプロイする前に、必ずすべてをテストする必要があります。 NFSマウントは、小さなファイルでより適切に機能するため、現在テストしています。