ADC

カスタム負荷方式

カスタム負荷分散は、CPU 使用率、メモリ、応答時間などのサーバパラメータに対して実行されます。カスタムロード方式を使用する場合、Citrix ADCアプライアンスは通常、アクティブなトランザクションを処理していないサービスを選択します。ロードバランシング設定のすべてのサービスがアクティブなトランザクションを処理している場合、アプライアンスは負荷が最小のサービスを選択します。ロードモニタと呼ばれる特殊なタイプのモニタは、ネットワーク内の各サービスの負荷を計算します。ロードモニタはサービスの状態をマークしませんが、サービスが UP でない場合、ロードバランシングの決定からサービスを取り出します。

負荷モニタの詳細については、「 負荷モニタについて」を参照してください。次の図は、ロードモニタの動作を示しています。

図1:ロードモニターの仕組み

CustomLoad_working

負荷モニタは 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:カスタムロード方法の仕組み

custom_working2

各リクエストが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:ウェイトが割り当てられている場合のカスタムロード方法の動作

カスタムロード重み

カスタムロード方式を構成するには、 ポリシーを含まない負荷分散方式の構成を参照してください

カスタム負荷方式

この記事の概要