22 Feb
2019
22 Feb
'19
2:02 a.m.
On 2019-02-21 14:41, admins wrote:
In a previous life we ran a pair of HA load
ballancers, serial
connected heartbeat and with STONITH, in a Primary Backup config, as a
front end to a whole bunch of ISP type services.
Then had these point to the services (multiples thereof). The
published IP/s on the load ballancers were virtual or floating and
moved between the two.
It gave us a lot of flexibility to adjust the load balancing
parameters sometimes pressing the same in to service for fail-over of
a back-end service, or dropping back end services out of the list for
maintenance or reloads. When you do this though it kills any TCP
sessions and it is up to the client to re-establish these but the load
ballancers just point them at a different service when the re-connect
happened. The state was lost though and each re-connect was a new
application session. For web servers or squid proxys this does not
matter much though
<snip other stuff>
It's 2019 and I wouldn't wish the product formerly known as "Linux HA"
on my worst enemy. Maybe that's overstating it a teeny bit, but it's not
that far from the truth. Heartbeat/Pacemaker/Corosync/STONITH are
horrible to configure and use, and are likely to lead to lower
availability when used inexpertly, which is very easy to achieve.
keepalived/LVS is a simpler and superior way to manage services which
require (or can manage with just) TCP load balancing and/or failover,
and it can even share TCP connection state so connections aren't
interrupted when handing over between redundant load balancers. It's
just Linux kernel plus a bit of user-space, so fast and robust. It has
been around since the days of Linux 2.4, but for some reason seems less
well-known than the linux-ha abominations. It can even do MAC-based
forwarding to hosts (on the same subnet or via a tunnel), so you can
handle high-bandwidth traffic flows without carrying the majority
server-to-client traffic through the load balancer.
At a pinch it can also run scripts on state change, but at that point
the OP needs to understand exactly what they're doing to achieve
resilient service because again it's not necessarily straightforward to
get what you want to happen automatically without bad things happening
that you didn't expect or plan for (see "automatic database failover").
For HTTP it often doesn't matter though, as people have already said.
haproxy is inaptly named, other than the fact that individual instances
tend to be very reliable, but it sits well for HTTP load-balancing on
top of LVS if for some reason plain connections with TCP are not enough.
People seem to love to stack haproxy/nginx/Apache/etc. reverse HTTP
proxies for some reason.
Ant