There are many storage systems on the market today that require a separate protected witness construct for high availability and fault tolerant data access. The quorum mandates that at least one server instance has ownership and active access to the underlying data subsystem. This arrangement is typical in cluster architectures. It’s important to recognize that a witness node in a clustered solution is vital for data awareness and data availability. For more information see here
As an example, here you will find a rudimentary design that illustrates where a witness makes a decision during a failure event, where Node 3 and 4 are isolated from the rest of the cluster. This arbitrated vote by the witness maintains order for a quorum to be met and eliminate split brain scenarios.
However, there is more than one way to meet the required demands of data availability and fault tolerance. DataCore is one such example of a data aware system that provides cluster like availability but without the high costs and complexity of a witness architecture. DataCore is a true "active-active" grid architecture and not a cluster architecture. Each of the nodes within the grid presents mirrored disks as "active-active" storage devices. This means that the backend storage is not only presented through one DataCore node, but it can be addressed via both DataCore nodes simultaneously (read and write, R/W).
Unlike a cluster solution, this grid approach won’t be affected by a split brain scenario, because every mirrored DataCore virtual disk is synchronously in sync. This means that each DataCore node functions similar to a witness node in that a decision is made where the active I/O needs to be acknowledged from, during a failure event. This also means one doesn’t have to figure out where to place a witness node for optimal design and failure handling.
Another way to think about this architecture is from the witness/quorum perspective. The responsibility of the witness is to make sure it has at least two votes within a clustered system and can thus achieve a majority decision on which site/node will be active during a failover scenario. For this comparison, one can think of DataCore’s grid architecture as having multiple intelligent witness nodes all actively participating making sure there is high availability and data redundancy. Having an active/active architecture with all server nodes acting as an intelligent witness with each other, one no longer needs to design another site/node just for witness protection.
All DataCore nodes can provide individual, autonomous services, and still only be accessed via a single DataCore node. The other peer DataCore node constitute a hot stand-by node for the (active) node and only becomes active should it be required during a failure event. This means one achieves a modern cluster like architecture without the limitations or complexity of dedicated witness nodes spread across geographic sites. There is no need to design a solution using DataCore software around a witness architecture. All DataCore nodes will function similar to a witness construct but provides a better architecture for data availability and redundancy.
So before asking ‘Can I have a witness’ the better question is why do you need one? If the objective is to keep your applications running with continuous availability, then why add the extra cost and complexity required to manage and support extra witness nodes. DataCore software will provide continuous availability, all with fewer nodes to manage while minimizing costs.