Witness node in a StarWind-based environment

INTRODUCTION

Contemporary business operations depend solely on applications. That means that IT infrastructure is critical to an organization’s success. Smooth operation, nowadays, is ensured through constant application uptime and high availability (HA). IT managers and system administrators use clustering mechanisms to achieve that. Usually, more than half of the nodes would be necessary to just keep the cluster operating on the desired level. Simultaneously, the storage cluster would normally use redundant HeartBeat connections to assure proper communication between nodes. However, such a feat won’t work for geographically disparate nodes. As a result, Node Majority was introduced to cater to that scenario.

PROBLEM

“Clustered environment” simply means that several servers (nodes) have been unified to serve as a single entity to applications. It also ensures HA, system scalability, and load balancing. Having an even number of nodes means that the entire cluster will shut down if half of those nodes fail, cutting off access to all data and applications. Such a disaster also creates a hazard of split-brain, which will lead to data corruption, if the nodes don’t have a proper voting mechanism in place for when they reconnect after losing network communication. Restoring data, in this case, will require using backups. For geographically disparate nodes, avoiding a single point of failure (SPOF) would require having redundant network connections between them but having several fiber channel connections isn’t always the way and it’s costly.

SOLUTION

To make sure that the entire cluster, along with all virtual machines (VMs) and applications, enjoys HA in the case of an even number of nodes, StarWind uses Node Majority. Here, a Witness node, which is a separate instance with minimum deployment requirements, is introduced to participate in the quorum voting. The Witness node in a StarWind-based environment secures that the system will continue running properly even if any of the nodes fail in a 2-node cluster. The possibility of split-brain is also eliminated since the StarWind Witness node will create a quorum and ensure correct cluster availability. Hardware isn’t principal in this case, as the Witness node can be deployed in cloud to ensure that the geographically disparate cluster will still show maximum uptime figures.

CONCLUSION

StarWind shrewdly leverages both HeartBeat as well as Node Majority mechanisms for any cluster configuration and node numbers. Moreover, StarWind has versatile options for setting up a Witness, hardware- or cloud-based, making it exceptionally easy to implement Node Majority. Your clustered environment is sure to experience the best possible high availability without any chances for downtime.