[Pacemaker] Multi-site support in pacemaker (tokens, deadman, CTR)

[Lars Marowsky-Bree]

On 2011-04-29T10:36:54, Andrew Beekhof <andrew at beekhof.net> wrote:

> > As I understood it we had essentially reached consensus in Boston that
> > CIB replication would best be achieved by a pair of complementary
> > resource agents. I don't think we had a name then, but I'll call them
> > Publisher and Subscriber for the purposes of this discussion.
> >
> > The idea would be that Publisher exposes the <configuration/> section of
> > the CIB via a network daemon, preferably one that uses encryption.
> > Suppose this is something like lighttpd with SSL/TLS support.
> 
> I can also offer a Matahari (QMF) agent.
> The new Luci is going to be using it to get the config off remote
> machines anyway.

A pull model works for me.

> > This would be a simple primitive running exactly once in the
> > Pacemaker cluster, and only if that cluster holds the "ticket".

Yeah, so logically it would make sense to collocate it with - or
incorporate it into - the Cluster Ticket Registry, since the same is
true for that.

> > Subscriber would be the only resource (besides STONITH resources and
> > Slaves of master/slave sets) that can be active in a cluster that does
> > not hold the "ticket".
> or:
>    colocation $ticket -inf

Well, the CTR needs to be active once per cluster anyway, and it knows
which site is the current "master" for a given ticket (or if it isn't
itself).

Maybe this component of the CTR can just switch state along with that
too?

Regards,
    Lars

-- 
Architect Storage/HA, OPS Engineering, Novell, Inc.
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde