NSX Advanced Load Balancer Controller Sizing

Overview

This guide explains the system capacity of NSX Advanced Load Balancer Controller.

Specifying System Capacity of the Controller

During deployment of the Controller, the system capacity of the Controller can be specified based on allocations of the following system resources:

• CPUs
• Memory (RAM)
• Disk

The amount of these resources allocated to the Controller have a direct impact on its performance.

The following table lists recommended allocations for each type of deployment:

In demonstration and deployments, a single Controller is adequate and is used for all control-plane activities and workflows, as well as analytics.

In a production deployment, a 3-node cluster is recommended. In a 3-node Controller cluster, one Controller is the leader and is used for control-plane activities and workflows. The other two Controllers are followers. The follower Controller nodes are used for analytics. The follower Controller nodes also provide backup if the leader Controller fails.

The following sections provide specific allocation recommendations. The recommendations are designed to fit most use cases, but might not fit every conceivable deployment scenario.

Allocating CPU/ Memory

NSX Advanced Load Balancer uses the allocations of CPU and memory as follows:

The Controller’s base processes include dynamic processes and metrics collection and processing. The allocations shown here are based on assumptions of no more than 10 percent disk swapping and 25 percent disk margin.

Notes:

• The Essentials Controller size is supported starting with NSX Advanced Load Balancer release 20.1.5. But, it can only be used for a Controller deployed in the ESSENTIALS license tier in conjunction with VMware Tanzu solutions and running on-premises in a VMware environment. For more information, click System Limits.

• Essential controller can support up to 100 Virtual services. For details on scale limits for other controller sizes, refer VMware Configuration Limits guide.

• Starting with NSX Advanced Load Balancer version 22.1.3, the minimum requirement for memory of essentials Controller is enforced at 24GB. It is recommended to increase the memory of essential Controllers to 24GB before starting upgrade to any version of 22.1 release.

• Starting with NSX Advanced Load Balancer version 22.1.2, the minimum requirement for memory of essentials Controller is enforced at 16GB which was soft limit with NSX Advanced Load Balancer version 22.1.1. It is recommended to increase the memory of essential Controllers to 16GB before starting upgrade to any version of 22.1 release.

• There is no capability for vCenter’s hot-add feature to expand the Controller virtual machine’s CPU/ memory.

Allocating Disk Capacity

The amount of disk capacity to allocate to the Controller is calculated based on the following parameters:

• The amount of disk capacity available on the Controller
• The number of virtual services to support.

Notes:

• The default Controller OVA template should be increased to 128 GB.

• The Controllers in the same cluster should all have the same/ similar disk capacity. Allocations of significantly different sizes should not be permitted for prolonged periods of time.

The following tables show recommended allocations based on each approach.

Allocating Disk based on available Disk Capacity

The disk space allocated to the Controller that is not used for base processes or analytics is used as follows:

• Logs: 70 percent of the disk that is not used for base processes or analytics.
• Metrics: the other 30 percent that is not used for base processes or analytics.

Disk drive quality impacts analytics performance and size:

• Traffic logs are deleted as the disk drive fills up.
• Metrics tables are deleted based on the archival scheme:
  • Realtime: deleted after 1 hour
  • 5-minute intervals: deleted after 1 day
  • 1-hour intervals: deleted after 1 week
  • 1-day intervals: deleted after 1 year

If the drive fills up, then current metrics tables are deleted to make room for new data.

Allocating Disk based on Number of Virtual Services

Metric DB Calculation in LSC

For the virtual machine form factor, the metrics quota is calculated automatically based on the size of the disk given to the virtual machine. However, for the LSC Container form factor, DISK_GB environment variable is used to calculate the quota for metrics.

The metric DB size auto calculates based on environment variable from file /etc/systemd/system/avicontroller.service where, disk_size = 30 GB (default) which is 8.38 GB allocation for Metric DB size (30%)

To get the correct metric DB size from the Controller container as follows: python3 /opt/avi/python/lib/avi/util/disk_usage.py -m

If Metric_DB is full, increase the disk size from HOST file to /etc/systemd/system/avicontroller.service (DISK_GB=30) and reload the daemon-reload on the HOST to increase metric_db quota.

#systemctl daemon-reload
#systemctl restart avicontroller.service

Assumptions and Sizing Data

The size recommendations shown in the table are based on the following operational assumptions:

• DDoS attacks are less than one percent of the traffic.
• Significant logs are no more than 10 percent of total logs. (This means 90 percent of the transactions are good and result only in non-significant logs.)
• Log analytics require about 10 kB disk space per log entry, i.e., 10 GB of disk space for 1 million log entries.
• Metrics and other analytics processing requires about 32 MB per virtual service. Client insights require additional drive capacity.

Note: A transaction is a single TCP or UDP connection (layer 4), or a single request-response exchange (layer 7). Traffic volume of 100,000 transactions per year is probably low for an e-commerce site but is applicable to most other types of applications.

Additional Information

FAQ on NSX Advanced Load Balancer Controller cluster.

Document Revision History