On 21 Jun 2014, at 1:32 am, Patrick Hemmer <pacema...@feystorm.net> wrote:
> From: Andrew Beekhof <and...@beekhof.net> > Sent: 2014-06-20 04:48:25 EDT > To: The Pacemaker cluster resource manager <pacemaker@oss.clusterlabs.org> > Subject: Re: [Pacemaker] Alternative communication engine to corosync > (etcd/consul/zookeeper/doozerd) > >> On 20 Jun 2014, at 2:14 pm, Patrick Hemmer <pacema...@feystorm.net> >> wrote: >> >> >>> After the demise of the old heartbeat service, and the switch to corosync >>> as the primary (sole) method of communication between nodes, >>> >> heartbeat is still supported as a messaging/membership layer >> >> >>> has there ever been any consideration into using services such as etcd, >>> consul, zookeeper, or doozerd? >>> >> I think most of these didn't exist at the time. >> Do any provide membership too? What about message ordering? >> > Yes. N/A (see below on the CPG vs KVS). >> >>> These alternative communication engines offer some stuff that corosync >>> doesn't. One such item etcd & consul offer is dynamic cluster scaling >>> capabilities (nodes can very easily join and leave the cluster). When >>> working in cloud computing, this feature becomes very important. Pcs is >>> somewhat helpful in this regard but it's still nowhere near as capable >>> (plus corosync doesn't have downscaling finished). >>> However one critical difference between these services and corosync is that >>> they are mainly key/value stores, and don't have something like Corosync's >>> CPG. >>> >> Yes, a rather critical difference. >> >> >>> Though you could probably implement something looking like CPG using a >>> keyvalue store, >>> >> I rather doubt it. k/v stores and CPG are not very alike from where I'm >> sitting. > No, they are not alike, but you could implement something looking like CPG. IF someone else implemented such a thing I would be happy to look at including support for it. But knowing what I do about the "joy" that went into writing CPG, there is no way that someone is going to be me. > When a key is created, that's a CPG message. They support atomic operations > (collision checking), so no 2 nodes could update a key at the same time. So > while it's a different underlying system, the end result is the same, ordered > messages. >>> I think pacemaker might be able to use a key/value store natively. > But I wouldn't even bother with hacking a KVS into something like CPG if it's > not needed. I would do it such that the CIB is stored as keys and values > natively. I would even think this is more efficient. I'm not sure how the CIB > is transmitted between nodes, but I think it easiest to just set a single key > when you want to update something like a resource's last-rc-change value. CPG is used for a lot more that just keeping the CIB in sync. I did look at some other KVP stores late last year for the CIB, but I was able to get O(2) speedup without it. > >>> >>> So, has this ever been considered? How heavily tied is pacemaker to the >>> corosync API? Could that be abstracted out enough to where different >>> communication engines could be implemented? >>> >> It's already abstracted to the point where it supports 4 different >> messaging/membership options: >> - heartbeat >> - corosync/pacemaker plugin >> - cman >> - corosync 2 >> > But aside from heartbeat, they all use corosync underneath. Technically yes, but they all expose very different APIs so they don't look at all alike to pacemaker. > I wasn't aware heartbeat was still supported. I assumed it was dropped. Bad > assumption :-) > >> >>> >>> -Patrick >>> _______________________________________________ >>> Pacemaker mailing list: >>> Pacemaker@oss.clusterlabs.org >>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker >>> >>> >>> Project Home: >>> http://www.clusterlabs.org >>> >>> Getting started: >>> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >>> >>> Bugs: >>> http://bugs.clusterlabs.org >> >> >> _______________________________________________ >> Pacemaker mailing list: >> Pacemaker@oss.clusterlabs.org >> http://oss.clusterlabs.org/mailman/listinfo/pacemaker >> >> >> Project Home: >> http://www.clusterlabs.org >> >> Getting started: >> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >> >> Bugs: >> http://bugs.clusterlabs.org > > _______________________________________________ > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org