This question has come up a few times now, what does Datastore Sharing/HCI Mesh/vSAN Max support when stretched? It is a question which keeps coming up somehow, and I personally had some challenges to find the statements in our documentation as well. I just found the statement and I wanted to first of all point people to it, and then also clarify it so there is no question. If I am using Datastore Sharing / HCI Mesh, or will be using vSAN Max, and my vSAN Datastore is stretched, what does VMware (or does not) support?
We have multiple potential combinations, let me list them and add whether it is supported or not, not that this is at the time of writing with the current available version (vSAN 8.0 U2).
- vSAN Stretched Cluster datastore shared with vSAN Stretched Cluster –> Supported
- vSAN Stretched Cluster datastore shared with vSAN Cluster (not stretched) –> Supported
- vSAN Stretched Cluster datastore shared with Compute Only Cluster (not stretched) –> Supported
- vSAN Stretched Cluster datastore shared with Compute Only Cluster (stretched, symmetric) –> Supported
- vSAN Stretched Cluster datastore shared with Compute Only Cluster (stretched, asymmetric) –> Not Supported
So what is the difference between symmetric and asymmetric? The below image, which comes from the vSAN Stretched Configuration, explains it best. I think Asymmetric in this case is most likely, so if you are running Stretched vSAN and a Stretched Compute Only, it most likely is not supported.
This also applies to vSAN Max by the way. I hope that helps. Oh and before anyone asks, if the “server side” is not stretched it can be connected to a stretched environment and is supported.
Thank you Duncan!
As many (maybe all) of your posts, we needed it.
Hi,
Thanks for this post, these details are often missing from the docs..
Since in the case of the client side being vSAN Stretched Cluster you don’t distinguish between symmetric and asymmetric (although, if it’s symmetric, is it really a “stretched” cluster”?), does that mean that the vSAN logic on the client side understand the topology and only reads from the local hosts on the server side?
Kind regards
Well like I said, symmetric is not something we see often, but it does happen with campus clusters for instance with multiple buildings in relatively close proximity with similar bandwidth and latency.
And not, vSAN on the client side misses the fault domain logic, so reads will not be only local, that is the reason we do not support asymmetric. We are aware this is a gap and we are hoping to solve this in the future.
Thanks for the reply!
But doesn’t that mean this statement is not correct, or at least needs a caveat (only in symmetric case): “vSAN Stretched Cluster datastore shared with vSAN Stretched Cluster –> Supported”?
I don’t see why this statement would be incorrect to be honest.
That’s what I asked about, you said it isn’t supported? “…that is the reason we do not support asymmetric”. It can’t be both..
Ah, now I see the confusion. When the client is also a vSAN Cluster then there’s the notion of fault domains, and you can mix/match those fault domains so that reads are local.
If the client has NO vSAN, then you cannot mix/match those fault domains as that concept doesn’t exists, and as such we don’t know how traffic flows, which would be disastrous in an asymmetric world.
OK, that makes sense, thanks for clarifying. Is the matching of sites done just by names of the fault domains or is there an extra configuration step to set which is local to which?
There’s a step for the pairing.