[ClusterLabs] Pacemaker with Zookeeper??

[Ken Gaillot]

On 05/17/2016 06:50 AM, Bogdan Dobrelya wrote:
> On 05/17/2016 01:17 PM, Adam Spiers wrote:
>> Bogdan Dobrelya <bdobrelia at mirantis.com> wrote:
>>> On 05/16/2016 09:23 AM, Jan Friesse wrote:
>>>>> Hi,
>>>>>
>>>>> I have an idea: use Pacemaker with Zookeeper (instead of Corosync). Is
>>>>> it possible?
>>>>> Is there any examination about that?
>>>
>>> Indeed, would be *great* to have a Pacemaker based control plane on top
>>> of other "pluggable" distributed KVS & messaging systems, for example
>>> etcd as well :)
>>> I'm looking forward to joining any dev efforts around that, although I'm
>>> not a Java or Go developer.
>>
>> Pacemaker and corosync are written in C, so I suspect it would be
>> pretty awkward to replace corosync with something which isn't.
>>
>> _______________________________________________
>> Users mailing list: Users at clusterlabs.org
>> http://clusterlabs.org/mailman/listinfo/users
>>
>> Project Home: http://www.clusterlabs.org
>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>> Bugs: http://bugs.clusterlabs.org
>>
> 
> Would be nice to see a clear picture for what is the coupling between
> those separate services making the Idea impossible? Is it libqb with its
> C-only API (wild guessing, sorry!), anything else? Theoretically, if
> there were no loose coupling, one could replace storage or messaging
> components or both and still leverage a Pacemaker CP :)

The only language dependency is that Pacemaker is written in C and needs
to hook into the messaging layer, so the messaging layer needs some C
API. Since most languages offer some way for library functions to be
called by a C program, it shouldn't be a deal-breaker.

Two issues make this challenging:

First, all the places in Pacemaker code that currently can call either
heartbeat or corosync functions would need equivalents for the new
layer, which would require a large investment of developer time. Search
the code for "SUPPORT_COROSYNC" to get an idea.

Second, corosync has been optimized over many years for the HA cluster
use case, and any replacement would have a lot of catching up to do, to
be truly equivalent. Communication layers that haven't been forged by
experience with HA clusters are highly unlikely to handle the known
corner cases and tricky situations. See the corosync and votequorum man
pages for just the user-tunable parameters that have evolved.

It is possible, just difficult.