Seeking Advice on Setting Up a Pi-hole Cluster Using Old Mac Minis

General
1

Hello everyone,

I've been running Pi-hole for several years as a virtual machine (not using Docker, but directly on Debian—more precisely, Raspberry Pi OS Desktop).
It has served as the primary DNS server in my network and also handles DHCP very reliably.
I never encountered any issues until recently when I attempted to upgrade from version 5 to version 6; after the update, my system became unreachable—but that's a story for another time.

I currently have a new project idea that I'd love to get some feedback on.
I own two 2014 Mac Minis that I would prefer not to discard.
Instead, I’m considering repurposing them by setting up a Pi-hole cluster.
My plan is to use the built-in network interfaces on each Mac Mini as the primary interface, while adding a USB 2.0-to-Ethernet adapter to each device to serve as the dedicated connection between them in the cluster.

For the operating system on both hosts, I’m leaning towards either Debian or Ubuntu. I’m curious to know if anyone here has tried a similar configuration.
Any insights, tips, or even words of caution would be greatly appreciated.
Do you have experience with such a setup, or would you advise against it?

If anyone is also interested, I’d be happy to discuss further details about network configurations or troubleshooting potential issues that might arise with hardware like these Mac Minis.
Additionally, I'm exploring the broader implications of clustering Pi-hole for load balancing and resilience, so any experiences in those areas would be just as valuable.

Looking forward to hearing your thoughts and suggestions.

Best regards, Tobi

(Answers are also possible in German ; Antworten sind von mir aus auch in deutscher Sprache möglich)

2

Can you do this? Yes.

Does it provide you any additional goodness? Probably not.

What do you hope to gain from a cluster? Are you looking just for some redundancy in case one Pi-hole instance fails?

Why would you want to put a USB2 to ethernet adapter to connect these two? Each has an ethernet port (and built in WiFi) - why not just connect them to your network and let them communicate that way?

Also note that the idle power for a Mac Mini 2014 is 6 watts (per the Mactracker app), so you would have 12 watts continuously for the two of them.

If you just used a Pi Zero W or Zero 2 W, the load is 1 watt per device, and it will do the same thing.

I have two old Mac Minis sitting in a drawer. A 2012 and a 2018. I keep older Mac OS's on them for legacy purposes, and occasionally I hook one to my network with a big hard drive attached and use it as a temporary NAS and to do a backup of my Synology NAS.

All you need for redundancy is two Pi-holes running in parallel, each advertised to clients as a DNS server. Client are free to use either at any time. If one fails, the clients naturally switch to the surviving half of the pair. I run all my Pi-holes in pairs (serving different groups of clients).

There is little value to load balancing DNS with Pi-hole. Even a low capability device like a Pi Zero W is basically idling serving my network of about 50 clients. There is little need to balance load between two devices - they will just idle a bit less. This is where the KISS principle applies - simple is better.

2 Likes
3

Hello jfb,
Thank you for your quick reply.
Actually, I was so busy formulating my answer that I forgot the main reason I was considering the cluster.
It's obviously high availability. If one instance fails, I want the second one to simply take over and continue.
Currently, as described, I have the Pi Hole running as a VM on a Hyper-V server. If this fails, the entire home network is cut off, and if this happens while I'm on a business trip or in the office, nothing at home is available, and in the worst case, my wife can't work from home.
Currently, I have a copy of the VM stored on a separate workstation that's always on in Hyper-V, and my wife knows what to start and where in an emergency.
I'm aware of the power consumption, but I'm probably just stupid in that regard. I think in the end, it's all about getting something out of the two late 2014 Mac Minis and at the same time reducing my fear of the HyperV server failing when I'm not at home.
Why did I think of a USB to Ethernet adapter? I think it's because I'm used to HA firewall clusters in the past, for example, requiring a direct connection to each other so that, regardless of who is active, the cluster is always available under the same IP and they can synchronize.
From what I gather, it wouldn't be necessary here? But I can't simply provide two DNS servers to the clients with Pi Hole, so I thought it would be great if the entire cluster listened to one IP address, which I assigned.

4

In my opinion, you are making this needlessly complicated.

Just spin up a second instance of Pi-hole (on a Mac Mini 2014 if that is your choice). Set it up the same as the instance you already have running on the Hyper-V server, with the exception of a different IP address on the LAN.

Then, in your DHCP server, provide the second Pi-hole as the second DNS server. Renew DHCP leases on all clients and Bob's your uncle.

Clients can use either Pi-hole instance, if either one fails the other automatically picks up all the DNS load.

I do this for most of my home network with a Pi-3B+ (wired) and a Pi 3A+ (wireless). All the network equipment (including the two Pis) is on a UPS that will keep it running for about 4-6 hours.

Most of the clients (but not all) favor the first DNS server listed in the DHCP server (my router). But, regardless of which they choose to use, they get the same filtering because the Pi-hole are set up the same.

I rarely pay attention to the Pi-hole status, but on one occasion the Pi-3B+ hung up for a few weeks and I never knew it until I went to update the OS. Every client on the network using those Pi-holes continued to work fine.

Sure you can. Enable additional dnsmasq configuration files, and add a single dnsmasq command in a new configuration file in directory /etc/dnsmasq.d. The contents of the file will look similar to this:

dhcp-option=6,Pi-holeIP,SecondaryDNSIP

Do this with each Pi-hole. Set the DHCP range on each Pi-hole so as to not overlap the other. And set reserved IP's the same on each Pi-hole, if you use reserved IP's.

Example

IP 25-100 reserved on each Pi-hole for reserved (static) IP's assigned to clients.

IP 101-150 in use for other client assignment on Pi-hole 1.

IP 151-200 in use for other client assignment on Pi-hole 2.

Either Pi-hole can provide IPs and DNS assignments to any requesting client, and they won't conflict. Either Pi-hole can fail completely, and the clients won't know the difference.

Or, to simplify things more, I just use my router as DHCP server. All regular clients on my LAN have reserved IPs, and these are mapped identically in the hosts file on each Pi-hole. When any Pi-hole gets a query from the client at IP 135, it shows up with the same name as on any other Pi-hole.

5

You have a mindset of working for big corporation where terminology like redundancy, load balancing, fail-over, cluster....etc... As this is for home network with 28 network connected devices, I prefer hot-swapable. I have 2 piholes (PC running Ubuntu and RPi Zero). I just configured both identical then turn off one. Having both running at the same time more likely both will fail due to hardware issue. Configured as jfb suggested

Set both Primary and Secondary DNS for both Pi-holes. When one goes down, power up the other and clients wouldn't notice anything at all.

6

I don't agree with your conclusion.

Each running P-hole is as likely to fail due to a hardware issue as the other (assuming similar hardware, etc). The two devices are separate and independent as far as hardware and software (although if your whole house loses power without a UPS everything goes down, including all the network equipment).

One half of your redundant pair is already in a failed state, since you turned it off.

You want to look at the probability of simultaneous failures with both running.

If one device has a 1/1000 probability of failure in a given time, and the other has the same probability, then the probability of both failing simultaneously is the product of these, or 1/1,000,000.

In your setup, with one already failed, the chance of a second failure which would bring the DNS down is 1/1000, three orders of magnitude higher than if both were running at the same time. You aren't running a redundant pair. You are running one Pi-hole with a semi-ready spare. When the running Pi-hole fails, your clients will certainly know it, until you fire up the spare.

This reminds me of the old statistics joke:

A professor of statistics calculated that the chance of a bomb on an airplane was one in a million. The chances of two bombs on an airplane were one in a billion. So, he traveled, but he always carried a bomb.

1 Like
7

I won't be debating on your analyst of probability or analogy of bomb on a plane :slightly_smiling_face:, because I'm just a retired IT engineer. It's hot and humid where I live and prefer not to have additional equipment exerting more heat in an area where I kept all my networking equipment covered with UPS. I'm not running redundancy or hot-swappable here. Just having two diff. hardware running identical software. This is a home network, so few minutes of down time is not an issue, but replacing a failed equipment is what I'm trying to prevent. I do appreciate the reply.

btw, hot-swappable wasn't what I meant....sorry

8

Hello everyone,

I'm glad I was able to spark a discussion. I already knew the statistics joke, but it was nice to hear it again.

jfb: Thanks for giving me a hint on how to distribute a second DNS server.

That's right, your solution for the DHCP issue also makes sense. I don't think I would have ever thought of having two active DHCP servers in the network.

At this point, however, I would like to return to the topic of HA clusters, perhaps with direct sync between them via a connection. Would such a thing be possible? I suspect the software itself wouldn't allow it, would it? At least I haven't found any option in V5. As I said, I recently had to roll back to V6 after the update.

I refuse to use my router as a DHCP server again.

Maintaining a hosts file doesn't make sense in my opinion, as I have a certain static range (servers, VMs, network infrastructure devices, workstations for my independent business, etc.) and an additional DHCP range for pure endpoints and whatever the family needs.

At this point, we've arrived at what smurf suggested.
Yes, I'm actually always thinking about what you'd normally only implement in a large company. Probably because that's exactly what I work in full-time. In my home network, however, I'd like to try to make it as convenient and easy for everyone else, even though it's more complicated for myself, and also as fail-safe as possible, of course with lower acquisition costs.

UPSs are already in place. One is under the Hyper-V server on which PiHole is currently running as a VM. There would also be enough capacity for one of the Mac Minis. A second UPS (which is bored) is active under the aforementioned always-on workstation, which currently hosts a powered-off copy of the PiHole VM, which can be started in an emergency. I would be able to place the Mac Mini on this.

If I understand correctly, I currently have essentially the same setup/idea as smurf.
Both instances are configured the same (instance two as of the day the copy was made) and both have the same IP. One instance is powered off and must be activated by someone in the event of a failure.

That's exactly what I'd like to avoid.
I understand if you say you don't need it redundantly since it's a home network. To be precise, I'll have to name mine a SoHo network. Here, every lost hour that I'm not at home and the network goes down is indeed annoying—not ruinously expensive, but annoying, and there will be discussions.

If we don't read each other again, I wish you a nice weekend.

9

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.