JBOD may sound like the name of a Jersey Shore cast member, but it’s actually a simple acronym that means “Just a Bunch of Disks.”
Simply put, JBOD architecture lets you take a group of motley hard drives of various sizes and makes and configure them into either a single logical volume or into a group of individual hard drives.
The Basics of JBOD
The ancient (in Internet terms) website PC Guide says JBOD is the opposite of partitioning:
While partitioning chops single drives into smaller logical volumes, JBOD combines drives into larger logical volumes.
Because JBOD does not provide fault tolerance or performance enhancements, this 2001-era writer concludes, “JBOD doesn’t really have a lot to recommend it” over RAID 0 (a configuration that also lacks fault tolerance but at least offers performance improvements over individual hard drives or JBOD).
According to him, the only advantages JBOD offers over RAID 0 (or any other RAID configuration) are:
- Avoiding Drive Waste: If you have a number of odd-sized drives, JBOD will let you combine them into a single unit without loss of any capacity; a 10 GB drive and 30 GB would combine to make a 40 GB JBOD volume but only a 20 GB RAID 0 array. This may be an issue for those expanding an existing system, though with drives so cheap these days it’s a relatively small advantage.
- Easier Disaster Recovery: If a disk in a RAID 0 volume dies, the data on every disk in the array is essentially destroyed because all the files are striped; if a drive in a JBOD set dies then it may be easier to recover the files on the other drives (but then again, it might not, depending on how the operating system manages the disks.) Considering that you should be doing regular backups regardless, and that even under JBOD recovery can be difficult, this too is a minor advantage.
Given this faint praise, why would you consider using JBOD architecture? And really, why am I even discussing an architecture that seemed passé back in the Y2K era?
The Resurgence of JBOD
Well, it seems JBOD has become a more useful architecture as time has passed.
In a 2011 MSExchange.org article, Andy Grogan notes that JBOD “historically is a technology that you would not consider using with Exchange Server. However, in the context of Exchange 2010 there have been some changes which now make the JBOD a potential cost effective storage consideration for solution designers,” as long as you deploy JBOD storage architecture that uses Database Availability Group (DAG) technology for resiliency.
According to Grogan, Microsoft added two features that make JBOD a viable storage solution in Microsoft Exchange 2010 (and beyond) environments:
The first of which were a number of breakthroughs in the context of Exchange database IOPS performance, these include between 50% – 70% performance increases over Exchange 2007 as well as new algorithms within the core code which are optimized for SATA disks (the code was changed so that disk writes did not come in bursts – which normal non-Enterprise SATAe disk could not handle).
There are also a number of changes within the Storage Engine (such as Larger and Sequential I/O) which means that random reads and writes to the Database are significantly reduced as most data is stored sequentially (this reduces the number of Read / Write operations).
Putting all this into context – a single 7200RPM SATA drive with 1TB of Storage can potentially provide around 75 – 80 IOPS – this combined with the optimizations above puts JBODs in as an alternative storage option if your budget is limited.
Grogan recommends using JBOD and DAG if you run Exchange 2010 for a medium-to-large-sized enterprise that leverages tiered storage architecture. I recommend reading the article in full if you want more detail.
I’d also like to make a larger point. Back in 2001, JBOD was seen as a poor man’s RAID, something you used if you had a ragtag group of hard drives and lacked the resources or technology chops to deploy RAID architecture.
Today, however, JBOD is becoming increasingly popular as storage becomes larger and more intricate. Several Hadoop distributions, including Cloudera’s popular CDH, recommend using JBOD configurations when building Hadoop clusters.
The Register’s Trevor Pott makes this point when discussing the advantages of using a JBOD system:
You’ll need an operating system that understands this, of course, but that doesn’t look to be too big a problem. Windows’s failover cluster manager makes this push-button simple in Server 2012, and [other options] certainly are available.
Now that systems can leverage other technologies to handle issues like performance and disaster recovery, JBOD is important in a way the PC Guide world couldn’t conceive back in the day. Whether the cast members of Jersey Shore will have a similar impact several years down the road is still an open question…
Photo credit: Wikimedia