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.conf
na 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.conf
na 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
       FAULT
stan.
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       
    do
             FAULT       
  • 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       
    do
             FAULT       
  • węzeł 2 wykrył zmianę stanu na węźle 1 i zmienił się z
             BACKUP       
    do
             MASTER       
    , 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.
Zaproszony:
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Natknęliśmy się na ten problem i zdecydowaliśmy, że jest to problem z systememd-networkd w systemie Ubuntu 18.04, który teraz używa netplan. Nowsza wersja keepalived powinna rozwiązać ten problem, ponieważ może wykryć usunięcie zmiennego adresu IP, które powoduje przełączenie awaryjne, patrz

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

Anonimowy użytkownik

Potwierdzenie od:

Ten problem został rozwiązany w keepalived 2.0.0 z dnia 26.05.2018, patrz.

keepalived changelog
https://www.keepalived.org/changelog.html
  • Monitoruj usuwanie VIP/eVIP i przejdź do kopii zapasowej, jeśli VIP/eVIP zostanie usunięty, odblokuj go, konfigurując opcję wyłączenia śledzenia.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Myślę, że twoje ogólne podejście jest dobre, ale musisz przemyśleć warunki testowania. Stan, o który się martwisz, to to, czy systemd restartuje infrastrukturę sieciową (jest to pośrednia konsekwencja, niezależnie od tego, czy twój VIP działa), więc to musisz sprawdzić.
Nie mam systemu, który mogę łatwo przetestować, wpisując to, więc YMMV jednak
         systemctl is-active network.service
może wystarczyć, aby to pokryć. W przeciwnym razie sprawdź stan
         systemctl show network.service | grep 'ActiveState'
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

Anonimowy użytkownik

Potwierdzenie od:

Aby obejść ten problem, skonfigurowałem zmienny adres IP jako dodatkowy adres IP w węźle głównym (z wyższym priorytetem)

/etc/netplan/01-netcfg.yaml

:
network:
version: 2
renderer: networkd
ethernets:
ens160:
addresses: [ 1.2.3.5/24, 1.2.3.4/24 ]
gateway4: 1.2.3.254
nameservers:
search: [ example.com ]
addresses:
- "1.2.3.40"

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:
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:50:56:a3:d7:d1 brd ff:ff:ff:ff:ff:ff
inet 1.2.3.5/24 brd 1.2.3.255 scope global ens160
valid_lft forever preferred_lft forever
inet 1.2.3.4/32 scope global ens160
valid_lft forever preferred_lft forever
inet 1.2.3.4/24 brd 1.2.3.255 scope global secondary ens160
valid_lft forever preferred_lft forever

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

Anonimowy użytkownik

Potwierdzenie od:

Myślę, że możesz pingować pływający adres IP, a gdy się nie powiedzie, zrestartuj usługę utrzymywania aktywności na wszystkich węzłach
Twoje IP powróci
Umieść to w cronjob, który uruchamia się co minutę lub 5 minut

Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się