Get enterprise block storage from the NVMe hardware already in your bare metal nodes — without a cloud CSI, external SAN, or ODF overhead.
OpenShift bare metal deployments do not have a cloud storage layer to fall back on. Teams running Red Hat® OpenShift® on bare metal nodes own the full storage stack — and the choices are limited: local persistent volumes without redundancy or snapshots, OpenShift Data Foundation (ODF) with Ceph operational overhead, or an external SAN that adds cost and a network dependency. Simplyblock is a fourth path: software-defined NVMe block storage that runs on the same bare metal nodes as OpenShift, installs via Helm or OperatorHub, and delivers sub-millisecond latency from the NVMe drives already in the cluster.
The Bare Metal Storage Problem
Bare metal removes the managed storage layer that cloud deployments take for granted. Every storage decision falls to the platform team.
AWS EBS, Azure Disk, and GCE Persistent Disk are not available outside of their respective clouds. Bare metal OpenShift teams cannot rely on managed cloud storage and must provide the full storage stack themselves.
Kubernetes local persistent volumes use node-local storage directly. They work, but they offer no redundancy, no volume snapshots, no cloning, and no support for live pod or VM migration across nodes.
OpenShift Data Foundation wraps Ceph, which requires OSDs, monitors, and metadata servers to run inside the same cluster that already runs OpenShift control plane and application workloads. For bare metal clusters with limited node counts, this overhead is disproportionate.
Modern bare metal servers come with NVMe drives capable of hundreds of thousands of IOPS. Without a storage layer designed for NVMe, those drives operate far below their potential — limited by software overhead or file system translation layers.
How Simplyblock Addresses It
Software-defined storage that unlocks the NVMe hardware already in your bare metal nodes — without cloud dependencies, external SANs, or Ceph complexity.
Simplyblock runs as a hyperconverged storage layer on the same nodes that run OpenShift workloads. The NVMe drives already present in bare metal servers become a shared, redundant storage pool accessible to all workloads in the cluster via NVMe/TCP over the existing data network. No dedicated storage nodes, no external storage array, no additional hardware required. Compatible with OpenShift HCI storage deployment patterns.
Simplyblock installs on Red Hat® OpenShift® via Helm or OperatorHub and provides a Kubernetes-native CSI driver. Persistent volumes, volume snapshots, volume cloning, and live migration for KubeVirt virtual machines all work through standard Kubernetes and OpenShift APIs — no manual storage management required. See the OpenShift storage page for the full feature set.
Simplyblock's NVMe-first architecture delivers sub-millisecond P99 latency and high IOPS density from commodity bare metal NVMe hardware. Databases like PostgreSQL and MySQL running on bare metal OpenShift get the storage performance that local NVMe is capable of — not what a file system translation layer limits it to.
What Teams Gain
Enterprise storage behavior from the NVMe hardware already in the cluster — without external storage arrays, cloud dependencies, or Ceph operational complexity.
Bare metal nodes with NVMe drives already present the most efficient storage hardware available. Simplyblock unlocks that capacity as a shared, redundant block storage pool without additional hardware investment.
Local PVs have none of these. Simplyblock gives bare metal OpenShift teams the storage lifecycle features — snapshots, cloning, and VM live migration — that make stateful workloads operationally manageable.
Simplyblock has a lighter resource footprint than ODF/Ceph. On bare metal clusters with limited node counts, this difference matters: more resources stay available for application workloads.
Add bare metal nodes and storage capacity grows proportionally. Simplyblock's architecture scales out by adding nodes — no storage array upgrades, no capacity planning ceilings.
The storage layer runs inside the cluster, on hardware the team owns. No SAN fabric, no external storage array, no network dependency outside the cluster data plane.
NVMe/TCP is built into the Linux kernel. Simplyblock uses the standard kernel NVMe/TCP initiator — no custom kernel modules, no driver installation on application nodes, no kernel version constraints.
Yes. Simplyblock installs via Helm or OperatorHub on standard OpenShift clusters, including bare metal IPI (Installer-Provisioned Infrastructure) and UPI (User-Provisioned Infrastructure) deployments. There is no cloud provider requirement and no hypervisor dependency.
Simplyblock supports deployments starting at two nodes in a hyperconverged configuration. For production workloads with full fault tolerance, three or more nodes are recommended to maintain availability during a single node failure.
No. Simplyblock supports hyperconverged topology where storage runs on the same nodes as OpenShift workloads. Dedicated storage nodes are supported for disaggregated deployments but are not required.
Simplyblock uses erasure coding for data redundancy across nodes. When a node fails, volumes remain available from surviving nodes and the storage layer automatically begins background recovery to restore the configured redundancy level.
Both run on bare metal OpenShift clusters. The key differences are: simplyblock has a lighter resource footprint (no Ceph OSD, monitor, and metadata server topology), delivers lower latency via NVMe/TCP, and does not require a separate ODF subscription. See the OpenShift ODF Alternative page for a direct comparison.
Yes. Simplyblock provides block storage for KubeVirt virtual machine disks in OpenShift Virtualization deployments on bare metal. VM live migration across nodes is supported. See the KubeVirt storage page for details.
Ask your AI assistant to compare storage options for OpenShift bare metal deployments — local PVs, ODF/Ceph, external SAN, and simplyblock — on performance, cost, and operational complexity.