I just noticed I still had a demo recoding on my desktop from a couple of weeks ago. The topic is vSAN 6.6 configuration assist. Hadn’t done anything with it, so I just added the narratives and shared it on youtube. Only a 3 minute video and quickly shows you where Configuration Assist can be useful. Hope you like it.
VMware
Change multicast address when running multiple vSAN clusters in same VLAN
Before vSAN 6.6 we would always recommend to change the multicast address when running multiple vSAN clusters in the same VLAN. Now that with vSAN 6.6 we removed multicast, does this best practice/recommendation still apply? I went looking for a clear statement but couldn’t find any, until Cormac pointed me to the excellent vSAN Networking Guide he wrote together with Paudie. After reading the table a couple of times, this is what I would consider to be the new best practice/recommendation:
If you run a vSAN 6.6 cluster with on-disk format v5.0 then there’s no need to change the multicast address when you have multiple clusters in the same VLAN as there’s no chance older host can be introduced in to the cluster as they will be partitioned instantly.
If you run a vSAN 6.6 cluster with on-disk format pre v5.0 then it is recommend to change the multicast address when you have multiple clusters in the same VLAN as when older hosts are added the cluster switches back to multicast mode. Although this could be considered an “operational consideration”, to avoid problems we would recommend changing the multicast address.
We also stated in the past that you could give each vSAN cluster a different VLAN for the vSAN network, the same applies. You can use a single VLAN for multi clusters, as long as those clusters are vSAN 6.6 and running on-disk format v5.0.
I hope that helps.
vSAN 6.6: Manual vs Automatic Disk Claim Mode
I received this question on Manual vs Automatic disk claim mode in vSAN 6.6. Someone upgraded a cluster from 6.2 to 6.6 and wanted to add a second cluster. They noticed that during the creation of the new cluster there was no option to select “automatic vs manual”.
I think a blog post will be published that explains the reasoning behind this, I figured I would share some of it before hand so you don’t end up looking for something that does not exist. In vSAN 6.6 the “Automatic” option which automatically creates disk groups for you has disappeared. The reason for this is because we see the world moving to all-flash rather fast. With All-Flash it is difficult to differentiate between the capacity and cache device. For that reason, in previous versions of vSphere/vSAN you already had to grab the devices yourself when it was an all-flash configuration. With 6.6 we removed the “automatic” option as we also recognized that when there are multiple disk groups and you need to take disk controllers, and location of disks etc in to account it even becomes more complex to automatically form disk groups. In our experience most customers preferred to maintain control and had this configured to “manual” by default. As such this option was removed.
I hope that clarifies things. I will add a link to the article explaining it.
Disk format change going from 6.x to vSAN 6.6?
Internally I received a comment around the upgrade to 6.6 and the disk format version change. When you upgrade to 6.6 also the version of disk changes, it goes to version 5. In the past with these on-disk format changes a data move was needed and the whole disk group would be reformat. When going from vSAN 6.2 (vSphere 6.0 U2 that is!) to vSAN 6.6 there is no data move needed. The update is simply a metadata update, and on the average cluster will take less than 20 minutes.
When introducing encryption in to the environment you will need to evac data though as this will be a reformat of the disk. Reason for it being is that the disk will need to be encrypted and so will the data. This doesn’t mean however that if you want to “rekey” your environment a full format and data move is needed, vSAN Encryption has the ability to do a so called “shallow rekey” which means that the Key Encryption Key (KEK) will be replaced (see animated gif below), but not the Data Encryption Key (DEK). It is possible to do a deep rekey, but this will mean a full reformat and data evac of all disk groups. I hope that clears things up.
vSAN 6.6 available now
vSAN 6.6 is available now. Check the release notes before you upgrade! Also note that for vSAN users currently on 6.0 Update 3 – upgrade to vSAN 6.6 is not yet supported. If you like to learn more about vSAN 6.6 check the following material:
Note that vSAN 6.6 comes as a patch release, download the bits here from the vSAN 6.6 landing page: