このページの内容
トラフィックロードバランサ
トラフィック負荷分散の概要
- トラフィック負荷分散サポートの概要
- トラフィックロードバランサアプリケーションの説明
- トラフィックロードバランサの動作モード
- トラフィックロードバランサー機能
- トラフィックロードバランサーのアプリケーションコンポーネント
- トラフィックロードバランサの設定制限
トラフィック負荷分散サポートの概要
表1は 、アダプティブサービス向けMS-MPCおよびMS-MICカードでのトラフィックロードバランシングサポートと、次世代サービス向けMX-SPC3セキュリティサービスカードでのサポートの概要を示しています。
MS-MPC |
MX-SPC3 |
||
|---|---|---|---|
Junosリリース |
< 16.1R6 および 18.2.R1 |
≥ 16.1R6 および 18.2R1 |
19.3R2 |
シャーシあたりの最大#インスタンス数 |
32 |
L2 DSRモードでは2,000 / 32 |
2,000 |
インスタンスあたりの仮想サービスの最大#数 |
32 |
32 |
32 |
仮想サービスごとの仮想IPアドレスの最大#個 |
1 |
1 |
|
インスタンスあたりのグループの最大#数 |
32 |
32 |
32 |
グループあたりのリアルサービス(サーバー)の最大#数 |
255 |
255 |
255 |
仮想サービスあたりのグループの最大#数 |
1 |
1 |
|
グループあたりのネットワークモニタープロファイルの最大#個 |
2 |
2 |
|
5秒以内にPIC/NPUごとのセキュリティサービスごとのHCの最大#数 |
4,000 |
1,250 – 19.3R2 10,000 – 20.1R1 |
|
サポートされているヘルスチェックプロトコル |
ICMP、TCP、UDP、HTTP、SSL、カスタム |
ICMP、TCP、UDP、HTTP、SSL、TLS Hello、カスタム |
|
トラフィックロードバランサアプリケーションの説明
トラフィックロードバランサ(TLB)は、マルチサービスモジュラーポートコンセントレータ(MS-MPC)、マルチサービスモジュラーインターフェイスカード(MS-MIC)、またはMXセキュリティサービス処理カード(MX-SPC3)のいずれかを備えたMXシリーズルーターでサポートされ、 表2で説明するように、MXシリーズルーターでサポートされているモジュラーポートコンセントレータ(MPC)ラインカードと組み合わせてサポートされます。
決定論的NATとTLBを同時に実行することはできません。
TLBモード |
MXプラットフォームのカバレッジ |
|---|---|
マルチサービス モジュラー ポート コンセントレータ(MS-MPC) |
MX240、MX2480、MX960、MX2008、MX2010、MX2020 |
MXセキュリティサービス処理カード(MX-SPC3) |
MX240、MX480、MX960 |
TLBを使用すると、複数のサーバー間でトラフィックを分散できます。
TLBは、MS-MPCベースのコントロールプレーンと、MXシリーズルーターフォワーディングエンジンを使用したデータプレーンを採用しています。
TLBは、ECMP(等価コストマルチパス)の拡張バージョンを使用します。拡張 ECMP は、サーバーのグループ間でのフローの分散を容易にします。ネイティブECMPの機能強化により、サーバーに障害が発生した場合、それらのサーバーに関連するフローのみが影響を受けるようになり、サービスやセッションにおけるネットワーク全体の混乱を最小限に抑えることができます。
TLBは、グループごとに最大255台のサーバーのアプリケーションベースのヘルスモニタリングを提供し、サーバーの可用性情報のヘルスチェックに基づいてインテリジェントなトラフィックステアリングを提供します。サーバーの正常性監視に使用されるMS-MPCまたは次世代サービスMX-SPC3カードに1対1の冗長性を提供するように、集約されたマルチサービス(AMS)インターフェイスを設定できます。
TLBは、そのフロー分散処理をイングレストラフィックに適用します。
TLBは複数の仮想ルーティングインスタンスをサポートし、大規模なロードバランシング要件に対するサポートを向上させます。
TLBは、ロードバランシング時の静的な仮想IPアドレスから実際のIPアドレスへの変換と、静的な宛先ポート変換をサポートします。
トラフィックロードバランサの動作モード
トラフィックロードバランサには、発信トラフィックの配信とリターントラフィックの処理のための3つの運用モードが用意されています。
表3は 、TLBサポートとそれがサポートされているカードをまとめたものです。
セキュリティサービスカード |
MS-MPC |
MX-SPC3 |
|---|---|---|
翻訳 |
はい |
はい |
透過的なレイヤー3ダイレクトサーバーリターン |
はい |
はい |
透過的なレイヤー2ダイレクトサーバーリターン |
はい |
未対応 |
透過モードレイヤー2ダイレクトサーバーリターン
透過モードレイヤー 2 ダイレクト サーバー リターン(DSR)を使用する場合:
PFEはデータを処理します。
ロードバランシングは、パケットのレイヤー2 MACを変更することで機能します。
MS-MPCは、ネットワーク監視プローブを実行します。
実際のサーバーは、MXシリーズルーターから直接(レイヤー2)到達可能である必要があります。
TLBがルートをインストールすると、そのルート上のすべてのトラフィックがロードバランシングされます。
TLBは、レイヤー3および上位レベルのヘッダーを変更することはありません。
図1 は、透過モードレイヤー2DSRのTLBトポロジーを示しています。
のTLBトポロジー
変換モード
変換モードは、透過モードレイヤー 2 DSR よりも柔軟性が高くなります。変換モードを選択した場合:
MS-MPCは、ネットワーク監視プローブを実行します。
PFE は、ステートレスロードバランシングを実行します。
仮想IPアドレスに送信されたデータトラフィックは、仮想IPアドレスを実サーバーIPアドレスに変換し、仮想ポートをサーバーリスニングポートに変換します。リターントラフィックは逆変換されます。
クライアントから仮想IPへのトラフィックが変換されます。トラフィックは宛先に到達するようにルーティングされます。
サーバーからクライアントへのトラフィックは、暗黙的なフィルターを使用してキャプチャされ、リバース処理のために適切なロードバランシングネクストホップに送られます。変換後、トラフィックはクライアントにルーティングされます。
ロードバランシングには、ランダムとハッシュの2つの方法があります。ランダム方式は UDP トラフィック専用で、quavms-random 配信を提供します。文字通りランダムではありませんが、このモードでは、利用可能なサーバーセットにトラフィックを公平に分散できます。ハッシュ方式は、送信元IPアドレス、宛先IPアドレス、プロトコルの任意の組み合わせに基づいてハッシュキーを提供します。
注:変換モード処理は、IPv4-to-IPv4 および IPv6-to-IPv6 トラフィックでのみ使用できます。
図2 は、変換モードのTLBトポロジーを示しています。
のTLBトポロジー
透過モードレイヤー3ダイレクトサーバーリターン
透過モード レイヤー3DSRロードバランシングは、レイヤー3ホップ離れたサーバーにセッションを分散します。トラフィックは、実サーバーからクライアントに直接返されます。
トラフィックロードバランサー機能
TLBは、以下の機能を提供します。
TLBは常にあらゆるフローの リクエスト を配信します。DSR モードを指定すると、応答はソースに直接返されます。変換モードを指定すると、リバーストラフィックはサーバーに面したインターフェイス上の暗黙的なフィルターを通過して誘導されます。
TLBは、ハッシュベースのロードバランシングまたはランダムロードバランシングをサポートします。
TLBでは、サーバーをオフラインに設定して、既存のすべてのフローのリハッシュによって引き起こされる可能性のあるパフォーマンスへの影響を防ぐことができます。管理ダウン状態のサーバーを追加し、管理ダウン状態を無効にすることで、後でトラフィック配信に使用できます。サーバーをオフラインに設定することで、他のサーバーへのトラフィックへの影響を防ぐことができます。
ヘルスチェックでサーバーがダウンしていると判断されると、影響を受けたフローのみがリハッシュされます。
以前にダウンしたサーバーがサービスに戻ると、ハッシュに基づいてそのサーバーに属するすべてのフローがそのサーバーに戻り、返されたフローのパフォーマンスに影響を与えます。このため、サーバーのアクティブグループへの自動再参加を無効にすることができます。
request services traffic-load-balance real-service rejoin操作コマンドを発行することで、サーバーをサービスに戻すことができます。注:分散フローには NAT は適用されません。
ヘルスチェック監視アプリケーションがMS-MPC/NPU上で実行されます。このネットワークプロセッサユニット(NPU)は、データトラフィックの処理には使用されません。
TLBは、ロードバランシング時の静的なvirtual-IP-adddress-to-real-IP-address変換と静的な宛先ポート変換をサポートします。
TLBは、複数のVRFサポートを提供しています。
トラフィックロードバランサーのアプリケーションコンポーネント
サーバーとサーバーグループ
TLBでは、ステートレスセッション配信の代替宛先として使用する最大255台のサーバーのグループ(構成ステートメントでは リアルサービスと呼ばれています)の設定を可能にします。サーバーグループで使用されるすべてのサーバーは、グループに割り当てる前に個別に設定する必要があります。ロードバランシングでは、セッションの分散にハッシュ化またはランダム化を使用します。ユーザーは、TLBサーバー配布テーブルとの間でサーバーを追加および削除したり、サーバーの管理ステータスを変更したりできます。
TLBは、セッション配信ネクストホップAPIを使用して、サーバー配信テーブルを更新し、統計を取得します。 アプリケーションは、サーバー配布テーブルの管理を直接制御することはできません。TLB APIの追加と削除サービスを通じて、間接的にのみ変更に影響を与えることができます。
サーバーヘルスモニタリング — シングルヘルスチェックとデュアルヘルスチェック
TLBは、TCP、HTTP、SSL Hello、TLS Hello、およびカスタムヘルスチェックプローブをサポートし、グループ内のサーバーの状態を監視します。サーバーグループに単一のプローブタイプを使用することも、2つのプローブタイプを含むデュアルヘルスチェック設定を使用することもできます。設定可能な正常性監視機能は、MX-SPC3 または MS-MPC のいずれかに存在します。デフォルトでは、プローブリクエストは5秒ごとに送信されます。また、デフォルトでは、実サーバーは 5 回連続してプローブが失敗した後にのみダウンが宣言され、5 回連続してプローブが成功した後にのみアップが宣言されます。
カスタムヘルスチェックプローブを使用して、以下を指定します。
-
プローブ応答で予想される文字列
-
プローブとともに送信される文字列
-
プローブがタイムアウトしたときに割り当てるサーバーステータス(アップまたはダウン)
-
プローブに対して予想される応答を受信したときに割り当てるサーバーステータス(アップまたはダウン)
-
プロトコル — UDPまたはTCP
TLBは アプリケーションのスティッキネスを提供するため、サーバーの障害や変更が他のアクティブサーバーへのトラフィックフローに影響を与えません。サーバーの管理状態をアップからダウンに変更しても、サーバー配布テーブル内の残りのサーバーへのアクティブなフローには影響しません。サーバーの追加またはグループからのサーバーの削除は、監視プロファイルの間隔と再試行パラメーターの設定に応じて、一定期間にわたってトラフィックに何らかの影響を与えます。
TLBは、2つのレベルのサーバーヘルス監視を提供します。
-
単一のヘルスチェック—1つのプローブタイプが、
network-monitoring-profile設定ステートメントによってサーバーグループに接続されます。 -
TLB デュアル ヘルス チェック(TLB-DHC)—2 つのプローブ タイプが、
network-monitoring-profile設定ステートメントによってサーバー グループに関連付けられます。サーバーのステータスは、2つのヘルスチェックプローブの結果に基づいて宣言されます。ユーザーは、サーバーグループごとに最大2つのヘルスチェックプロファイルを設定できます。サーバーグループがデュアルヘルスチェック用に設定されている場合、両方のヘルスチェックプローブが同時に稼働している場合にのみ、実サービスが稼働していることが宣言されます。それ以外の場合、実サービスは DOWN と宣言されます。
サーバーの正常性監視に使用される AMS インターフェイスには、以下の制限が適用されます。
-
TLBインスタンスの下で設定されたAMSインターフェイスは、設定された複数の実サーバーのヘルスチェックにのみ、設定されたメンバーインターフェイスを使用します。
-
メンバーインターフェイスは、単一のVRFケースにはユニット0を使用しますが、複数のVRFケースには1以外のユニットを使用できます。
-
TLBは、AMSメンバーインターフェイスに設定されているIPアドレスを、ヘルスチェックの送信元IPアドレスとして使用します。
-
メンバーインターフェイスは、実際のサーバーへの到達に使用するインターフェイスと同じルーティングインスタンスにある必要があります。これは、TLBサーバーのヘルスチェック手順に必須です。
Junos OS リリース 24.2R1 以降、TLS と SSL が同じグループに設定されている場合、実際のサーバーのステータスを判断するために AND ではなく OR メカニズムが使用されるようになりました。つまり、いずれかのプローブが動作している場合、実際のサーバーは UP としてマークされます。以前は、両方のプローブが成功した場合にのみ、実サーバーはアップとしてマークされていました。
SSLプローブバージョンが提供されると、そのバージョンでプローブします。SSLバージョンが指定されていない場合、動作はバージョンv3からv2へのフォールバックに変更されます。プローブはSSLv3で開始します。SSLv3 プローブが失敗した場合、システムは SSLv2 をプローブします。 以前は、バージョン属性が明示的に指定されていない場合、プローブはデフォルトバージョンであるv3で行われていました。
このヘルスチェック動作の強化は、TLSプローブとSSLプローブが同じヘルスチェックグループで構成されている場合にのみ適用されます。
show services traffic-load-balance statistics instance<inst>extensiveの出力が変更されました。
user@host# show services traffic-load-balance statistics instance <inst-name>
Traffic load balance instance name : <inst-name> Multi services interface name : vms-3/0/0 Interface state : UP Interface type : Multi services Route hold timer : 180 Active real service count : 0 Total real service count : 8 Traffic load balance virtual svc name : vs1 IP address : 60.0.0.1 Virtual service mode : Translate mode Routing instance name : fwd_instance_1 Traffic load balance group name : group1 Traffic load balance group warmup time: 15 Traffic load balance group auto-rejoin: TRUE Health check interface subunit : 0 Traffic load balance group down count : 5 Protocol : tcp Port number : 443 Server Listening Port Number : 443 Route metric : 1 Virtual service down count : 5 Traffic load balance hash method : source Network monitoring profile count : 2 Active real service count : 0 Total real service count : 8 Demux Nexthop index : 673 Nexthop index : 674 Down time : 6d 00:01 Total packet sent count : 361749 Total byte sent count : 55165331 Total packet received count : 542636 Total byte received count : 28940680 Network monitoring profile index : 1 Network monitoring profile name : nm_prof_ssl Probe type : SSL-HELLO Probe interval : 2 Probe failure retry count : 5 Probe recovery retry count : 3 Port number : 443 Network monitoring profile index : 2 Network monitoring profile name : nm_prof_tls Probe type : TLS-HELLO Probe interval : 5 Probe failure retry count : 5 Probe recovery retry count : 5 Port number : 443 Traffic load balance real svc name : rs_1 Routing instance name : server_vrf_1 IP address : 40.1.1.2 Traffic load balance group name : group1 Admin state : UP Oper state : UP Network monitoring probe up count : 1 Network monitoring probe down count : 1 Total rejoin event count : 8 Total up event count : 9 Total down event count : 9 Real Service packet sent count : 69804 Real Service byte sent count : 10644724 Real Service packet received count : 104706 Real Service byte received count : 5584336 Total probe sent : 358307 Total probe success : 76 Total probe fail : 358231 Total probe sent failed : 0 Network monitoring profile index : 1 Network monitoring profile name : nm_prof_sslv3 Probe type : SSL-HELLO Probe state : UP SSL probe version : 3 Probe sent : 255933 Probe success : 255879 Probe fail : 54 Probe sent failed : 0 Probe consecutive success : 254635 Probe consecutive fail : 0 Network monitoring profile index : 2 Network monitoring profile name : nm_prof_tls Probe type : TLS-HELLO Probe state : DOWN TLS probe version : 1.2 Probe sent : 102374 Probe success : 22 Probe fail : 102352 Probe sent failed : 0 Probe consecutive success : 0 Probe consecutive fail : 101854
SSL-helloプローブバージョンは、ヘルスチェックプロファイルでSSLバージョンが指定されていない場合、仮想サービスから実際のサーバー統計情報の下に移動されます。
仮想サービス
仮想サービスは、ハッシュベースまたはランダムなセッション配信とサーバーの正常性監視によって決定されるように、トラフィックが送信されるサーバーのグループに関連付けられた仮想IPアドレス(VIP)を提供します。L2 DSRおよびL3 DSRの場合、特殊アドレス0.0.0.0により、転送インスタンスに流れるすべてのトラフィックがロードバランシングされます。
仮想サービス構成には以下が含まれます。
-
モード—トラフィックがどのように処理されるか(変換または透過)を示します。
-
セッションが配信されるサーバーのグループ。
-
ロードバランシング方式。
-
ルーティングインスタンスとルートメトリック。
デフォルトルーティングを使用するには0.0.0.0の仮想アドレスを割り当てることができますが、TLB用に特別に設定されたルーティングインスタンスに割り当てることができる仮想アドレスの使用を推奨します。
トラフィックロードバランサの設定制限
トラフィックロードバランサの設定制限を 表4に示します。
構成コンポーネント |
設定制限 |
|---|---|
最大インスタンス数 |
Junos OSリリース16.1R6およびJunos OSリリース18.2R1以降、TLBアプリケーションは、ダイレクトサーバーリターンまたは変換モードを使用する仮想サービスで2,000TLBインスタンスをサポートします。それ以前のリリースでは、インスタンスの最大数は32です。 複数の仮想サービスが同じサーバーグループを使用している場合、それらの仮想サービスはすべて同じロードバランシング方式を使用して、2,000個のTLBインスタンスをサポートする必要があります。 layer2-direct-server-returnモードを使用する仮想サービスの場合、TLBは32個のTLBインスタンスのみをサポートします。layer2-direct-server-returnモードと同じ機能を実行し、2000TLBインスタンスをサポートするには、direct-server-returnモードを使用し、スキップアクションでサービスフィルターを使用できます。 |
グループあたりの最大サーバー数 |
255 |
サービスPICごとの仮想サービスの最大数 |
32 |
5秒間隔でのサービスPICあたりのヘルスチェックの最大数 |
MS-MPC サービス カードの場合:2000 次世代サービスモードおよびMX-SPC3サービスカードの場合:1250 |
仮想サービスあたりの最大グループ数 |
1 |
仮想サービスごとの仮想IPアドレスの最大数 |
1 |
サポートされているヘルスチェックプロトコル |
ICMP、TCP、HTTP、SSL、TLS-Hello、カスタム
注:
ICMPヘルスチェックは、MS-MPCサービスカードでのみサポートされています。 Junos OSリリース22.4R1以降、TLBはTLS-Helloヘルスチェックタイプをサポートするように拡張されています。TCP を介した TLS-Hello では、TLS v1.2 および v1.3 のヘルスチェックがサポートされています。 |
関連項目
TLBの設定
次のトピックでは、TLBの設定方法について説明します。完全なアプリケーションを作成するには、インターフェイスとルーティング情報も定義する必要があります。オプションでファイアウォールフィルターとポリシーオプションを定義して、TLBトラフィックを区別できます。
- TLBサービスパッケージの読み込み
- TLBインスタンス名の設定
- インターフェイスとルーティング情報の設定
- サーバーの設定
- ネットワーク監視プロファイルの設定
- サーバーグループの設定
- 仮想サービスの設定
- ヘルスチェック監視機能のトレース設定
TLBサービスパッケージの読み込み
TLBを実行する各サービスPICにTLBサービスパッケージをロードします。
次世代サービスおよびMX-SPC3サービスカードの場合、このパッケージを読み込む必要はありません。
サービスPICにTLBサービスパッケージを読み込むには:
jservices-traffic-dirdパッケージを読み込みます。[edit chassis fpc slot-number pic pic-number adaptive-services service-package extension-provider] user@host# set package jservices-traffic-dird
例えば:
[edit chassis fpc 3 pic 0 adaptive-services service-package extension-provider] user@host# set package jservices-traffic-dird
TLBインスタンス名の設定
system processes sdk-service enable を設定してsdkサービスプロセスを有効にします。
TLBインスタンスの名前を設定するには:
-
[edit services traffic-load-balance]階層レベルで、TLBインスタンス名を特定します。[edit services traffic-load-balance] user@host# set instance instance-name
例えば:
[edit services traffic-load-balance] user@host# set instance tlb-instance1
インターフェイスとルーティング情報の設定
インターフェイスとルーティング情報を設定するには:
サーバーの設定
TLBインスタンスのサーバーを設定するには:
[edit services traffic-load-balance instance instance-name] user@host# set real-service real-service-name address server-ip-address
例えば:
[edit services traffic-load-balance instance tlb-instance1] user@host# set real-service rs138 address 172.26.99.138 user@host# set real-service rs139 address 172.26.99.139 user@host# set real-service rs140 address 172.26.99.140
ネットワーク監視プロファイルの設定
ネットワーク監視プロファイルは、セッショントラフィックが配信されるサーバーグループに割り当てるヘルスチェックプローブを設定します。
ネットワーク監視プロファイルを設定するには:
サーバーグループの設定
サーバーグループは、ステートレス、ハッシュベースのセッション配信およびサーバーの正常性監視によってトラフィックが配信されるサーバーで構成されています。
サーバーグループを設定するには:
仮想サービスの設定
仮想サービスは、ハッシュベースまたはランダムなセッション配信とサーバーの正常性監視によって決定されるように、トラフィックが送信されるサーバーのグループに関連付けられたアドレスを提供します。オプションでフィルターとルーティングインスタンスを指定して、TLBのトラフィックを誘導することもできます。
仮想サービスを設定するには:
ヘルスチェック監視機能のトレース設定
ヘルスチェック監視機能のトレースオプションを設定するには:
変更履歴テーブル
サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がお使いのプラットフォームでサポートされているかどうかを確認します。