Configuring the tiebreaker

Configure a tiebreaker for cluster environments with an even number of nodes.

System Automation for Multiplatforms requires the majority of nodes to be online in the domain to start automation actions. If the domain consists of an even number of nodes, it might happen that exactly half of the nodes of the domain are Online. In this case, System Automation uses a tiebreaker to decide the quorum state, which determines whether automation actions can be started (HAS_QUORUM), or if no automation actions are possible (PENDING_QUORUM, NO_QUORUM).

Configure a shared disk tiebreaker such as ECKD or SCSI by using the IBM.TieBreaker resource class. Additionally two tie breakers are predefined, operator and fail. The operator tiebreaker provides an undetermined result when a tie occurs and it is left to the administrator to resolve the tie through granting or denying the operational quorum. When a tie occurs and a tiebreaker of type Fail is active, the attempt to reserve the tiebreaker is always denied. The default tie breaker type is set to Operator.

Additional implementations of a tiebreaker can be added by using the tiebreaker type EXEC. System Automation for Multiplatforms provides a network and an NFS tiebreaker as additional tiebreaker implementations.

List the available tiebreaker type:

lsrsrc -c IBM.TieBreaker

Output:

Resource Class Persistent Attributes for: IBM.TieBreaker
        resource 1:
                  AvailableTypes ={["SCSI",""],["EXEC",""],["Operator",""],["Fail",""]}

List the tiebreaker name:

lsrsrc IBM.TieBreaker

Output:

Resource Persistent Attributes for: IBM.TieBreaker
        resource 1:
            Name                = "FAIL"
            Type                = "FAIL"
            DeviceInfo          = ""
            ReprobeData         = ""
            ReleaseRetryPeriod  = 0
            HeartbeatPeriod     = 0
            PreReserveWaitTime  = 0
            PostReserveWaitTime = 0
            NodeInfo            = {}

        resource 2:
            Name                = "Operator"
            Type                = "Operator"
            DeviceInfo          = ""
            ReprobeData         = ""
            ReleaseRetryPeriod  = 0
            HeartbeatPeriod     = 0
            PreReserveWaitTime  = 0
            PostReserveWaitTime = 0
            NodeInfo            = {}

resource 3:
           Name                = "myTieBreaker"
           Type                = "SCSI"
           DeviceInfo          = "ID=0 LUN=0 CHAN=0 HOST=2"
           ReprobeData         = ""
           ReleaseRetryPeriod  = 0
           HeartbeatPeriod     = 5
           PreReserveWaitTime  = 0
           PostReserveWaitTime = 0
           NodeInfo            = {}

resource 4:
           Name                = "mytb"
           Type                = "EXEC"
           DeviceInfo          = "PATHNAME=/usr/sbin/rsct/bin/samtb_net 
                                           Address=192.168.177.2"
           ReprobeData         = ""
           ReleaseRetryPeriod  = 0
           HeartbeatPeriod     = 30
           PreReserveWaitTime  = 0
           PostReserveWaitTime = 30
           NodeInfo            = {}
           ActivePeerDomain    = "21"

Although you can define several tiebreaker resources in the resource class IBM.TieBreaker, only one of them can be active in the cluster at the same time. Enter the following command to list the tiebreaker that is active in the cluster:

lsrsrc -c IBM.PeerNode OpQuorumTieBreaker

Output:

Resource Class Persistent Attributes for: IBM.PeerNode
        resource 1:
          OpQuorumTieBreaker = "Operator"

Set the active tiebreaker:

chrsrc -c IBM.PeerNode OpQuorumTieBreaker="Operator"

Enter the following command to grant or deny the operational quorum when tiebreaker is Operator:

runact -c IBM.PeerDomain ResolveOpQuorumTie Ownership=1 (0 to deny)

Note: To avoid race conditions, the operator tiebreaker must be denied for the losing subcluster. Then the operator tiebreaker can be granted to the subcluster, which is supposed to continue.