LRTM方式

最終公開日 : Sep 25, 2026
注：LRTMは、モニターを使用する最小応答時間方式（LRTM）の略です。
負荷分散仮想サーバーがLRTM方式を使用するように構成されている場合、既存の監視インフラストラクチャを使用して最速の応答時間を実現します。次に、負荷分散仮想サーバーは、アクティブなトランザクションの数が最も少なく、応答時間が最も短いサービスを選択します。LRTM 方式を使用する前に、アプリケーション固有のモニターを各サービスにバインドし、これらのモニターで LRTM モードを有効にする必要があります。次に、NetScalerアプライアンスは、監視プローブから計算した応答時間に基づいて負荷分散を決定します。
LRTM メソッドを使用して、HTTP 以外のサービスと非 HTTPS サービスの負荷分散を行うこともできます。この方法は、複数のモニターがサービスにバインドされている場合にも使用できます。各モニターは、バインドされているサービスに対して測定するプロトコルを使用して応答時間を決定します。次に、仮想サーバは結果を平均化して、そのサービスの平均応答時間を計算します。
次の表に、さまざまなモニタの応答時間の計算方法をまとめます。
監視 応答時間の計算
PING ICMP エコー要求と ICMP エコー応答の時間差。
TCP SYN リクエストと SYN+ACK レスポンスの時間差。
HTTP HTTP リクエスト (TCP 接続が確立された後) と HTTP レスポンスの時間差。
TCP-ECV データ送信文字列が送信されてから、データ受信文字列が返される時間の差。送受信文字列を使用しない TCP-ECV モニタの設定が正しくないと見なされます。
HTTP-ECV HTTP リクエストと HTTP レスポンスの時間差。
UDP-ECV UDP の送信文字列と受信文字列の間の時間差。受信文字列がない UDP-ECV モニタは、正しくない構成と見なされます。
DNS DNS クエリと DNS 応答の時間差。
TCPS SYN リクエストと SSL ハンドシェイク完了の時間差。
FTP ユーザー名の送信とユーザー認証の完了との時間差。
HTTPS (HTTPS 要求を監視する) 時差は HTTP モニタの場合と同じです。
HTTPS-ECV（HTTPS要求の監視） 時差は HTTP-ECV モニタの場合と同じです
USER 要求がディスパッチャーに送信された時刻とディスパッチャー応答が受信された時刻との時間差。
次の例は、NetScalerアプライアンスがLRTM方式を使用して負荷分散用のサービスを選択する方法を示しています。次の 3 つのサービスを検討してください。
  • Service-HTTP-1 は 3 つのアクティブなトランザクションを処理しており、応答時間は 5 秒です。
  • Service-HTTP-2 は 7 つのアクティブなトランザクションを処理しており、応答時間は 1 秒です。
  • Service-HTTP-3はアクティブなトランザクションを処理しておらず、応答時間は2秒です。
次の図は、NetScalerアプライアンスがリクエストを転送するときに実行するプロセスを示しています。
図1：LRTM メソッドの仕組み
応答時間の最小メカニズム
仮想サーバーは、次の式で値 (N) を使用してサービスを選択します。
N = (アクティブなトランザクションの数 x モニターによって決定される応答時間)
仮想サーバーは、次のようにリクエストを送信します。
  • Service-HTTP-3 は、このサービスはアクティブなトランザクションを処理していないため、最初の要求を受信します。
  • Service-HTTP-3 は、2 番目、3 番目、4 番目の要求を受信します。これは、このサービスの N 値が最も小さいためです。
  • Service-HTTP-2 は、5 番目の要求を受信します。これは、このサービスの N 値が最小であるためです。
  • 現在、Service-HTTP-2とService-HTTP-3の両方が同じN値を持つため、NetScaler ADCアプライアンスはラウンドロビン方式に切り替わります。したがって、Service-HTTP-3 は 6 番目の要求を受信します。
  • Service-HTTP-2 は、7 番目と 8 番目の要求を受信します。これは、このサービスの N 値が最も小さいためです。
Service-HTTP-1は、他の2つのサービスと比べて負荷が大きい（N値が最も大きい）ため、負荷分散の対象にはなりません。ただし、Service-HTTP-1がアクティブなトランザクションを完了すると、NetScalerアプライアンスは再びそのサービスを負荷分散の対象と見なします。
次の表は、サービスの N の計算方法をまとめたものです。
リクエストを受け取りました サービス選択済み 現在の N 値 (アクティブなトランザクションの数* TTFB) 注釈
Request-1 サービス-HTTP-3; (N = 0) N = 2 Service-HTTP-3 は最小 N 値を持ちます。
Request-2 Service-HTTP-3; (N = 2) N = 4 Service-HTTP-3 は最小 N 値を持ちます。
Request-3 Service-HTTP-3; (N = 4) N = 6 Service-HTTP-3 は最小 N 値を持ちます。
Request-4 サービス-HTTP-3; (N = 6) N = 8 Service-HTTP-3 は最小 N 値を持ちます。
Request-5 サービス-HTTP-2; (N = 7) N = 8 Service-HTTP-2 は最小 N 値を持ちます。
Request-6 サービス-HTTP-3; (N = 8) N = 10 サービス HTTP-2 とサービス HTTP-3 の N 値は同じ。NetScalerアプライアンスがラウンドロビン方式に切り替わり、Service-HTTP-3を選択する
Request-7 Service-HTTP-2; (N = 8) N = 9 Service-HTTP-2 は最小 N 値を持ちます。
Request-8 Service-HTTP-2; (N = 9) N = 10 Service-HTTP-2 は最小 N 値を持ちます。
アクティブなトランザクションが完了したとき、またはその N 値が他のサービス（Service-HTTP-2 と Service-HTTP-3）よりも小さいときに、サービス HTTP-1 がロードバランシングの対象として再び選択されます。
Related information

ウェイト割り当て時のサービスの選択

NetScalerアプライアンスは、サービスに異なる重みが割り当てられている場合は、アクティブなトランザクション数、応答時間、および重みを使用して負荷分散も実行します。NetScalerアプライアンスは、次の式の値（Nw）を使用してサービスを選択します。
Nw = (N) * (10000 /重量)
ここで N = (アクティブなトランザクションの数 x モニターによって決定される応答時間)
次の図は、重みが割り当てられるときに仮想サーバーが LRTM 方式を使用する方法を示しています。
図2：重みが割り当てられている場合の最小応答時間負荷分散方法の仕組み
LRTウェイト
この例では、Service-HTTP-1 に重みが 2、Service-HTTP-2 に重みが 3、Service-HTTP-3 に重みが 4 が割り当てられているとします。
NetScaler ADCアプライアンスは、次のようにリクエストを送信します。
  • Service-HTTP-3 は、アクティブなトランザクションを処理していないため、最初の要求を受信します。
  • Service-HTTP-3 は、Nw の値が最小であるため、2 番目、3 番目、4 番目、5 番めの要求を受信します。
  • Service-HTTP-2 は 6 番目のリクエストを受信します。これは、このサービスの Nw 値が最も低いためです。
  • Service-HTTP-3 は 7 番目のリクエストを受け取ります。これは、このサービスの Nw 値が最も小さいためです。
  • Service-HTTP-2 は 8 番目のリクエストを受信します。これは、このサービスの Nw 値が最も低いためです。
Service-HTTP-1は重みが最も低く、Nw値が最も高いため、NetScalerアプライアンスは負荷分散の対象として選択しません。
次の表は、さまざまなモニターでの Nw の計算方法をまとめたものです。
リクエストを受け取りました サービス選択済み Current Nw Value (N) * (10000 / Weight) 注釈
Request-1 サービス-HTTP-3; (新規 = 0) Nw = 5000 サービス HTTP-3 の Nw 値は最も低いです。
Request-2 Service-HTTP-3; (Nw = 5000) Nw = 10000 サービス HTTP-3 の Nw 値は最も低いです。
Request-3 Service-HTTP-3; (Nw = 10000) Nw = 15000 サービス HTTP-3 の Nw 値は最も低いです。
Request-4 Service-HTTP-3; (Nw = 15000) Nw = 20000 サービス HTTP-3 の Nw 値は最も低いです。
Request-5 Service-HTTP-3; (New = 20000) Nw = 25000 サービス HTTP-3 の Nw 値は最も低いです。
Request-6 Service-HTTP-2; (New = 23333.34) Nw = 26666.67 サービス HTTP-2 の Nw 値は最も低いです。
Request-7 Service-HTTP-3; (New = 25000) Nw = 30000 サービス HTTP-3 の Nw 値は最も低いです。
Request-8 Service-HTTP-2; (Nw = 26666.67) Nw = 30000 サービス HTTP-2 の Nw 値は最も低いです。
Service-HTTP-1は、アクティブなトランザクションが完了したとき、またはNw値が他のサービス（Service-HTTP-2およびService-HTTP-3）よりも小さい場合に、ロードバランシングの対象として選択されます。

CLI を使用して LRTM ロードバランシング方式を設定するには

コマンドプロンプトで、次のように入力します。
set lb vserver <name> [-lbMethod <lbMethod>]
例:
set lb vserver Vserver-LB-1 -lbMethod LRTM

GUI を使用して LRTM ロードバランシング方式を設定するには

  1. > > に移動し、仮想サーバーを開きます。
  2. 「詳細設定」で「 LRTM」を選択します。

CLI を使用してモニターの LRTM オプションを有効にするには

コマンドプロンプトで、次のように入力します。
set lb monitor <monitorName> <type> [-LRTM ( ENABLED | DISABLED )]
例:
set lb monitor monitor-HTTP-1 HTTP -LRTM ENABLED

GUI を使用してモニタの LRTM オプションを有効にするには

  1. > > に移動し、 モニターを開きます。
  2. 「拡張パラメータ」で、「 LRTM (監視を使用した最小応答時間)」を選択します。
モニタの構成の詳細については、「 負荷分散セットアップでのモニタの設定」を参照してください。