The machines running the PKI Hub must meet the following requirements.

Memory requirements

Each node needs at least 16 GB of RAM.

CPU requirements

Each node needs at least 8 CPU cores. 

Main disk requirements

You need a main disk with the following requirements.

Setting

Required value

Size

1 TiB or more

Storage type

 SSD (Solid-state Drive) or NVMe (Non-Volatile Memory Express). NVMe is preferred for better performance.

A disk labeled as "SSD" does not guarantee sufficient IOPS. Cloud burstable disk tiers, thin-provisioned shared datastores, and network-attached storage may fall short of the required IOPS even when using SSD media. Always verify the sustained (non-burst) IOPS specification of your storage.


Input/output operations per second (IOPS)

3,000 or more random read/write operations per second (4 KiB block size, mixed workload).

Additional disk requirements

The etcd daemon requires a dedicated disk with the following requirements.

Setting

Required value

Size

15 GiB or more

Storage type

 SSD (Solid-state Drive) or NVMe (Non-Volatile Memory Express). NVMe is preferred for better performance.

A disk labeled as "SSD" does not guarantee sufficient IOPS. Cloud burstable disk tiers, thin-provisioned shared datastores, and network-attached storage may fall short of the required IOPS even when using SSD media. Always verify the sustained (non-burst) IOPS specification of your storage.


fsync latency

The p99 percentile of the wal_fsync_duration_seconds duration should be less than 10 ms to confirm the disk is reasonably fast for production workloads.

See https://etcd.io/docs/v3.4/metrics/#disk for more details on disk latency.


Input/output operations per second (IOPS)

50 or more sequential write operations per second.

General recommendations

In any deployment, it is recommended to:

  • Allocate dedicated IOPS to each disk.
  • Use storage quality of service policies to guarantee minimum IOPS.
  • Use the built-in CSP PKI backup feature for data protection.

Do not:

  • Use spinning disks (HDDs), regardless of RAID configuration.
  • Use network-attached storage (NAS, NFS, SAN with high latency, Ceph RBD).
  • Use cloud disk tiers with low baseline IOPS and burst-only capacity (e.g., Azure Standard SSD, AWS gp2 with small disk sizes).
  • Use thin-provisioned datastores where other VMs compete for the same physical IOPS pool.
  • Overcommit storage on the hypervisor.
  • Use storage features that introduce unpredictable delays, such as deduplication or tiered storage.
  • Use virtual machine snapshots or disk-level backups, as these mechanisms rely on copy-on-write techniques, which can introduce additional latency and lead to an inconsistent state.
  • Run real-time antivirus or file scans on the data directories, as these processes may lock files or slow down I/O operations, causing latency spikes.
  • Move a CSP PKI node to a different host (for example, using vMotion or live migration), as this can introduce I/O latency or disrupt clock consistency. If you need to move nodes, migrate one node at a time and wait for it to be fully available on the new host before migrating the next one.

Platform-specific recommendations

Follow the recommendations below to meet the storage requirements on each platform. 

Other configurations that meet the required IOPS and throughput values are equally valid.

Platform

Main disk

etcd disk

Notes

VMware vSphere

Thick-provisioned VMDK on SSD/NVMe datastore

Separate thick-provisioned VMDK on SSD/NVMe

Avoid shared datastores with high contention from other VMs. Do not use thin provisioning.

AWS

gp3 (3,000 IOPS baseline, 125 MiB/s) or io2

gp3 or io2

Do NOT use gp2 with volumes below 1 TiB (IOPS scales with volume size on gp2).

Azure

Premium SSD v2 or Premium SSD P30 (1 TiB = 5,000 IOPS)

Premium SSD v2 or Premium SSD P4+

Do NOT use Standard SSD (500 baseline IOPS, burst-only to 6,000).

Hyper-V

Fixed-size VHDX on NVMe/SSD

Separate fixed-size VHDX on NVMe/SSD

Avoid dynamically expanding VHDX on shared storage.

When using VMware, enable VM-to-Host affinity in all CSP PKI Hub deployments. See the VMware documentation for details.

https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.resmgmt.doc/GUID-0591F865-91B5-4311-ABA6-84FBA5AAFB59.html

This allows avoiding Admin Key Recovery due to host migration. 

We recommend selecting Should run on hosts in group for the rule specification. The group should contain only the one ESXi host that you are using for this CSP PKI VM.