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.