CPU and RAM requirements

Each service and role reserves CPU and memory on a node, and its logs consume space on the system disk. Both are additive: a node's total is the sum of the reservations and log footprints of everything it hosts, plus OS and workload headroom. If erasure coding is used in the storage cluster, add the storage-client reservation once per node.

Service reservations (per node)

The following table lists the amount of RAM and CPU cores that will be reserved on one node, according to the services you will use:

Service		Management node		Secondary node
		RAM1 Use only Error correction code (ECC) memory, to avoid data corruption.	CPU cores2 A CPU core here is a physical core in a multicore processor (hyperthreading is not taken into account).	RAM3 Use only Error correction code (ECC) memory, to avoid data corruption.	CPU cores4 A CPU core here is a physical core in a multicore processor (hyperthreading is not taken into account).
System		4.5 GB	1 core	1.5 GB	1 core
Storage services	Each disk with Metadata, Storage, or Cache role (any size)5 For clusters larger than 1 PB of physical space, add 0.5 GB of RAM per Metadata service.	0.5 GB	0.2 cores	0.5 GB	0.2 cores
	Storage client (vstorage-mount) when erasure coding is used6 Add this reservation once per node. It is calculated from the node's total physical RAM.	5 percent of the node's total RAM + 2 GiB		5 percent of the node's total RAM + 2 GiB
Compute7 The recommended configuration for a compute cluster node starts with 64+ GB and 16+ cores.	Service	8 GB	1 core
	Each virtual machine	128 MB		128 MB
	Load balancer (add-on service)	1.5 GB	0.5 cores
	Kubernetes (add-on service)	1 GB	0.5 cores
	Metering (add-on service)	3 GB	1 core
	Resource policies (add-on service)	0.3-5 GB8 Memory reservation for resource policies depends on the compute cluster's size and workload. The larger the cluster, the more RAM is required. In large clusters, such as those with around 100 nodes and 1000 VMs per node, RAM reservation may reach up to 5 GB.	3 cores
Backup Gateway9 When working with public clouds and NFS, Backup Gateway consumes as much RAM and CPU as with a local storage.		1 GB	0.5 cores	1 GB	0.5 cores
S310 By default, each S3 node runs 4 S3 gateways and can run up to 10 NS and 10 OS instances, but the entire S3 cluster cannot host more than 24 OS and 16 NS instances. The number of OS and NS services is defined during the initial S3 cluster setup. Adding more nodes to the S3 cluster does not affect it. The CPU and RAM reservations depend on the number of S3 nodes. Generally, the larger the S3 cluster, the less resources are reserved on each node.	Each S3 gateway	512 MB	0.5 cores	512 MB	0.5 cores
	Each OS service	256 MB	0.1 cores	256 MB	0.1 cores
	Each NS service	512 MB	0.2 cores	512 MB	0.2 cores
NFS	Service	4 GB	1 core	4 GB	1 core
	Each share11 The RAM reservation for an NFS share depends on the number of cluster nodes. The larger the NFS cluster, the less RAM is reserved on each node.	up to 9 GB	up to 8 cores	up to 9 GB	up to 8 cores
iSCSI		1 GB	1 core	1 GB	1 core

Log and OS-disk footprint

The following values can be used for initial system-disk sizing:

Service or role	Log / OS-disk footprint (maximum retained)
System (base OS)	Typically ≤4 GB for journald, plus about 0.5 GB for syslog
Hypervisor (kernel, libvirt, QEMU)	Typically about 0.5 GB for libvirtd, plus about 10 MB per VM for QEMU logs
Storage service per metadata, storage, or cache disk	About 400 MB per disk
Storage client per mount	About 1 GB per mount
Compute controller	About 0.7 GB per OpenStack service log
Compute worker agents	About 0.7 GB
Compute per VM	About 10 MB per VM for QEMU logs
Compute database cache	No dedicated log
Load balancer, Kubernetes, metering, migration, and resource policy add-ons	About 0.7 GB per service log
Backup Gateway	Up to about 10 GB, plus up to 1 GB for sysinfo
S3 gateway, object service, or name service	Typically about 100 MB per service
NFS service	Typically about 1 GB
NFS share	No separate log; logged in the NFS service log
iSCSI	Typically about 0.5 GB for the target log, plus iscsiuio logs

Log files are automatically rotated and retained according to the mechanism used by each service. The maximum amount of disk space consumed by logs depends on the services running on the node.

• System services use logrotate.
• OpenStack services use Kolla log rotation and retain up to six archived log files.
• Storage services (CS, MDS, and client components) retain a fixed number of compressed log files.
• S3 and configuration services retain the current log file and one compressed archived copy.

journald stores logs for services that write to the system journal. By default, journal storage is limited to 4 GB.

When sizing the system disk, account for the logs generated by the services running on the node, as well as the system journal. Backup Gateway and OpenStack services typically generate the largest amount of log data and may require several gigabytes of additional system-disk capacity.

CPU and RAM limits

Hardware	Theoretical	Certified
RAM	64 TB	1 TB
CPU	5120 logical CPUs	384 logical CPUs

CPU recommendations

• Minimum CPU frequency 2.0 GHz; recommended 2.4 GHz+. Higher frequency reduces latency almost linearly and is preferable to more cores.
• Nodes running the metadata service benefit from high CPU frequency (CPU-intensive).
• For erasure-coding performance, use CPUs with AVX-512 (e.g. Intel Xeon Silver 4110 / Gold 5115 / Platinum 8171 or newer).