Since my previous post about VMware Virtual SAN ROBO Edition, I received some requests for a recorded demonstration of the configuration procedure for the Virtual SAN cluster for ROBO. Well, it happens to be a very simple process so I able to put a couple of systems together and record a demo.
There is one question in particular that I have been asked a few times that has to do with the configuration of the Fault Domains and the wizard that is utilized that I want to briefly discussed. The question I have been asked is:
Why is it that when configuring a Virtual SAN Cluster for ROBO, the wizard says – Configure VSAN Stretched Cluster when in reality this is not a stretched cluster configuration?
First of all, great observation and I think it is an observation that deserves an explanation. The reality is that from a configuration semantics perspective, the configuration procedure for creating a Virtual SAN Stretched Cluster and a Virtual SAN Cluster for ROBO are the same. Both capabilities are built upon Virtual SAN’s Fault Domain feature, which is a way in which the system qualifies logical failures zones.
From a Virtual SAN internals standpoint, both solutions are achieved with the identical internal functions. The cluster level object manager (CLOM), is configured to ensure that all of the virtual machines witness components are placed onto a witness node within the witness fault domain. Then, the cluster monitoring, membership, and directory service (CMMDS) orchestrates the management of the cluster formation, failover, and other functions of the Virtual SAN cluster.
The distributed object manager (DOM), and the local log-structure object manager (LSOM) are modified to accommodate all the required functions and behaviors of the cluster. All of these configurations and functions are performed as you go through the configuration wizard, and they are the same for both the stretched cluster and ROBO cluster.
When it comes down to it, the difference between the two use cases is really determined by the network connectivity, bandwidth requirements, and licensing models utilized for the two different use case and their implementation. If you think about it, in a ROBO implementation you are in essence extending (stretching) the cluster’s connectivity across to a remote site (witness fault domain) for centralized management. Beyond that, the implementation details and concepts are identical.
Because of these facts we can use the same exact wizard for both solutions. I have taken into account the observation and this is something I believe is worth bringing up with the Virtual SAN engineering team and see if we can come up with a solution that works for both use cases without causing any confusion from the UI perspective.
I hope that answers the question with regards to the configuration wizard and clears up any potential confusion that may have existed. Now without further delay enjoy the demonstration of configuring a Virtual SAN Cluster for ROBO use cases.
In the words of our VP of engineering Yanbing “Go Virtual SAN!!!” 😀
– Enjoy
For future updates on Virtual SAN (VSAN), vSphere Virtual Volumes (VVol) and other Storage and Availability technologies, as well as vSphere Integrated OpenStack (VIO), and Cloud-Native Apps (CNA) be sure to follow me on Twitter: @PunchingClouds
