Dat heb ik inderdaad ook zo draaien (2x AGH via Docker). Het werkt behoorlijk goed, maar met 1 beperking: het is afhankelijk van het host ip adres. Dus als je host wel draait, maar de Master AGH container functioneert niet goed, dan komt de Slave niet in actie. En dus loopt de DNS resolving dan alsnog spaak. Ik heb van alles geprobeerd, maar krijg een extra controle hierop niet aan de praat.Glassertje schreef op maandag 9 februari 2026 @ 14:45:
[...]
Ik gebruik keepalived met 2 raspberry pi's en AGH. Met 1 virtueel ip zijn beide Pi's. Verbonden. Als de ene niet reageert, dan reageert de andere. @stormfly heeft de config hier in het topic gepost.
Ik gebruik geen docker op de pizordaz schreef op maandag 9 februari 2026 @ 16:09:
[...]
Dat heb ik inderdaad ook zo draaien (2x AGH via Docker). Het werkt behoorlijk goed, maar met 1 beperking: het is afhankelijk van het host ip adres. Dus als je host wel draait, maar de Master AGH container functioneert niet goed, dan komt de Slave niet in actie. En dus loopt de DNS resolving dan alsnog spaak. Ik heb van alles geprobeerd, maar krijg een extra controle hierop niet aan de praat.
Beide pi's zijn in keepalived BACKUP zodat ik nopreempt optie kan gebruiken. Zo heb je dan geen onnodige VIP-wissels. Vind het niet nodig als de 1e AGH install terug reageert, dat die dan weer overspringt. Dit gebeurd pas als de andere AGH niet reageert. En tot nu toe werkt het vlekkeloos.
Dat is wel mogelijk hoor, maar dan moet je zelf een healthcheck scriptje maken voor AGH. In bijvoorbeeld /etc/keepalived/check_service.sh. Die moet executable zijn.zordaz schreef op maandag 9 februari 2026 @ 16:09:
[...]
Dat heb ik inderdaad ook zo draaien (2x AGH via Docker). Het werkt behoorlijk goed, maar met 1 beperking: het is afhankelijk van het host ip adres. Dus als je host wel draait, maar de Master AGH container functioneert niet goed, dan komt de Slave niet in actie. En dus loopt de DNS resolving dan alsnog spaak. Ik heb van alles geprobeerd, maar krijg een extra controle hierop niet aan de praat.
Bash:
/etc/keepalived/keepalived.conf:1
2
3
4
5
6
7
8
9
10
11
| #!/bin/bash HOST=127.0.0.1 PORT=3000 nc -z "$HOST" "$PORT" >/dev/null 2>&1 if [ $? -eq 0 ]; then exit 0 # OK else exit 1 # FAIL fi |
Bash:
Er zijn vast slimmere manieren om AGH te monitoren, maar dit kwam nu bij mij even uit de hoge hoed
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| vrrp_script chk_service { script "/etc/keepalived/check_service.sh" interval 2 timeout 2 fall 2 rise 2 } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 200 advert_int 1 virtual_ipaddress { 10.0.0.100 } track_script { chk_service } } |
gemiddelde procestijd is bij mij 19 ms en 127.0.0.1:5335 445 ms. Vooral deze laatste vind ik vrij traag. Misschien dat het aan Ipv6 ligt. Die heb jij uit staan en gebruik ik wel.Villager schreef op donderdag 5 februari 2026 @ 17:49:
[...]
Ik heb op Adguard Dashboard pagina 2 waarden die de responsetijden weergeven.
Onder Algemene Statistieken > Gemiddelde procestijd: 6 ms
en onder Gemiddelde upstream responstijd> Gemiddelde upstream responstijd voor de afgelopen 24 uren
127.0.0.1:5335 32 ms