Clustering/Failover design notes.

[Alan Conway <ac...@redhat.com>]

I just put up

http://cwiki.apache.org/confluence/display/qpid/Clustering+Design+Notes
+2

It's quite preliminary, but I'd like to get some discussion started on
this topic. In particular I'd like to
- document out a set of use cases to guide further design refinement.
- establish some common framework for clustering across languages.

I'd particularly like to be informed by the experience of the existing
Java clustering implementation and look at some consolidation of
designs.

I think we want to share at least some basic principles and at least
basic interop for the loosely coupled scenarios. I'm not we can/want to
provide full interop for tightly coupled failover clusters.

So for example: both proposals talk about proxy brokers using AMQP to
transfer state. There's no reason that shouldn't interop at some level.
On the other cluster membership protocols or transaction log storage
might best be addressed in different way for each language (e.g. OpenAIS
vs. JGroups etc.)

Cheers,
Alan.

Re: Clustering/Failover design notes.

[John O'Hara <jo...@gmail.com>]

I'll have a look.

Previous discussion has settled on two approaches:
a) Clustering; where several servers look/behave as one.
b) Bridging; to link geographically separate servers, or servers under
control of a different organisation.  Bridging is also useful to link to
different middlewares.

It is my strong opinion that clusters should be homogenious, single vendor
affairs.  No interop within a cluster is needed.
Bridging is all about interop - here support for linking heterogenious
servers is critical (or a cluster to a remote server, in another
organisation).

Reading the doc linked.
I would expect that things are kept as simple as possible, while maintaining
the appearance of a single system image (a nice to have; don't do it if it
gets silly complicated).
The concept of data ownership and lock management is critical.  The less
transfer of ownership and locking activity the better (from a reliability
viewpoint, which is the main one!).  Remember, the most scalable
applications have their data horizontally partitioned (e.g. customers A-F,
G-M, N-Z); whether at the application level or within Qpid we should bear
this in mind.

Cheers
John


On 27/11/06, Alan Conway <ac...@redhat.com> wrote:
>
> I just put up
>
> http://cwiki.apache.org/confluence/display/qpid/Clustering+Design+Notes
> +2
>
> It's quite preliminary, but I'd like to get some discussion started on
> this topic. In particular I'd like to
> - document out a set of use cases to guide further design refinement.
> - establish some common framework for clustering across languages.
>
> I'd particularly like to be informed by the experience of the existing
> Java clustering implementation and look at some consolidation of
> designs.
>
> I think we want to share at least some basic principles and at least
> basic interop for the loosely coupled scenarios. I'm not we can/want to
> provide full interop for tightly coupled failover clusters.
>
> So for example: both proposals talk about proxy brokers using AMQP to
> transfer state. There's no reason that shouldn't interop at some level.
> On the other cluster membership protocols or transaction log storage
> might best be addressed in different way for each language (e.g. OpenAIS
> vs. JGroups etc.)
>
> Cheers,
> Alan.
>
>