[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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.

Greg Charles

-----Original Message-----
From: linux-cluster-bounces redhat com [mailto:linux-cluster-bounces redhat com] On Behalf Of Andreas Bleischwitz
Sent: Monday, January 10, 2011 5:25 AM
To: linux-cluster 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.

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 redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]