The typical usage in this case would be to make all mail servers serve all 
domains (virtual domain support) and then run N instances across those N 
servers. Then there is no per-server unique information to deal with. Then you 
can run, for example, load sharing between the nodes using iptables CLUSTERIP 
(since all nodes would then be serving the same data) and put a constraint in 
the CIB that says that if the clone fails on a node, pull that node from the 
load-sharing config by stopping or moving away your load-sharing resource. At 
least, that's how I would do it.


Eliot Gable
Senior Engineer
1228 Euclid Ave, Suite 390
Cleveland, OH 44115

Direct: 216-373-4808
Fax: 216-373-4657
ega...@broadvox.net


CONFIDENTIAL COMMUNICATION.  This e-mail and any files transmitted with it are 
confidential and are intended solely for the use of the individual or entity to 
whom it is addressed. If you are not the intended recipient, please call me 
immediately.  BROADVOX is a registered trademark of Broadvox, LLC.

-----Original Message-----
From: Joe Armstrong [mailto:jarmstr...@postpath.com]
Sent: Thursday, May 21, 2009 11:04 AM
To: pacemaker@oss.clusterlabs.org
Subject: [Pacemaker] globally-unique clone question

Hi All,

I am a little confused about globally-unique clones, since there can be no 
instance attributes for a clone how do you tell each clone that it is unique ?

My use case is that we need to run N instances of a mail server, each mail 
server is unique in that it serves a specific domain, two mail server can never 
run on the same host.  In order to provide HA we need to tell the mail server 
instance what domain to serve (or what filesystem to mount in order to get the 
right data/config).

I was thinking that using globally-unique clones would be the way to manage 
this (it makes the mutual exclusion rule easy: clone-node-max=1) but I don't 
see how to make each instance unique.

... then again I could be mis-using the concept...

Thanks for any pointers.

Joe

_______________________________________________
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

CONFIDENTIAL.  This e-mail and any attached files are confidential and should 
be destroyed and/or returned if you are not the intended and proper recipient.

_______________________________________________
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Reply via email to