Installation guide

indeterminately long amount of time to start or stop. Unfortunately, a failure to stop (including a

timeout) renders the service inoperable (failed state). You can, if desired, turn on timeout enforcement

on each resource in a service individually by adding __enforce_timeouts="1" to the reference in

the cluster.conf file.

The following example shows a cluster service that has been configured with the

__enforce_timeouts attribute set for the netfs resource. With this attribute set, then if it takes

more than 30 seconds to unmount the NFS file system during a recovery process the operation will

time out, causing the service to enter the failed state.

</screen>

<rm>

<netfs export="/nfstest" force_unmount="1" fstype="nfs" host="10.65.48.65"

mountpoint="/data/nfstest" name="nfstest_data" options="rw,sync,soft"/>

</resources>

</service>

</rm>

E.3. Changing Consensus T imeout

The consensus timeout specifies the time (in milliseconds) to wait for consensus to be achieved

before starting a new round of membership configuration.

When consensus is calculated automatically, the following rules will be used:

If configuring a cluster of 2 or less nodes, consensus will be (token * 0.2) , with a maximum

of 2000 milliseconds and a minimum of 200 milliseconds.

If configuring a cluster of 3 or more nodes, consensus will be (token + 2000 milliseconds)

If you let cman configure your consensus timeout in this fashion, realize that moving from 2 to 3 (or

more) nodes will require a cluster restart, since the consensus timeout will need to change to the

larger value based on the token timeout.

When configuring a 2-member cluster with the ultimate intention of adding more nodes at a later time,

you must adjust the consensus timeout so that you do not have to restart the cluster to add the new

nodes. To do this, you can edit the cluster.conf as follows:

Note that the configuration parser does not calculate X + 2000 automatically. An integer value must

be used rather than an equation.

The advantage of the optimized consensus timeout for 2 node clusters is that overall failover time is

reduced for the 2 node case since consensus is not a function of the token timeout.

Red Hat Ent erprise Linux 5 Clust er Administ rat ion

120