[Pacemaker] Does pingd works on openais?

Atanas Dyulgerov atanas.dyulgerov at postpath.com
Mon Mar 10 05:13:51 EDT 2008

-----Original Message-----
From: Lars Marowsky-Bree [mailto:lmb at suse.de] 
Sent: Friday, March 07, 2008 9:18 PM
To: The Pacemaker cluster resource manager
Subject: Re: [Pacemaker] Does pingd works on openais?

On 2008-03-07T20:11:46, Atanas Dyulgerov <atanas.dyulgerov at postpath.com> wrote:

>> To lock the network block device if node fails to bring down the
>> service application or if for any reason the cluster software fails on
>> that node. In that case the application will be started on a passive
>> node and the cluster might end up with two nodes which try to access
>> the same data.
>Pacemaker/Heartbeat handle this through fencing/STONITH. It'd of course
>be fatal if not.
>But it does. Pacemaker already "locks" the resources to one node, and
>orders fencing, STONITH, start/stop etc as needed to ensure that
>resources are not running where they aren't allowed to.That's what a
>cluster resource manager is all about.
>I'm not sure what more you are asking for?

STONITH brutally shutdowns a node. To do that you need redundant communication lines, smart power devices and definitely a local cluster. For geographically separated cluster with remote nodes STONITH is not applicable.
The method is called Node Fencing and as I said it has too many obstacles. 

As for me a better choice is 'resources locking' option aka Resource Fencing. Instead of killing the errant node the cluster CRM just fence/lock its I/O access to the shared storage resource unit cluster messaging system reports back successful service stop on that node. Perfectly suits DR cluster and no need of additional communication lines. More elegant solution!

Heartbeat/Pacemaker does not support resource fencing. To fence resources, the resources have to support locking features by themselves. You cannot lock something that cannot be locked. Software iSCSI targets does not have locking mechanisms whereas GNBD does. However, GNBD locking features work with RedHat ClusterSuite only.

I don't understand what you mean by saying "Pacemaker already "locks" the resources to one node, and orders fencing ...". Which resources does Pacemaker lock?

What I'm trying to say is that the resource fencing is at least as important as node fencing. Pacemaker should be able to support the feature like RedHat Cluster Suite does. Resource locking should be supported in CRM/Pacemaker as well as in the resource by itself (gnbd, iscsi, drbd, etc...).

>> I don't have SAN. I'm looking for a cheaper solution. The reason I'm
>> not using NFS is the slower performance compared to the fastest GNBD
>> and iSCSI.
>Have you _benchmarked_ that for your workload?

Yes, I have benchmarked the application performance. With GNBD it had the best score, then comes iSCSI and NFS is at the end. 

> iSCSI/GNBD are
>block-level protocols, that means a higher overhead over the network.
>And because OCFS2/GFS2 do their own locking, the nodes also have a fair
>bit of additional internode communication.
>> Also a very specific service application is running on the cluster and
>> it does not get along with NFS very well.
>What kind of features does it use that don't get along with NFS? In
>theory, NFSv4/3 should be 1:1 compatible?

There are internal application bugs causing problems when running on NFS. I'm not familiar with them in details. NFS is not an option for me.


Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

Pacemaker mailing list
Pacemaker at clusterlabs.org

More information about the Pacemaker mailing list