Note - For a list of the specific devices that Oracle Solaris Cluster software supports
as quorum devices, contact your Oracle service provider.

Because cluster nodes share data and resources, a cluster must never split into
separate partitions that are active at the same time because multiple active partitions
might cause data corruption. The Cluster Membership Monitor (CMM) and quorum algorithm guarantee
that, at most, one instance of the same cluster is operational at any
time, even if the cluster interconnect is partitioned.

Split brain occurs when the cluster interconnect between nodes is lost and the cluster
becomes partitioned into subclusters. Each partition “believes” that it is the only partition
because the nodes in one partition cannot communicate with the node or nodes
in the other partition.

Amnesia occurs when the cluster restarts after a shutdown with cluster configuration data
that is older than the data was at the time of the shutdown.
This problem can occur when you start the cluster on a node that
was not in the last functioning cluster partition.

Oracle Solaris Cluster software avoids split brain and amnesia by:

Assigning each node one vote

Mandating a majority of votes for an operational cluster

A partition with the majority of votes gains quorum and is allowed to
operate. This majority vote mechanism prevents split brain and amnesia when more than
two nodes are configured in a cluster. However, counting node votes alone is
not sufficient when more than two nodes are configured in a cluster. In
a two-host cluster, a majority is two. If such a two-host cluster becomes
partitioned, an external vote is needed for either partition to gain quorum. This
external vote is provided by a quorum device.

A quorum device is a shared storage device or quorum server that
is shared by two or more nodes and that contributes votes that are
used to establish a quorum. The cluster can operate only when a quorum
of votes is available. The quorum device is used when a cluster becomes
partitioned into separate sets of nodes to establish which set of nodes constitutes
the new cluster.

Oracle Solaris Cluster software supports the monitoring of quorum devices. Periodically, each node
in the cluster tests the ability of the local node to work
correctly with each configured quorum device that has a configured path to the
local node and is not in maintenance mode. This test consists of an
attempt to read the quorum keys on the quorum device.

When the Oracle Solaris Cluster system discovers that a formerly healthy quorum device
has failed, the system automatically marks the quorum device as unhealthy. When the
Oracle Solaris Cluster system discovers that a formerly unhealthy quorum device is now
healthy, the system marks the quorum device as healthy and places the appropriate
quorum information on the quorum device.

The Oracle Solaris Cluster system generates reports when the health status of a
quorum device changes. When nodes reconfigure, an unhealthy quorum device cannot contribute votes
to membership. Consequently, the cluster might not continue to operate.

About Quorum Vote Counts

Both nodes and quorum devices contribute votes to the cluster to form quorum.

A node contributes votes depending on the node's state:

A node has a vote count of one when it boots and becomes a cluster member.

A node has a vote count of zero when the node is being installed.

A node has a vote count of zero when a system administrator places the node into maintenance state.

Quorum devices contribute votes that are based on the number of votes that
are connected to the device. When you configure a quorum device, Oracle Solaris
Cluster software assigns the quorum device a vote count of N-1 where
N is the number of connected votes to the quorum device. For example,
a quorum device that is connected to two nodes with nonzero vote counts
has a quorum count of one (two minus one).

A quorum device contributes votes if one of the following two conditions are
true:

At least one of the nodes to which the quorum device is currently attached is a cluster member.

At least one of the hosts to which the quorum device is currently attached is booting, and that host was a member of the last cluster partition to own the quorum device.

About Quorum Configurations

The following list contains facts about quorum configurations:

Quorum devices can contain user data.

In an N+1 configuration where N quorum devices are each connected to one of the 1 through N Oracle Solaris hosts and the N+1 Oracle Solaris host, the cluster survives the death of either all 1 through N Oracle Solaris hosts or any of the N/2 Oracle Solaris hosts. This availability assumes that the quorum device is functioning correctly.

In an N-host configuration where a single quorum device connects to all hosts, the cluster can survive the death of any of the N-1 hosts. This availability assumes that the quorum device is functioning correctly.

In an N-host configuration where a single quorum device connects to all hosts, the cluster can survive the failure of the quorum device if all cluster hosts are available.

A Network-Attached Storage (NAS) device from Oracles' Sun product line or from Network Appliance, Incorporated.

A quorum server process that runs on the quorum server machine.

Any shared disk, provided that you have turned off fencing for this disk, and are therefore using software quorum. Software quorum is a protocol developed by Oracle that emulates a form of SCSI Persistent Group Reservations (PGR).

Caution - If you are using disks that do not support SCSI, such as Serial Advanced Technology Attachment (SATA) disks, turn off fencing.

Note - You cannot use a replicated device as a quorum device.

In a two–host configuration, you must configure at least one quorum device to
ensure that a single host can continue if the other host fails. See
Figure 3-2.

Adhering to Quorum Device Best Practices

Use the following information to evaluate the best quorum configuration for your topology:

Do you have a device that is capable of being connected to all Oracle Solaris hosts of the cluster?

If yes, configure that device as your one quorum device. You do not need to configure another quorum device because your configuration is the most optimal configuration.

Caution - If you ignore this requirement and add another quorum device, the additional quorum device reduces your cluster's availability.

If no, configure your dual-ported device or devices.

Ensure that the total number of votes contributed by quorum devices is strictly less than the total number of votes contributed by nodes. Otherwise, your nodes cannot form a cluster if all disks are unavailable, even if all nodes are functioning.

Note - In particular environments, you might want to reduce overall cluster availability to meet your needs. In these situations, you can ignore this best practice. However, not adhering to this best practice decreases overall availability. For example, in the configuration that is outlined in Atypical Quorum Configurations the cluster is less available: the quorum votes exceed the node votes. In a cluster, if access to the shared storage between Host A and Host B is lost, the entire cluster fails.

Recommended Quorum Configurations

This section shows examples of quorum configurations that are recommended. For examples of
quorum configurations you should avoid, see Bad Quorum Configurations.

Quorum in Two–Host Configurations

Two quorum votes are required for a two-host cluster to form. These two
votes can derive from the two cluster hosts, or from just one
host and a quorum device.

Figure 3-2 Two–Host Configuration

Quorum in Greater Than Two–Host Configurations

Quorum devices are not required when a cluster includes more than two hosts,
as the cluster survives failures of a single host without a quorum device.
However, under these conditions, you cannot start the cluster without a majority of
hosts in the cluster.

You can add a quorum device to a cluster that includes more
than two hosts. A partition can survive as a cluster when that partition
has a majority of quorum votes, including the votes of the hosts and
the quorum devices. Consequently, when adding a quorum device, consider the possible host
and quorum device failures when choosing whether and where to configure quorum devices.

Atypical Quorum Configurations

Figure 3-3 assumes you are running mission-critical applications (Oracle database, for example) on Host A and
Host B. If Host A and Host B are unavailable and cannot access shared data, you
might want the entire cluster to be down. Otherwise, this configuration is suboptimal
because it does not provide high availability.