カスタム負荷方式
カスタム負荷分散は、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 | - |
サービス HTTP-1 は、アクティブなトランザクションが完了したとき、または他のサービス (サービス HTTP-2 と Service-HTTP-3) の Nw 値が 400,000 になったときに、ロードバランシングの対象として選択されます。
次の図は、重みが割り当てられるときにNetScalerアプライアンスがカスタムロード方法を使用する方法を示しています。
図3：ウェイトが割り当てられている場合のカスタムロード方法の動作
カスタムロード方式を構成するには、 ポリシーを含まない負荷分散方式の構成を参照してください。
Related information