Nginx долгое переключение на upstream backend как проверить?

Question

[Kacblm]

Коллеги добрый день!
При балансировке нагрузки через nginx (upstrem) используя только DNS RR имею следующую проблему.
На балансировщике, через iptables закрываю все tcp соединения на один из backend серверов. И тыркаю на открытом сайте F5. Переключение на вторую ноду происходит не сразу. А по теории должно произойти после нескольких неспешных запросов. Подскажите как быть в данной ситуации и какие логи смотреть?) Игрался с параметрами max_fails=3 fail_timeout=5s; результат аналогичен.

Answer 1

[Kacblm]

Ответ нашел сам Точнее спросил у старшего товарища Ликсуйда.
Я эмитировал падение одного из бекендов с помощью IPTABLES (iptables -A OUTPUT -d 172.20.5.12 -j DROP)
Видимо у Nginx есть свои механизмы опроса, он наверное ждёт ответ от хоста. А в данном случае ответа как бы не было. И Nginx не понимал что проиходит с одним из бекендов.
Нужно прописать REJECT и будет счастье =) Если у кого-то есть более академическое объяснение то я готов выслушать)

Answer 2

[borodka_lenina]

Добавьте в upstream параметр
keepalive 10;

Если 10 секунд один из беков не ответил, то он начинает слать всё на другой бекэнд

Comments

[sunnybear]

Все бы хорошо, но параметр upstream "Задействует кэш соединений для группы серверов.

Параметр соединения устанавливает максимальное число неактивных постоянных соединений с серверами группы, которые будут сохраняться в кэше каждого рабочего процесса. При превышении этого числа наиболее давно не используемые соединения закрываются."