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

Andrew Beekhof andrew at beekhof.net
Fri Apr 29 08:36:54 UTC 2011


On Thu, Apr 28, 2011 at 3:06 PM, Florian Haas <florian.haas at linbit.com> wrote:
> On 2011-04-27 20:55, Lars Marowsky-Bree wrote:
>> On 2011-04-26T23:34:16, Yan Gao <ygao at novell.com> wrote:
>>> And the cibs between different sites would still be synchronized?
>>
>> The idea is that there would be - perhaps as part of the CTR daemon - a
>> process that would replicate (manually triggered, periodically, or
>> automatically) the configuration details of resources associated with a
>> given ticket (which are easily determined since they depend on it) to
>> the other sites that are eligible for the ticket.
>>
>> Initially, I'd be quite happy if there was a "replicate now" button to
>> push or script to call - admins may actually have good reasons not to
>> immediately replicate everywhere, anyway.
>>
>> It's conceivable that there would need to be some mangling as
>> configuration is replicated; e.g., path names and IP addresses may be
>> different. We _could_ express this using our CIB syntax already
>> (instance attribute sets take rules, and it'd probably be easy enough
>> to extend this matching to select on ticket ownership), and perhaps that
>> is good enough, since I'd imagine there would actually be quite little
>> to modify.
>>
>> (Having many differences would make the configuration very complex to
>> manage and understand; hence, we want a syntax that makes it easy to
>> have a few different values, and annoying to have many ;-)
>
> 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.

> This would
> be a simple primitive running exactly once in the Pacemaker cluster, and
> only if that cluster holds the "ticket".
>
> Subscriber, by contrast, subscribes to this stream and will usually
> mangle configuration in some shape or form, preferably configurable
> through an RA parameter. What was discussed in Boston is that in an
> initial step, Subscriber could simply take an XSLT script, apply it to
> the CIB stream with xsltproc, and then update its local CIB with the result.
>
> 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

> Comments?

Sounds like what I remember too.
Although lmb's idea of allowing rules to make use of tickets has merit too.
But that would only affect the xslt part above.




More information about the Pacemaker mailing list