Re: upstream max_fails и упавшие сервера
Hello! On Tue, Jul 09, 2013 at 12:10:14PM +0400, Андрей Урядов wrote: Сделал так, как советовали: после старта бэкенд говорит фронтенду, что надо перечитать конфигурацию. Но в логах почему-то даже после перечитывания появляются ошибки: (110: Connection timed out) while connecting to upstream, причем указан ip бэкенда не из списка текущих - видимо, старый остался. Причем, такое повторяется через несколько минут после перечитывания конфигурации. Хотя, эти ошибки явно одиночные - проявляются только для нескольких клиентов, у остальных все нормально работает. Это результаты какого-то кэширования? Потому что запрос от клиента на nginx пришел явно после того, как конфигурация уже была перечитана. Такое может быть, e.g., если запрос _начал_ приходить давно, и соответственно - в старый рабочий процесс, и делал это долго - e.g. от клиента принималось большое тело запроса. Либо запрос до этого где-то долго обрабатывался (e.g. ходил на другой бекенд, и потом из-за ошибки или по X-Accel-Redirect был куда-то ещё отправлен). В сообщениях об ошибках написан pid процесса, имеет смысл на него посмотреть - там должен быть pid одного из старых рабочих процессов. Ну и $request_time, $upstream_response_time имеет смысл в логи добавить - чтобы не писать явно после, а оперировать фактами. -- Maxim Dounin http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: upstream max_fails и упавшие сервера
Да
17 июня 2013 г., 17:53 пользователь Maxim Dounin mdou...@mdounin.ruнаписал:
Hello!
On Mon, Jun 17, 2013 at 04:09:19PM +0400, Андрей Урядов wrote:
Всем привет.
Столкнулся с интересным поведением директивы max_fails в upstream.
Версия nginx 1.2.6.
Опишу ситуацию.
1. Nginx работает на сервере some_host1. Кусок конфига:
upstream fpm {
server some_host1:9000 weight=6;
serversome_host2:9000 weight=4;
}
2. В какой-то момент some_host2 зависает (на уровне ОС), т.е. не отвечает
на запросы.
3. В логах появляются строки connect() failed (110: Connection timed
out)
while connecting to upstream. Причем, я считал, что т.к. max_fails не
указан, он равен 1, и, стало быть, таких строчек не должно быть, т.к.
nginx
должен перекидывать всех на первый сервер.
4. some_host2 перестартует. На нем запускается fpm.
5. Но почему-то строки из лога не пропадают и клиентам отдаются ошибки.
6. Если перестартовать nginx, то он подцепит оба сервера, и все
продолжится
в штатном режиме.
Вопросы:
1. Почему после первого неудачного раза сервер не отрубается? Ведь
max_fails равно 1.
После того, как случилась ошибка - nginx будет посылать запросы на
плохой сервер раз в fail_timeout секунд (нюанс: из каждого
рабочего процесса). Если он успешно ответит на запрос - то будет
вновь включён в работу.
2. Почему после рестарта сервера nginx его не видит? Он же продолжает его
дергать, и мог бы понять, что сервер восстановился.
Если продолжают происходить ошибки - значит, он как-то странно
восстановился. Возможно, у него в процессе поменялся ip-адрес?
Это бы объяснило, почему после рестарта nginx его увидел.
--
Maxim Dounin
http://nginx.org/en/donation.html
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: upstream max_fails и упавшие сервера
Если продолжают происходить ошибки - значит, он как-то странно
восстановился. Возможно, у него в процессе поменялся ip-адрес?
Это бы объяснило, почему после рестарта nginx его увидел.
Дело в том, что эти 2 сервера - aws-инстансы. Внешний ip-адрес у них
постоянный, а вот внутренний - может меняться. Т.к. у меня идет привязка к
внутренней aws-dns-службе. Так что вариант, что во внутренней сети и них
разные ip, вполне имеет почву.
А, если это так, можно ли что-то сделать на стороне nginx? Я же их
прописываю в конфиге по dns-адресам, а не ip. Или nginx внутри себя все
равно хранит представление в ip-адресе?
17 июня 2013 г., 17:56 пользователь Андрей Урядов anurya...@gmail.comнаписал:
Да
17 июня 2013 г., 17:53 пользователь Maxim Dounin mdou...@mdounin.ruнаписал:
Hello!
On Mon, Jun 17, 2013 at 04:09:19PM +0400, Андрей Урядов wrote:
Всем привет.
Столкнулся с интересным поведением директивы max_fails в upstream.
Версия nginx 1.2.6.
Опишу ситуацию.
1. Nginx работает на сервере some_host1. Кусок конфига:
upstream fpm {
server some_host1:9000 weight=6;
serversome_host2:9000 weight=4;
}
2. В какой-то момент some_host2 зависает (на уровне ОС), т.е. не
отвечает
на запросы.
3. В логах появляются строки connect() failed (110: Connection timed
out)
while connecting to upstream. Причем, я считал, что т.к. max_fails не
указан, он равен 1, и, стало быть, таких строчек не должно быть, т.к.
nginx
должен перекидывать всех на первый сервер.
4. some_host2 перестартует. На нем запускается fpm.
5. Но почему-то строки из лога не пропадают и клиентам отдаются ошибки.
6. Если перестартовать nginx, то он подцепит оба сервера, и все
продолжится
в штатном режиме.
Вопросы:
1. Почему после первого неудачного раза сервер не отрубается? Ведь
max_fails равно 1.
После того, как случилась ошибка - nginx будет посылать запросы на
плохой сервер раз в fail_timeout секунд (нюанс: из каждого
рабочего процесса). Если он успешно ответит на запрос - то будет
вновь включён в работу.
2. Почему после рестарта сервера nginx его не видит? Он же продолжает
его
дергать, и мог бы понять, что сервер восстановился.
Если продолжают происходить ошибки - значит, он как-то странно
восстановился. Возможно, у него в процессе поменялся ip-адрес?
Это бы объяснило, почему после рестарта nginx его увидел.
--
Maxim Dounin
http://nginx.org/en/donation.html
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: upstream max_fails и упавшие сервера
Понятно, спасибо. Видимо, самым дешевым вариантом будет прописывание в cron перечитывания конфигурации каждый час + ручное перечитывание каждый раз после сбоя. Тогда, даже если забыть руками перечитать конфигурацию, через час она перечитается. Я так понимаю, это дешевая операция? 17 июня 2013 г., 18:19 пользователь Maxim Dounin mdou...@mdounin.ruнаписал: Hello! On Mon, Jun 17, 2013 at 05:59:15PM +0400, Андрей Урядов wrote: Если продолжают происходить ошибки - значит, он как-то странно восстановился. Возможно, у него в процессе поменялся ip-адрес? Это бы объяснило, почему после рестарта nginx его увидел. Дело в том, что эти 2 сервера - aws-инстансы. Внешний ip-адрес у них постоянный, а вот внутренний - может меняться. Т.к. у меня идет привязка к внутренней aws-dns-службе. Так что вариант, что во внутренней сети и них разные ip, вполне имеет почву. А, если это так, можно ли что-то сделать на стороне nginx? Я же их прописываю в конфиге по dns-адресам, а не ip. Или nginx внутри себя все равно хранит представление в ip-адресе? Имена превращаются в IP-адреса при чтении конфигурации. Если IP-адреса меняются - нужно пнуть nginx, чтобы он перечитал конфигурацию. -- Maxim Dounin http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: upstream max_fails и упавшие сервера
Hello! On Mon, Jun 17, 2013 at 06:32:29PM +0400, Андрей Урядов wrote: Понятно, спасибо. Видимо, самым дешевым вариантом будет прописывание в cron перечитывания конфигурации каждый час + ручное перечитывание каждый раз после сбоя. Тогда, даже если забыть руками перечитать конфигурацию, через час она перечитается. Я так понимаю, это дешевая операция? Это зависит от структуры нагрузки. Если есть длинные запросы - то старые рабочие процессы могут долго не завершаться. В общем случае - я бы скорее смотрел в сторону init-скриптов на бекендах, уведомляющих фронтенд, что ему надо перечитать конфигурацию. -- Maxim Dounin http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
