[Linux-cluster] Howto define two-node cluster in enterprise environment

gcharles at ups.com gcharles at ups.com
Mon Jan 10 12:38:25 UTC 2011


While a third idle node in the cluster is a way to regulate the quorum votes, you're right in that it's not very economical.

A way to keep the quorum device from being an SPOF is to assure it is multipathed as well.  However, by default, the quorum code does not define the device from its multipathed name.  Instead, it defaults to the dm-# which we've proven in the past does not retain its name through reboots or rescans.  What you need to do is get the disk ID number of the shared quorum disk itself, and create an alias name for it in multipath.conf:
...
multipaths {
         multipath {
                 wwid                    36006016338602300ca974b4b1b7edf11
                 alias                   qdisk
         }
...

...then define it in cluster.conf with a device="/dev/mapper/qdisk" in the quorumd stanza.  When you enter a clustat, your qdisk should show up like this:

/dev/mapper/qdisk         0 Online, Quorum Disk

You can test this by disconnecting one of your SAN connections, and watch the cluster log.  It will show a loss of communication with the quorum disk for a few seconds and then return to normal.


Regards;
Greg Charles

-----Original Message-----
From: linux-cluster-bounces at redhat.com [mailto:linux-cluster-bounces at redhat.com] On Behalf Of Andreas Bleischwitz
Sent: Monday, January 10, 2011 5:25 AM
To: linux-cluster at redhat.com
Subject: [Linux-cluster] Howto define two-node cluster in enterprise environment

Hello list,

I recently ran into some questions regarding a two-node cluster in an enterprise environment, where single-point-of-failures were tried to be eliminated whenever possible.

The situation is the following:
Two-node cluster, SAN-based shared storage - multipathed; host-based mirrored, bonded NICS, Quorum device as tie-breaker.

Problem:
The quorum device is the single-point-of-failure as the SAN-device could fail and hence the quorum-disc wouldn't be accessible.
The quorum-disc can't be host-based mirrored, as this would require cmirror - which depends on a quorate cluster.
One solution: use storage-based mirroring - with extra costs, limited to no support with mixed storage vendors.
Another solution: Use a third - no service - node which has to have the same SAN-connections as the other two nodes out of cluster reasons. This node will idle most of the time and therefore be very uneconomic.

How are such situations usually solved using RHCS? There must be a way of configuring a two-nodecluster without having a SPOF defined.

HP had a quorum-host with their no longer maintained Service Guard, which could do quorum for more than on cluster at once.

Any suggestions appreciated.

Best regrads,

Andreas Bleischwitz

--
Linux-cluster mailing list
Linux-cluster at redhat.com
https://www.redhat.com/mailman/listinfo/linux-cluster




More information about the Linux-cluster mailing list