On Mar 10, 2008, at 10:13 AM, Atanas Dyulgerov wrote:
-----Original Message-----
From: Lars Marowsky-Bree [mailto:[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]
> 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@clusterlabs.org
http://list.clusterlabs.org/mailman/listinfo/pacemaker
_______________________________________________
Pacemaker mailing list
Pacemaker@clusterlabs.org
http://list.clusterlabs.org/mailman/listinfo/pacemaker
_______________________________________________
Pacemaker mailing list
Pacemaker@clusterlabs.org
http://list.clusterlabs.org/mailman/listinfo/pacemaker
