CamoiAguiar
Disclaimer - VMware Employee, working in the Storage and Availability Storage Unit - I could be biased :smileyhappy:
As an administrator (of storage/compute/directory services/collaboration services) for 15 years, it was always a challenge to "right size" storage for different workloads. (I've worked for a vendor since late 2010.)
Whenever I had to carve up storage for this/that/other workload, there was always a huge amount of work ensuring I met the requirements of the workload (performance, protection, capacity) while not being wasteful with that storage. It was common to have to size storage this way to meet a performance requirement, often wasting capacity, or size storage another way for capacity and either wasting performance, or not providing enough. What I like the most about Virtual SAN, is that it allows Administrator to individually assign policies per vmdk/object to allow for appropriate performance, capacity, or protection. Virtual SAN is a radical departure from the traditional sense of managing and consuming storage.
VMware Virtual SAN is integrated into the ESXi Hypervisor. Virtual Storage Appliances run on top of a hypervisor in a Virtual Machine.
It has been argued that the number of "hops" for data, when using a VSA can add significant overhead. The may or may not be the case. I don't know if I 100% agree with that. ESXi itself can handle massive IO, along with hardware of today, presenting storage from a VSA could be entirely appropriate for the workload expected. It is important though, to keep in mind that VSA's operate in the same space as other Virtual Machines. Things like CPU Ready Time and multiple vCPU scheduling requirements do not affect Virtual SAN in the way they do Virtual Machines. Additionally, Virtual SAN requires a small amount of host RAM, entirely dependent on the architecture (Hybrid vs All-Flash), capacity of cache devices, and number of cache devices.
Requirements for Virtual SAN 6.0 can be found here: VMware Virtual SAN 6.0 Requirements (2106708) | VMware KB
From a CPU overhead perspective, we typically state Virtual SAN requires around 10% CPU overhead.
Some features in Virtual SAN 6.2 (Deduplicaton&Compression, Erasure Coding, Checksum) add a small overhead to that.
We might be giving worst case values, as many customers report a lower overall utilization.
I'd also state that KB 2106708 mentions 32GB of RAM as a minimum, but that is only needed for a full compliment of disk groups. Most customer deployments are well below that requirement per host.
Another KB is a bit more indicative of Memory requirements: Understanding Virtual SAN 6.x memory consumption (2113954) | VMware KB
*My home lab (All-Flash) w/Micron P420m drives for caching (1 disk group) requires only 7.7GB of RAM per host.
Virtual SAN is compatible with:
And yes, Virtual SAN is only compatible with VMware vSphere, the most proven and widely deployed hypervisor.
Best regards,
Jase