StarWind Software has just released a new version of their flagship software StarWind VSAN for VMware. OVF Version 20211012 Version V8 (build 14338). In case you don't know StarWind, you're missing out as it is one of the most cost-effective solutions for ROBO, where you only need 2 nodes to create a highly available solution. StarWind VSAN leverages the internal disks of each host, to create a highly available shared datastore where you run your VMs.
Unlike other systems, StarWind VSAN only needs 2-nodes (not 3) and still be able to avoid split-brain scenarios. A split-brain can happen if active nodes lose all synchronization and heartbeat connections between them at the same time and are not able to communicate anymore to define the synchronization state of the partner node.
When dealing with network partition, the highest priority is to eliminate the risk of split-brain and data corruption. Heartbeat is an advanced mechanism that is used to avoid data corruption in case of synchronization channel failure. If data can`t be transferred through the synchronization channel StarWind checks the availability of the second node through the alternate network interface, and shuts down the secondary node in case of synchronization channel failure.
StarWind VSAN for VMware – What's new in this new build?
StarWind Health Service was updated in this new build.
- Fixed the crash for client writes request handling.
- Fixed the deadlock for the processing of SCSI persistent reservation during client session registration.
- Fixed the issue with the service getting stuck when the log file would be located on the storage that had a degrading performance.
StarWindX PowerShell Module
- Fixed memory leak on getting information for HA devices.
StarWind VSAN, as with previous builds, this new build only fixes some issues, but not bringing new features.
What are the differences between the Heartbeat Failover strategy and Node majority failover strategy?
If there is no connection to another node, the StarWind service assumes the partner nodes are offline and continues operations on a single-node mode using data written to it.
Heartbeat strategy is when at least one heartbeat link is online, StarWind services can communicate with each other via this link. The device with the lowest priority will be marked as not synchronized and get subsequently blocked for further read and write operations until the synchronization channel resumption.
At the same time, the partner device on the synchronized node flushes data from the cache to the disk to preserve data integrity in case the node goes down unexpectedly. It is recommended to assign more independent heartbeat channels during replica creation to improve system stability and avoid the “split-brain” issue.
With the heartbeat failover strategy, the storage cluster will continue working with only one StarWind node available.
Node majority, on the other hand, is able to synchronize connections without any additional heartbeat links. When there is no connection to the partner the solution considers that there is a failure. The main requirement for keeping the node operational is an active connection with more than half of the HA device’s nodes. Calculation of the available partners is based on their “votes”.
Note: You'll need a “witness” (a 3rd node) for this strategy.
In case of a two-node HA storage, all nodes will be disconnected if there is a problem with the node itself, or in communication between them. The Node Majority failover strategy does not work in case of just two synchronous nodes. That's why it is necessary to add the third Witness node which participates the node's count for the majority, but does not have data and does not process clients’ requests.
With Node Majority failover strategy, failure of only one node can be tolerated. If two nodes fail, the third one will also become unavailable to clients’ requests.
The Witness node should be additionally configured for an HA device that uses Node Majority failover strategy if it is replicated between 2 nodes. In case an HA device is replicated between 3 nodes, no Witness node is required.
A cost-effective solution for synchronous replication by using 2-nodes only with heartbeat strategy. Worth to note that you can use “direct-connect” with two ESXi hosts and eliminate the use of physical switches. This brings costs down even more.
The use of ESXi free is also possible for those scenarios, but then you might consider other backup solutions than using traditional backup solutions such as Veeam. As you know, ESXi free version provides read-only access to certain APIs so those backup software solutions aren't able to leverage VMware changed block tracking (CBT) for incremental backups. There are some backup tool which are able to leverage
Recent StarWind news on ESX Virtualization:
- HCI Evaluation Kit From StarWind useful for quick cluster Sandboxing tests
- StarWind Backup Appliance (BA) with NVMe Storage Speed – New Product release
- StarWind SAN & NAS has been released !!!
- StarWind SAN & NAS Free For VMware vSphere Released
- StarWind VSAN as a truly fault-tolerant virtual storage pool
- Free License of StarWind VSAN from StarWind for IT pros
- StarWind HyperConverged Appliance for Video and Surveillance
- How to Build Your StarWind VSAN Infrastructure from Scratch and ensure that it runs at Maximum Speed
- StarWind Virtual SAN on Linux for VMware vSphere
- VMware ESXi Free and StarWind – Two node setup for remote offices
- VMware vSphere and HyperConverged 2-Node Scenario from StarWind – Step By Step
- StarWind Storage Gateway for Wasabi Released
- StarWind and Highly Available NFS
- StarWind VSAN on 3 ESXi Nodes detailed setup
More posts from ESX Virtualization:
- Upgrade VMware ESXi to 7.0 U3 via command line
- vSphere 7 U2 Released
- vSphere 7.0 Download Now Available
- vSphere 7.0 Page [All details about vSphere and related products here]
- VMware vSphere 7.0 Announced – vCenter Server Details
- VMware vSphere 7.0 DRS Improvements – What's New
- How to Patch vCenter Server Appliance (VCSA) – [Guide]
- What is The Difference between VMware vSphere, ESXi and vCenter
- How to Configure VMware High Availability (HA) Cluster