HP Serviceguard Quorum Server Version A.04.00 Release Notes, May 2014

Configuring Serviceguard to Use the Quorum Server
About the QS Polling Interval and Timeout Extension
Serviceguard probes the Quorum Server at intervals determined by the QS_POLLING_INTERVAL
parameter in the cluster configuration file. The default value for QS_POLLING_INTERVAL is 5
minutes and the minimum value is 10 seconds.
If the quorum server process goes down while its node is still up, the Serviceguard cluster nodes
can detect the halt in the quorum server process. Serviceguard will try to reconnect to the quorum
server every 10 seconds until the quorum server is back up and the connection is successful. If the
quorum server is needed as a tie-breaker during this downtime, the cluster will halt.
However, Serviceguard cannot immediately detect the loss of connection to the process if the
quorum server’s node goes down. Serviceguard will continue to poll at the configured interval,
and will not discover that the quorum server connection is down until the next polling is done. If a
cluster reformation starts before the next polling has occurred, Serviceguard assumes the Quorum
Server is down. Because it requires the Quorum Server as a tie-breaker, it will halt the cluster. (Even
if the Quorum Server comes back up before or during reformation, Serviceguard will not know
that it has until the next polling.)
Reducing the QS_POLLING_INTERVAL means Serviceguard will detect Quorum Server failures
sooner, but it will also increase the load on the Quorum Server. If you set a short interval, you may
have to reduce the number of clusters or nodes using the Quorum Server to reduce the load. Test
very low settings carefully to fine-tune all timing parameters, and do the tests in an environment
that imitates the actual production environment as closely as possible.
You can use the optional QS_TIMEOUT_EXTENSION to increase the time interval (in microseconds)
after which the current connection (or attempt to connect) to the quorum server is deemed to have
failed; see “Network Recommendations” (page 8) and “Setting Quorum Server Parameters in
the Cluster Configuration File” (page 14).
Using Alternate Subnets
Some versions of Serviceguard (see “Compatibility with Serviceguard Versions” (page 9)) support
new functionality in the Quorum Server that allows you to configure more than one subnet on which
communication between the Quorum Server and the cluster nodes can take place.
In this case, you configure a primary subnet (indicated by the QS_HOST parameter in the cluster
configuration file) and a second subnet (indicated by QS_ADDR in the cluster configuration file).
Requirements for Using Alternate Subnets
All of the following must be true in order for you to configure more than one subnet for
communication between the Quorum Server and the cluster nodes:
• You must be running a version of Serviceguard, and of Quorum Server, that support this
capability. See “Compatibility with Serviceguard Versions” (page 9), and “System
Requirements and Recommendations” (page 7).
• All of the cluster nodes must be able to communicate with both of the Quorum Server subnets
when you configure or reconfigure the cluster.
If this is not true when you run cmquerycl, cmcheckconf, or cmapplyconf, the command
will fail.
• Both of the IP addresses specified for the Quorum Server must map to the same Quorum Server.
• The authorization file must specify all the addresses from which the cluster nodes will
communicate with the Quorum Server. See “Creating and Updating the Authorization File”
(page 18).
Configuring Serviceguard to Use the Quorum Server 13