On 6/28/12 7:15 PM, Willy Tarreau wrote:
That's already what keepalived does, and it goes a bit further
in that you can monitor the service for real, not just the
process presence, and even decide several failover scenarios
using floating VRRP priorities. For instance, I usually assign
a weight of 4 to my haproxy process and 2 to sshd. That way, if
haproxy dies, the other one takes the VIP. However, if both
haproxy work and one sshd dies, the one taking the VIP is the
one still reachable for administration. If one of each dies,
the one with the running haproxy wins.
You can do similar functionality with Pacemaker - Not sure if it is more
complex, the same, or simpler to support than keepalived. It's just
'different'. I've used keepalived twice in the last 10 years, and
pacemaker pretty much every day - Probably a little biased.
Pacemaker is tech preview in RHEL6, and SuSE 11 uses it as it's standard
resource manager for clustering. Would be nice if there was
documentation or at least config snippets from users who have
implemented it in the field.
Some more complex setups involve switching a VIP depending on the
number of application servers that haproxy sees, using
monitor-fail if This is handy for multi-layer architectures
with an inter-DC LAN for instance.
Do you have a configuration example of this? I don't think there is a
custom HAProxy OCF for Pacemaker yet - I've just been using the init.d
script, but sounds like it could use a 'real' Pacemaker script to
support it properly, especially if you can feed availability information
of backend systems as attributes to influence where resources are placed.
Is parsing out the http stats page (in csv, xml, or whatever) the
simplest way to get the current 'state' of HAProxy and the systems it is
routing to, or is there a better/cleaner/other way to do it?
