Warren - Hardware Recommendations

RECOMMENDED SETUP

Separation of control, compute and storage keeps the platform reliable, easy to grow, and simpler to operate over time.

CONTROL PLANE

Always 3 nodes

Runs the Warren control plane and core services. Three nodes ensure quorum, safe upgrades, and maintenance without tenant disruption.

Compute PLANE

Starts at 2 nodes

Hosts user workloads (VMs and services). At 2 nodes you can already use live migration. With licensed Windows workloads we recommend starting from 4 compute nodes for economic efficiency.

Storage PLANE

Starts at 3 nodes

Provides block (and optional S3 object) storage for all compute nodes. Block storage only starts at 3 nodes; to also offer S3 object storage, plan for at least 5 nodes.

specifications

Warren is flexible with hardware, but we recommend certain minimum thresholds to achieve predictable performance and availability. Use this as a baseline and adjust for your workload mix.

Storage nodes: two hardware options

Choose one configuration. All hardware quantities are per storage node. In the hybrid configuration, every node carries both NVMe block storage and HDD object storage in one Ceph cluster.

Components	Block only (RBD)	Block + S3 object (RBD + RGW)
Number of nodes	3 minimum 4+ recommended for recovery	5 minimum for S3 with EC 3+2 6+ recommended for recovery [4]
CPU	Modern AMD EPYC or Intel Xeon Recommended: 24+ physical cores total / 48+ threads; ≥2.5 GHz base Single or dual socket [1]	Modern AMD EPYC or Intel Xeon Recommended: 24+ physical cores total / 48+ threads; ≥2.5 GHz base Single or dual socket [1]
Memory	128 GB ECC baseline 192/256 GB for growth	256 GB ECC recommended 128 GB starting configuration, subject to workload validation [1]
OS + monitor storage	2 × 960 GB enterprise SSD Software RAID 1; PLP; ≥1 DWPD [2]	2 × 960 GB enterprise SSD Software RAID 1; PLP; ≥1 DWPD [2]
Block data (NVMe OSDs)	4 × 3.84 TB enterprise NVMe PLP; ≥1 DWPD baseline Higher endurance for write-heavy workloads [3]	4 × 3.84 TB enterprise NVMe PLP; ≥1 DWPD baseline Higher endurance for write-heavy workloads [3]
Object data (HDD OSDs)	Not required	4 × 18 TB enterprise CMR HDD SAS preferred; SATA supported Capacity-optimised S3 storage
BlueStore DB/WAL for HDD OSDs	No separate devices required	2 × 3.84 TB enterprise NVMe PLP; ≥1 DWPD baseline Higher endurance as needed [3]
Network	1 × 1 GbE management 2 × 25 GbE data	1 × 1 GbE management 2 × 25 GbE data

Monitor databases may share the mirrored OS SSDs. The dedicated DB/WAL NVMe devices accelerate the object-storage HDDs; they are additional to the four NVMe block-storage drives.

At the minimum node counts, full redundancy cannot be restored while a storage node is absent. Additional nodes and free capacity provide recovery headroom.

PLP: power-loss protection. DWPD: drive writes per day. CPU totals are per server, not per socket. Final sizing depends on performance requirements, growth and workload.

Control and compute nodes

Components	Control node	Compute node
Number of nodes	3	2 or more; scale as needed
CPU	2 × Intel Xeon E5-2xxx or better; minimum 10 cores	2 × Intel Xeon Silver/Gold/Platinum or AMD EPYC; minimum 20 cores per CPU
Memory	128 GB ECC DDR4 or newer	512 GB ECC DDR4 or newer
Storage (OS)	2 × 512 GB SSD, RAID 1	2 × 256 GB SSD, RAID 1
Network	1 × 1 GbE management 2 × 25 GbE data	1 × 1 GbE management 2 × 25 GbE data

Why these storage specifications

[1] CPU and memory. The table is a proposed Warren baseline, not a vendor-certified BOM. Ceph supports 128 GB as a starting point for 8-10 OSDs; 256 GB provides additional headroom. Choose a balanced DIMM layout; 192 GB may suit some platforms. CPU speed refers to base clock, not boost.

[2] Boot and monitor disks. Ceph Tentacle recommends ≥960 GB and ≥1 DWPD for combined OS/monitor SSDs. The mirrored OS pair in this table describes locally booted servers.

[3] Data disks and endurance. Keep the proposed capacities, but confirm interface generation, endurance and capacity for each exact drive SKU. Ceph does not universally require 3 DWPD. Use ≥1 DWPD as a selection baseline; request ≥3 DWPD for write-heavy workloads and recheck available capacity. Higher endurance remains workload-dependent, including for DB/WAL.

The proposed 2 × 3.84 TB DB/WAL devices provide generous capacity. A conservative 4% sizing allowance requires 720 GB per 18 TB HDD, or 2.88 TB per node. A 2 × 1.92 TB alternative meets that capacity allowance, but its endurance and performance still require validation. Keeping two devices limits how many HDDs depend on one device.

[4] Node count. Four nodes are recommended for three-copy replication to provide a spare host for recovery. Ceph advises an extra failure domain beyond the EC shard count; that gives six hosts for EC 3+2. The three-/five-node options remain entry configurations. Reserve free capacity for recovery and expansion; nominal drive capacity is not usable customer capacity.

Server compatibility. The hybrid chassis must accommodate four 3.5-inch HDDs, six NVMe devices and the OS drives. Confirm PCIe lanes, direct CPU connectivity, power and cooling. Use a plain IT/JBOD HBA for HDDs; no data-drive RAID controller is needed. Provide redundant switch connectivity for the two data ports. Validate sustained mixed-workload performance before purchase.

Network equipment

The standard setup fits into a single rack. As you grow, you can stack additional switches and repeat the same pattern across racks or locations.

Components	Specification
Top-of-rack	2 x 25Gbit/s TOR, 48-port each (stacked)
Management	1 x 1Gbit/s, 48-port
Uplinks	Dual 100G (or according to DC design and upstream capacity)

ARCHITECTURE OVERVIEW

How control, compute and storage work together

Each node group has a distinct role. Separating them keeps failure domains small, simplifies upgrades and lets you scale capacity where it is actually needed.

Control nodes

Run the Warren control plane, APIs and management services.

Store cluster configuration, metadata, billing and API endpoints.

Orchestrate cluster-wide tasks such as upgrades, monitoring and scheduling.

Always deployed as 3 nodes for high availability and safe rolling upgrades.

Compute nodes

Run tenant workloads: virtual machines and managed services.

Consume block storage from the storage cluster over high-speed networks.

Scale linearly as usage grows; capacity can be added node-by-node.

Can be specialised into pools of high-memory, high-CPU, GPU or other instance types as needed.

Storage nodes

Run the distributed storage cluster for block and optional S3 object storage.

Use NVMe/SSD for performance-critical block storage and HDD/SAS for deep capacity.

Maintain availability during disk or node failures through replication or erasure coding.

Increase capacity and throughput by adding storage nodes without any interruption.

Planning at scale

Rack planning for growth

If you are planning a larger deployment, including multi-rack or high-density layouts, our team can help review the design and ensure smooth scaling.

Configuration Number of server nodes	Minimum 8 nodes	Fully features 12 nodes	Multi-rack  Depends
Aggregation node *
Control nodes
Compute nodes
Network nodes
Storage nodes
+ Object storage

* every other rack with multi-rack deployments.

Alternatives

Planning a hyper-converged infrastructure (HCI) or other special setup?

If you are designing an HCI cluster, mixing GPU nodes, or re-using existing hardware, our team can help validate the design and trade-offs for Warren.

Schedule a Technical Call

Documentation and resources