I had this question today, probably sparked by my post earlier where a showed a single-node cluster being able to leverage HCI Mesh to mount a remote vSAN Datastore. The question was if this also works with 2-node vSAN or with a vSAN Stretched Cluster. Unfortunately, the answer is no, a 2-node cluster or a vSAN Stretched Cluster is not supported with HCI Mesh today. Yes, this is a hard limit today, meaning that the “health check”, which is done before mounting the datastore, will actually report the issue and not allow it to progress. You can imagine that this is the result of the latency and bandwidth/throughput requirements there are in place for vSAN HCI Mesh today. This may, or may not, change over time.
Does vSAN Enhanced Durability work when you have a limited number of hosts?
Last week I had a question about how vSAN Enhanced Durability works when you have a limited number of hosts. In this case, the customer had a 3+3+1 stretched cluster configuration, and they wondered what would happen when they would place a host into maintenance mode. Although I was pretty sure I knew what would happen, I figured I would test it in the lab anyway. Let’s start with a high-level diagram of what the environment looks like. Note I use a single VM as an example, just to keep the scenario easy to follow.
In the diagram, we see a virtual disk that is configured to be stretched across locations, and protected by RAID-1 within each location. As a result, you will have two RAID-1 trees each with two components and a witness, and of course, you would have a witness component in the witness location. Now the question is, what happens when you place esxi-host-1 into maintenance mode? In this scenario, vSAN Enhanced Durability will want to create a “durability component”. This durability component is used to commit all new write IO to. This will allow vSAN to resync fast after maintenance mode, and enhances durability as we would still have 2 copies of the (new) data.
However, in the scenario above we only have 3 hosts per location. The question then is, where is this delta component created then? As normally with maintenance mode you would need a 4th host to move data to. Well, it is simple, in this case, what vSAN does is it creates a “durability component” on the host where the witness resides, within the location of course. Let me show you in a diagram, as that makes it clear instantly.
By adding the Durability component next to the witness on esxi-host-3, vSAN enhances durability even in this stretched cluster situation, as it provides a local additional copy of new writes. Now, of course I tested this in my lab. So for those who prefer to see a demo, check out the youtube video below.
Using HCI Mesh with a stand-alone vSphere host?
Last week at the French VMUG we received a great question. The question was whether you can use HCI Mesh (datastore sharing) with a stand-alone vSphere Host. The answer is simple, no you cannot. VMware does not support enabling vSAN, and HCI Mesh, on a single stand-alone host. However, if you still want to mount a vSAN Datastore from a single vSphere host, there is a way around this limitation.
First, let’s list the requirements:
- The host needs to be managed by the same vCenter Server as the vSAN Cluster
- The host needs to be under the same virtual datacenter as the vSAN Cluster
- Low latency, high bandwidth connection between the host and the vSAN Cluster
If you meet these requirements, then what you can do to mount the vSAN Datastore to a single host is the following:
- Create a cluster without any services enabled
- Add the stand-alone host to the cluster
- Enable vSAN, select “vSAN HCI Mesh Compute Cluster”
- Mount the datastore
Note, when you create a cluster and add a host, vCenter/EAM will try to provision the vCLS VM. Of course this VM is not really needed as HA and DRS are not useful with a single host cluster. So what you can do is enable “retreat mode”. For those who don’t know how to do this, or those who want to know more about vCLS, read this article.
As I had to test the above in my lab, I also created a short video demonstrating the workflow, watch it below.
vSphere Native Key Provider backup not working
I had three people asking this question the past few weeks, they were trying to configure the vSphere Native Key Provider so that they could enable vSAN Encryption, but the backup function wasn’t working. If you have not seen the Native Key Provider in action yet, just watch the video below.
As demonstrated in the video, when you configure the vSphere Native Key provider, you need to back up the key first before you can use it. Now, as mentioned, I had a few folks asking the past weeks why they couldn’t back up the key. The reason for it is simple, when you configure the Native Key Provider and want to back it up, you need to access the vSphere UI via the fully qualified domain name. In other words, when you access the H5 UI via the IP address of the vCenter Server, then the backup function won’t work. Also, when you have multiple vCenter Server instances in Linked Mode, you need to make sure you access the correct vCenter Server, the vCenter Server instance on which the Native Key Provider is enabled. Isn’t all of this documented? Yes, it is! But who reads documentation these days right?
vSAN File Services and Stretched Clusters!
As most of you probably know, vSAN File Services is not supported on a stretched cluster with vSAN 7.0 or 7.0U1. However, starting with vSAN 7.0 U2 we now fully support the use of vSAN File Services on a stretched cluster configuration! Why is that?
In 7.0 U2, you now have the ability to specify during configuration of vSAN File Services to which site certain IP addresses belong. In other words, you can specify the “site affinity” of your File Service services. This is shown in the screenshot below. Now I do want to note, this is a soft affinity rule. Meaning that if hosts, or VMs, fail on which these file services containers are running it could be that the container is restarted in the opposite location. Again, a soft rule, not a hard rule!
Of course, that is not the end of the story. You also need to be able to specify for each share with which location they have affinity. Again, you can do this during configuration (or edit it afterward if desired), and this basically then sets the affinity for the file share to a location. Or said differently, it will ensure that when you connect to file share, one of the file servers in the specified site will be used. Again, this is a soft rule, meaning that if none of the file servers are available on that site, you will still be able to use vSAN File Services, just not with the optimized data path you defined.
Hopefully, that gives a quick overview of how you can use vSAN File Services in combination with a vSAN Stretched Cluster. I created a video to demonstrate these new capabilities, you can watch it below.