Planning compute

Use this topic to estimate the CPU and memory resources required for virtualized workloads. Compute requirements depend on the workload type, the number of virtual machines, the CPU overcommit ratio, memory allocation, and high-availability requirements. For predefined deployment architectures, see Deployment scenarios; for service reservation values, see CPU and RAM requirements.

Architectures

Architecture	Compute & storage	How it scales	Use when
Hyperconverged (HCI)	Every node runs both VMs and Virtuozzo Storage	Compute and storage scale together, node by node	Converged operations and a predictable per-node ratio are required
Disaggregated (non-HCI)	Compute-only nodes; storage from a separate Virtuozzo Storage cluster or an external array over iSCSI	Compute and storage scale independently	Compute-heavy or storage-heavy growth is expected, or an existing SAN is used
Mixed	An HCI core plus compute-only and/or storage-only nodes	Add the resource you are short on	Balancing capacity against performance as the cluster grows

Compute prerequisites

Run production compute clusters on physical servers.
Use 64-bit x86 AMD-V or Intel VT processors with hardware virtualization extensions enabled. For Intel processors, enable "unrestricted guest" and VT-x with Extended Page Tables in BIOS.
Use the same CPU models on all compute nodes to avoid VM live migration issues. If different CPU models are required, set a baseline CPU model that ensures compatibility across all nodes or a group of nodes, as described in Setting virtual machine CPU model.
If you intend to enable RAM overcommitment for virtual machines, ensure that the system disk has enough space for swap and additionally 100 GiB of free space.

Sizing a node

A node needs enough CPU and RAM for everything it runs: the base OS, storage services, the compute controller on management nodes, add-on services, and the VMs it hosts. Add those up from the service reservations, then apply overcommit. On HCI or storage nodes that use EC, include the storage-client reservation before calculating how much RAM remains available for VMs. On a disaggregated compute-only node, there are no storage services, so nearly the whole node is available for VMs.

RAM: Provide enough physical RAM for all VM RAM plus a small per-VM overhead, about 128 MB per VM. Depending on the workload, you can overcommit VM RAM up to three times the amount of physical RAM, but the overcommitted part must be backed by NVMe swap. For example, at 2:1 overcommit on a node with 256 GiB of RAM, provide at least 512 GiB of NVMe swap.
CPU: You can overcommit virtual CPUs against physical cores. A higher ratio places more VMs on a node but raises latency under load. Cores reserved for storage services, the compute controller, and add-on services are physical and are not overcommitted.

Effects of overcommit

The vCPU:pCPU overcommit ratio sets how many virtual cores share one physical core. A higher ratio increases VM density on a node but raises CPU-ready latency under load:

Idle or bursty workloads, such as general server VMs and VDI, tolerate higher ratios because they prioritize density and cost per VM.
Latency-sensitive or steady-load workloads, such as databases and real-time applications, need a low ratio or no CPU overcommit.
For 100 VMs with 2 vCPU each, a 3:1 ratio requires about 67 physical cores, a 4:1 ratio requires 50 physical cores, and a 1:1 ratio requires 200 physical cores. The tradeoff is VM density versus tail latency.

The examples below use 3:1 as a conservative general-purpose starting point for mixed workloads. Use a lower ratio, or no CPU overcommit, for latency-sensitive workloads, and validate the selected ratio under expected load before committing production capacity.

Reservation example

The following example shows only system, storage, compute controller, and add-on reservations. If the storage policy uses EC, add the storage-client reservation on each node. Extra RAM and CPU are available for virtual machines.

10 nodes for the compute service with management node high availability
Service	Management nodes (nodes 1-3)	Secondary nodes (nodes 4-10)
System	4.5 GB RAM, 1 core	1.5 GB RAM, 1 core
Storage services	10 storage disks, 1 metadata disk, and 1 cache disk: 6 GB RAM, 2.4 cores	10 storage disks, 1 metadata disk, and 1 cache disk: 6 GB RAM, 2.4 cores
Compute controller	8 GB RAM, 1 core	—
Load balancer	1.5 GB RAM, 0.5 cores	—
Kubernetes	1 GB RAM, 0.5 cores	—
Service reservations	21 GB RAM, 9.9 cores	7.5 GB RAM, 3.4 cores
Recommended hardware configuration	64 GB RAM, 16 cores	64 GB RAM, 16 cores

Workload example

Target: 200 VMs, each with 4 vCPU and 8 GB RAM.

As HCI (all-flash, EC 3+2)

Node count: EC 3+2 requires five nodes. Plan one additional node as high-availability headroom, for six nodes in total. With 200 VMs, place the active workload across five nodes, which gives about 40 VMs per node.
RAM per node: assuming six disks with storage-service roles, 40 VMs × (8 GB + 0.125 GB overhead) + 1.5 GB for the system + 3 GB for storage services + about 21.2 GiB for the EC storage client on a 384 GB node gives about 351 GB. Use 384 GB per node. Management nodes also require 8 GB for the compute controller and additional RAM for the database cache.
Cores per node: 40 VMs × 4 vCPU at a 3:1 overcommit ratio requires about 54 physical cores. Add one core for the system and about 1.2 cores for storage services. Management nodes also require one core for the compute controller. Size the node to 64 physical cores.

As disaggregated (compute-only nodes)

The same 200 VMs on compute-only nodes carry no storage reservation, so each node gives all its RAM and cores to VMs. You size the compute tier purely by VM density and your HA spare, and size the storage separately as a Virtuozzo Storage cluster or external array.
This architecture lets compute and storage grow at different rates. Add compute workers for more VMs without changing the storage cluster, and add storage capacity without changing the compute tier.

This example is a planning estimate. Adjust it according to the overcommit ratio, high-availability headroom, VM profile, and add-on services in the target environment.

Compute cluster network requirements

Whether you deploy the minimum network configuration for evaluation or the advanced network configuration for production, the following network requirements apply:

Configure the VM private network to accommodate VXLAN encapsulation. Private virtual networks use VXLAN encapsulation over the infrastructure network assigned the VM private traffic type. Because VXLAN adds encapsulation overhead, the effective MTU inside a virtual machine is lower than the MTU configured on the underlying network. To provide a 1500-byte MTU inside virtual machines, configure the underlying VM private network with sufficient encapsulation headroom, for example, by enabling jumbo frames. Ensure that the same MTU is supported on node interfaces, bonds, VLAN interfaces, switches, and all intermediate network devices.
Assign an IP address to the VM private interface on every compute node. In addition to carrying overlay network traffic, this network is also used by compute networking services, including VM console traffic.
Configure the appropriate MTU for public VM networks. Public VM networks may use a different effective MTU than private VM networks. Ensure that the MTU configured or advertised to virtual machines does not exceed the smallest MTU on the network path.
Configure 10 GbE and faster network adapters with an MTU of 9000 to achieve maximum performance.

Changing MTU settings or reassigning the VM private traffic type can temporarily interrupt private virtual networks and VM console connectivity. Perform these changes during a maintenance window.

When using specific features, the following additional requirements apply:

If third-party backup software pulls VM backups over the network, assign the VM backups and VM public traffic types to the same dedicated isolated network for security.
RDMA requires a dedicated physical interface assigned to the Storage traffic type.

Minimum network configuration for the compute cluster

The minimum configuration includes two networks, for internal and external traffic:

Recommended network configuration for the compute cluster

The recommended configuration expands to five networks connected to the following logical network interfaces:

One private bonded connection with a single VLAN (or a native interface) for internal management and storage traffic with the Storage and Internal management traffic types.
One public bonded connection with at least three VLANs over it:
- The trunk interface assigned the VM public traffic type, to automatically create VLAN-based networks for external (public) traffic of virtual machines.
- One VLAN for overlay network traffic between VMs with the VM private traffic type.
  
  Starting from the version 5.2, we support data-in-transit encryption between nodes. Enabling encryption decreases the VXLAN payload by 37 bytes, thus increasing the default overhead for virtual networks from 50 to 87 bytes.
- One VLAN for service delivery via the admin and self-service panels, compute API, and for management via SSH, with these traffic types: Compute API, Admin panel, Self-service panel, and SSH.
  
  This VLAN can also be used for public export of iSCSI, NFS, S3, Backup Gateway data, and accessing cluster monitoring statistics via the SNMP protocol.
- One or more VLANs for external VM traffic with the VM public traffic type.

The table below includes the full list of network recommendations for the compute cluster:

Bond	VLAN	Network	Traffic types	MTU	Specifics
Bond0	101 or native	Private	Storage, Internal management1	To achieve the maximum performance, these networks must have the MTU size close to 9000 bytes.2	The bond must be built on top of a high-performance network, as storage traffic requires low latency and high throughput. We recommend using 25 or 40 Gbit/s network adapters. Using 10 Gbit/s adapters is also possible, but not recommended. For this network, we also recommend using RDMA (over Infiniband or RoCEv2), as it significantly increases storage performance for IOPS-intensive workloads.
Bond1	Trunk	Trunk	VM public		The bond must be built on top of 10+ Gbit/s network, as it includes internal traffic between virtual machines in private virtual networks (VXLAN).
	102	Overlay	VM private		Includes the 87-byte overhead due to VXLAN (50 bytes) and encryption (37 bytes).
	103	Services	Compute API, Admin panel, Self-service panel, SSH3		The self-service panel traffic should be exposed to public networks via NAT. Furthermore, we do not recommend exposing such services as the admin panel and SSH to the Internet. For managing your cluster, use a secure VPN. If you need to provide end users access to the OpenStack API, expose the compute API traffic via NAT and configure the OpenStack endpoints.
	104	Public	VM public		—

Kubernetes-as-a-Service network requirements

To be able to deploy Kubernetes clusters in the compute cluster and work with them, make sure your network configuration allows the compute and Kubernetes services to send the following network requests:

The request to bootstrap the etcd cluster in the public discovery service - from all management nodes to https://discovery.etcd.io via the public network.
The request to obtain the “kubeconfig” file - from all management nodes via the public network:
- If high availability (HA) for the master VM is enabled, the request is sent to the public or floating IP address of the load balancer VM associated with Kubernetes API on port 6443.
- If HA for the master VM is disabled, the request is sent to the public or floating IP address of the Kubernetes master VM on port 6443.
Requests from Kubernetes master VMs to the compute APIs (the Compute API traffic type) via the network with the VM public traffic type (via a publicly available VM network interface or a virtual router with enabled SNAT). By default, the compute API is exposed via the IP address of the management node (or to its virtual IP address if high availability is enabled). But you can also access the compute API via a DNS name.
The request to update the etcd cluster member state in the public discovery service - from Kubernetes master VMs to https://discovery.etcd.io via the network with the VM public traffic type (via a publicly available VM network interface or a virtual router with enabled SNAT).
The request to download container images from the public Docker Hub repository - from Kubernetes master VMs to https://registry-1.docker.io via the network with the VM public traffic type (via a publicly available VM network interface or a virtual router with enabled SNAT).

It is also required that the network where you create a Kubernetes cluster does not overlap with these default networks:

10.100.0.0/16—Used for pod-level networking
10.254.0.0/16—Used for allocating Kubernetes cluster IP addresses