F5ロードバランサーがタイムアウト時にリクエストを再送信する

私はシステム管理者ではない、私はプログラマーであると言って、これを前置きさせてください。

最近、システム管理者がF5ロードバランサーをインストールしました。それ以来、リクエストがタイムアウトして500がスローされるたびに、ロードバランサーが同じリクエストを他のサーバーに送信することに気付きました。IISは、スクリプトが実際に実行されていても、タイムアウト応答を送信します。スクリプトの実行時間が5分を超えると、POSTリクエストも複製されます。これは、特に顧客への請求が関係するeコマースサイトでは、潜在的な問題のようです。

これは、実行時間の長いスクリプトのいくつかにのみ問題があります（ただし、深刻な問題です）。これは予想される動作であり、準拠するようにコードを変更する必要があると言われました。だから私の質問は：

• これは予想される動作ですか？
• ユーザーが更新する必要がないこと以外に、タイムアウト後にロードバランサーが要求をレプリケートする利点は何ですか？
• このアーキテクチャでは、サーバーを停止するかリソースを占有するスクリプトを実行すると、最終的に両方のサーバーで実行されます。それは本当に最適ですか？

Big-IPでのパッシブアプリケーションモニタリングに関するこのエントリをご覧ください

あなたの質問に対する私の答えは、彼らがそうかもしれないのと同じくらい残念です

• 多分（パッシブモニタリング設定に依存）

• ユーザーにエラーが表示されない

• たぶん（ユーザーのエラーに対応したいのですか、それとも別の場所でリクエストを試したいのですか？）

「サービス停止時のアクション」は構成可能な設定です。

500エラーが発生した場合は、Webサーバーに問題があることを示しています。F5は、このエラーを接続しているクライアントに転送するだけです。それはそれ自体の要求の「再送信」はしません。これが発生する唯一の方法は、クライアントが要求を再試行する場合です。その時点で、このリクエストは別のプールメンバーに負荷分散される可能性がありますが、保証はなく、永続性または使用される負荷分散方法（ラウンドロビン、最小接続など）に基づいています。

つまり、F5に本当にクレイジーなiRuleがない限り、これはスクリプト自体が原因の動作です。

（注：私はF5のネットワークサポートエンジニアとして1年半、LTMで働いていました）