We discussed about 2 node vSAN cluster in the last post. Let's look at a few key design factors for a 2 node vSAN cluster in this article.
VMware recommends, end users ought to be using 50% of the resources available in the vSAN 2 Node Cluster. In the event of a node failure, all of the virtual machines could be run on the surviving node. Not all customers, however, will desire to operate resource usage levels below or at 50%. Customers should be aware that even it is possible to run at higher utilization in each site, in the event of failure not all virtual machines will be restarted on the surviving node.
Network Design Considerations -
VMware vSAN requires these ports to be open, both inbound and outbound -
It is a best practice to implement separate vSAN networking on an alternate VMkernel interface, with alternate addressing. It is important to remember that vSAN uses the same TCP/IP stack as the Management interface, and therefore if an alternate interface is used, static routing must be in place for the vSAN node to properly communicate with the vSAN Witness Host. The Witness Host on the Witness Site will require a static route added so that requests to reach the 2 Node Cluster are routed out the WitnessPg VMkernel interface.
Bandwidth Calculation
It is another crucial factor that you must take into account while creating the 2 Node vSAN Cluster. The bandwidth requirement between the two main sites is dependent on workload and in particular the number of write operations per ESXi host.
Hosts designated as a vSAN Witness Host do not maintain any VM data, but rather only component metadata, the requirements are much smaller than that of the backend vSAN data network.
The required bandwidth between the vSAN Witness Host and each node is equal to ~1138 B x Number of Components /5s
1138 B x NumComp / 5 secondsThe 1138 B value comes from operations that occur when the Preferred Site goes offline, and the Secondary Site takes ownership of all of the components.
When the Preferred Node goes offline, the Secondary Node becomes the Primary Node. The vSAN Witness Host sends updates to the new Primary node followed by the new Primary node replying to the vSAN Witness Host as ownership is updated.
The 1138 B requirement for each component comes from a combination of a payload from the vSAN Witness Host to the backup agent, followed by metadata indicating that the Preferred Site has failed.
In the event of a Preferred Node failure, the link must be large enough to allow for the cluster ownership to change, as well ownership of all of the components within 5 seconds.
vSAN Heartbeats
As mentioned earlier, when vSAN is deployed in a 2 Node Cluster configuration, the vSAN Primary node is found in the Fault Domain designated as Preferred and the vSAN backup node is found in the alternate Fault Domain.
The vSAN Primary node and the vSAN Backup node send heartbeats every second. If communication is lost for 5 consecutive heartbeats (5 seconds) between the primary node and the backup due to an issue with the backup node, the primary node chooses a different ESXi host as a backup on the remote site. This is repeated until all hosts on the remote site are checked. If there is a complete site failure, the primary node selects a backup node from the “Preferred” site.
A similar scenario arises when the primary node has a failure.
When a node rejoins an empty site after a complete site failure, either the primary node (in the case of the node joining the primary site) or the backup (in the case where the node is joining the secondary site) will migrate to that site.
If communication is lost for 5 consecutive heartbeats (5 seconds) between the primary node and the Witness, the Witness is deemed to have failed. If the Witness fails permanently, a new Witness host can be configured and added to the cluster.
That's it for now. I'll conclude this post here. In the next blog we will discuss more about vSAN witness Node.
Thank you for reading!
*** Explore | Share | Grow ***
Comments