The most important feature for us is the converged infrastructure, which is all this tool is about. There is no need to manage separate storage areas in SAN/NAS environments. Storage management comes built-in with the vSAN tool. Storage is managed via policies. Define a policy and apply it to the datastore/virtual machine and the software-defined storage does the rest. These are valuable features.
Scalability and future upgrades are a piece of cake. If you want more IOPS, then add disk groups and/or nodes on the fly. If you want to upgrade the hardware, then add new servers and retire the old ones. No service breaks at all.
The feature that we have not yet implemented but are looking at, is the ability to extend the cluster to our other site in order to handle DR situations.
Improvements to My Organization
Provisioning virtual machines has been simplified, as there is no provisioning/management of the separate storage layer and it is no more in question.
Room for Improvement
The management client, i.e., the Flash-based client, is just not up to the mark. I’m really waiting for the HTML5 client to be fully ready and all the features are implemented to it. This, of course, is not a vSAN issue but a vSphere issue.
Of course as vSAN is tightly embedded into vSphere, it is also managed by the same tool. vSphere management is done via browser, and currently the only supported client is the flash-based one. VMware is rolling out a new HTML5 –based client, but that is a slow process. It began as a Fling and since then, there has been quite a number of releases as new features are added. It is today quite usable, but still not complete yet.
There is also the C# -client, also known as the fat-client, which is to be installed onto a management system. Recent versions of vSphere do not support the C#-client anymore. Thus the browser is the only possibility with current versions.
So, my criticism is aimed towards the current Flash-based client, which is utterly slow, and Flash itself being deprecated technology. The sooner we can get rid of it, the happier we all will be.
Use of Solution
I have used this solution for around a year.
Stability has not been an issue for us. We have not run into any serious software faults. VMware ESXi is a mature product with very few problems and today, vSAN is also getting there.
The scalability of the product is way beyond our needs.
Customer Service and Technical Support
L1 technical support, which I have mostly been dealing with, has been pretty solid, especially the guys in Ireland, who do handle it pretty well, both technically and in reference to the customer service aspect.
We did not have any comparable solution previously. We did previously use traditional SAN / NAS environments from where the storage areas were provisioned for the VMware clusters.
The initial setup was quite straightforward. All in all, it took three days to complete the entire process; that included installation of the hardware itself, installation of ESXi onto the hardware, creating the data center and the cluster, configuring the networks and multicasting on the surrounding network infrastructure, defining all the disk groups and networks at the cluster, and finally turning the vSAN on. vSAN was the simplest part of the whole process.
Pricing, Setup Cost and Licensing
As VMware products are licensed per number of sockets, you need to think this fully through. However, don’t go cheap on the number of hosts. You’ll thank me later.
Other Solutions Considered
We got presentations both from SimpliVity and Nutanix. No serious evaluation of other products was made. We did evaluate vSAN a couple months before the purchase, so as to get familiar with it, and we do have a lab environment now to play with.
In hindsight, we could have carried out a more-thorough evaluation of vSAN to get a really good feel about it; maybe even run a part of your actual production there for an extended period of time to see all the pros and cons.
Study the VMware Hardware Compatibility List (HCL) carefully with your server hardware provider and make sure all the components/firmware versions are on the HCL; either that or buy predefined hardware, a.k.a. vSAN-ready nodes, from a certified vendor. Always make sure that the hardware and firmware levels are on par with the HCL. You may have to upgrade; for example, you may need to upgrade the disk controller firmware when the updates to ESXi are installed. VMware does a pretty good job here and vCenter tells you that there are inconsistencies. However, you should still be prepared for that in advance, before actually installing the updates.
Don’t go with the minimum number of (storage) nodes, as that won’t give you enough room for a hardware failure during a scheduled maintenance break. For a minimum setup, without advanced options in vSAN 6.5 such as deduplication, compression and when Failures to Tolerate (FTT) = 1, the required number of nodes is three. VMware recommends in best practices a minimum number of four nodes. Do yourself a favour and go with at least that or even five would be good.
When disk groups are designed, it is always better to have more smaller disk groups than a few larger disk groups. This increases your availability, decreases time to heal from disk troubles and gives you an improved performance, as there are more cache devices.
If your budget allows it, then go with the all-flash storage. If not, go with even more disk groups. Our cluster has pretty good performance; although we have spinning disks, the read latency usually stays below 1ms and write latency stays below 2ms.
Plan your network infrastructure carefully, especially that part which handles the vSAN traffic. Go with separate 10G switches and dual interfaces for each server just for vSAN. Handle the virtual machine traffic, migration traffic and management traffic elsewhere. Go with 10G or faster, if you need that. Don’t use 1G for vSAN traffic, unless your environment is really small or is a lab.
Plan your backup / restore strategy really well and test it through. Test restore periodically for both full virtual machines and single files inside virtual machines. To carry out test restore is always important, but with vSAN it is even more so, as all your eggs are in the same basket and there are no more traditional .vmdk files that you can fiddle with. A separate test / lab vSAN cluster would be really good to test various things such as installing updates, restoring backups etc.
Disclosure: I am a real user, and this review is based on my own experience and opinions.