ESX Virtualization

VMware ESXi, vSphere, VMware Backup, Hyper-V... how-to, videos....

Latest Build of StarWind VSAN for VMware Released

By | Last Updated:

Shares

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.

Core

  • 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.

StarWind Virtual SAN

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.

 

Final Words

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:

 

More posts from ESX Virtualization:

Stay tuned through RSS, and social media channels (Twitter, FB, YouTube)

 

Shares
5/5 - (1 vote)

About Vladan SEGET

This website is maintained by Vladan SEGET. Vladan is as an Independent consultant, professional blogger, vExpert x16, Veeam Vanguard x9, VCAP-DCA/DCD, ESX Virtualization site has started as a simple bookmarking site, but quickly found a large following of readers and subscribers.

Connect on: Facebook. Feel free to network via Twitter @vladan.

x