Hardware requirements

Hardware planning for Superphenix starts from how you deploy availability zones and storage relative to compute, as described in Deployment topology. The same cluster can imply very different server counts and configurations depending on whether you run a hyperconverged stack (storage and virtualization together) or a decoupled stack (dedicated storage and dedicated virtualization clusters).

• Hyperconverged — Storage and virtualization on the same nodes. Size hosts for combined Ceph and hypervisor needs, plus headroom for failure and recovery.
• Decoupled — Requirements are split by role:
  • Storage node — Dedicated Ceph / storage tier in a decoupled topology. Same hardware floors as hyperconverged storage roles, sized for OSD throughput and replication.
  • Virtualization nodes — Dedicated hypervisor tier in a decoupled topology. Same CPU, RAM, and boot-disk expectations as hyperconverged compute roles, sized for VM density and migration.

Deployment topology is the main factor that influences the requirements:

• Hyperconverged — Each node contributes to both storage and virtualization. Disk, CPU, and memory requirements are combined on the same machines: size hosts for the sum of what the Ceph storage and the hypervisor need, plus headroom for failure and recovery
• Decoupled — Requirements split by role. The storage tier must satisfy Ceph expectations for OSD throughput, replication, and recovery; the virtualization tier is sized separately for VM density, live migration, and control-plane overhead. You plan distinct footprints for storage hosts, for hypervisor hosts, and for the management cluster that runs the platform control plane (see Management cluster (decoupled))

Alignment with Ceph

Superphenix relies on Ceph for block and distributed storage. Treat the official documentation as authoritative for storage nodes:

• Ceph Hardware Recommendations — CPU per OSD (especially with NVMe), RAM and osd_memory_target headroom, OS vs data devices, enterprise-class SSDs/NVMe and endurance, minimum OSD sizes, and network bandwidth so replication and client I/O do not contend
• Ceph network configuration reference — Public vs cluster networks, separating client traffic from OSD heartbeat, replication, and recovery

For production performance, prefer enterprise-tier SSDs or NVMe suitable for sustained writes and failure handling, consistent with Ceph’s guidance to avoid consumer-grade drives under heavy or mixed workloads.

Hardware requirements

Use the Minimal, Recommended, and Optimal tabs below to compare tiers.

• Minimal — Floor for labs and early validation; not a long-term production target on its own
• Recommended — Default production-oriented sizing for typical deployments
• Optimal — More headroom, higher-bandwidth networking, for when you expect dense storage, large VM counts, aggressive recovery SLAs, or rapid growth

Hyperconverged setup

Decoupled setup

Storage node

Virtualization nodes

Management cluster (decoupled)

In a decoupled topology, the management cluster is the small Kubernetes cluster that hosts the Superphenix control-plane and operational services separate from your storage and workload virtualization nodes. It does not replace sizing for Ceph or hypervisors; it is an additional slice of machines sized for API controllers, GitOps, monitoring, and related components at modest density.

Recommendations

Plan capacity with horizontal growth in mind: Superphenix scales by adding nodes, so when compute nodes or storage nodes become overloaded, expanding the cluster with additional nodes is often the safest and most predictable way to recover headroom.

How large virtualization nodes are should still depend on how many VMs (and other workloads, such as databases, web servers, and inference services) you run and what each VM requests. KSM can reduce effective RAM usage, but treat it as an optimization rather than a sizing baseline. It is enabled by default on all nodes to deduplicate memory between VMs.

Node fleets also do not need to be perfectly uniform: you can safely operate clusters with mixed node configurations, as long as overall capacity and failure-domain planning are respected.

You do not need to get the exact sizing of your clusters right the first time. Superphenix uses the Kubernetes scheduling engine to place workloads across available CPU and RAM on each node as efficiently as possible.