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 |
||
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 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.
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 |
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.
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.
