Storage upstart tells El Reg: Our software's NOT a VSA
It's an accelerator. So there
Brouhaha Satyam Vaghani, the co-founder and chief technology officer of PernixData took exception to El Reg's characterisation of the startup's FVP software, which virtualises flash storage attached to virtualised servers and creates a single pool of block-addressable flash capacity across those servers.
From the small amount of information provided by the company about the new product, El Reg speculated that it would be like a disk drive-based Virtual Storage Appliance (VSA) such as HP's StoreVirtual (Lefthand) VSA. Vaghani said it is not. We had a discussion, and this is El Reg storage desk's understanding of PernixData's viewpoint.
According to its CTO, FVP is not a replacement for any other primary storage system but rather accelerates the execution of virtual machines - so if these VMs run VSAs then it will accelerate the VSA.
The company explains that any VSA networked storage provided through virtual machines (VMs), be it HP's StoreVirtual, a NetApp VSA or ScaleIO exports its capacity to applications with the vendor's ID and chosen protocol - iSCSI, NFS, etc. But if the VSA fails, then - in the same way it would if a storage array failed - you'd lose access to your data, which is, in a way, a definition of primary storage.
FVP is transparent to the primary storage, says PernixData. An EMC LUN still remains an EMC LUN, ditto HP or NetApp LUNs. The protocol remains the same - iSCSI, NFS, Fibre Channel, whatever. But if FVP fails or is closed, the primary storage stays in place, unlike in a situation where a VSA stops running.
From this explanation, it would appear FVP holds a copy of the primary storage data and is, effectively, a cache rather than a storage tier. "Cache" is my term and not PernixData's. With FVP pooling flash storage across servers, this would make it a distributed, virtualised cache.
But let's suppose a VSA doesn't fail and that it uses flash as well as disk. How would it compare to PernixData's SVP?
Again, this is my understanding of what happens. When an app in a VM using the VSA makes a data request it goes up into the hypervisor layer, down into the VSA, and then the reply, the data or acknowledgement, goes from the VSA up into the hypervisor again and down to the originating VM, making two hypervisor traversals. With FVP there is only one hypervisor to traverse, since it is in the hypervisor, which makes it faster.
Secondly, the more VMs using a VSA, the more likely there will be scheduling difficulties with the VSA scheduled less often, meaning the VMs are waiting for the VSA to run their IO requests and the VM is waiting to get scheduled.
My understanding now is that PernixData's FVP is not a VSA, rather it is a hypervisor-resident virtualised and distributed cache to accelerate apps in VMs by accelerating primary storage access transparently.
That said, how does it relate to VMWare's Virsto acquisition? Virsto's vDisk software is a VSA. Going by what PernixData has told us, FVP should accelerate it. ®
Sponsored: DevOps and continuous delivery