ソフトウェアベースの共有ファイルストレージには何を使用しますか？

Question

状況：ロードバランサーのセットアップ

現在、データセンターにはすべてのサーバー（CentOS Linuxを実行）がペアであります。各サーバーにはミラーリングサーバーがあります。現時点では負荷分散を採用していないため、serverAはすべてのトラフィックを取得し、障害が発生した場合（ハードウェアまたはソフトウェア）、serverBでserverAのIPアドレスを構成することでserverBにすばやく切り替えることができます。 MySQLマスター/マスターレプリケーション（現在のセットアップではマスター/スレーブレプリケーションを使用できますが）とrsyncを使用して、vhostファイルの同期を維持しています（serverAはserverBに同期します）。

これは私たちにとってはうまく機能していますが、ハードウェアの50％がマシンに障害が発生するまで何もしないため、非常に非効率的です。サーバーペアの前にロードバランサーを配置して、両方のマシンに負荷を分割し、クラスターごとにサーバーを追加することを検討しています。

問題：ファイルストレージの共有

これを設定するのに、ロードバランサーを各サーバーペアの前に配置してから、ペアの各サーバーへのトラフィックを分割するだけで済みます。 1つを除いて：ファイルストレージ。現在、rsyncはserverAからserverBに変更をプッシュしますが、その逆はありません。 rsyncがserverBからserverAにも実行されるように設定できますが、問題は、rsyncがserverAには存在するがserverBには存在しないファイルを作成するか削除するかを認識しないことです。 nison を見ましたが、そのプロジェクトは中止されたようです。

質問：ソフトウェアベースの共有ファイルストレージに最適なソリューションは何ですか？

だから、私は別の解決策を探しています。ハードウェアを追加したくないので（NAS/SANソリューションはありません）、注意してください。また、クラスターごとに必要なストレージの量は少なく（500GB未満）、すべてのサーバーが同じローカルネットワーク上にあることにも注意してください。適切なバックアップソリューションが用意されています（バックアップは3時間ごとに実行されます）。

私は [〜＃〜] drbd [〜＃〜] を見てきましたが、それは私たちの状況によく合っているようですが、私はそれについての経験がありません。 DRBDは私たちのために行く方法ですか？このソリューションや他の同様のソリューションの経験を共有してください。考えるべき落とし穴はありますか？私は正しい方向に進んでいますか？私を啓発してください:)

Kvisle · Accepted Answer

DRBDは素晴らしいです。

良いこと：

それはデータを複製するのに素晴らしい仕事をします
DRBDは、ボリュームが他のノードにすでにマウントされていることを発見したいくつかのケースで災害を防止しました。これは、SANから取得したrawボリュームではわかりません。
HeartbeatはすでにDRBDを強力にサポートしています。

課題：

それを適切に監視することを忘れないでください。そうすれば、スプリットブレインが発生したときにそれを発見し、それに対処することができます。
クラスター対応のファイルシステムが上にないと、DRBDを両方のサーバーにマウントすることはできません。その部分の経験はありません。
ディスクの同期に使用可能なすべての帯域幅を使用するようにDRBDを構成することで、サーバーを「DOS」するのは簡単です。スループットを下げるように構成するだけで、問題ありません。

「同じ」ファイルシステムを複数のノードにマウントするために、さまざまなソリューションをテストし続けていますが、NFSに戻り続けています。私が本番環境で問題なくセットアップできるのは、DRBDの上にあるEXT4の上にあるNFSです。データベースファイルシステムでこれを行うことはあえてしませんが、wwwrootでは問題ありません。

quanta · Answer

DRBDは、データをリアルタイムで透過的にミラーリングします。以下の点に注意してください。

3つまたは4つのノードをセットアップする場合は、以下を参照してください。

Nils · Answer

クラスタごとに2つ（またはそれ以上）のサービスを設定し、デフォルトで各サイドで1つずつ実行してみませんか？