[Pacemaker] Failover with multiple services on one node

Martin Aspeli optilude+lists at gmail.com
Mon Mar 8 07:21:32 UTC 2010


Matthew Palmer wrote:
> On Mon, Mar 08, 2010 at 01:34:01PM +0800, Martin Aspeli wrote:
>> This question was sort of implied in my thread last week, but I'm going
>> to re-ask it properly, to reduce my own confusion if nothing else.
>>
>> We have two servers, master and slave. In the cluster, we have:
>
> [bunchteen services, some HA, some not, one service IP]
>
>> Each Zope instance is configured with a database connection string for
>> Postgres (e.g. postgres://192.168.245.10:5432) and a similar connection
>> string for memcached (e.g. 192.168.245.10:11211).
>>
>> My question is this: Do we need to group all the clustered resources
>> (the IP address, HAProxy, Postgres, memcached) so that if any one of
>> them fails, they all fail over to slave?
>>
>> If we don't do this, how can we manage the connection strings in Zope?
>> Since Zope needs a domain name or IP address as part of the connection
>> string, it'd be no good if, e.g. memcached failed over to slave, but the
>> IP address stayed with master, because Zope would still be looking for
>> it on master.
>>
>> What is the normal way to handle this? Do people have one floating IP
>> address per service?
>
> This is how I prefer to do it.  RFC1918 IP addresses are cheap, IPv6 address
> quintuply so.  Having everything tied to one address causes some mayhem when
> something falls over (failover is quick, but it ain't instantaneous), so
> it's far better to give everything it's own address and let them drift about
> independently.  Also, it makes load-spreading (run PgSQL on one machine,
> memcached on the other, for instance) much easier.

Pardon my Linux ignorance, but does mean we need one NIC per service as 
well, or can we bind multiple (floating) IPs to each interface?

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book





More information about the Pacemaker mailing list