This section explains the system capacity of the Controller.

Specifying System Capacity of Controller

While deploying a Controller, you can specify its system capacity based on resource allocation like CPU, memory (RAM), and disk. The amount of these resources allocated has a direct impact on its performance.

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

Deployment Type

Node Count

Recommended Allocations - CPU

Recommended Allocations -Memory

Recommended Allocations - Disk

Demo / Customer Eval

1

8

24 GB

128 GB

Production

3

See Allocating CPU/Memory and Drive Allocation section

Note:

A new classification of Controller is made available as Essentials. This new Controller size is applicable only to deployments with VMware Tanzu and with the controller running on-premises in VMware environment. For more information, see System Limits.

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

In a production deployment, it is recommended to use a three-node cluster. In a three-node Controller cluster, one Controller is the leader used for control-plane activities and workflows, while the other two are followers. The follower nodes are used for analytics. They also provide backup in case the leader fails.

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

Allocating CPU/Memory

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

CPU/Memory Allocation

4 CPUs / 12 GB

8 CPUs / 24 GB

16 CPUs / 32 GB

24 CPUs / 48 GB

Base processes

11 GB

15 GB

20 GB

24 GB

Log analytics

1 GB

9 GB

13 GB

24 GB

Virtual Service Scale

0-50

0-200

200-500

500-5000

SE Scale

0-10

0-100

100-200

200-400

The base processes of the Controller includes dynamic processes, metrics collection and processing. The above allocations are based on assumptions of no more than ten percent disk swapping and twenty-five percent disk margin.
Note:

The hot-add feature of vCenter does not have the capability to expand the CPU or memory of the Controller virtual machine.

Allocating Disk Capacity

The amount of disk capacity allocated 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.

Note:
  • The default Controller OVA template must be increased to 128 GB.

  • Controllers in the same cluster must have similar disk capacity. Allocations of significantly different sizes must 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 a Controller that is not used for base processes or analytics, is utilized 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 Allocation based on Disk Space

128 GB

256 GB

512 GB

1 TB

Log analytics (70%)

56 GB

144 GB

328 GB

672 GB

Metrics (30%)

24 GB

64 GB

128 GB

288 GB

Base Processes

48 GB

48 GB

56 GB

64 GB

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, the current metrics tables are deleted to make room for new data.

Allocating Disk Based on Number of Virtual Services

Disk allocation based on VS count

Log analytics without full logs

Log analytics with full logs

Metrics

Base processes

Total (without full logs)

100 VS

16 GB

128 GB

16 GB

48 GB

80 GB

1,000 VS(100k transactions / year)

128 GB

1 TB

32 GB

56 GB

216 GB

5,000 VS

512 GB

Not Supported

160 GB

64 GB

736 GB

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. For the LSC Container form factor, DISK_GBenvironment variable is instead used to calculate the quota for metrics.

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

The correct metric DB size from the Controller container can be obtained through the following command:

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 1 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 require 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). A traffic volume of 100,000 transactions per year is probably low for an e-commerce site but applies to most other types of applications.

For more information on sizing, see FAQ on Controller cluster.