-
-
-
VMware ESX、Linux KVM、およびCitrix HypervisorでNetScaler ADC VPXのパフォーマンスを最適化する
-
AWSでNetScaler ADC VPXインスタンスを展開する
-
-
-
-
-
-
-
-
-
-
-
-
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
再試行を要求する
バックエンドサーバーがTCP接続をリセットすると、要求の再試行機能は、リセットをクライアントに送信する代わりに、次に使用可能なサーバーに要求を転送します。リ負荷分散を実行すると、アプライアンスが次の利用可能なサービスに対して同じ要求を開始すると、クライアントは RTT を保存します。
リクエストリトライ機能は、次のエラーシナリオに適用できます。
- アプライアンスがリクエストデータパケットを送信すると、バックエンドサーバーは TCP 接続をリセットします。
- バックエンドサーバーが SYN 確立時に TCP 接続をリセットした場合
バックエンドサーバーが要求データパケットの受信時にTCP接続をリセットするときの要求の再試行のしくみ
次の図は、コンポーネントがどのように相互作用するかを示しています。
- このプロセスは、アプライアンスで AppQoE 機能を有効にすることから始まります。
- クライアントがHTTPまたはHTTPS要求を送信すると、負荷分散仮想サーバーはその要求をバックエンドサーバーに送信します。
- 要求されたサービスが利用できない場合、バックエンドサーバーはTCP接続をリセットします。
- AppQoE 構成で「再試行」が有効になっていて、希望する再試行回数が指定されている場合、負荷分散仮想サーバーは構成された負荷分散アルゴリズムを使用して、次の使用可能なアプリケーションサーバーに要求を転送します。
- 負荷分散仮想サーバーが応答を受信した後、アプライアンスは応答をクライアントに転送します。
- 使用可能なバックエンドサーバーが再試行回数以下で、すべてのサーバーがリセットを送信すると、アプライアンスは内部サーバーエラーを 500 個応答します。使用可能なサーバーが5つあり、再試行回数が6に設定されているシナリオを考えてみます。5 台のサーバすべてが接続をリセットすると、アプライアンスはクライアントに 500 の内部サーバエラーを返します。
- 同様に、バックエンドサーバーの数がリトライ回数を超え、バックエンドサーバーが接続をリセットすると、アプライアンスはリセットをクライアントに転送します。3つのバックエンドサーバーがあり、再試行回数が2に設定されているシナリオを考えてみます。3 台のサーバで接続をリセットすると、アプライアンスはクライアントにリセット応答を送信します。
バックエンドサーバーが SYN 確立時に TCP 接続をリセットした場合の要求の再試行の仕組み
次の図は、コンポーネント同士が相互作用することを示しています。
- このプロセスは、アプライアンスで AppQoE 機能を有効にすることから始まります。
- クライアントが HTTP または HTTPS 要求を送信すると、負荷分散仮想サーバーはバックエンドサーバーへの接続を開始します。
- 要求されたサービスが TCP SYN 確立で使用できない場合、バックエンドサーバーは TCP 接続をリセットします。
- AppQoE 構成で「再試行」が有効になっていて、希望する再試行回数が指定されている場合、負荷分散仮想サーバーは構成された負荷分散アルゴリズムを使用して、次の使用可能なアプリケーションサーバーに要求を転送します。
- 負荷分散仮想サーバーが応答を受信した後、アプライアンスは応答をクライアントに転送します。
- 使用可能なバックエンドサーバーが再試行回数以下で、すべてのサーバーがリセットを送信すると、アプライアンスは内部サーバーエラーを 500 回応答します。使用可能なサーバーが5つあり、再試行回数が6に設定されているシナリオを考えてみます。5 台のサーバすべてが接続をリセットすると、アプライアンスはクライアントに 500 の内部サーバエラーを返します。
- 同様に、バックエンドサーバーの数がリトライ回数を超え、バックエンドサーバーが TCP SYN 確立上の接続をリセットした場合、アプライアンスはリセットをクライアントに転送します。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接続をリセットした場合は、再試行を有効にします。
numretries
。再試行回数。
AppQoEポリシーの追加
AppQoE を実装するには、AppQoE ポリシーを設定して、特定のキューの受信 HTTP または SSL リクエストに優先順位を付ける必要があります。
コマンドプロンプトで入力します:
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
AppQoEアクションの追加
TCPリセットと再試行回数の後に再試行するには、AppQoEアクションを追加する必要があります。
add appqoe action reset_action -retryOnReset ( YES | NO ) -numretries <positive_integer>]
例:
add AppQoE action reset_action –retryOnReset YES –numretries 5
AppQoEポリシーの追加
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 ADC GUI を使用してリクエストを再試行するための AppQoE ポリシーを構成する
- [ **AppExpert] > [ **AppQoE** ] > [ポリシー] に移動します。**
- 「 AppQoE ポリシー 」ページで、「 追加」をクリックします。
-
[ AppQoEポリシー の作成]ページで、次のパラメーターを設定します。
- 名前。AppQoE ポリシー名
- アクション。アクションを追加または編集します。アクションを作成するには、 AppQoE アクションの作成セクションを参照してください 。
-
式。
HTTP.REQ.CONTENT_LENGTH.le (2000)
ポリシー表現を選択または入力します。
- [作成]して[閉じる] をクリックします。
NetScaler ADC GUI を使用してリクエストリトライバランシングを行うための AppQoE アクションの設定
- [ **AppExpert] > [ **AppQoE** ] > [アクション] に移動します。**
- 「 AppQoE アクション 」ページで、「 追加」をクリックします。
- 「 AppQoE アクションの作成 」ページで、TCP リセット時に再試行するための次のパラメータを設定します。 a. TCP リセットで再試行してください。このチェックボックスを選択すると、TCP リセットのリトライアクションが有効になります。 b. 再試行回数。再試行回数を入力します。
- [作成]して[閉じる] をクリックします。
TCP SYNの確立時にバックエンドサーバーがリセットされたときに、GETメソッドの要求の再試行を構成します
CLI および GUI の設定は、GET メソッドのステップと同様です。詳細については、「 GET メソッドのリクエスト試行を設定する 」セクションを参照してください。バックエンドサーバーが接続をリセットしたとき。
共有
共有
This Preview product documentation is Cloud Software Group Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Cloud Software Group Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Cloud Software Group product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.