Chapter 3. Clustering

The PCS cluster stop operation now completes successfully when cluster nodes include resources that require DLM

When stopping the cluster on all nodes by running pcs cluster stop --all, resources that require the Distributed Lock Manager (DLM), such as gfs2 or clustered logical volumes, in some cases lost quorum before they were able to shut down. As a consequence, the stop operation became unresponsive. With this update, pcs cluster stop --all stops the cman service on all nodes only after Pacemaker has stopped those nodes. As a result, quorum is maintained while all resources are stopping, and the operation is thus able to complete successfully. (BZ#1322595, BZ#1353738)

The rgmanager daemon can now correctly start clustered services on surviving nodes when quorum is regained

With central processing mode enabled, when quorum was dissolved and regained, the rgmanager daemon stopped working on a surviving cluster node. With this update, the configuration tree is repopulated after quorum is regained. As a result, clustered services start up on the surviving cluster node as expected in the described scenario. (BZ#1084053)

Short time between the start of rgmanager and clustat no longer leads to rgmanager crashing

When the clustat utility was run shortly after the rgmanager daemon started but before it completely finished initializing, rgmanager was susceptible to unexpected termination. This bug has been fixed and rgmanager now starts without crashing in this scenario. (BZ#1228170)

rgmanager exits without problems after cman is stopped

When the cman service was stopped before the rgmanager daemon, rgmanager in some cases exited unexpectedly on cluster nodes. With this update, the cpg_lock() function has been fixed and rgmanager exits gracefully in the described scenario. (BZ#1342825)

Time-related values of cluster resource configuration are now evaluated properly

Previously, time-related resource values in actual use could differ from the values configured in the cluster.conf file, especially at the initial configuration load. This could cause the rgmanager daemon to behave unpredictably. With this fix, rgmanager behaves exactly as configured with regards to resources and respective time-related values. (BZ#1414139)