Why you don’t need Vvols in Coho Data

whyyoudontneedvvolswithcohoWhy Coho’s Users don’t need vSphere Virtual Volumes (VVols)
Having driven the design of vSphere’s feature Virtual Volumes (VVols) as a product manager for what feels like an eternity after almost 4 years, you would naturally assume my first task at Coho Data would be to diligently oversee their integration into Coho’s products. When I made the move from VMware to Coho two months ago, many of my contacts asked if that is going to be my first order of business, while I silently muttered to myself “I sure hope not”.  And here is why…..

Virtual Volumes 101

In today’s world, everything is either LUN or Volume-centric and data services, such as Snapshots, Clones, Replication are based off these constructs. Virtual Volumes is all about moving storage from a LUN/Volume-centric to a VM-centric world.  This would enable the storage vendor to provide the same data services but at a VM level.

This means a lot, particularly for Block vendors, since it allows them to overcome limits associated with LUNs and present block storage at a fine granular level.

The inner mechanics of VVols are quite nifty – It bypasses ESX’s VMFS and NFS stack, and introduces a robust set of APIs. With these APIs, a storage vendor now creates small volumes on the array that backs up the VMDKs. The same set of APIs is then used to provide data services on those volumes. With just a set of APIs, you get fine granular representation of storage, scale and faster data services.

Frankly, this solves a long-standing storage problem that should have been addressed a long time ago.

Coho Data Architecture

That being said and being an ardent fan of Virtual Volumes, it still behooves me to talk about Coho Data’s architecture.

Coho’s Datastream MicroArrays are built for web scale solutions. Each MicroArray in the 1000h comes with 2 PCI-e Flash cards and 6 HDDs.  The MicroArrays come in pairs and they fit snugly in a 2U plug & play building block. If you want more capacity, you just keep adding the pairs of MicroArrays. Coho Data’s storage virtualization software runs on the array and creates coarse-grained objects (for those of you who are VMware die-hards, think of this as something similar to how VMware VSAN creates small VMDKs on local disks, except we create small objects).

A nice twist to the tale is the addition of the SDN component. Each MicroArray pair comes attached to a switches through 10Gbe network connectivity. Using Coho Data’s implementation of OpenFlow, a daemon runs on one of the array pairs. This along with the storage virtualization layer takes care of mapping the clients to the storage nodes in the backend while presenting a single namespace with a single NFS share to the storage administrator.

Coho Data Architecture

The architecture is truly fine granular – Everything is “per-VM” by default, because of the underlying object representation. Snapshots, replication and clones are at the object level.  For those vSphere admins who prefer to use vCenter for all their data operations, clones are offloaded to the Coho array using VAAI APIs. Snapshots and our SiteProtect replication are integrated with vCenter. Web scale economy of this architecture combined with per VM storage management renders unnecessary the need to retrofit VVols into the Coho architecture.

If you are interested in learning more about the gory details of the architecture, please visit www.cohodata.com.

Do I think we are at a disadvantageous position because we are not in the VVol vendor bandwagon?
Absolutely not.  I simply think VVols are not necessary in Coho Data systems.

5,643 total views, 2 views today