• zordaz
  • Registratie: Januari 2002
  • Laatst online: 00:16
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.
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
  • Registratie: September 2020
  • Laatst online: 23:22
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.
Ik gebruik geen docker op de pi

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.

  • lolgast
  • Registratie: November 2006
  • Laatst online: 22:17
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.
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.
Bash:
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
/etc/keepalived/keepalived.conf:
Bash:
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
    }
}
Er zijn vast slimmere manieren om AGH te monitoren, maar dit kwam nu bij mij even uit de hoge hoed

  • tomdh76
  • Registratie: Maart 2015
  • Laatst online: 21:22
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
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.
Pagina: 1 ... 32 33 Laatste