keepalived nie wykrywa utraty wirtualnego adresu IP
Używam keepalived do przełączania pływającego adresu IP między dwiema maszynami wirtualnymi.
/etc/keepalived/keepalived.confna VM 1:
vrrp_instance VI_1 {
state MASTER
interface ens160
virtual_router_id 101
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass secret
}
virtual_ipaddress {
1.2.3.4
}
}
/etc/keepalived/keepalived.confna VM 2:
vrrp_instance VI_1 {
state MASTER
interface ens160
virtual_router_id 101
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass secret
}
virtual_ipaddress {
1.2.3.4
}
}
Zwykle działa to dobrze, z jednym wyjątkiem: za każdym razem, gdy systemd jest aktualizowany (działa na nim Ubuntu 18.04), restartuje komponent sieciowy, co powoduje usunięcie pływającego adresu IP, ponieważ nie jest skonfigurowany w systemie. Ponieważ obie instancje keepalived nadal mogą pingować się nawzajem, żadna z nich nie widzi niczego złego i żadna z nich nie odpowiada, pozostawiając wyłączony zmienny adres IP.
Odkryłem, że możesz sprawdzić adres IP za pomocą prostego skryptu, takiego jak ten:
vrrp_script chk_proxyip {
script "/sbin/ip addr |/bin/grep 1.2.3.4"
}vrrp_instance VI_1 {
# [...]
track_script {
chk_proxyip
}
}
Ale nie jestem pewien, czy jest to podejście robocze.
Jeśli dobrze rozumiem, to jeśli skonfiguruję ten skrypt na VM1, wydarzy się co następuje:
- VM1 traci adres IP z powodu ponownego uruchomienia systemu
- keepalived na VM1 wykrywa utratę adresu IP
- Keepalived przełącza się na
FAULT
stan i zatrzymaj nadawanie pakietów vrrp - Keepalived na VM2 wykrywa utratę utrzymania na VM1 i ustawia zmienny adres IP
W tej chwili IP działa ponownie na VM2, ale VM1 pozostanie w tym stanie, ponieważ IP nigdy więcej nie pojawi się na VM1. Jeśli VM2 ulegnie awarii (z jakiegokolwiek powodu), VM1 nie przejmie kontroli, ponieważ nadal jest w
FAULTstan.
Jak mogę się upewnić, że zmienny adres IP jest zawsze aktywny na jednej z maszyn wirtualnych?
Dalsze testy:
Próbowałem pingować pływający adres IP zamiast sprawdzić, czy jest aktywny na określonym hoście w check_script:
vrrp_script chk_proxyip {
script "/bin/ping -c 1 -w 1 1.2.3.4"
interval 2
}
Skonfigurowanie tego skryptu w węźle 2 dało następujące rezultaty:
- usunięto adres IP na hoście 1 do testów
- host 2 wykrył utratę adresu IP i zmienił go z
BACKUP
doFAULT
- węzeł 1 zignorował zmianę stanu i został
MASTER
Wynik: adres IP pozostał wyłączony.
Skonfigurowanie skryptu w węźle 1 dało następujące rezultaty:
- usunięte IP na hoście 1
- host 1 wykrył utratę adresu IP i zmienił go z
MASTER
doFAULT
- węzeł 2 wykrył zmianę stanu na węźle 1 i zmienił się z
BACKUP
doMASTER
, skonfiguruj zmienny adres IP na węźle 2
No więc ...
Feb 13 10:11:26 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 13 10:11:27 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 13 10:11:29 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100
Feb 13 10:11:29 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering BACKUP STATE
Feb 13 10:11:32 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 13 10:11:33 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 13 10:11:36 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100
Feb 13 10:11:36 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering BACKUP STATE
Feb 13 10:11:38 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 13 10:11:39 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 13 10:11:41 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100
Feb 13 10:11:41 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering BACKUP STATE
Feb 13 10:11:44 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 13 10:11:45 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 13 10:11:47 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100...
Musiałem ponownie uruchomić keepalived na node1, aby przestać grać w ping ponga między węzłami.
Nie znaleziono powiązanych wyników
Zaproszony:
Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się
5 odpowiedzi
Anonimowy użytkownik
Potwierdzenie od:
https://github.com/acassen/keepalived/issues/836
https://github.com/acassen/keepalived/issues/836
.
Nowsza wersja keepalived nie jest dostępna 18.04 i zamiast próbować wykonać kopię zapasową, zdecydowaliśmy się pozostać na ubuntu 16.04 i poczekać do ubuntu 20.04 na naszych serwerach, które używają keepalived.
Anonimowy użytkownik
Potwierdzenie od:
keepalived changelog
https://www.keepalived.org/changelog.html
Anonimowy użytkownik
Potwierdzenie od:
Nie mam systemu, który mogę łatwo przetestować, wpisując to, więc YMMV jednak
może wystarczyć, aby to pokryć. W przeciwnym razie sprawdź stan
dla stanu innego niż „aktywny” powinien to zrobić.
Nawiasem mówiąc, czy nie powinieneś konfigurować jednego ze swoich węzłów ze stanem ZAPASOWY zamiast obu jako „MASTER”?
Anonimowy użytkownik
Potwierdzenie od:
/etc/netplan/01-netcfg.yaml
:
Dlatego podczas uruchamiania lub rekonfiguracji systemu systemd zmienny adres IP znajduje się w węźle podstawowym. W przypadku niepowodzenia trafia do drugorzędnego poprzez podtrzymanie życia. Jeśli główny host zwróci odpowiedź, adres IP zostanie zwolniony dzięki utrzymaniu drugiego przy życiu.
To naprawdę nie jest rozwiązanie, ale nie widzę jeszcze nic lepszego.
Odświeżać
Chociaż to obejście zadziałało, miało pewne skutki uboczne. Po restarcie zmienny adres IP występował w interfejsie dwukrotnie:
Wydawało się, że to na nic nie wpływa, zadziałało, ale mnie to martwiło. Skończyło się na
odpowiedź z mp3foley
https://serverfault.com/a/956219/38644
i ponownie zainstalowane maszyny wirtualne z Ubuntu 16.04.
Anonimowy użytkownik
Potwierdzenie od:
Twoje IP powróci
Umieść to w cronjob, który uruchamia się co minutę lub 5 minut