i assume you're interested in simple active-passive setup.
ucarp & heartbeat in such setup do pretty much the same thing. in essence - they run provided scripts when machine is elected to be master / hot-standby.
heartbeat might look much more complicated [ since it can help you autoamte drdb mounts, restarting multiple services etc ] but at the end - you can script all of this and let ucarp invoke it].
personally - i run heartbeat with single resource - that is script that does following:
- [un]binds appropriate ip address
- runs couple of arp-broadcasts
- starts[stops] required services
my very simplistic setup [ heartbeat 2.1.3-6 under debian lenny ]: i have two servers:
- ser0 [preferred active node] with permanently assigned 10.0.0.2/24 at eth0
- ser0b [hot-standby node waiting to replace master] with permanently assigned 10.0.0.3/24 at eth0
'floating ip' - assigned to the active node is 10.0.1.1/24 assigned to eth1
in this case service that gets high availability is apache. i separately sync apache's configs and content that is served from ser0 to ser0b.
files below are identical on both machines with one marked exception:
/etc/ha.d/authkeys:
auth 1
1 md5 somethingrandom
/etc/ha.d/haresources
ser0 ha.sh
/etc/ha.d/ha.cf
keepalive 2
deadtime 10
udpport 694
; below - address permanently assigned to the peer node . this is for master:
ucast eth1 10.0.0.3
; and on slave i have
; ucast eth1 10.0.0.2
udp eth0
logfacility local0
auto_failback on
node ser0
node ser0b
/etc/init.d/ha.cf [ it can as well be in /etc/ha.d/resources.d/ha.cf ]
#!/bin/bash
case "$1" in
start)
ip link set dev eth1 up
# bind 'floating' ip to the interface
ip a a 10.0.1.1/24 dev eth1
# you might want to add some route-changes here if needed
/usr/lib/heartbeat/send_arp -r 10 eth1 10.0.0.1 auto 10.0.0.255 255.255.255.0
# to make sure apache reloads it's config when machine becomes master
/etc/init.d/apache2 restart
;;
stop)
# we are no longer active, un-bind 'floating' ip from the interface
ip a d 10.0.1.1/24 dev eth1
# you could stop it as well or just skip this step
/etc/init.d/apache2 restart
;;
esac
exit 0
well i reached answer on myself! clustering include two part:
1.cluster resource management
2.infrastructure with massaging layer
legacy heartbeat is broken into heartbeat message layer and pacemaker so pacemaker is CRM.
and we have two option on message layer:heartbeat,openais.
openais/corosync is preferred as:
http://comments.gmane.org/gmane.linux.highavailability.user/32355
There are, however, features in Pacemaker that require OpenAIS which
will work only with Corosync, not Heartbeat. Those features are
concerned with the distributed lock managers used by cLVM (but not
regular LVM), GFS/GFS2, and OCFS2. If you need that functionality, you
must select OpenAIS/Corosync. If you do not, you're free to choose.
as: http://www.clusterlabs.org/wiki/FAQ
Originally Corosync and OpenAIS were the same thing. Then they split into two parts... the core messaging and membership capabilities are now called Corosync, and OpenAIS retained the layer containing the implementation of the AIS standard.
Pacemaker itself only needs the Corosync piece in order to function, however some of the applications it can manage (such as OCFS2 and GFS2) require the OpenAIS layer as well.
so i went to openais/corosync and integrate it with pacemaker.
Best Answer
Believe the question has been very precisely answered by Willy Tarreau, the author of HAProxy, in http://www.formilux.org/archives/haproxy/1003/3259.html.
Citation from the above link
(Yeah I know it is an old question, but for future reference)