[asterisk-dev] [Code Review] 4490: astdb: Allow clustering of the Asterisk Database between multiple Asterisk servers

[Matthew Jordan]

On Wed, Apr 8, 2015 at 1:03 PM, Mark Michelson <reviewboard at asterisk.org> wrote:

Before I repost the AstDB Clustering review from Review Board onto
Gerrit, I wanted to address Mark's concerns below. Depending on what
people think, it may be worth just shelving the idea.


>
> The only things I can think of that are issues here are based on theoretical usage of shared DB families, especially global ones.
>
> Say that someone is sharing /foo/key between Asterisk 1 and Asterisk 2. A user on Asterisk 1 sets /foo/key = bar at the same time that a user on Asterisk 2 sets /foo/key = baz. What may happen is that the local Asterisk boxes will set the values locally and then publish the updated values near-simultaneously to the other Asterisk box. The result may be that they both have /foo/key = bar, they both might have /foo/key = baz, or Asterisk 1 may end up with /foo/key = baz and Asterisk 2 ends up with /foo/key = bar. Essentially, there is nothing in place to guarantee the synchronization of globally shared values.

That is correct. There is no implicit synchronization.

Using a 'global shared family' implies some level of knowledge about
how the keys are used on the respective systems. Where this is useful
is places like registration, where you "know" that the devices
registering to a cluster of Asterisk servers are all unique, but you
want the knowledge of the registration to be shared globally. In that
respect, this is very much like clustering of MWI. There is no
aggregation of MWI IDs between Asterisk instances, nor is there
synchronization of values. If someone configures identical mailbox IDs
on two Asterisk systems and updates the mailbox state to different
states on different servers, a discontinuity will occur.

> So what's the best way to deal with this? I can think of several answers:
> * The AstDB may not be the right tool for this use case and you should be using a key-value store that is built for this instead.

Possibly. In that case, you'd simply have the AstDB pass through to
some other mechanism (redis/RabbitMQ/etc.) In the long run this may be
better. It would be interesting to have the AstDB act as a facade on
top of some other technology, defaulting to SQLite3.

> * You may be able to satisfy your use case with unique shared keys instead of global shared keys.

I think they are separate use cases. If you don't know whether or not
you will have collisions, unique shared keys is clearly the answer,
but you have to aggregate the duplicates yourself. If you have global
keys, you're either not caring about the synchronization, or you
'know' that all keys will be unique across all Asterisk instances.

> * We may want to make global shared keys one-way. In other words, there is an "owner" of the key and "listeners" for changes in the key's value. Listeners on a global shared key cannot update their local DB with new values; only the owner can push new values to it. Listeners on a global shared key cannot share the value with other listeners; only owners may push changes to listeners.

I think if we went down that road, I'd personally rather scrap the
change and have the AstDB sit in front of other technologies.

> While I'm thinking about it, there's also the possibility that the underlying AstDB implementation could be replaced with a key-value store that has the concept of replication built into it. If that were done, then presumably, there would be no need to involve Stasis or SIP PUBLISH in the process of sharing values between Asterisk boxes.
>

Yup.

SO!

The question is: is this change worth having, or should it be scrapped
in favour of some alternate approach that makes use of other
technology? My feelings won't be hurt if the answer is "ditch it and
do something else" - this was a fun piece of code to right on some
plane flights. On the other hand, I don't have any real interest in
writing an alternative approach, so if the expectation is that an
AstDB wrapper around RabbitMQ or Redis will magically appear if I hit
the delete key, that expectation is likely to be wrong.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org