このセクションでは、コントローラのシステム キャパシティについて説明します。

コントローラのシステム キャパシティを指定する

コントローラの展開時に、CPU、メモリ (RAM)、ディスクなどのシステム リソースの割り当てに基づいてシステム キャパシティを指定できます。割り当てられたこれらのリソースの量がパフォーマンスに直接影響します。

次の表に、展開のタイプごとに推奨される割り当てを示します。

展開タイプ

ノード数

推奨される割り当て - CPU

推奨される割り当て - メモリ

推奨される割り当て - ディスク

デモ/ユーザー評価

1

6

24 GB

128 GB

本番

3

以下の「CPU/メモリの割り当て」セクションを参照
デモと評価展開では、単一のコントローラが適切で、すべての制御プレーンのアクティビティとワークフロー、および分析に使用されます。

本番環境では、3 ノード クラスタを推奨します。3 ノードの Controller クラスタでは、1 つのコントローラが制御プレーンのアクティビティとワークフローに使用されるリーダーで、その他の 2 つはフォロワーです。フォロワー ノードは分析に使用されます。また、リーダーに障害が発生した場合にバックアップを提供します。

次のセクションでは特定の割り当てに対する推奨事項について説明します。これらの推奨事項は、ほとんどのユースケースに適合するように設計されていますが、考えられるすべての展開シナリオに適合するとは限りません。

注：

ホストの CPU とメモリの割り当てが増えるたびに、avicontroller.service ファイルが自動的に更新されることはありません。これらの値が変更されるたびに、avicontroller.service ファイルを手動で更新する必要があります。

CPU を変更するパラメータは -cpu-quota です。

CPU/メモリの割り当て

NSX Advanced Load Balancer は、次のように CPU とメモリの割り当てを使用します。

CPU/メモリ割り当て

Essentials（4 個の CPU/24 GB）

小（6 個の CPU/24 GB）

中（10 個の CPU/32 GB）

大（16 個の CPU/48 GB）

基本プロセス

15 GB

15 GB

19 GB

24 GB

ログ分析

9 GB

9 GB

13 GB

24 GB

SE スケール

0 ～ 10

0 ～ 100

100 ～ 200

200 ～ 400

コントローラの基本プロセスには、動的なプロセスとメトリックの収集/処理が含まれます。ここに示す割り当ては、10% 以下のディスク スワップと 25% のディスク マージンを前提としています。

注：

  • Essentials Controller のサイズは、NSX Advanced Load Balancer リリース 20.1.5 以降でサポートされます。ただし、VMware Tanzu ソリューションを使用して ESSENTIALS ライセンス層に展開され、VMware 環境でオンプレミスで実行されている Controller にのみ使用できます。詳細については、「システム制限」をクリックしてください。

  • Essentials Controller は、最大 100 個の仮想サービスをサポートできます。その他の Controller サイズのスケール制限の詳細については、『VMware 構成の上限』ガイドを参照してください。

  • NSX Advanced Load Balancer バージョン 22.1.3 以降では、Essentials Controller のメモリの最小要件は 24 GB に適用されます。22.1 リリースの任意のバージョンへのアップグレードを開始する前に、Essentials Controller のメモリを 24 GB に増やすことをお勧めします。

  • NSX Advanced Load Balancer バージョン 22.1.2 以降では、Essentials Controller のメモリの最小要件は 16 GB に適用されます。これは、NSX Advanced Load Balancer バージョン 22.1.1 のソフト制限でした。22.1 リリースの任意のバージョンへのアップグレードを開始する前に、Essentials Controller のメモリを 16 GB に増やすことをお勧めします。

  • vCenter Server のホット アド機能を使用してコントローラ仮想マシンの CPU/メモリを拡張する機能はありません。

ディスク容量の割り当て

コントローラに割り当てるディスク容量は、次のパラメータに基づいて計算されます。

  • コントローラで使用可能なディスク容量。

  • サポートする仮想サービスの数

注：

デフォルトのコントローラ OVA テンプレートは 128 GB に増やす必要があります。同じクラスタ内のコントローラはすべて、同一/類似のディスク容量を持つ必要があります。サイズが大幅に異なる割り当てを長期間使用することはできません。

次の表は、各アプローチに基づく推奨割り当てを示しています。

使用可能なディスク容量に基づくディスクの割り当て

基本プロセスまたは分析に使用されないコントローラに割り当てられたディスク容量は、次のように使用されます。

  • ログ：基本プロセスまたは分析に使用されていないディスクの 70%。

  • メトリック：基本プロセスまたは分析に使用されないその他の 30%。

ディスク容量に基づくディスク割り当て

128 GB

256 GB

512 GB

1 TB

ログ分析 (70%)

56 GB

144 GB

328 GB

672 GB

メトリック (30%)

24 GB

64 GB

128 GB

288 GB

基本プロセス

48 GB

48 GB

56 GB

64 GB
ディスク ドライブの品質は、分析のパフォーマンスとサイズに影響します。

  • ディスク ドライブの容量がいっぱいになると、トラフィック ログは削除されます。

  • メトリック テーブルは、アーカイブ スキームに基づいて削除されます。

    • リアルタイム：1 時間後に削除

    • 5 分間隔：1 日後に削除

    • 1 時間間隔：1 週間後に削除

    • 1 日間隔：1 年後に削除

ドライブがいっぱいになると、現在のメトリック テーブルは削除され、新しいデータ用の空き容量が作り出されます。

仮想サービス数に基づくディスク割り当て

VS 数に基づくディスク割り当て

完全なログなしのログ分析

完全なログ付きのログ分析

メトリック

基本プロセス

合計 (完全なログなし)

100 VS

16 GB

128 GB

16 GB

48 GB

80 GB

1,000 VS（100,000 トランザクション/年）

128 GB

1 TB

32 GB

56 GB

216 GB

5,000 VS

512 GB

サポート対象外

160 GB

64 GB

736 GB

LSC のメトリック DB 計算

仮想マシン フォーム ファクタの場合、メトリックの割り当ては、仮想マシンに指定されたディスクのサイズに基づいて自動的に計算されます。ただし、LSC コンテナ フォーム ファクタの場合、DISK_GB 環境変数を使用してメトリックの割り当て容量を計算します。

メトリック DB サイズは、ファイル /etc/systemd/system/avicontroller.service の環境変数に基づいて自動的に計算されます。ここで、disk_size = 30 GB（デフォルト）は、メトリック DB サイズ (30%) に対して 8.38 GB の割り当てです。

Controller コンテナから次のように正しいメトリック DB サイズを取得するには、python3 /opt/avi/python/lib/avi/util/disk_usage.py -m を実行します。

Metric_DB がいっぱいの場合は、ディスク サイズを HOST ファイルから/etc/systemd/system/avicontroller.service (DISK_GB = 30) に増やし、HOST で daemon-reload を再ロードして、metric_db 割り当てを増やします。

#systemctl daemon-reload
#systemctl restart avicontroller.service

前提条件とサイジング データ

この表に示すサイズの推奨値は、次の運用上の前提条件に基づいています。

  • DDoS 攻撃がトラフィックの 1% 未満であること。

  • 重要なログがログの合計の 10% 以下であること。（トランザクションの 90% が良好で、重要でないログのみを生成している。）

  • ログ分析で、ログの 1 エントリあたり約 10 KB のディスク容量、つまりログ エントリ 100 万に対して 10 GB のディスク容量が必要。

  • メトリックなどの分析処理に、1 仮想サービスあたり約 32 MB が必要。クライアント情報には、追加のドライブ容量が必要です。

注：

トランザクションは、単一の TCP または UDP 接続（レイヤー 4）または単一の要求と応答の交換（レイヤー 7）です。E コマース サイトで年間 100,000 件のトランザクションのトラフィック量はおそらく少ない方ですが、他のほとんどのタイプのアプリケーションに当てはまります。