バックエンドサーバーが TCP 接続をリセットした場合に再試行をリクエストする
バックエンドサーバーがTCP接続をリセットすると、要求の再試行機能は、リセットをクライアントに送信する代わりに、次に使用可能なサーバーに要求を転送します。リロードバランシングを行うことで、アプライアンスが次に使用可能なサービスへの同じリクエストを開始したときに、クライアントは RTT を節約できます。
Related information
バックエンドサーバーが TCP 接続をリセットしたときの要求再試行の仕組み
次の図は、コンポーネントが互いにどのように相互作用するかを示しています。
-
このプロセスでは、まずアプライアンスの appqoe 機能を有効にします。
-
クライアントがHTTPまたはHTTPS要求を送信すると、負荷分散仮想サーバーはその要求をバックエンドサーバーに送信します。
-
要求されたサービスが利用できない場合、バックエンドサーバーはTCP接続をリセットします。
-
appqoe 設定で「再試行」が有効になっていて、必要な再試行回数が指定されている場合、負荷分散仮想サーバーは、設定された負荷分散アルゴリズムを使用して、次に利用可能なアプリケーションサーバーに要求を転送します。
-
負荷分散仮想サーバーが応答を受信した後、アプライアンスは応答をクライアントに転送します。
-
使用可能なバックエンドサーバーが再試行回数と同じかそれ以下で、すべてのサーバーがリセットを送信した場合、アプライアンスは500の内部サーバーエラーを返します。使用可能なサーバーが5つあり、再試行回数が6に設定されているシナリオを考えてみます。5 台のサーバーすべてが接続をリセットすると、アプライアンスはクライアントに 500 内部サーバーエラーを返します。
-
同様に、バックエンドサーバーの数が再試行回数よりも多く、バックエンドサーバーが接続をリセットした場合、アプライアンスはリセットをクライアントに転送します。3つのバックエンドサーバーがあり、再試行回数が2に設定されているシナリオを考えてみます。3 台のサーバーが接続をリセットすると、アプライアンスはリセット応答をクライアントに送信します。
GETメソッドの要求再試行を構成します
GET メソッドのリトライ機能を設定するには、次の手順を完了する必要があります。
-
AppQoEを有効にする
-
AppQoEアクションの追加
-
AppQoEポリシーの追加
-
AppQoE ポリシーを負荷分散仮想サーバーにバインドする
AppQoEを有効にする
コマンドプロンプトで入力します：
enable ns feature appqoe
AppQoEアクションの追加
AppQoE アクションを設定して、TCP リセット後にアプライアンスを再試行するかどうか、および再試行回数を指定する必要があります。
add appqoe action reset_action -retryOnReset ( YES | NO ) -numretries <positive_integer>]
例:
add appqoe action reset_action –retryOnReset YES –numretries 5
ここで、 リセット時に再試行してください。バックエンドサーバーがTCP接続をリセットした場合は、再試行を有効にします。 数字。再試行回数。
AppQoEポリシーの追加
AppQoE を実装するには、特定のキューで受信する HTTP または SSL リクエストに優先順位を付けるように AppQoE ポリシーを設定する必要があります。
コマンドプロンプトで入力します：
add appqoe policy <name> -rule <expression> -action <string>
例:
add appqoe policy reset_policy -rule http.req.method.eq(get) -action reset_action
appqoeポリシーを負荷分散仮想サーバーにバインドする
バックエンドサーバーがTCPパケット要求をリセットし、負荷分散仮想サーバーがその要求を次に利用可能なサービスに転送するようにする場合は、負荷分散仮想サーバーをAppQoEポリシーにバインドする必要があります。
コマンドプロンプトで入力します：
bind lb vserver <name> ((<serviceName> (-policyName <string> [-priority <positive_integer>] [-gotoPriorityExpression <expression>] [-type ( REQUEST | RESPONSE )]
例:
bind lb vserver v1 -policyName reset_policy -type REQUEST -priority 1
POST リクエストのリクエストリトライの設定
バックエンドサーバーにデータを書き込むバランスリクエストをリロードする場合は、常に注意が必要です。このようなリクエストには、コンテンツの長さが短いことを確認してください。コンテンツの長さが長いと、リソースを消費する可能性があります。POST リクエストのリ負荷分散を設定するには、以下の手順に従ってください。
-
AppQoEを有効にする
-
AppQoEアクションの追加
-
AppQoEポリシーの追加
-
AppQoE ポリシーを負荷分散仮想サーバーにバインドする
AppQoEを有効にする
コマンドプロンプトで入力します：
enable ns feature appqoe
Apple アクションを追加
TCPリセットと再試行回数の後に再試行するには、AppQoEアクションを追加する必要があります。
add appqoe action reset_action -retryOnReset ( YES | NO ) -numretries <positive_integer>]
例:
add appqoe action reset_action –retryOnReset YES –numretries 5
アップルポリシーの追加
AppQoE を実装するには、AppQoE ポリシーを設定して、特定のキュー内の接続をキューに入れる方法を定義する必要があります。
コマンドプロンプトで入力します：
add appqoe policy <name> -rule <expression> -action <string>
例:
add appqoe policy reset_policy -rule HTTP.REQ.CONTENT_LENGTH.le(2000) -action reset_action
注：
この構成は、リクエストのリトライ機能をコンテンツの長さが 2000 未満に制限したい場合に使用できます。
負荷分散仮想サーバーをAppQoEポリシーにバインドする
バックエンドサーバーがTCPパケット要求をリセットしたときに、負荷分散仮想サーバーが特定のキューを介して次の利用可能なサービスに要求を転送するようにするには、負荷分散仮想サーバーをAppQoEポリシーにバインドする必要があります。
コマンドプロンプトで入力します：
bind lb vserver <name> ((<serviceName> (-policyName <string> [-priority <positive_integer>] [-gotoPriorityExpression <expression>] [-type ( REQUEST | RESPONSE )]
例:
bind lb vserver v1 -policyName reset_policy -type REQUEST -priority 1
NetScaler GUIを使用してリクエストリトライ用のAppQoEポリシーを構成する
。 c. 式。 NetScaler GUIを使用してリクエストリトライバランシング用のAppQoEアクションを構成する
TCP SYNの確立時にバックエンドサーバーがリセットされたときに、GETメソッドの要求の再試行を構成します
CLIとGUIの構成は、GETメソッドの場合と同様の手順です。詳細については、「 GET メソッドのリクエスト試行を設定する 」セクションを参照してください。 バックエンドサーバーが接続セクションをリセットしたとき。