3 ms·
I rarely see an install of Heartbeat/Pacemaker/CRM preventing more downtime than they cause. If you add in DRBD on top, you get an entire suite of false-HA inf
by seiji 15y ago
I rarely see an install of Heartbeat/Pacemaker/CRM preventing more downtime than they cause. If you add in DRBD on top, you get an entire suite of false-HA infrastructure.
- stock_toaster 15y agoJust curious, but what have you seen working well? At a previous gig we used heartbeat with haproxy, and it worked pretty well. We would drop connections on cutover, but it was considered 'acceptable' for our purposes at the time. I wanted to try whackamole with haproxy, but we never got around to it.
- seiji 15y agoThe only IP failover I trust is carp (http://www.openbsd.org/faq/pf/carp.html http://www.openbsd.org/faq/pf/carp.html) on OpenBSD/FreeBSD. Once set up properly with syncing, you lose no state on a failover (all connection and NAT state is gossiped between cluster nodes sharing an IP address). The only downside is most services aren't well tested under OpenBSD/FreeBSD these days so you may end up hitting a few edge cases in software designed and tested only under Linux.
- ww520 15y agoFor most apps and servers, migrating the IP state is not enough. The app server's connection state cannot be easily migrated. E.g. The MySQL connection of a failed MySQL server will be gone. Migrating the IP connection to a new MySQL server won't do anything. Carp is good for firewall server redundancy because IP state is all that firewall is maintaining.
- ww520 15y agoReally? I've built a MySQL HA cluster using that setup plus DRDB and it work beautifully. Have couple unplanned failure in couple years and they all failed over and came up correctly.