Baza wiedzy

Scaling & high availability · zaktualizowano 17 listopada 2020 · zweryfikowano 9 lipca 2026

Naprawa zmian stanu VRRP wywołanych błędem „Receive advertisement timeout”

Jak wyeliminować niezamierzone przełączenia master/backup w VRRP przy dużym obciążeniu, dostrajając interwał pulsu.

W niektórych przypadkach przy dużym obciążeniu w logach vrrp (docker logs vrrp) może pojawić się następujący błąd:

Tue Nov 17 02:26:36 2020: (nas) Receive advertisement timeout
Tue Nov 17 02:26:36 2020: (nas) Entering MASTER STATE
Tue Nov 17 02:26:36 2020: (nas) setting VIPs.
Tue Nov 17 02:26:36 2020: (nas) Sending/queueing gratuitous ARPs on eth0 for 1.1.1.1

W tym przypadku dochodzi do niezamierzonej zmiany stanu VRRP w usłudze nas, ponieważ instancja w stanie BACKUP wykryła, że instancja MASTER przestała odpowiadać. Może to wynikać z dużego obciążenia węzła MASTER, a także z problemów z łącznością między instancjami. Instancja BACKUP odczekuje 3 interwały, zanim rozpocznie przełączenie — domyślnie jest to 3×1 sekundy, czyli 3 sekundy.

Wartość tego licznika można dostosować w konfiguracji. Aby ustawić interwał na 3 sekundy, należy wykonać:

ntk cfg set vrrp.services.nas.pulse_interval 3
ntk vrrp restart

Teraz limit czasu wykrycia awarii mastera wyniesie 3×3 sekundy, czyli 9 sekund. Wartość ta powinna być taka sama na wszystkich węzłach, które obsługują tę usługę przez VRRP.

Należy pamiętać, aby zastąpić nazwę usługi (w tym przypadku nas) własną nazwą usługi, jeśli korzystają Państwo z usług niestandardowych.

← Powrót do pomocy

Pierwsze logowanie bez hasła jeszcze w tym tygodniu

30 minut rozmowy z inżynierem, a nie prezentacja handlowa. Wspólnie zaplanujemy, jak uruchomić działający projekt pilotażowy w Państwa środowisku VPN, SSO lub Windows.