VMware Cloud Foundation 9.0 was recently launched, and that means vSAN 9.0 is also available. There are many new features introduced in 9.0, so a perfect time to ask Pete Koehler to join the podcast once again and go over some of these key enhancements. Below, you can find the links we discussed during the episode, as well as the embedded player to listen to the episode. Alternatively, you can also listen to the episode via Spotify, Apple, or any other podcast app you may use. Make sure to like and subscribe!
vSAN
Introducing vSAN 9.0!
As most have probably seen, Broadcom has just announced VMware Cloud Foundation 9.0. Of course, this means that there’s also a brand new shiny version of vSAN available, namely vSAN 9.0. Most of the new functionality released was already previewed at VMware Explore by Rakesh and I, but I feel it is worth going over some key new functionality anyway. I am not going to go over every single item, as I know folks like Pete Koehler will do this on the VMware Blog anyway.
The first big item I feel is worth discussing is vSAN ESA Global Deduplication. This is probably the main feature of the release. Now I have to be fair, it is released as “limited availability” only at this stage, and that basically means you need to request access to the feature. The reason for this is that in the first release it is not supported yet in combination with for instance stretched clustering, so Broadcom/VMware will want to make sure you meet the requirements for this feature before it is enabled. Hopefully that will change soon though!
Now what is so special about this feature compared to vSAN OSA Deduplication? Well first of all, vSAN OSA is on a per diskgroup basis, whereas vSAN ESA is global deduplication. This should result in a much higher deduplication ratio, as the chances of finding duplicates are simply much higher across hosts than within a single disk group. Dedupe is also post-process, which removes the risk of a potential performance impact. On top of that, the layout of the data is done in such a way that vSAN ESA can still efficiently read large contiguous blocks of data, even when it is deduplicated.
The next feature, which is worth discussing, is specifically introduced for vSAN Storage Clusters (the architecture formerly known as vSAN Max) and is all about network separation. This new capability allows you to differentiate between Client traffic and Server traffic for a vSAN Storage Cluster. Which means that you could have east-west traffic within a rack for instance to a top-of-rack 100GbE switch, but do north-south to connecting clusters via a 10GbE switch, or any other speed. It not only provides a huge amount of flexibility, but it also improves efficiency, performance and security at the same time by isolating these traffic streams from each other as visualized below.
Then, the next big-ticket item isn’t necessarily a vSAN feature, but rather a vSAN Data Protection and VMware Live Recovery feature. Starting with 9.0 it will be possible to replicate VMs between clusters using the snapshot technology, which is part of vSAN ESA. This provides the big benefit of being able to go 200 snapshots deep at no (significant, single-digit) performance loss. On top of that, vSAN Data Protection can do this at a 1 minute RPO and leverages the already familiar UI and protection group capabilities that were introduced in 8.x. Big difference though being that you no longer have to download the vSAN Data Protection appliance, but that everything is now available as part of the VLR appliance.
The last thing I want to discuss is the vSAN Stretched Cluster functionality we introduced. I’ve already discussed this previously as a preview, but now it is available for stretched cluster customers to test out (Note, you do have to file an RPQ for both). vSAN Stretched Cluster Site Maintenance Mode is available starting with vSAN 9 for OSA via RPQ, and it allows you to place a whole site into maintenance while maintaining data consistency within the site. This solves a major operational hurdle for customers, as previously, customers would have to place a site into maintenance mode one host at a time. If you had a 10+10+1 configuration, that indeed meant you had to place 10 hosts into maintenance mode sequentially. This issue is now solved via a simple UI button!
Lastly, also for vSAN Stretched Clustering we are introducing, in “limited availability,” the vSAN Stretched Cluster Manual Take Over functionality. This will help customers who have lost a site that was placed into maintenance to regain access to their data. Of course, the idea here is though that over time this feature will also help customers to regain access to data when a data site and the witness fails simultaneously. It is a fairly delicate and complicated process, so as you can imagine, this is “limited availability” for now, as it requires some education/explanation of how this works and what the potential impact is of running the manual take over command.
I hope that provides an overview of some of the key functionality. I am also recording a podcast with Pete Koehler where we will discuss these capabilities soon, I will add the link to the podcast, and to the videos, when they are released.
#098 – VMware Cloud Foundation 5.x in a single box for homelabs featuring William Lam!
I noticed an excellent blog by William Lam not too long ago, which discussed how to bring up VMware Cloud Foundation 5.x on a single box for home labs. William created a Github page that goes over the whole process, and provided all the tweaks and scripts needed to get it done. I wanted to discuss this process with William, as I believe many folks in the VMware/Broadcom community will be interested in deploying this at home, or at work, to go through that full VCF experience but without needing a larger lab environment. You can listen to the episode on Spotify (bit.ly/43WFSpA), Apple (bit.ly/4jqbYyx), or any other podcasting platform. Or simply use the embedded player below! Thanks William, for a fantastic episode.
Are the vSAN disks encrypted or not, and is the environment health?
There was an internal question that came up, and I figured I would write a quick article as I had to grab some screenshots anyway. If you have vSAN Encryption – Data At Rest enabled, how do you verify the disks are actually encrypted? There are a couple of things you can do, and one is, of course verify in the vSAN UI that encryption is enabled in the configuration section. But you can also verify on a per-host basis if the disks have been encrypted through the command: esxcli vsan storage list. The output would look as follows:
As you can see, Encryption: true.
Of course, it is also beneficial to know if the Key Management System is reachable and healthy, as well as whether the necessary CPU instructions are available. These details can be viewed in vSAN Skyline Health, as shown in the next screenshot.
Hope that helps… OH, if you do use the Native Key Server, and encounter an error “not available on host”, verify if you enabled it with “Use key provider only with TPM” ticked or not, as if that is selected and you don’t have a TPM would result in that error.
Does vSAN support a Franken cluster configuration?
It is funny that this has come up a few times now, actually for the third time in a month. I had a question if you can mix AMD and Intel hosts in the same cluster. Although nothing stops you from doing this, and vSAN supports this configuration, you need to remember that you cannot live migrate (vMotion) between those hosts, which means that if you have DRS enabled you are seriously crippling the cluster as it makes balance resource much more complex.
You are creating a Franken cluster when mixing AMD and Intel. You may ask yourself, why would anyone want to do this in the first place? Well, you could do this for migration purposes for instance. If you use vSAN iSCSI Services for instance, this could be a way to migrate those iSCSI LUNs from old hosts to new host. How? Well, simply add the new hosts to the cluster, place the old hosts into maintenance, and make sure to migrate storage. Do note, all the VMs (or containers) will have to be powered off, and powered on again manually on the new hosts, as a result of moving from Intel to AMD (or the other way around).
If you do end up doing this for migration purposes, please ensure it is for the shortest time possible. Please avoid running with a Franken cluster for multiple days, weeks, or, god forbid, months. Nothing good will come out of it, and your VMs may become little monsters!
