vSAN JBOF Disaggregated Storage: Samsung Flash Shelf Architecture for VMware
What happens when you decouple flash capacity from compute nodes? Inside VMware vSAN's JBOF reference design with Samsung — architecture, performance implications, and why it matters for AI-ready infrastructure.
Enterprise storage architecture is no longer one-size-fits-all. VMware vSAN now gives organizations a full spectrum of deployment models — from hyperconverged, to disaggregated with vSAN Max, to fully external flash with JBOF. The Samsung JBOF reference design gives us the first concrete look at how that third option works at scale.
This architecture is in its early validation phase, but the benchmark data and design principles are worth understanding now — this is the direction AI-driven storage demand is heading.
Not vSAN Max — A Different Architecture
This is an important distinction. vSAN Max uses dedicated storage nodes that hold and manage data independently from compute nodes. The vSAN JBOF architecture works differently.
In a JBOF design, there are no storage nodes. The vSAN processor nodes handle both compute workloads and storage management. They connect over NVMe-oF to the Samsung JBOF chassis — which is just a shelf of flash drives with no hypervisor, no vSAN software, no intelligence of its own. The processor nodes create and manage the disaggregated storage pool by reaching across the fabric to claim NVMe devices on the JBOFs.
Think of it this way: the processor node is still the brain. The JBOF is just high-speed, externally attached flash. vSAN treats those remote NVMe drives as if they were local, handling erasure coding, placement policies, and data services entirely from the processor tier.

The Hardware Layout
vSAN Processor Nodes run VMware vSphere 8.0 U2 on Dell PowerEdge R750s — dual Intel Xeon Gold 6342 processors, 512GB DDR4-3200 memory, and Mellanox ConnectX-5/ConnectX-6 100GbE NICs. These nodes are diskless. They run VMs and manage the storage fabric simultaneously.
Samsung JBOF Chassis (SMC ASG-2115S-NE332R) are passive flash shelves housing 32 Samsung PM1743 16TB NVMe 5.0 E3.S SSDs each — 512TB raw per unit. They connect via dual Mellanox ConnectX-6 100GbE NICs. An AMD EPYC Genoa 9334 processor and 128GB DDR5 handle the NVMe-oF target-side protocol, but no vSAN or hypervisor software runs on the JBOF.
The test configuration connects 6 processor nodes to 3 JBOFs through a 100 GbE switch — 1 port per processor node, 2 ports per JBOF.
What the Numbers Show
The benchmark data demonstrates independent scaling — you grow compute and capacity separately, and each scales near-linearly.
Compute scaling (4KB random read, 3 JBOFs fixed):
The test kept total VM count constant at 60, redistributing across nodes as the cluster grew. Each VM ran 4 VMDKs with 4 threads.
| Processor Nodes | VMs per Node | OIO per Node | Total IOPS |
|---|---|---|---|
| 4 nodes | 15 VMs | 240 | 1.34M |
| 5 nodes | 12 VMs | 192 | 1.67M (+25%) |
| 6 nodes | 10 VMs | 160 | 1.96M (+46%) |
Same storage tier, more compute, more throughput. Linear.
Capacity scaling (128KB sequential read, 6 processor nodes fixed):
Each processor node ran 8 VMs (48 total), 4 VMDKs and 4 threads per VM, OIO of 128 per node.
| JBOFs | SSDs per Host | Bandwidth per Host | Total Throughput |
|---|---|---|---|
| 1 JBOF | 5 SSDs | 200 Gbits | 21.1 GB/s |
| 2 JBOFs | 10 SSDs | 400 Gbits | 40.7 GB/s (1.9x) |
| 3 JBOFs | 15 SSDs | 600 Gbits | 58.4 GB/s (2.8x) |
Same compute tier, more flash shelves, more throughput. Linear.
This is the financial argument: you buy exactly what you need, when you need it.
Why This Matters for AI Workloads
AI infrastructure has a storage challenge that scales differently from compute. Training pipelines need massive sequential throughput to feed GPUs. Inference needs low-latency random reads. Data lakes grow independently of processing capacity.
A disaggregated architecture lets you right-size each tier for the workload. Need more compute for inference? Add processor nodes without touching storage. Dataset doubled? Add JBOF shelves without buying CPUs. The capacity and performance scale independently.
Resilience Without Data Migration
One of the strongest advantages of this architecture is resilience. Because the flash capacity lives on the JBOF chassis, a processor node failure triggers no data rebuild at all. Surviving nodes reconnect over NVMe-oF instantly. Maintenance becomes non-disruptive — drain a node, patch it, bring it back. No data evacuation needed.
The Bottom Line
vSAN now covers the full spectrum — converged, disaggregated with dedicated storage nodes, and disaggregated with passive JBOF shelves. This gives architects a single platform that adapts to any workload profile, from traditional enterprise applications to the most demanding AI pipelines. The JBOF reference design proves that vSAN can deliver near-2 million IOPS and 58+ GB/s throughput with linear scaling — all through a familiar operational model.
Source: Samsung vSAN JBOF Reference Architecture Whitepaper (PDF)↗
Discussion
No comments yet. Be the first to start the discussion.