Hello Greg,

On 01/10/2011 01:38 PM, [email protected] wrote:
> 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
>          }
> ...
This will not eleminate the SPOF using one ONE storage... What I meant
is using at least two storage devices in different locations i.e. DCs.
I'll assume serious SAN connections are always using multipath ;) And by
the way, I would prefer using the qdisc-label - which should be unique
and is scanned during start of qdiscd.
> 
> ...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.
... and qdisc will fail if the underlaying SAN device got lost - f.e.
power failure in one DC. As already said, SAN-storage will be mirrored
to two DCs using cmirorror, but this is not possible for the qdisc.

Thanks for your answer, anyways.
> 
> 
> Regards;
> Greg Charles
> 
> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Andreas Bleischwitz
> Sent: Monday, January 10, 2011 5:25 AM
> To: [email protected]
> 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
> [email protected]
> https://www.redhat.com/mailman/listinfo/linux-cluster

--
Linux-cluster mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-cluster

Reply via email to