Episode #096 is a cross-post of the When Shit Hits The Fan Podcast episode. I loved the conversation with Johan and Jeff, and I hope you get something out of it as well! You can listen via Spotify (https://bit.ly/3GFTUTy), via Apple (https://bit.ly/4iSiUEh), or anywhere else you get your podcasts! Or just use the embedded player below.
#095 – Event Season Kickoff: NVIDIA GTC, KubeCon, and Dutch VMUG with Johan van Amersfoort
For this episode I decided to invite Johan van Amersfoort to discuss with us his experiences at NVIDIA GTC, Kubecon London, and of course the Dutch VMUG. Or should we say, the start of event season? Johan shared countless of updates and videos on LinkedIn, make sure to check those out while you are at it! Also, make sure to check out the “When Shit Hits The Fan” Episode I was featured on, which is hosted by Johan and Jeffrey! The Unexplored Territory Podcast episode with Johan can be found on Spotify (https://bit.ly/42TbMTp), Apple (https://bit.ly/42F14Pk), or just listened to below.
#094 – Discussing SAP HANA support for vSAN ESA 8.x with Erik Rieger!
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:
- SAP note 3406060 – SAP HANA on VMware vSphere 8 and vSAN 8 for details.
- SAP HANA and VMware support pages
- SAP HANA on HCI powered by vSAN
- vSphere and SAP HANA best practices
#093 – Best practices for Latency Sensitive Workloads featuring Mark A!
For episode 93 I invited Mark A to discuss with us what low latency workloads are all about, and what they require! Mark explains all the ins and outs of why vSphere, and VCF, is the perfect platform for latency sensitive workloads. Listen on Spotify (https://bit.ly/4bT0Lod), Apple (https://bit.ly/4kSbxiC), or just via the below embedded player!
vSAN Component vote recalculation with Witness Resilience, the follow up!
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.