Hi,
for various reasons I run 3 pi-hole's and the router assigns these 3 pi-holes correctly as dns servers via dhcp. I thought this setup would ensure that even if 2 of the pi-holes go down everything would still work.
However as this is not the case I was looking around for some solution to make the setup high-availability (which to my limited understanding is having X instances of the same thing allowing X-1 things to die and the whole setup will still work), but all the conversations about it seem to devolve to discussion about how to sync the settings between the pi-holes. I already have this set up, all the 3 pi-holes are identical as they run in docker.
What I'm looking for is having only 1 IP for dns, which would automatically forward the dns request to any of the 3 pi-hole's that are up. Is that not high-availability? If so, then what is the thing I'm looking fo called?
I only run into this issue 1 day a week when the raspberry devices are being backed up, which shuts down all services takes a image of the sd-card and restarts all services. The backups are staggered and 2 out of 3 pi-holes are always up, but during the 3 or so hours on saturday the backups are running I often get warning e-mails from various hosts where various services complain about losing internet connectivity.
What would be the most noob-friendly way to make the system failover to next pihole seamlessly when 1 pihole dies?
Sorry if it doesn't make much sense, I'm not all that technical when it comes to concepts like this.
I don't know whether you'd really need more than you already have.
As your clients may try a different one out of your three Pi-holes if the one they are currently using fails to answer, some delays and warnings may be expected.
If your clients return to normal very shortly after that warning, then everything works as it should.
For those clients that don't, you should verify that they have acquired all of your DNS servers correctly. Some clients may have a limited amount of slots to store DNS servers.
Once you considered the above and still decide it would be necessary to resort to IP address fail-over, have a look at solutions using the Common Address Redundancy Protocol (CARP) or the Virtual Router Redundancy Protocol (VRRP). ucarp and keepalived are among the more well known implementations. They would have to be installed on all Pi-hole machines. Availability would depend on your actual OS (AFAIK, Debian has packages for both).
I'd only recommend either for solitary Pi-holes: If you run additional software next to Pi-hole on the same machine, you'd have to evaluate if that software and the clients using it would behave as expected when IPs are switched.
Both protocols do little more than switching an IP from one machine to another, so any software relying on some kind of state (session or not) will fail in that case, unless the respective software itself is prepared to take all necessary steps to run in such a scenario.
This would seem especially relevant in a Docker scenario, where the host for which the IP address is changed may run additional services in separate containers or on bare metal.
And suffice to say, those solutions are well outside of Pi-hole's scope.
You should consider consulting network forums specialising in IP address fail-over solutions for support on those.
I do indeed run many other different things on the 3 pi's, but I could migrate those as it's all in docker, but perhaps I'm overthinking the whole thing just to get rid of 3-4 warning emails once a week. After having checking the logs, it indeed appears the "outage" is only very short, not lasting the whole duration of the time the particular pi-hole is offline, indicating most systems indeed do recover and start using other pihole(s).
