We recently had a question from our field staff on behalf of a customer who is considering a 2-node VSAN (remote office/branch office) deployment. The query was regarding scale out of the VSAN deployment, should they reach resource limits on the 2-node implementation. We gave this some consideration, and the following were the sequence of events we thought an administrator may have to run through.
The assumption is that the current 2-node setup is in production with a witness appliance.
- Decommission 2-node setup to remove witness appliance
- Delete witness disk group from witness host
- Remove witness host from VSAN cluster
- Remove fault domains associated with the 2-node VSAN cluster
- This leaves you with a 2 node VSAN cluster with 2 copies of the data and no witness components.
- This also leaves the witness components in a degraded state
- There are also going to be some alarms associated with this, as well as errors in the health check
- Disable VSAN traffic on original witness appliance
- Add third host to the VSAN cluster
- Now you have a 3 node cluster, but the witness components are still absent.
- If the VSAN cluster is in manual disk claim mode, add a new disk group from the new node
- This would already be created if the cluster was in automatic mode
- With deduplication and compression enabled, the cluster would be in manual mode
- Wait 60 minutes OR repair all objects immediately via VSAN health check
- Re-balance the cluster via VSAN health check if necessary
- This should place data components on all 3 hosts
- Deploy a sample VM, and verify that witness component can be placed on any node in the cluster
We then tested this procedure out in our lab, and following the steps above, we successfully transitioned a 2-node VSAN deployment to a 3-node VSAN. Our virtual machines remained accessible throughout the procedure.
One final point to make is in relation to the licensing. Check the VMware VSAN site for differences between ROBO features and standard licensing features.
