複数のマシンで1つのアプリケーション(サーバー)を実行しており、各サーバーは異なるクライアントにサービスを提供しています。アプリケーションをフェイルオーバーできるようにする必要があります。これは、アプリケーションの 1 つが何らかの理由でダウンしたときに、もう 1 つのアプリケーションがデータを失うことなく作業を再開できる場合です。
任意の提案、資料をいただければ幸いです。
複数のマシンで1つのアプリケーション(サーバー)を実行しており、各サーバーは異なるクライアントにサービスを提供しています。アプリケーションをフェイルオーバーできるようにする必要があります。これは、アプリケーションの 1 つが何らかの理由でダウンしたときに、もう 1 つのアプリケーションがデータを失うことなく作業を再開できる場合です。
任意の提案、資料をいただければ幸いです。
これを行うのに最も適切な場所は、ネットワーク レベルであるように思われます。実際のアプリ サーバーの前にあるある種の負荷分散プロキシにクライアントを接続し、それに応じてトラフィックを誘導します。このロードバランサーは通常、質問に従ってクライアントを別のサーバーに送信しますが、サーバーが応答していないことを検出すると、失敗したサーバーをブラックリストに登録し、代わりにクライアントを他のアクティブなサーバーにリダイレクトします。
多くのロード バランサーは、この種のフェイルオーバー動作を提供します。私は過去にHAProxyでまさにこれを行ったことがありますが、それが機能する唯一の実装ではないと確信しています。
サーバー間の通勤状態に関しては、それは非常に困難です。フェールオーバーは、すべてのサーバーが同一/代替可能である場合にのみ、(前述のように) ネットワーク レベルで簡単に処理できます。サーバー固有の状態になり始めるとすぐに、A と B は同じではないため、サーバー B をドロップしてサーバー A を置き換えることはできなくなります。
これに対処する必要がある場合は、サーバー B がサーバー A がダウンしたことを認識し、何らかの方法で A の状態を回復して独自の状態にマージするようなロジックを作成する必要があります。これが競合なしで実行できることを願っていますが、これは保証されていません。サーバーは、以前の B クライアントに対しては B のように見え/動作し、以前の A クライアントに対しては A のように見え/動作する必要がありますが、これは実際には不可能かもしれません。また、A が正常にシャットダウンされなかった場合、状態データが破損している/古くなっている可能性があります。(その間ずっと、B はサーバー C または D がこの同じ復旧を実行するのを停止する必要があり、ロード バランサーが自分が新しい A であることを認識していることを確認する必要があります。)
ローカル状態なしでフェイルオーバーを行う方がはるかに 簡単です。この場合、すべてのサーバーは事実上単なる CPU サイクルの集まりであり、クライアントの Cookie または中央データベースに状態を保存します。このようにして、個々のマシンを透過的に切り替えることができます。可能であれば、このモデルを追求することをお勧めします。