22 Feb
2019
22 Feb
'19
2:09 p.m.
If all you want to do is monitor the functionality of a service and
restart the service, or service and its dependents (rebooting the full
box is often not necessary and much quicker). You could do much worse
then look into Monit.
It is already in the repo's too.
Kirbs
On 22/02/2019 09:11, Chris Smith via users wrote:
I certainly don’t need anything as complex as all
that. I’m not dealing with anything mission-critical as such and I don’t need it to work
seamlessly to the user either, I just need it to be automated. The more I think about
this, the more I realise that all I need is an automated way to detect a problem and
reboot the server. Ideally, this would happen from an external VPS or other system being
able to poke Xen (in case the server cannot restart itself) and ideally this would be tied
in to the existing BitFolk monitoring services (if possible) to avoid re-inventing the
wheel.
Regards,
Chris
—
Chris Smith <space.dandy(a)icloud.com>
On 22 Feb 2019, at 02:02, Anthony Newman via
users <users(a)lists.bitfolk.com> wrote:
On 2019-02-21 14:41, admins wrote:
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users 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
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users