One of the most interesting (among the few) announcements at VMworld was regarding VSAN 6.1.
The product is quickly maturing and new features are being added version after version (here what’s new). And the product promises to be even better (with erasure coding and dedupe coming up in the next version!).
Even though some of the features could easily be disputable, like the 2-node cluster for ROBO (with its workarounds to make it work), VSAN is becoming a competitive product… And the fact that VMware owns all the stack makes this solution even more appealing from the simplification and support POVs.
I don’t know why (except that such a product can directly hurt EMC revenues), but I think that the potential of VSAN is totally underutilized.
VSAN is storage!
VSAN is a distributed scale-out storage platform and it is designed to offer (primary) storage resources within a VMware cluster.
But I’d like to repeat… scale-out, distributed, storage! In fact, this is very similar to what some startups are doing in the hyper-convergence/software-define space.
Hedvig, Cohesity, Nutanix, Rubrik (just to name a few) have a similar design, and even though the design principles and primary use cases are different… they are all distributed, scale-out storage platforms (again!).
Do you see the similarity now? Without questioning pros and cons of any single solution available, VSAN could have something to say in this space too.
Adding NFS/SMB or backup capabilities or any other data service you can think of, equals to adding one or more VMs/Containers doing that specific job!
Scale-out File services (SMB/NFS), Object storage (S3/Swift), Backup, HDFS and more, can be very easy to implement on top of a similar storage repository… and these are just the first things that pop into my mind. I’m sure that it won’t be difficult to find many more storage applications, especially because you can run sophisticated VMs (or containers now!) on top of the storage cluster to do whatever you want!
A different licensing model
All the services I have mentioned are part of what we usually call secondary storage, not your database or VM storage.
This product should see the light with a specific vSphere/VSAN licensing based on capacity and with a strong limit on supported/allowed VMs per node. But it would be a killer!
Nutanix, for example, has already caught on and is going to release a specific version of its product to address capacity needs of its customers.
End users need more (and more) capacity
VMware needs to play the same game and opportunities are plenty. All end users want more (and more) capacity but traditional vendors can’t seem to offer solutions that fully satisfy. TCA, TCO, ease of use and scalability are all key factors.
A VSAN-based secondary storage solution could satisfy their needs:
• Same architecture they love in their clusters
• Same UI
• Same functionalities
• Same vendor for all their infrastucture
• Same monitoring tools
• …
Without adding all the advantages for partners… they already know about each single piece of this technology, it’s just a different use case!
Why not?
Technically speaking I’m sure that something like this already exists in VMware labs, the potential is too huge to be ignored!
On the other hand I also think that the relationship between EMC and VMware is stopping this from happening, as well as many other innovations/evolutions. In fact, allowing to develop a storage solution like this one could be a great success for VMware in term of revenues but the first victim would be EMC itself… a company that is still number 1 in the storage market but, at the same time, is already seeing a decline in its hardware revenues.
Closing the circle
It was 2011 when I started talking about VMware as a potential big storage vendor. Now, 4 years later, VMware is still part of almost any storage conversation… but it isn’t making a lot of money out of it.
I’m still confident about VMware’s potential but they really need to think more about storage as a source of revenue and being more aggressive before it’s too late… and rumors about a VMware-led takeover of EMC definitely isn’t helping matters for the moment!
[UPDATE: looks like Duncan Epping has an interesting article on his website talking about a potential development of VSAN in the direction I’m hoping… Now, only time will tell if/when it will become a product.]
If you want to know more about this topic, I’ll be presenting at next TECH.unplugged event in Amsterdam next 24/9. A one day event focused on cloud computing and IT infrastructure with an innovative formula combines a group of independent, insightful and well-recognized bloggers with disruptive technology vendors and end users who manage rich technology environments. Join us!
Enrico,
I think the approach of bolting an Object or NAS package over a VSAN
(Hedvig way) is rather inefficient. Object and scale-out NAS need to have insight into network/disk locality, stripes, caches, failures, etc. Otherwise you end up with 2x more network traffic, IO amplifications, journaling overhead, sequential workloads become random, limited scalability, etc (in one of the
OpenStack/Vancuver sessions they showed HDFS in a VM over a RAID was 2x slower, and HDFS is not known to be fast).
You also end up paying CPU and memory cycles for things like replication, thin-provisioning, snapshots, dedup, consistency when those would need to be duplicated at the file/object layer anyway (Metadata replication, file/object versioning ..)
The right approach IMO is to build a good scale-out mutable object layer over raw disks or NVMe (I think it’s what Coho and Formation DS do), and treat vDisk, Files, etc, as yet another object type, but that is way more complicated to do and can’t be done in an after thought 🙂
Yaron
SDSBlog.com
Hi Yaron,
thanks for commenting.
I agree with you (again). But in this case there are other things to consider. VSAN is something very easy to sell (especially to VMware customers) and many end users don’t have multi-petabyte needs.
Look at sync&share for example. it’s not unusual to have end users asking for private sync&share with less than 100TB of data. many of these solutions can address various needs at the same time and they could be a good fit for this kind of non-high-demanding users… 😉