Now that VSAN 6.2 is officially launched, it is time to start discussing some of the new features that we have introduced into our latest version of Virtual SAN. Possibly one of the most eagerly anticipated feature is the introduction of deduplication and compression, two space efficiency techniques that will reduce the overall storage consumption of the applications running in virtual machines on Virtual SAN. Of course, this also lowers the economics of running an all-flash VSAN, and opens up all-flash VSAN to multiple use cases.
We are hearing about a number of VSAN stretched cluster implementations going on at the moment, which is great news. I just set up such a configuration once again in my lab as we look at some various scenarios for the next release of VSAN. Now, for anyone looking at implementing VSAN stretched cluster, there is the VSAN 6.1 stretched cluster guide which should be your first port of call. However I noticed that once VSAN stretched cluster is implemented, you get a few warnings that you typically wouldn’t see in standard VSAN deployments. That is what I want to…
In the VSAN Troubleshooting Reference Manual, the following description of VSAN.ClomMaxComponentSizeGB is provided: By default VSAN.ClomMaxComponentSizeGB is set to 255GB. When Virtual SAN stores virtual machine objects, it creates components whose default size does not exceed 255 GB. If you use physical disks that are smaller than 255GB, then you might see errors similar to the following when you try to deploy a virtual machine: There is no more space for virtual disk XX. You might be able to continue this session by freeing disk space on the relevant volume and clicking retry.
Attention VSAN users. A new Log Insight content pack has just been released specifically for Virtual SAN. For those of you not familiar with Log Insight, this product does automated log management through log analytics, aggregation and search. It allows administrators to analyze terabytes of logs, perform smart parsing to discover structure in unstructured data, and enable interactive, real-time search and analytics through a GUI-based, easy to use interface.
A short post to let you know about some upcoming speaking engagements that I am doing over the next couple of weeks. First up, I will be speaking at the TechUG, or Technology User Group event next week. This event will be held on Thursday, November 26th. It will be held in the Westin Hotel in the heart of Dublin city, Ireland. There is a really good agenda for this event (which is not a VMware centric event), that you can find at this link here. I personally will be speaking about Virtual SAN (VSAN), VMware’s hyper-converged compute and storage…
This week I was in Berlin for our annual Tech Summit in EMEA. This is an event for our field folks in EMEA. I presented a number of VSAN sessions, including a design and sizing session. As part of that session, the topic of VSAN memory consumption was raised. In the past, we’ve only ever really talked about the host memory requirements for disk group configuration as highlighted in this post here. For example, as per the post, to a run a fully configured Virtual SAN system, with 5 fully populated disk groups per host, and 7 disks in each…
There have been a number of questions recently about SMP-FT on Virtual SAN. The Symmetric Multi-Processing Fault Tolerance (SMP-FT) is a feature that many VMware customers have been waiting for. With the release of vSphere 6.0, the SMP-FT capability finally became available. This release did not include SMP-FT support when the VM was run on VSAN however. With the release of vSphere 6.0U1, which included VSAN 6.1, there is now support for SMP-FT when the VM is run on VSAN. There are some caveats when it comes to the different VSAN deployment methodologies: On standard VSAN deployments, SMP-FT is supported…