Traffic Load Balancerの概要
トラフィック負荷分散サポートの概要
表 1 は、アダプティブ サービス向けの MS-MPC および MS-MIC カードでのトラフィック ロードバランシング サポートと、次世代サービス向けの MX-SPC3 セキュリティ サービス カードでのサポートの概要を示しています。
MS-MPC |
MX-SPC3 |
||
|---|---|---|---|
Junos リリース |
< 16.1R6 および 18.2.R1 |
≥ 16.1R6 および 18.2R1 |
19.3R2 |
シャーシあたりのインスタンスの最大数 # |
32 |
2,000 / 32(L2 DSR モード) |
2,000 |
インスタンスあたりの仮想サービスの最大数 # |
32 |
32 |
32 |
仮想サービスあたりの仮想 IP アドレスの最大 # 数 |
|
1 |
1 |
インスタンスあたりのグループの最大数 # |
32 |
32 |
32 |
グループあたりのReal Services(サーバー)の最大# |
255 |
255 |
255 |
仮想サービスあたりの最大グループ数 # |
|
1 |
1 |
グループあたりのネットワーク モニター プロファイルの最大 # |
|
2 |
2 |
5秒のPIC/NPUあたりのセキュリティサービスごとのHCの最大# |
|
4,000 |
1,250 - 19.3 R2 10,000 – 20.1R1 |
サポートされているヘルスチェックプロトコル |
ICMP、TCP、UDP、HTTP、SSL、カスタム |
ICMP、TCP、UDP、HTTP、SSL、TLS こんにちは、カスタム |
|
トラフィック・ロード・バランサー・アプリケーションの説明
トラフィックロードバランサー(TLB)は、 表2に示すように、マルチサービスモジュラーポートコンセントレータ(MS-MPC)、マルチサービスモジュラーインターフェイスカード(MS-MIC)、またはMXセキュリティ サービスプロセシングカード(MX-SPC3)のいずれかを搭載したMXシリーズルーターでサポートされ、モジュラーポートコンセントレータ(MPC)ラインカードと組み合わせてMXシリーズルーターでサポートされます。
確定的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 アドレスへの静的変換と、ロードバランシング中の静的宛先ポート変換をサポートします。
トラフィックロードバランサーの動作モード
Traffic Load Balancer には、送信トラフィックの分散とリターントラフィックの処理の 3 つの操作モードがあります。
表 3 は、TLB のサポートとサポートされているカードをまとめたものです。
セキュリティサービスカード |
MS-MPC |
MX-SPC3 |
|---|---|---|
翻訳 |
はい |
はい |
透過的なレイヤー 3 ダイレクト サーバー リターン |
はい |
はい |
透過的なレイヤー 2 ダイレクト サーバー リターン |
はい |
サポートされていません |
透過モード レイヤー 2 ダイレクト サーバー リターン
透過モードのレイヤー2ダイレクトサーバーリターン(DSR)を使用する場合:
PFE はデータを処理します。
ロードバランシングは、パケットのレイヤー2 MACを変更することで機能します。
MS-MPC は、ネットワーク監視プローブを実行します。
実サーバーは、MXシリーズルーターから直接(レイヤー2)到達可能である必要があります。
TLBがルートをインストールすると、そのルート上のすべてのトラフィックがロードバランシングされます。
TLB がレイヤー 3 以上のヘッダーを変更することはありません。
図 1 は、透過モード レイヤー 2 DSR の TLB トポロジーを示しています。
のTLBトポロジー
変換モード
変換モードは、透過モードのレイヤー2 DSRよりも柔軟性に優れています。翻訳モードを選択した場合:
MS-MPC は、ネットワーク監視プローブを実行します。
PFE はステートレスなロードバランシングを実行します。
仮想IPアドレスに向けられたデータトラフィックは、仮想IPアドレスから実サーバIPアドレスに変換され、仮想ポートがサーバリスニングポートに変換されます。リターントラフィックは逆変換されます。
クライアントから仮想 IP へのトラフィックが変換されます。トラフィックは宛先に到達するようにルーティングされます。
サーバーからクライアントへのトラフィックは、暗示的フィルタを使用してキャプチャされ、リバース処理のために適切な負荷分散ネクストホップに送られます。変換後、トラフィックはクライアントにルーティングされます。
ロードバランシングには、ランダムとハッシュの 2 つの方法があります。random 方式は UDP トラフィック専用で、quavms-random 分散を提供します。このモードでは、文字通りランダムではありませんが、利用可能なサーバーのセットにトラフィックを公平に分散できます。ハッシュ方式は、送信元 IP アドレス、IP アドレス、およびプロトコルの任意の組み合わせに基づくハッシュ鍵を提供します。
手記：変換モード処理は、IPv4からIPv4およびIPv6からIPv6へのトラフィックでのみ使用できます。
図 2 は、変換モードの TLB トポロジーを示しています。
のTLBトポロジー
透過モード レイヤー 3 ダイレクト サーバー リターン
透過モードのレイヤー3 DSRロードバランシングは、レイヤー3ホップ離れたサーバーにセッションを分散します。トラフィックは、実サーバからクライアントに直接返されます。
トラフィックロードバランサー機能
TLB は、以下の機能を提供します。
TLB は、どのフローに対しても常に リクエスト を配信します。DSR モードを指定すると、応答はソースに直接返されます。変換モードを指定すると、リバーストラフィックはサーバーに接続するインターフェイス上の暗黙的なフィルターを介して誘導されます。
TLB は、ハッシュベースのロードバランシングまたはランダムロードバランシングをサポートします。
TLB を使用すると、サーバーをオフラインで構成して、既存のすべてのフローの再ハッシュによって引き起こされる可能性のあるパフォーマンスへの影響を回避できます。管理ダウン状態のサーバーを追加し、管理ダウン状態を無効にすることで、後でトラフィック分散に使用できます。サーバーをオフラインで構成すると、他のサーバーへのトラフィックの影響を防ぐことができます。
ヘルスチェックでサーバーがダウンしていると判断された場合、影響を受けたフローのみが再ハッシュされます。
以前にダウンしたサーバーがサービスに戻ると、ハッシュに基づいてそのサーバーに属するすべてのフローがそのサーバーに戻り、返されたフローのパフォーマンスに影響を与えます。このため、アクティブグループへのサーバーの自動再参加を無効にすることができます。
request services traffic-load-balance real-service rejoin操作コマンドを発行することで、サーバをサービスに戻すことができます。手記：分散フローにNATは適用されません。
ヘルスチェック監視アプリケーションは、MS-MPC/NPU上で動作します。このネットワークプロセッサユニット(NPU)は、データトラフィックの処理には使用されません。
TLBは、仮想IPアドレスから実際のIPアドレスへの静的変換と、ロードバランシング時の静的宛先ポート変換をサポートしています。
TLB は複数の VRF サポートを提供します。
Traffic Load Balancerアプリケーションのコンポーネント
サーバーとサーバー グループ
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):
network-monitoring-profile設定ステートメントによって、2 つのプローブタイプがサーバーグループに関連付けられます。サーバーのステータスは、2 つのヘルスチェックプローブの結果に基づいて宣言されます。ユーザーは、サーバーグループごとに最大 2 つのヘルスチェックプロファイルを設定できます。サーバ グループがデュアル ヘルス チェック用に設定されている場合、両方のヘルス チェック プローブが同時に UP の場合にのみ、実際のサービスが UP として宣言されます。それ以外の場合、実際のサービスは DOWN であると宣言されます。
サーバーの正常性モニタリングに使用される AMS インターフェイスには、次の制限が適用されます。
-
TLB インスタンスの下に設定された AMS インターフェイスは、設定された複数の実サーバーのヘルスチェックにのみ、設定されたメンバーインターフェイスを使用します。
-
メンバー インターフェイスは、単一の VRF のケースではユニット 0 を使用しますが、複数の VRF のケースでは 1 以外のユニットを使用できます。
-
TLB は、AMS メンバー インターフェイスに設定された IP アドレスをヘルス チェックの送信元 IP アドレスとして使用します。
-
メンバーインターフェイスは、実サーバーへの到達に使用されるインターフェイスと同じルーティング インスタンスにある必要があります。これは、TLB サーバーのヘルスチェック手順に必須です。
Junos OS リリース 24.2R1 以降、TLS と SSL が同じグループで設定されている場合、実サーバのステータスを判断するために AND ではなく OR メカニズムが使用されるようになりました。つまり、プローブのいずれかが動作している場合、実サーバは UP としてマークされます。以前は、両方のプローブが成功した場合にのみ、実サーバは UP とマークされていました。
SSL プローブ・バージョンが提供されると、そのバージョンでプローブします。SSL バージョンが指定されていない場合、動作はバージョン v3 から v2 へのフォールバックに変更されます。プローブは SSLv3 で開始します。SSLv3 プローブが失敗すると、システムは SSLv2 をプローブします。 以前は、version 属性が明示的に指定されていない場合、プローブはデフォルト バージョン 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バージョンが指定されていない場合、SSL-helloプローブバージョンは仮想サービスから実サーバ統計情報の下に移動されます。
仮想サービス
仮想サービスは、ハッシュベースまたはランダムなセッション配信とサーバー正常性監視によって決定される、トラフィックが送信されるサーバーのグループに関連付けられた仮想 IP アドレス (VIP) を提供します。L2 DSR と L3 DSR の場合、特別なアドレス 0.0.0.0 により、転送インスタンスに流れるすべてのトラフィックがロード バランシングされます。
仮想サービス構成には、次のものが含まれます。
-
モード—トラフィックの処理方法(変換済みまたは透過的)を示します。
-
セッションが配布されるサーバーのグループ。
-
ロードバランシング方式です。
-
ルーティングインスタンスとルートメトリック。
デフォルト ルーティングを使用するために 0.0.0.0 の仮想アドレスを割り当てることもできますが、TLB 専用に設定されたルーティング インスタンスに割り当てることができる仮想アドレスを使用することをお勧めします。
トラフィックロードバランサの設定制限
Traffic Load Balancer の設定制限については、 表 4 を参照してください。
構成コンポーネント |
設定制限 |
|---|---|
最大インスタンス数 |
Junos OS リリース 16.1R6 および Junos OS リリース 18.2R1 以降、TLB アプリケーションは、direct-server-return または translated モードを使用する仮想サービスで 2,000 TLB インスタンスをサポートします。以前のリリースでは、インスタンスの最大数は 32 です。 複数の仮想サービスが同じサーバ グループを使用している場合、それらの仮想サービスはすべて、2000 TLB インスタンスをサポートするために同じロードバランシング方法を使用する必要があります。 layer2-direct-server-return モードを使用する仮想サービスの場合、TLB は 32 個の TLB インスタンスのみをサポートします。layer2-direct-server-return モードと同じ機能を実行し、2000 個の TLB インスタンスをサポートするには、direct-server-return モードを使用し、skip アクションでサービス フィルターを使用します。 |
グループあたりの最大サーバー数 |
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ヘルスチェックがサポートされています。 |
変更履歴
サポートされる機能は、使用しているプラットフォームとリリースによって決まります。特定の機能がお使いのプラットフォームでサポートされているかどうかを確認するには、 Feature Explorer を使用します。