Once a technology with convoluted vendor definitions, today's software-defined storage has gone mainstream, and most users, at the very least, understand what it achieves.
That's according to analyst and founder of Toigo Partners International, Jon Toigo, who says today there is a general consensus that software-defined storage products separate software functionality from the array controller in order to expose it to all the storage in the environment.
But there's still many different ways to achieve that. One of the approaches that is getting the most attention as of late is the software-defined storage appliance model. Appliance software-defined storage products, such as VMware's EVO:RAIL, are commodity hardware products that are sold with proprietary software that can offload some of the I/O to the storage controller for better application performance. Users find this beneficial because as opposed to buying a software-only version of software-defined storage, they don't have to install it on hardware themselves.
Toigo cited another benefit of the appliance model: easier migration. Unlike other software-defined storage configurations, appliances don't require copies of data to be stored on each node -- that means there's no increase in capacity demand. Data lives in one place, and moving an application from one location to another doesn't require replication.
But software-defined appliances are also proprietary, something some IT professionals may try to avoid in their storage technology. "Remember, it still leaves the control of your storage in the hands of the vendor who you buy it from," Toigo warned.
"I think in the long-term, some sort of unified storage with software surfaced away from the storage is the way to go, but I like storage virtualization to accomplish that better than I like using a proprietary hypervisor," he added.
Transcript - Consider appliance software-defined storage products
Software-defined storage is getting a lot of buzz, a lot of hype, and a lot of confusion around it. Where are we in terms of understanding it?
John Toigo: I think there has been a big breakthrough in understanding that there is a separation of software value-added functions from the array controller. I think that's a really important thing, and I have to give kudos to the hypervisor guys for making what that really means clear.
They've done a better job of defining it. I think [software-defined storage] went mainstream. People understand it now. The definition used to get gouged by the value-added software that the vendors were adding to the array controller. An array controller these days is nothing but a PC or a server mainboard that's installed inside a cabinet of disk drives. If you're booting a VMAX from EMC and you squint hard as it boots, you'll see Window Server 2008 R2.
If you're using VNX, it's Windows 7. So you realize that, "Hey, what I'm doing is I'm running a motherboard that's running like a PC," and in the case of EMC it's a VMware environment and then they have Wind River software for RAID and whatever value-added software products all running on this main board. Why does it have to live on the storage array? Why can't we take all that software and stick it somewhere under the hypervisor stack?" and then just delete the rest. I think that's way too confusing of a sentence and I can't figure out how to fix it. That makes more sense.
The big thing that's missing that I don't think people get is that even with this virtualization of storage, there's still a need to monitor the physicality of the storage. And we're still not doing anything about that. And we're also not doing anything about the data and managing the data we're throwing out on that infrastructure. So we've still have a junk drawer when it comes to storage. This hasn't done anything to fix the junk drawer. And that's where the real cost of storage comes from is we're putting mostly unmanaged data on mostly unmanaged hardware.
What about the appliance method? A lot of people are talking about appliances in software-defined storage products.
Toigo: Appliances solve a lot of problems. You have to remember that VMware always had a storage I/O problem. They knew it. They had some choke points built into their software and it was making reads and writes occur at a very slow pace. One of the first things they tried was putting in a bunch of their own proprietary commands in SCSI command language. And they didn't tell SCSI about it. So it didn't work with very many rigs.
Then they went to ANSI T10 and they got some approvals on some of those commands and they tried to make it right with the world, and they pretty well succeeded with that. But their strategy was to offload certain I/O operations down to the array controller, and the appliance model was born. Products like NetApp filers were certified to run with VMware, and you could use [vStorage APIs for Array Integration] VAAI commands and transfer things like mirroring down to the array and let the controller on the array deal with that so that VMware didn't have to. And that would speed up your applications a little bit. That was what the appliance model was all about originally. Now, at the last VMworld, I remember reading a a blog post by somebody who was there that said, "VMware just kicked all their appliance guys under the bus." They had good relationships with SimpliVity and with Nutanix and with a couple of others and then they announced they were going with EVO:RAIL which was basically their version of server-side storage by saying, "We're going to control it from now on with our own software-defined storage play." And they kicked all their partners under the bus. And so the partners are unhappy about that. They're publishing hate mail now about VMware, which is funny because a year ago VMware was the thing. [People were saying that] it's not a product, it's a movement. Now they're crying crocodile tears over it.
The bottom line here is that appliances have their place. It's certainly a lot easier to share an appliance. A NAS box was beneficial because the problem we have with VMware was if you were going to move workload from machine A to machine B, you were going to do template cut and paste or what they call vMotion. The storage had to be at the next location.
This server-side stuff that they're talking about today as software-defined storage means that we have to replicate that data behind every box that might potentially be a host for that application. Every node has the same data. That's a 300% increase in capacity demand. What's that going to do to your cost model? It's going to increase your need for more storage. Which I guess the vendors like a lot, but I don't know that I like it a lot as a user.
With an appliance, if you had the data in one place, when the application moved from place to place it could still access that network location where the data is located, and you wouldn't have to replicate it by 300%. You wouldn't have that kind of capacity demand growth. That's a very compelling argument. But remember, it still leaves the control of your storage in the hands of the vendor who you buy it from. It is not this software-defined stuff which is supposed to be the great leveler of storage arrays. I think in the long-term, some sort of unified storage with software surfaced away from the storage is the way to go, but I like storage virtualization to accomplish that better than I like using a proprietary hypervisor.
So how big of a challenge is this proprietary model?
John: I've had problems with hypervisors since they first came out. As far as I'm concerned, we've been down this path before. Remember, I'm an old guy. I have gray in my beard, and I started in a mainframe data center 35 years ago when there was the idea of service bureau computing and multi-tenant computing. In fact, it was really disaster recovery that drove that. The idea that SunGard would set up a mainframe and then many of its clients could all join into the mainframe, take a piece of the mainframe and recover themselves if they got hit by the same hurricane. And they had 30 years to work the bugs out so that if one application crashed, the rest of them would stay up and running. If client A had a problem it wouldn't affect client B's environment.
They came up with what were known as logical partitions inside the mainframe. Firewalls between different workloads so that what happened in one workload wouldn't impact others. The problem with x86 hypervisor technology is that the applications are literally stacked on top of each other. One application crashes and you have Jenga. They all come down. They still have a way to go to insulate against that kind of a risk. And, frankly, if I were putting mission-critical applications in a box, I don't know that I'd feel real comfortable putting them in a technology powered by Jenga. I can virtualize workload in the mainframe for $400 a workload. I need $25,000 software licenses to do it with VMware.
So even cost-effectively, I don't think that there's a good argument to be made there. And I've been saying this for a long time. Of course, I'm a hater. That's the way I'm described. I'm a hater.