-
-
-
VMware ESX、Linux KVM、およびCitrix HypervisorでNetScaler ADC VPXのパフォーマンスを最適化する
-
-
NetScalerアプライアンスのアップグレードとダウングレード
-
-
-
-
-
-
-
-
-
-
-
-
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!
カスタム負荷方式
カスタム負荷分散は、CPU 使用率、メモリ、応答時間などのサーバパラメータに対して実行されます。カスタムロード方式を使用する場合、NetScaler ADCアプライアンスは通常、アクティブなトランザクションを処理していないサービスを選択します。ロードバランシング設定のすべてのサービスがアクティブなトランザクションを処理している場合、アプライアンスは負荷が最小のサービスを選択します。ロードモニタと呼ばれる特殊なタイプのモニタは、ネットワーク内の各サービスの負荷を計算します。ロードモニタはサービスの状態をマークしませんが、サービスが UP でない場合、ロードバランシングの決定からサービスを取り出します。
負荷モニタの詳細については、「 負荷モニタについて」を参照してください。次の図は、ロードモニタの動作を示しています。
図1：ロードモニターの仕組み
負荷モニタは SNMP プローブを使用して、SNMP GET 要求をサービスに送信して、各サービスの負荷を計算します。このリクエストには、1 つ以上のオブジェクト ID (OID) が含まれます。サービスは、SNMP OID に対応するメトリックとともに、SNMP GET 応答で応答します。負荷モニターは、レスポンスメトリックを使用してサービスの負荷を計算します。
負荷モニターは、次のパラメーターを使用してサービスの負荷を計算します。
- NetScalerアプライアンスにテーブルとして存在するSNMPプローブを介して取得されたメトリック値。
- 各メトリックに設定されたしきい値。
- 各メトリックに割り当てられた重み。
たとえば、Service-HTTP-1、Service-HTTP-2、Service-HTTP-3 の 3 つのサービスを考えてみます。
- Service-HTTP-1 は 20 MB のメモリを使用しています。
- Service-HTTP-2 では、70 MB のメモリを使用しています。
- サービス HTTP-3 は 80 MB のメモリを使用しています。
負荷分散されたサーバーは、CPU やメモリの使用量などのメトリックをサービスにエクスポートし、サービスがそれらを負荷モニターに提供できます。ロードモニターは、OID 1.3.6.1.4.1.5951.4.1.41.1.5、1.3.6.1.4.1.5951.4.1.41.1.4、および 1.3.6.1.4.1.5951.4.1.5951.4.1.41.1.3 を含む SNMP GET リクエストをサービスに送信します。文字列 OID を使用して負荷を計算することはできないため、文字列型の SNMP OID はサポートされていません。負荷は、INT や gauge32 などの他のデータ型を使用して計算できます。3 つのサービスが要求に応答します。NetScalerアプライアンスはエクスポートされたメトリックを比較し、使用可能なメモリの方が多いためService-HTTP-1を選択します。次の図は、このプロセスを示しています。
図2：カスタムロード方法の仕組み
各リクエストが10 MBのメモリを使用する場合、NetScalerアプライアンスは次のようにリクエストを配信します。
- Service-HTTP-1 は、1 番目、2 番目、3 番目、4 番目、5 番目のリクエストを受信します。これは、このサービスの N 値が最小であるためです。
- Service-HTTP-1とService-HTTP-2の負荷が同じになったため、仮想サーバーはこれらのサーバーのラウンドロビン方式に戻ります。したがって、Service-HTTP-2 は 6 番目の要求を受信し、Service-HTTP-1 は 7 番目の要求を受信します。
- Service-HTTP-1、Service-HTTP-2、Service-HTTP-3 はすべて同じ負荷を持つため、仮想サーバも Service-HTTP-3 のラウンドロビン方式に戻ります。したがって、Service-HTTP-3 は 8 番目の要求を受信します。
次の表は、N の計算方法をまとめたものです。
| リクエストを受け取りました | サービスが選択されました | 現在の N 値 (アクティブなトランザクションの数) | 注釈 |
|---|---|---|---|
| Request-1 | Service-HTTP-1; (N = 20) | N = 30 | Service-HTTP-3 は最小 N 値を持ちます。 |
| Request-2 | Service-HTTP-1; (N = 30) | N = 40 | - |
| Request-3 | Service-HTTP-1; (N = 40) | N = 50 | - |
| Request-4 | Service-HTTP-1; (N = 50) | N = 60 | - |
| Request-5 | Service-HTTP-1; (N = 60) | N = 70 | - |
| Request-6 | Service-HTTP-1; (N = 70) | N = 80 | サービス HTTP-2 とサービス HTTP-3 の N 値は同じ。 |
| Request-7 | Service-HTTP-2; (N = 70) | N = 80 | サービス HTTP-3 の N 値は同じ。 |
| Request-8 | Service-HTTP-1; (N = 80) | N = 90 | サービス HTTP-1、サービス HTTP-2、およびサービス HTTP-3 には、同じ N 個の値があります。 |
サービスに異なる重みが割り当てられている場合、カスタム負荷アルゴリズムは各サービスの負荷と各サービスに割り当てられた重みの両方を考慮します。次の式の値 (Nw) を使用してサービスを選択します。
Nw = (N) * (10000 /重量)
前の例と同様に、サービス HTTP-1 には 4 の重みが割り当てられ、サービス HTTP-2 には 3 の重みが割り当てられ、サービス HTTP-3 には重み 2 が割り当てられているとします。各リクエストが10 MBのメモリを使用する場合、NetScalerアプライアンスは次のようにリクエストを配信します。
- Service-HTTP-1 は、1 番目、2 番目、3 番目、4 番目、5 番目、6 番目、7 番目、8 番目のリクエストを受信します。これは、このサービスの Nw 値が最も低いためです。
- Service-HTTP-2 は 9 番目のリクエストを受信します。これは、このサービスの Nw 値が最小であるためです。
Service-HTTP-3 は Nw 値が最も高いため、ロードバランシングの対象にはなりません。
次の表は、Nw の計算方法をまとめたものです。
|リクエストを受け取りました|サービスが選択されました|現在の新しい価値 (アクティブなトランザクションの数) * (10000/重量)|注釈 |-|-|-|-| |Request-1|Service-HTTP-1; (Nw = 50000)|Nw = 75000|サービス HTTP-1 の Nw 値は最も低いです。 |Request-2|Service-HTTP-1; (Nw = 5000)|Nw = 100000|-| |Request-3|Service-HTTP-1; (Nw = 15000)|Nw = 125000|-| |Request-4|Service-HTTP-1; (Nw = 20000)|Nw = 150000|-| |Request-5|Service-HTTP-1; (New = 23333.34)|Nw = 175000|-| |Request-6|Service-HTTP-1; (Nw = 25000)|Nw = 200000|-| |Request-7|Service-HTTP-1; (New = 23333.34)|Nw = 225000|-| |request-8|service-HTTP-1; (Nw = 25000) |Nw = 250000||-| |request-9|Service-HTTP-2; (Nw = 233333.34) |Nw = 266666.67|Service-HTTP-2 の Nw 値が最も低い。
サービス HTTP-1 は、アクティブなトランザクションが完了したとき、または他のサービス (サービス HTTP-2 と Service-HTTP-3) の Nw 値が 400,000 になったときに、ロードバランシングの対象として選択されます。
次の図は、重みが割り当てられるときにNetScalerアプライアンスがカスタムロード方法を使用する方法を示しています。
図3：ウェイトが割り当てられている場合のカスタムロード方法の動作
カスタムロード方式を構成するには、 ポリシーを含まない負荷分散方式の構成を参照してください。
共有
共有
この記事の概要
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.