F5ロードバランサーがタイムアウト時にリクエストを再送信する
私はシステム管理者ではない、私はプログラマーであると言って、これを前置きさせてください。
最近、システム管理者がF5ロードバランサーをインストールしました。それ以来、リクエストがタイムアウトして500がスローされると、ロードバランサーが同じリクエストを他のサーバーに送信することに気づきました。 IISスクリプトが実際に実行されている場合でもタイムアウト応答を送信します。スクリプトが5分以上実行される場合でも、POST要求は重複します。これは特に顧客への請求が関係するeコマースサイトでは、私にとって潜在的な問題です。
これは、実行時間の長いスクリプトのいくつかの問題にすぎません（ただし、深刻な問題です）。これは予想される動作であり、準拠するようにコードを変更する必要があると言われました。だから私の質問は：
- これは予想される動作ですか？
- ユーザーが更新する必要がない以外のタイムアウト後にリクエストをレプリケートするロードバランサーの利点は何ですか？
- このアーキテクチャでは、サーバーを停止するかリソースを占有するスクリプトが実行されると、両方のサーバーで実行されます。それは本当に最適ですか？
Big-IPでのパッシブアプリケーションモニタリングに関するこのエントリをご覧ください
あなたの質問に対する私の答えは、彼らがそうかもしれないのと同じくらい残念です
多分（パッシブモニタリング設定に依存します）
ユーザーにエラーが表示されない
- たぶん（ユーザーのエラーに対応したいですか、それとも別の場所でリクエストを試したいですか？）
500エラーが発生した場合、これはWebサーバーに問題があることを示しています。 F5は、このエラーを接続しているクライアントに転送するだけです。それはそれ自体の要求を「再送信」しません。これが発生する可能性がある唯一の方法は、クライアントが要求を再試行する場合です。その時点で、このリクエストは別のプールメンバーに負荷分散される可能性がありますが、保証はなく、永続性または使用される負荷分散方法（ラウンドロビン、最小接続など）に基づいています。
つまり、F5に本当にクレイジーなiRuleがない限り、これはスクリプト自体が原因の動作です。
（注：私はF5のネットワークサポートエンジニアとして1年半、LTMで働いていました）