Clustering Linux Servers with the Concurrent Deployment of HP Serviceguard Linux and Red Hat Global File System for RHEL5, October 2008

4
The concurrent deployment of HP Serviceguard for Linux and Red Hat GFS clusters on the same
group of servers must ensure that co-existence is stable. The concurrent deployment is based on
the criteria that, both the clusters, maintain the same cluster membership at all times; during
failures or normal cluster management operations. This ensures that, in case of a failure, both the
clusters, select and removes the same members from the cluster. The concurrent deployment of HP
Serviceguard for Linux and Red Hat GFS clusters must also ensure that the two clusters don’t
interfere with each other, especially with regard to ensuring data integrity during failures.
HP has tested these two clusters in a variety of failure scenarios and has documented guidelines in
this paper for using these two clusters together.
Audience
This document is for users of HP Serviceguard 11.18 on Linux who want to take advantage of the
features in Red Hat GFS for RHEL5. It documents the guidelines to implement a stable dual-cluster -
two clusters sharing the same hardware - with HP Serviceguard for Linux and Red Hat GFS for
RHEL5.
For the support of Serviceguard for Linux with Red Hat 4 and GFS 6.0 or GFS 6.1, continue to
use the white paper “Clustering Linux Servers with the Concurrent Deployment of HP Serviceguard
for Linux and Red Hat Global File System” February 2006 update.
It is assumed that the reader has a general understanding of HP Serviceguard for Linux and Red
Hat GFS for RHEL5 features. For more information on each solution, see
http://www.hp.com/go/sglx
and http://www.redhat.com/docs/manuals/csgfs.
Cluster membership
To better understand the requirements for co-existence which will be described later, it is best to
understand some of the aspects of the membership mechanisms of each cluster.
HP Serviceguard for Linux membership
When there is loss of heartbeat communication between the nodes, active cluster nodes execute a
cluster reformation algorithm that is used to determine the new cluster quorum (membership). This
new quorum, in conjunction with the previous quorum, is used to determine which nodes remain
in the new active cluster.
In Serviceguard for Linux, the algorithm for cluster re-formation requires a cluster quorum of a
simple majority i.e., more than half of the nodes that were previously running. However, exactly
half of the previously running nodes are allowed to reform as a new cluster, provided that a
quorum arbitrator guarantees that the other half of the previously running nodes do not also re-
form. Serviceguard for Linux supports lock LUN and quorum server as the quorum arbitrator.
However if more than half the nodes in the cluster fail at the same time, the remaining nodes have
insufficient quorum to form a new cluster and fail themselves.
Red Hat Cluster membership
Quorum rule
In Red Hat Cluster, the quorum is based on a simple voting majority of the defined cluster i.e., to
reform successfully, a majority of all possible votes is required.
In Red Hat cluster, each cluster node is assigned some number of votes, and they contribute to the
cluster while they are members. If the cluster has a majority of all possible votes, it has quorum
(also called quorate), otherwise it does not.