A JBOF, a just-a-bunch-of-flash enclosure, is the all-NVMe answer to a question that storage architects have asked for years: why should fast drives be trapped inside the server that happens to own them? Instead of scattering NVMe across every host, a JBOF concentrates flash in a shared enclosure that many servers can draw on over a fabric, turning stranded local capacity into a pool that gets used. It is not the right answer everywhere, but where it fits it changes the economics of flash, and this is how to tell whether it fits your estate.
What a JBOF is, and is not
A JBOF is an enclosure full of NVMe drives with fabric controllers and fast network ports, designed to present those drives to external hosts rather than to run applications itself. It is the flash equivalent of a JBOD shelf, but where a JBOD chains spinning disks over SAS, a JBOF serves NVMe over a fabric such as RoCE or NVMe/TCP, preserving the low latency that makes NVMe worth buying.
What a JBOF is not is a full storage array. It deliberately keeps intelligence thin: the data services, resilience and pooling usually live in software on the hosts or in a storage layer above, not in the enclosure. That thinness is the point, because it keeps the enclosure cheap per terabyte and lets you choose the software stack that fits, but it also means a JBOF on its own is raw capacity, not a finished storage product.
The stranded-flash problem it solves
Flash is expensive, and local flash is often badly used. One host fills its NVMe to ninety per cent while the box next to it sits at twenty, and there is no way to lend capacity from one to the other because it is bolted to separate PCIe buses. Multiply that across a rack and you have paid for a great deal of fast storage that is idle by accident of placement.
A JBOF turns that stranded capacity into a single pool. Hosts draw what they need from a shared enclosure, so average utilisation climbs and you buy less flash to do the same work. The saving is real but it is not free: you add a fabric, a target enclosure and the operational care that goes with shared storage, so the maths only works above a certain scale and a certain degree of imbalance.
The hardware inside
A JBOF is built for fan-out and bandwidth. It needs enough PCIe lanes and switching to drive a large number of NVMe drives, fabric controllers to terminate the network protocol, and dual high-speed NICs sized to the aggregate bandwidth of the drives behind them, because an under-provisioned network turns an expensive flash pool into a slow one. The drive bays are typically EDSFF or U.2 for density and serviceability.
Because the enclosure serves many hosts, the drives see a blended, frequently write-heavy load, so endurance class and steady latency under pressure matter more than peak sequential figures. We choose the media from our SSD and NVMe range to match that profile, and pair the enclosure with the controller and HBA path from our host bus adapters range so the storage software gets clean pass-through access to every drive.
- •High PCIe lane count and switching to fan out to many NVMe drives
- •Dual fast NICs sized to aggregate drive bandwidth, not a token uplink
- •EDSFF or U.2 bays for density and front serviceability
- •Endurance class chosen for a shared, write-heavy blended load
Shared flash versus flash per server
The decision usually comes down to shared flash versus flash-per-server. Flash-per-server is simplest: every host owns its NVMe, there is no fabric, and latency is as low as it gets, but utilisation is whatever each host happens to need and capacity cannot move between boxes. For a handful of servers with steady, similar storage needs, that simplicity wins.
Shared flash through a JBOF wins when needs are uneven or growing, when you want to raise utilisation across many hosts, or when diskless hosts simplify your fleet management. The break-even is a function of how many hosts you have and how unevenly they use flash; below it, per-server is cheaper once you count the fabric, and above it the pooled enclosure pulls ahead on both cost and flexibility.
Operational realities
Sharing flash means the network is now in the storage path, so dual fabrics, multipath and redundant NICs become part of the resilience story rather than optional extras. The enclosure needs dual power and redundant components, and the fabric needs congestion control configured so one busy host cannot starve the others. None of this is exotic, but it is real work that flash-per-server does not require.
There is also a skills dimension. A JBOF rewards teams comfortable running a fast, lossless or near-lossless fabric and a software-defined storage layer on top; it punishes teams that bolt it on and hope. We design the enclosure, the fabric and the storage software together in our server configuration service so the whole path is sized and resilient, not just the box.
Putting it together
Reach for a JBOF when you have enough hosts, enough flash, and enough imbalance that pooling pays, and when your team can run the fabric it depends on. Stay with flash-per-server when the estate is small, steady and self-contained. For the protocol layer that makes a JBOF possible, read NVMe over Fabrics, and for the wider question of growing storage by adding shelves, hosts or pools see add a JBOD or buy another server.