このセクションでは、同時接続数や HTTP キャッシュなどの機能に割り当てられるメモリ量を見積もるための、サービス エンジン (SE) 内のメモリ使用率の計算について説明します。
SE は 2 ～ 256 GB のメモリをサポートします。NSX Advanced Load Balancer に推奨される最小メモリは 2 GB です。より多くのメモリを提供すると、キャパシティのスケールが大幅に増加し、同時接続と最適化されたパフォーマンス バッファの間でメモリの優先順位が調整されます。
書き込みアクセス モードの NSX Advanced Load Balancer SE 展開のメモリ割り当ては、 によって構成されます。サービス エンジンごとのメモリ プロパティの変更は新しく作成された SE にのみ影響します。読み取りモードまたはアクセス権なしモードの場合、メモリは vCenter Server などのリモートの Orchestrator で構成されます。既存の SE に変更を加える場合は、変更の前に SE をパワーオフする必要があります。
メモリの割り当て
次の表に、SE のメモリ割り当ての詳細を示します。
Base |
500 MB |
SE（Linux および基本的な SE 機能）をオンにするために必要です。 |
ローカル |
100 MB/コア |
vCPU コアごとに割り当てられたメモリ。 |
共有 |
残りのメモリ |
残りのメモリは、接続とバッファの間で分割されます。 |
接続は、TCP、HTTP、および SSL 接続テーブルで構成されます。接続に割り当てられたメモリは、SE が維持できる同時接続数の合計に直接影響します。
バッファは、アプリケーション レイヤのパケット バッファで構成されます。これらのバッファは、パケットをキューに入れてネットワーク パフォーマンスを向上させるために、レイヤー 4 ～ 7 で使用されます。たとえば、クライアントが 1 Mbps の遅延の大きい NSX Advanced Load Balancer SE に接続され、サーバが遅延のない 10 Gbps スループットの SE に接続されている場合、サーバは応答全体を送信してクライアント クエリに応答し、次のクライアント要求の処理に進むことができます。SE は応答をバッファリングし、大幅に低い速度でクライアントに送信して、サーバを中断することなく再送信を処理します。このメモリ割り当てには、HTTP キャッシュや強化された圧縮などのアプリケーション中心の機能も含まれます。
バッファは、接続の優先順位を変更することで同時接続数を最大化します。NSX Advanced Load Balancer の計算は、デフォルトの設定に基づいて行われ、共有メモリの 50% を接続に割り当てます。
同時接続数
アプリケーション提供コントローラ (ADC) ベンチマークのほとんどの数値は、client IP:port がサーバ IP:port にマッピングされた単純なメモリ テーブルを使用する同等の TCP 高速パスに基づいています。TCP 高速パスは使用するメモリが非常に少なく、非常に多くの同時接続数を可能にしますが、TCP およびアプリケーション レイヤーのプロキシに依存する実世界の展開の大部分には関係ありません。NSX Advanced Load Balancer ベンチマークの数値は、完全な TCP プロキシ (L4)、バッファリングと DataScript による基本的なキャッシュを備えた TCP と HTTP プロキシ (L7)、およびクライアントと NSX Advanced Load Balancer 間のトランスポート レイヤー セキュリティ プロトコル (TLS) 1.2 を使用した同じシナリオに基づいています。
以下に示す接続ごとのメモリ消費量は、これより大きくなる場合もあれば、小さくなる場合もあります。たとえば、一般的なバッファリングされた HTTP 要求ヘッダーは 2 KB のメモリを消費しますが、消費量は 48 KB に達する場合もあります。以下の数値は、実際のサイズ設定ガイドラインを提供することを目的としています。
接続あたりのメモリ消費量：
10 KB L4
20 KB L7
40 KB L7 + SSL（RSA または ECC）
SE の潜在的な同時接続数を計算するには、次の式を使用します。
Concurrent L4 connections = ((SE memory - 500 MB - (100 MB * number of vCPU)) * Connection Percent) / Memory per Connection
((8000 - 500 - ( 100 * 8 )) * 0.50) / 0.01 = 335k。
1 vCPU |
4 個の vCPU |
32 個の vCPU |
|
|---|---|---|---|
1 GB |
36k |
NA |
NA |
4 GB |
306k |
279k |
NA |
32 GB |
2.82m |
2.80m |
2.52m |
CLI を使用した割り当ての表示
show serviceengine <SE Name> memdist コマンドは、SE のメモリ分布の内訳を切り詰めて表示します。SE には、共有メモリの接続テーブルに 141 MB が割り当てられた 1 つの vCPU コアがあります。huge_pages の値 91 は、91 ページがそれぞれ 2 MB であることを意味します。これは、共有メモリの HTTP キャッシュ テーブルに 182 MB が割り当てられていることを示します。
[admin:grr-ctlr2]: > show serviceengine 10.110.111.10 memdist +-------------------------+-----------------------------------------+ | Field | Value | +-------------------------+-----------------------------------------+ | se_uuid | 10-217-144-19:se-10.217.144.19-avitag-1 | | proc_id | C0_L4 | | huge_pages | 2353 | | clusters | 1900544 | | shm_memory_mb | 398 | | conn_memory_mb | 4539 | | conn_memory_mb_per_core | 1134 | | num_queues | 1 | | num_rxd | 2048 | | num_txd | 2048 | | hypervisor_type | 6 | | shm_conn_memory_mb | 238 | | os_reserved_memory_mb | 0 | | shm_config_memory_mb | 160 | | config_memory_mb | 400 | | app_learning_memory_mb | 30 | | app_cache_mb | 1228 | +-------------------------+-----------------------------------------+ [admin:grr-ctlr2]: >
コード |
説明 |
|---|---|
クラスタ |
SE 用に予約されたパケット バッファ (mbufs) の合計数。 |
|
SE 用に予約された共有メモリの合計量。 |
|
接続用にヒープから予約されたメモリの合計量。 |
|
コアあたりの接続（ |
|
接続用に予約された共有メモリから予約されたメモリの量。 |
|
NIC キュー ペアの数。 |
|
RX 記述子の数。 |
|
TX 記述子の数。 |
|
SE 以外のデータパス プロセス用に予約されている追加メモリの量。 |
|
構成用に予約された共有メモリから予約されたメモリの量。 |
|
構成用にヒープから予約されたメモリの量。 |
hypervisor_type は、次のハイパーバイザー タイプのリストと、それに関連付けられているそれぞれの値を示します。
ハイパーバイザー タイプ |
値 |
|---|---|
|
0 |
|
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
API を使用した割り当ての表示
接続テーブルに割り当てられている合計メモリと使用中の割合を表示できます。次のコマンドを使用して、API をクエリします。
https://<IP Address>/api/analytics/metrics/serviceengine/se-<SE UUID>?metric_id=se_stats.max_connection_mem_total は、接続テーブルで使用可能なメモリの容量の合計を返します。次の応答スニペットでは、141 MB が割り当てられています。
"statistics": {
"max": 141,
}
https://<IP Address>/api/analytics/metrics/serviceengine/se-<SE UUID>?metric_id=se_stats.avg_connection_mem_usage&step=5 は、クエリされた期間内に使用されたメモリの平均割合を返します。以下の結果スニペットでは、メモリの 5% が使用中でした。
"statistics": {
"min": 5,
"max": 5,
"mean": 5
},
共有メモリ キャッシュ
サービス エンジンのプロパティの app_cache_percent フィールドを使用して、レイヤー 7 キャッシュ用の SE メモリの割合を予約できます。デフォルト値は 0 です。これは、NSX Advanced Load Balancer がオブジェクトをキャッシュしないことを意味します。これは、SE の起動に影響を与えるプロパティであるため、構成後に SE の再起動が必要です。
仮想サービス アプリケーション プロファイルのキャッシュが有効になっている場合、NSX Advanced Load Balancer を以前のバージョンからアップグレードすると、このフィールドは自動的に 15 に設定されるため、SE メモリの 15% がキャッシュ用に予約されます。この値は割合の構成であり、絶対的なメモリ サイズではありません。
機能を構成したら、SE を再起動して構成を有効にします。
キャッシュ用に割り当てられたメモリの合計は、コアあたり 1 GB 以上の割り当てという条件を満たす必要があります。app_cache_persent がこの条件を超えると、割り当てられたメモリはシステム メモリの合計の % 未満になります。
たとえば、アプリケーション キャッシュ メモリ = 合計メモリ - コア数*1 GB となります。
10 GB、9 コア SE の場合、15 % の app_cache_percent は 1.5 GB ではなく 1 GB になります。
CLI を使用した構成
次のコマンドを入力して、app_cache_percent を構成します。
[admin:cntrlr]: > configure serviceenginegroup Serviceenginegroup-name [admin:cntrlr]: serviceenginegroup> app_cache_percent 30 Overwriting the previously entered value for app_cache_percent [admin:cntrlr]: serviceenginegroup> save
ユーザー インターフェイスを使用した構成
この機能は、NSX Advanced Load Balancer ユーザー インターフェイスを使用して有効にできます。 に移動し、目的の SE グループの編集アイコンをクリックします。[基本設定] タブの [メモリ割り当て] セクションで、レイヤー 7 キャッシュ用に予約される値を [キャッシュ用メモリ] フィールドに入力します。
コア ファイル サイズを減らす
次の新しいフィールドが導入され、一部のセクションがコアに含まれないように除外するのに役立ちます。
core_shm_app_learning：コア ファイルにアプリケーション学習用の共有メモリを含めます。core_shm_app_cache：コア ファイルにアプリケーション キャッシュ用の共有メモリを含めます。
デフォルトでは、これらのオプションは False に設定されています。次のコマンドを使用して、core_shm_app_learning および core_shm_app_cache オプションを有効にします。
[admin:cntrlr]: serviceenginegroup> core_shm_app_learning Overwriting the previously entered value for core_shm_app_learning [admin:cntrlr]: serviceenginegroup> core_shm_app_cache Overwriting the previously entered value for core_shm_app_cache [admin:cntrlr]: serviceenginegroup> save
この構成を有効にするには、SE を再起動します。
仮想サービス レベルごとのアドミッション コントロール
仮想サービスでの受信要求への接続拒否
特定の仮想サービスの接続拒否は、その仮想サービスによるパケット バッファの消費量が多いことが原因である可能性があります。
仮想サービスのパケット バッファ使用率がパケット バッファの合計の 70% を超えると、接続拒否が開始されます。そのため、クライアントの速度が低下し、仮想サービスでパケット バッファが蓄積されます。
この問題を軽減するには、SE ごとに割り当てられるメモリを増やすか、ネットワーク セキュリティ ポリシーを使用して低速なクライアントによる要求を特定してその数を制限します。
仮想サービス レベルごとのアドミッション コントロールは、デフォルトで無効になっています。この設定を有効にするには、[サービス エンジン グループ] オプション per_vs_admission_control を True に設定します。
[admin Controller]: > configure serviceenginegroup <name-of-the-SE-group> [admin Controller]: serviceenginegroup> per_vs_admission_control Overwriting the previously entered value for per_vs_admission_control [admin Controller]: serviceenginegroup> save | per_vs_admission_control | True |
仮想サービスのパケット バッファ消費量が 50% に低下すると、接続拒否が停止します。生成されたサンプル ログには、アドミッション コントロールが表示されます。
C255 12:46:28.774900 [se_global_calculate_per_vs_mbuf_usage:1561] Packet buffer usage for the Virtual Service: 'vs-http' UUID: 'virtualservice-e20cfff1-173f-4f4c-9028-4ae544116191' has breached the threshold 70.0%, current value is 71.8%. Starting admission control. C255 12:49:01.285088 [se_global_calculate_per_vs_mbuf_usage:1575] Packet buffer usage for the Virtual Service: 'vs-http' UUID: 'virtualservice-e20cfff1-173f-4f4c-9028-4ae544116191' is below the threshold 50.0%, current value is 46.7%. Stopping admission control.
アドミッション コントロールによる接続拒否とパケット スロットルは、se_stats metrics API を使用してモニタリングできます。
https://<Controller-IP>/api/analytics/metrics/serviceengine/se-<SE-UUID>?metric_id=se_stats.sum_connection_dropped_packet_buffer_stressed,se_stats.sum_packet_dropped_packet_buffer_stressed
トラフィック量の増加に関連付けられた NSX Advanced Load Balancer SE での断続的な接続拒否を解決する方法については、「NSX Advanced Load Balancer サービス エンジンで確認された受信要求への接続拒否」を参照してください。
