アプリケーションサーバーに障害が発生した場合のこのようなセットアップのシステム動作を理解しようとしています:
私の理解では、リクエストの処理中に 2 つの tomcat のいずれかがクラッシュした場合、ユーザーは http エラー メッセージを受け取り、ページを更新しようとすると、バランサーがユーザーを作業中の tomcat にリダイレクトし、リクエストの処理が再び開始されるということです。
これは正しいですか? 要求を処理しているサーバーに障害が発生したときにユーザーにエラー メッセージが表示されるのを回避する方法はありませんか?
動作は、ロードバランサーの構成方法、Tomcat サーバーから取得しているエラー、およびアプリケーションの動作によって異なります。
ロードバランサーは、監視しているサーバーを定期的に (数秒ごとに) ヘルスチェックします。そのため、単一のサーバーがユーザー リクエストの間にクラッシュし、ロード バランサーに通知される可能性は十分にあります。そのサーバーはグループから外され、ユーザーが次に更新すると、途中で何か問題が発生したことを知らずに残りのサーバーの 1 つにリダイレクトされます。
ただし、これはアプリケーションがステートレスであることに依存します。いずれかの状態が単一のサーバーに保存されている場合 (スティッキー セッションの使用によって暗示されます)、ユーザーが別のサーバーにリダイレクトすると、セッション タイムアウトまたはその他のエラーが発生し、再ログインして再起動する必要があります。したがって、ユーザーがエラーを受け取るのを回避するためのステップ 1 は、アプリケーションをステートレスにするか、何らかの方法で効果的に状態を共有することです。
また、アプリケーションがどのように失敗するか、およびロード バランサーがそれを検出するかどうかも検討する価値があります。通常、ロード バランサーは、レイヤー 4 またはレイヤー 7 のヘルスチェック用に構成されます。
レイヤー 4 は、Web サーバーが特定のポート (ポート 80 など) でリッスンしていることを確認します。サーバーが応答している限り、サーバーはグループに保持されます。これは、サーバーのアップ/ダウン タイプの監視には問題ありませんが、アプリケーションがエラーまたはフリーズしているにもかかわらず、Web サーバーがポート 80 で応答しており、ユーザーがまだそこに誘導されているという状況が発生する可能性があります。
レイヤー 7 は、監視するように構成されている Web ページ上の特定のコンテンツをチェックします。これは、ユーザーと同じ種類のコンテンツを見ているため、より「現実世界」の監視であり、アプリケーションレベルの問題のためにサーバーをグループから外します。