[Pacemaker] Does pingd works on openais?

[Andrew Beekhof]

On Mar 10, 2008, at 10:13 AM, Atanas Dyulgerov wrote:

>
>
> -----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.

Technically it does (or could)... you just need to write an RA that  
implements the locking you want.

a) write the locking RA
b) run it everywhere as a clone
c) have the RA "fail" when the node/resource/whatever (a fancy version  
might implement more than one zone) is "fenced"
d) have any resource that needs resource fencing depend on the lock  
resource (colocation)

At least thats how I remember the discussion.
I forget exactly how the exclusion of the node (so that the locking  
resource fails) was going to work... maybe a new stonith plugin would  
do the trick.

> 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.
>
> Regards,
> Atanas
>
> -- 
> 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
> http://list.clusterlabs.org/mailman/listinfo/pacemaker
>
> _______________________________________________
> Pacemaker mailing list
> Pacemaker at clusterlabs.org
> http://list.clusterlabs.org/mailman/listinfo/pacemaker