DataCore Chairman Ziya Aral shares opinions on the state of the storage industry and trends with flash, hyper-converged and software-defined storage.
DataCore Software Chairman and Founder Ziya Aral is a keen observer of the storage industry and where flash, hyper-converged and software-defined storage initiatives will take it.
SearchStorage recently caught up with DataCore’s Aral to discuss storage trends in software and hardware. As the chairman of a software-only company, he joked, “I hate hardware.” Still, DataCore’s SANsymphony-V software virtualizes other vendor’s hardware, so he needs to pay attention to it.
Below are excerpts from the interview.
What is the biggest challenge for you now, either in communicating to DataCore Software customers or from a technology perspective?
Ziya Aral: For us, it’s to dust ourselves off. The stuff that was a gleam in our eye 20 years ago and seemed practical to us 10 years ago is right now. Because there’s a lot of loose talk out there, it’s time for us to talk a little and to try new stuff and to shake ourselves off and get going. And, frankly, any allies are appreciated, including EMC. I think their whole technical picture on ViPR is brilliant. I urge people to read why and how they think this is going to evolve because I think it’s important. EMC is not the only one.
What caught your attention about ViPR?
Aral: EMC was the one holdout on a whole bunch of issues, and it should be ironic that they suddenly have embraced software-defined storage, and people like me should laugh because they did it in a really good way. I’m used to EMC—forgive me, EMC—taking really obvious things and twisting them to the point where I can’t recognize what the hell they’re talking about. Suddenly, it’s the opposite. This is a very interesting strategy and a comprehensive view of how the space is going to change, and they seem to be paying little attention to what the immediate or midterm impacts will be for their hardware revenue. I’m not used to large computer companies doing that. And maybe it doesn’t survive in EMC. Maybe it’s a trial balloon. But it’s fabulous. They’re the leader of the industry. For people like me, they have a tremendous impact—not just the direct and immediate impact but a long-term impact.
Will DataCore develop to ViPR now that EMC has made available an open source version?
Aral: We might. I’m not sure. I’m talking in general terms about ViPR. As software in its current level of implementation, it’s pretty crude stuff. It’s fairly primitive. I don’t believe we’re at the point where we can open the core environment, and they’re not opening the core environment.
DataCore Software’s recent annual user survey found there is little spending on big data, object storage and OpenStack, and most customers have no more than 10% of their capacity on flash. Did these results surprise you?
Aral: We anticipated that we’d see some real momentum in OpenStack and big data and the stuff that people read about and talk about, and we didn’t see it, at least, in the base that was surveyed. [There were] still a lot of ‘Not sure what to do with it’ kind of responses. The other hallway conversation that I ran into was that a lot of people apparently are slowing down adoption of flash internally. A significant number [28%] don’t have any flash, which surprised me to death. I thought everybody would have some flash to play around with. And the ones that have adopted flash have run into some performance issues associated with adoption.
What sort of anecdotal feedback have you gotten from DataCore customers on flash problems?
Aral: The typical problem is not knowing where to use flash. When they’re write-intensive [applications], it’s a lot more problematic than when it’s a read-intensive application. The other side of the issue is that a lot of people have gone to flash as an easy way to get tier one or quasi-tier one applications into the virtualization space. It’s not so easy necessarily. Part of the reason for virtualizing is to share the platform, and the demands of the applications on the platform can vary widely. I think it’s an open secret that flash has issues with writes, and you really have to take those into account when you build your architecture, or you have software that takes that into account for you. Across applications, that can be problematic.
The bigger issue is all-flash arrays. We hide the rotational latency of the device in the wire because the wire carries latency with it. If it’s local, it’s one thing. But if the array is sitting at the end of a wire shared by many others, that doesn’t have the same advantage as say an early Fusion-IO [drive] stuck in your bus. So, it raises architectural and complexity issues.
Haven’t vendors worked to overcome many of the problems with flash?
Aral: There are two classes of issues. At a higher level, people are putting [dynamic RAM] in front of flash and overcoming the writes that way, which is the way they overcome writes to disk. They’re cheating — and very effectively, by the way. I love working with this stuff, but there’s really no advantage between solid-state and rotational devices at that point, unless you’re really exceeding the ability of the front end to deal with it.
The other set of issues has to do with burnout. They’re more fundamental to the flash. The biggest issue used to be that flash had a limited number of writes that could be done to it before it burned out. So, when you burned out a block you had to substitute a new block. That happened all too often on a lot of the technologies that were employed, and you have this sort of continuous background garbage collection going on.
I can’t comment on whether those are as general as I’ve read or have the legs that we would hope that those technologies would have. Flash is here to stay. Don’t get me wrong. I’m not being an old fart about flash. It’s just that flash is not a panacea to anything. It helps at a whole bunch of places.
What do you think of hyper-convergence?
Aral: We have hyper-converged discussions all the time these days. There are two elements to hyper-converged. One is sort of the VMware plot to use another wire around that hyper channel because all the software guys conspire to play with hardware. So, [VMware] didn’t like the wires. They wanted new wires. That part of it, ho hum. But the really interesting thing is the idea of putting the storage stack on the same box as the applications and then putting the network stack on that same box. It’s so obvious and so beneficial. Everybody can pile on to one of these machines that don’t cost much, and they’re reasonable, and they’re rocket ships, and the whole game is changing. It’s fantastic.
What value does DataCore bring to a hyper-converged system?
Aral: First, we do hyper-converged. We will run on any Windows machine, and we are the stack. There’s nothing out there that says you have to have a VMware box as a hyper-converged platform. And then, frankly, we can also run on the VMware box. We take about a 7% penalty on running in a virtual machine.
Second angle is we’ll run over any wire. You don’t have to buy the box and the wire from us. We’ll run on everything. Third angle is that you can place us and architect us anyway you’d like. In my opinion, every server built will have a storage stack on it pretty soon.
How do you position the DataCore Software hyper-converged Virtual SAN (VSAN) product versus your core SANsymphony product that can be used to create hyper-converged systems?
Aral: We built VSAN as a front end to SANsymphony. Our assumption was that it would migrate to servers that were capable of and needed to bring the storage stack closer to it. It wasn’t built as a replacement for or an alternative to SANsymphony. We increased the node counts radically. Right now, we’re qualified at 128 nodes, and we’re going to qualify at 1,024. We never thought that we would build networks with 1,024 servers in them. That’s front end. We’re anticipating the day when the storage stack runs on everything.
Read the full article: DataCore Software chairman lauds EMC’s ViPR strategy
