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.
2021-03-02 Dodaj komentarz
Udostępnij to

Nie znaleziono powiązanych wyników

    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.
    2021-03-02 0 0
    Udostępnij to
    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.
    2021-03-02 0 0
    Udostępnij to
    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”?
    2021-03-02 0 0
    Udostępnij to
    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.
    2021-03-02 0 0
    Udostępnij to
    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
    2021-03-02 0 0
    Udostępnij to
    Dlaczego jest złożony? 0 odpowiedzi zostało zwiniętych

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

    Polityka prywatności: https://zweryfikowac.pl/Polityka-prywatnosci.pdf
    Copyright © 2023, All Rights Reserved