Evil SAN Will Always Triumph Because Good JBOD is Dumb

Tom Lyon is Chief Scientist for DriveScale.

“Evil will always triumph because good is dumb.” -- Dark Helmet, Spaceballs

A colleague of mine (jokingly?) claimed that it has been a longtime ambition of his to find a way to use this classic film line in a work context. Well, here it is! And it even makes sense: SANs are evil, and JBODs are dumb.

Now, obviously, SANs don’t triumph in all situations, but they are a pretty foundational element of many data center deployments. They build in a lot of intelligence to magically make failures disappear, provide a host of features such as dedupe, and allow you to pool your storage resources. Sure they are expensive, but you get what you pay for, right? You probably aren’t thrilled to be forking over the amount of cash that’s needed for purchase and maintenance and there is a lot of “proprietary” written all over them but they are a necessary evil (okay, not pure evil) if you want storage consolidation.

A JBOD, on the other hand, is “just a bunch of disks” whether deployed as internal server DAS or alongside a server in an enclosure. They are “dumb” as the name even implies. No RAID, just pass-through. In other words, it's a poor man’s storage solution, so caveat emptor. Now, it is important to point out that not all JBOD enclosures are really JBODs. I think of a JBOD enclosure as literally a bunch of disks, some storage expanders, and sheet metal housing, but some folks slap some processors into the box as well. I, as a purist, think that doesn’t sound like “just a bunch of disks” but rather “a bunch of disks with some processors”, but that’s just me. For the purposes of this article, anytime I refer to a JBOD enclosure, I am specifically referring to a purist’s definition of a JBOD enclosure.

What are JBODs Used For?

It’s useful to understand the advantages of a JBOD first. The two main advantages of JBODs are that they allow you to get at all the space on the drives (since they don’t use RAID), and they are, relatively speaking, cheap. On the other hand (since they don’t use RAID), they lose the redundancy and performance advantages that RAID can provide. As a result, JBODs tend to be used in places where storage capacity is tantamount and failure at the disk level would not be catastrophic. JBOD enclosures stuffed full of disks could provide a server with a storage controller a relatively large number of drives. (Of course, with a JBOD enclosure, if you need RAID functionality for a file server or some such you can have that server’s storage controller be a RAID controller or utilize RAID in software.) JBODs are also sometimes deployed as disk shelves managed by a separate storage head controlling a broader system.

More recently, JBODs have become an important part of some data-heavy Scale-Out deployments, where application software can be assumed to manage around drive failure. For example, the Open Compute Project’s Open Vault (original code name “Knox”) JBOD specs are ones that were contributed by Facebook, which utilized variants of them in their data centers. In the case of OCP, JBODs were used as the storage building block in server disaggregation. However, they still live down to their expectation of being a poor man’s storage solution with limited manageability and sharing, plus JBOD enclosures are extraordinarily limited in enterprise penetration, even for Scale-Out use cases.

So what’s the point? In scale-out environments, the sheer volume of data can make the use of traditional centralized storage technologies very expensive or even impossible, and the application stacks themselves assume that they have direct access to disk. JBOD enclosures, being the cheap beasts that they are, look tantalizingly attractive for those environments as a way to provide some kind of pooled storage. If they weren’t so dumb it feels like they should be able to offer real value in enterprises with Big Data needs. There has to be a better way.

First, JBOD vendors themselves need to start drinking the Kool-Aid around easy machine-driven management for scale-out. Scale-Out environments can get big, and people shouldn’t be forced into individual device management in big environments. Easy to understand device mapping and machine readable unique serial numbers are examples of enabling technologies that have the potential to usher us into an era of machine-driven management.

Second, the way in which JBODs are used must change. JBODs should be made into shareable entities and make friends with smarter management systems that can make them sing. At the application level, software-defined storage stacks can make JBOD storage capacity shareable. At the infrastructure level, technologies like DriveScale’s can enable JBODs to provide storage in a transparent way to Scale-Out application stacks broadly.

In other words, good can triumph, but it needs friends to help it along.

Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.