Yellow Bricks

by Duncan Epping

vsan

Are the vSAN disks encrypted or not, and is the environment health?

· · Leave a Comment

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:

Are the vSAN disks encrypted or not, and is the environment health?

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?

· · Leave a Comment

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!

#094 – Discussing SAP HANA support for vSAN ESA 8.x with Erik Rieger!

· · Leave a Comment

Recently Broadcom announced that ⁠vSAN ESA support for SAP HANA was introduced⁠. Erik Rieger is Broadcom’s Principal SAP Global Technical Alliance Manager and Architect, and as such I invited him on the show to go over what this actually means, and why this is important for customers! Listen to the episode on Apple (https://bit.ly/42AKWze), Spotify (https://bit.ly/4j1Jo7r), via the player below, or your favorite podcast app. Make sure to like and subscribe wherever possible!

For more details, make sure to check:

vSAN Component vote recalculation with Witness Resilience, the follow up!

· · Leave a Comment

I wrote about the Witness Resilience feature a few years ago and had a question on this topic today. I did some tests and then realized I already had an article describing how it works, but as I also tested a different scenario I figured I would write a follow up. In this case we are particularly talking about a 2-node configuration, but this would also apply to stretched cluster.

In a stretched cluster, or a 2-node, configuration when a data site goes down (or is placed into maintenance mode) a vote recalculation will automatically be done on each object/component. This is to ensure that if now the witness ends up failing, the objects/VMs will remain accessible. How that works I’ve explained here, and demonstrated for a 2-node cluster here.

But what if the Witness fails first? Well, I can explain it fairly easily, then the VMs will be inaccessible if the Witness goes down. Why is that? Well because the votes will not be recalculated in this scenario. Of course, I tested this and the screenshots below demonstrate it.

This screenshot shows the witness as Absent and both the “data” components have 1 vote. This means that if we fail one of those hosts the component will become inaccessible. Let’s do that next and then check the UI for more details.

As you can see below, the VM is now inaccessible. This is the result of the fact that there’s no longer a quorum, as 2 out of 3 votes are dead.

I hope that explains how this works.