Every 6-9 months VMware has been pushing out a new feature release of vSAN. After vSphere and vSAN 7.0, which introduced vSphere Lifecycle Manager and vSAN File Services, it is now time to share with you what is new for vSAN 7.0 U1. Again it is a feature-packed release, with many “smaller enhancements, but also the introduction of some bigger functionality. Let’s just list the key features that have just been announced, and then discuss each of these individually. You better sit down, as this is going to be a long post. Oh, and note, this is an announcement, not the actual availability of vSAN 7.0 U1, for that you will have to wait some time.
- vSAN HCI Mesh
- vSAN Data Persistence Platform
- vSAN Direct Configuration
- vSAN File Services – SMB support
- vSAN File Services – Performance enhancements
- vSAN File Services – Scalability enhancements
- vSAN Shared Witness
- Data-in-transit encryption
- Secure wipe
- vSAN IO Insight
- Effective capacity enhancements
- Enhanced availability during maintenance mode
- Faster host restarts
- Enhanced pre-check for vSAN maintenance mode
- Ability to override default gateway through the UI
- vLCM support for Lenovo
The first feature I would like to discuss is vSAN HCI Mesh. This feature was discussed at VMworld 2019 by Vijay, and now has made it into the release. What is HCI Mesh? HCI Mesh provides the ability to cross-mount vSAN Datastores. In other words, you can go to a vSAN based cluster and mount a vSAN Datastore from another vSAN Cluster. Why would you want to do this? Well, maybe you are running out of disk space locally for instance. HCI Mesh would now allow you to run VMs “locally” while having the storage objects be stored remotely. Of course, it means that an administrator will need to mount the remote datastore, and the decision will need to be made to use that remote datastore from a storage point of view, but if and when this is has been done the VM can even move between the cluster by simply doing a compute-only vMotion, as demonstrated in the below diagram. One thing to note is that we leverage the native vSAN protocol, and the datastore is not exposed through standard NFS or iSCSI etc.
Another huge feature is the vSAN Data Persistence Platform, which kind of goes hand in hand with vSAN Direct. Some of you may have heard about this project already, and basically what this is is a new framework that allows partners to build a tight integration with vSAN and enables customers to deploy data persistence platforms easily on top of vSAN! These data persistence services would be targeting cloud-native workloads. You can imagine that this framework would for instance enable you to easily deploy an S3 object storage solution on top of vSAN. Now typically a lot of these services already have their own replication mechanism to ensure the availability of data and service, hence we also introduce vSAN Direct. vSAN Direct enables you to deploy these services on vSAN without the need to leverage the data availability mechanisms that are part of vSAN but does provide the simplicity of vSAN management. In case you are wondering, the solutions that have been announced (for which we can expect integration in the future) are Dell EMC ObjectScale, Cloudian, DataStax, and MinIO.
Of course, there are also multiple enhancements for vSAN File Services. First and foremost, we introduce the support for SMB (v2.1 and v3) in 7.0 U1 next to NFS. As you can imagine, that also means we will include support for Active Directory for SMB, and we are also introducing the support for Kerberos for NFS! The interest in vSAN File Services has been overwhelming, and it is great to see how fast the team keeps adding features. In one of my blogs on the topic of vSAN File Services I mentioned that we would have at most 8 containers running in any given cluster, this number has also been increased to 32. This will provide not only better performance but also a more balanced environment in larger vSAN clusters.
vSAN Shared Witness is a feature especially customers running many edge locations will be interested in. So far customers had to deploy a Witness Appliance for every single 2-node cluster out there. Starting vSAN 7.0 Update you can now share your Witness Appliance, meaning that you can have up to 64 two-node clusters using the same Witness Appliance. This will greatly reduce the overhead typically associated with these witness appliances. Do note that the size of the Witness you deploy will determine the maximum number of clusters and components you can run on/against that shared witness. Please consult the documentation for more detail on this.
Over the past year or so we have provided VMware Cloud on AWS customers “compression only” as a feature for their vSAN based clusters. Starting 7.0 U1 we also provide this capability to on-premises customers. The great thing about “compression only” is that it comes at a much lower cost from a performance and resource point of view then Deduplication and Compression does, plus when it comes to availability compression only also shines as a single capacity disk failing does not impact the disk group. Enabling it is, of course, just a single click as shown in the screenshot below. The other feature that is shown in the screenshot that I want to mention is Data-in-transit encryption. We already had data-at-rest encryption, and we provided data-in-transit encryption via VM level encryption, but now with 7.0 U1 we also have this option natively as part of vSAN. And also from a security point of view, we provide the option to do a secure wipe of a disk via PowerCLI and/or the API, for those who need to wipe a disk using the decommission process for compliancy/regulations reasons.
vSAN IO Insight is a feature that has been promoted from a fling to generally available. I am sure many of you will appreciate it, as I have had conversations about the fling on many occasions. A lot of people saw the value that vSAN IO Insight brought, but they were hesitant to use a fling in production. Starting 7.0 U1 you will have the ability to analyze workloads using vSAN IO Insight right from the vCenter UI and in a fully supported way. After enabling the option for a workload and analyzing the workload for the configured time, you now have the ability to look at the workload IO characteristics in-depth via a new section in the UI called IO Insight as shown in the screenshot below
In terms of day-2 operations, there are 6 enhancements in vSAN which I can probably combine in 2 or 3 paragraphs. Starting vSAN 7.0 U1 we introduce what we internally refer to as “delta components”. These components are using to enhance the availability during maintenance mode. When you place a host into maintenance mode without evacuating the data, new writes would normally not comply with the selected protection level in your policy. Delta components solve this problem by simply creating a temporary component elsewhere in the cluster and allowing that new write to occur to the delta component. So in the case, a host fails during maintenance, you would still have 2 copies of that write available! We also introduce some changes around effective capacity, and how much capacity needs to be reserved for your vSAN Datastore, both for vSAN operations as well as to allow for a host rebuild to happen. The great thing about the new mechanism is that the larger the cluster is, the lower the overhead is from a reserved capacity stance.
We also introduce faster restart times as part of vSAN 7.0 U1, note that these improvements are not directly related to the vSphere Quickboot feature, but we actually introduce a mechanism to save and restore in-memory metadata. This will save a lot of time during maintenance where you potentially have to reboot a full cluster! Talking about maintenance mode, we also have enhanced the data migration pre-checks which were introduced in 6.7 U3. For vSAN 7.0 U1 we extended the functionality to not only do pre-checks for hosts, but also for disks and diskgroups!
Last but not least, I also briefly want to mention that vSphere Lifecycle Manager now also provides support for Lenovo, and we now also have the ability in the UI to configure the gateway for the vSAN VMkernel interface. This sounds like a tiny enhancement, and it is a tiny enhancement, but those doing something with stretched clusters, or vSAN on an L3 network will greatly appreciate it I am sure.
For those interested, I recorded three quick demo’s: