The migration to the VSAN cluster
What’s hot in storage industry? The answer to that question has radically changed over the last couple of years. Hyper-converged storage is now the new kid on the block!
At SecureLink and Raido, we work with various vendors such as Nutanix and VMware. VSAN is a fairly new product of VMware that now combines their already well-established hypervisor with hyper-converged storage features.
Does VSAN meet our business needs?
A VSAN implementation consists of a minimum of 3 hosts. Each host has at least 1 disk group which consists of 1 performance device (SSD) and multiple capacity devices (SDD or HDD). These disk groups will be committed to the Virtual SAN storage. VSAN will present a shared data storage to all hypervisors in that cluster.
Since we needed a new hardware platform capable of running our ever-expanding lab, we took a closer look in order to see if this solution could meet our needs.
We chose a Supermicro 4-node 2U chassis in a Hybrid configuration and made sure all components were listed on VMware’s HCL. The hardware had a few minuses on which I will elaborate later in this article.
Throughout the migration from our previous lab platform to the new VSAN cluster, we encountered a number of issues. This was mainly due to the fact that we couldn’t find any available official documentation on how to migrate the VSAN cluster from our temporary vCenter (which we used for initial testing) to the vCenter appliance of our lab environment.
On the first attempt, we migrated VSAN hosts in bulk to our lab vCenter. Unfortunately, this broke the existing VSAN configuration. The new vCenter tried to reconfigure the newly-added nodes with a new VSAN configuration (GUID). This resulted in corrupting the existing one.
If these were production nodes with critical business data, it would have resulted in 100% data loss.
Moving towards a healthy cluster
Obviously, we were not satisfied with these results. Therefore, we tried it again but this time, we used a different method:
First, we migrated a single host from the old cluster to the new VSAN cluster. That initial server will register with the new Vcenter and apply the cluster-enabled features. As there already is a VSAN partition of the old cluster on the server, the new cluster will reuse its UUID.
Subsequently, we moved the other 3 hosts to the cluster. This time, the cluster did not report any VSAN partition related issues, as it did in the previous attempt (see illustration above).
The cluster was healthy again. This is based on the only documentation I found about a VSAN moving cross DC / VCenter:
Note: If you try to add all of the ESXi hosts from the existing VSAN Cluster to the new VSAN Cluster at once, you will see an error regarding UUID mismatch. The trick is to add one host first and once that has been done, you bulk add the remaining ESXi hosts and you will not have an issue. This is handy if you are trying to automate this process.
After the host migration was over, we migrated all our lab VMs (+/- 320 VM’s) to the new VSAN cluster and declared the new VSAN cluster open for business!