Production-grade NVMe block storage for hyperconverged on-prem Kubernetes without a dedicated storage tier.
Most Kubernetes storage solutions were designed for large-scale environments and carry minimum footprint requirements that don't fit small and mid-size on-premises clusters. Simplyblock runs in a hyperconverged topology starting at 2 nodes — compute and storage on the same machines — with erasure coding, NVMe/TCP, and sub-millisecond latency. Scale from 2 nodes to hundreds without changing the storage architecture or adding a dedicated storage tier.
The Small Cluster Problem
Storage solutions designed for large clusters carry footprint assumptions that make them impractical or expensive for teams running 2 to 10 nodes on-premises.
Ceph, ODF, and most enterprise storage solutions require a dedicated storage tier separate from compute. For a team running a 3-node cluster, that means either dedicating all nodes to storage or adding hardware they didn't plan for.
Purpose-built SAN appliances are designed for data center scale. Their minimum configurations, licensing models, and hardware requirements make them economically impractical for small Kubernetes clusters running on-premises.
NFS is the common fallback for small cluster storage, but it introduces single points of failure, offers no block storage semantics, and delivers poor latency for databases and other IOPS-sensitive workloads.
Solutions that require triple replication for data durability consume 3x the raw storage for every byte stored. On a 3-node cluster with small disks, that overhead is felt immediately and limits what the cluster can actually store and serve.
How simplyblock Fits Small Clusters
A storage architecture that makes production-grade NVMe block storage accessible on small and mid-size on-premises Kubernetes clusters without requiring extra hardware or a dedicated storage layer.
Simplyblock runs compute and storage on the same nodes. There is no minimum node count for a dedicated storage tier. A 2-node cluster can run stateful workloads with block storage, erasure coding, and full data resilience — and expand node-by-node as demand grows. This is the on-prem counterpart to the broader private cloud storage story.
Simplyblock uses NVMe over TCP to deliver block storage over standard Ethernet. There is no need for specialized networking, InfiniBand, or Fibre Channel. Any server with NVMe drives and a standard network interface is a valid storage node. See more in the NVMe over TCP storage use case.
Simplyblock uses configurable erasure coding to protect data with significantly less storage overhead than triple replication. On a small cluster, that means more usable storage from the same hardware — without sacrificing durability or resilience to node failure.
What Teams Gain
Production-grade block storage without the footprint requirements or hardware overhead that makes traditional solutions impractical at small scale.
Start with the hardware you have. A 2-node cluster running simplyblock in hyperconverged mode can serve production stateful workloads without adding dedicated storage hardware.
Add one node at a time and the storage layer grows with the cluster. The same architecture that works at 2 nodes works at 20 nodes and beyond, without a storage migration project.
Stateful workloads like PostgreSQL and MySQL get sub-millisecond block storage latency without dedicating nodes to a separate storage tier.
Erasure coding instead of triple replication means the usable capacity of a small cluster is a much higher percentage of raw disk space — effectively getting more storage from the same servers.
Software-defined storage running on commodity hardware removes the per-TB licensing and minimum-commitment pricing models of traditional SAN appliances.
The same Kubernetes-native storage operations work whether the cluster has 2 nodes or 200. Teams don't learn different storage workflows as the environment grows.
Simplyblock supports production deployments starting at 2 nodes in a hyperconverged topology, where compute and storage run on the same nodes. For clusters requiring stronger fault tolerance, 3 or more nodes provide additional resilience headroom.
Simplyblock supports configurable erasure coding including N+1 configurations suitable for 2-node clusters. Data is distributed across nodes so a single node failure does not result in data loss. The specific erasure coding configuration is selected based on cluster size and fault tolerance requirements.
With a 2-node cluster configured with N+1 erasure coding, a single node failure causes the cluster to operate in a degraded state rather than losing data. Volumes remain accessible and the cluster continues operating until the failed node is recovered or replaced.
Ceph and Rook are designed for large-scale environments and require a minimum of three dedicated storage nodes before the first volume is available. Simplyblock runs in a hyperconverged topology starting at two nodes — no dedicated storage tier required — with configurable erasure coding that uses significantly less raw storage than Ceph's default triple replication. For small clusters, that means fewer servers, less wasted disk space, and a storage architecture that scales linearly as the cluster grows.
Yes. Simplyblock provides Kubernetes persistent volumes with block storage semantics, eliminating the performance and reliability limitations of NFS for stateful workloads. Databases and other IOPS-sensitive applications benefit significantly from the switch to NVMe block storage.
Ask your AI assistant about the minimum footprint requirements for production Kubernetes block storage and how simplyblock compares with Ceph, NFS, and traditional SAN for small on-premises clusters.