Killing the storage array controller
You don't need low-stack intelligence
Comment Stealthy startup ZeRTO's CEO Ziv Kedem could have opened his technology kimono in a comment on a storage controller location story.
The lengthy comment cited Cisco's Nexus 1000V virtual switch. It said: "When you are hypervisor resident, you can support things like VM vMotion and storage vMotion, without requiring any reconfiguration or complex management tasks."
What does this mean? The 1000V operates inside the VMware ESX hypervisor, not being a standard virtual machine (VM). Bearing that in mind let's take a fresh look at ZeRTO's intentions. Its CEO blogged about how hardware boxes are turning into software.
He asked: "When you run on top of a hypervisor and your storage is virtualised anyway (e.g. VMFS), does it really make sense to run all these services and operations inside the storage? Is there any benefit for replication, backup, encryption, clustering, etc. to stay outside the hypervisor, ‘looking up’ to the virtualisation and application layers? I think not."
He then cited the Nexus virtual switch. Put these three things together and we have ZeRTO creating software ethnology to run "replication, backup, encryption, clustering, etc." inside VMware's ESX hypervisor.
Why is this a good idea? Kedem writes: "Check out VMware's own SIOC (Storage I/O Control) functionality. It guarantees responsiveness for different VMs, even if they are running on the same disk.
"This functionality cannot reside in the storage array (or storage virtualisation appliance, even if it is a VM) since the array cannot differentiate different I/Os from different VMs. This is the reason VMware provided SIOC to solve this problem for their customers."
At first glance this idea would seem to chime with Xiotech's belief that storage arrays should concentrate on fast and reliable basic storage operations with upper-level storage controller functions moved up the stack to a server. Up to a point that is true, but the pure application of the ZeRTO idea is that the storage array is a JBOD (Just a Bunch Of Disks) with no inherent ability to cope with disk failures and recover from them.
Xiotech prefers the idea of a "storage brick" aggregating disks together and providing very much faster and very much more reliable access to and storage of data than a JBOD can provide. That needs "low-stack" intelligence as well as upper-stack intelligence. It's a where-do-you-draw-the-line argument.
Of course, with all storage controller functions in the hypervisor the commodity-based JBOD storage will be cheap, with Xiotech likely to point out that you get what you pay for. Hardware is a commodity but data is not, most assuredly it is not, and the hardware needs organising in a way to safeguard the data that doesn't suck up server core processing cycles
It seems likely that ZeRTO will push the idea of having your expensive storage array controller functionality cake while eating your cheap JBODs. No more need to shell out for EMC, HDS, HP, IBM or NetApp replication, mirroring, encryption, clustering, snapshots, deduplication, etc. that come with their arrays. These are software functions carried out by a hypervisor plug-in.
The net cost of the plug-in and JBODs will be far less than the cost of the storage arrays that ZeRTO, in our reading of its intentions, wants to replace. ®
Sponsored: Hyper-scale data management