On 21.05.2021 10:09, Evgeniy Berdnikov wrote:

>> Есть nginx, который проксирует запросы на единственный бекенд php-fpm.
>> Во время перезапуска php-fpm клиентам сразу сыпятся 5хх ошибки.
>>
>> Каким образом можно настроить nginx так, чтобы он в случае ошибки
>> связи с бекендом пытался достучаться до него в течении N секунд
>> (например, 30 сек), с интервалом, например, в K секунд
>> (например, 0.1 сек) ?
>>
>> Тогда клиент вместо сообщения про ошибку видел бы просто небольшое
>> замедление ответа сервера на секунду или максимум несколько секунд,
>> что гораздо лучше, чем мгновенный возврат сообщения про ошибку 5хх.
>
> Возврат 5xx говорит о том, что либо
>
> 1. хост недоступен по сети (возможно, ребутается), по сисколу connect(2)
> возвращается EHOSTUNREACH.
> 2. хост доступен, но порт в этот момент не прослушивается, тогда
> возвращается ECONNREFUSED,
> 3. приложение возвращает 5xx и nginx форвардит этот ответ клиенту.
>
> Ели речь о п.2 и п.3 (перезапуск php-fpm), то это вовсе не ситуация
> "нет связи с бэкендом", которая п.1.

nginx и php-fpm у меня находятся на одном и том же хосте,
связь между ними идет через unix domain socket по протоколу fastcgi.

Обрабатывать таким образом, через повтор запроса имеет смысл,
разумеется, только 502 и 504 статусы на стороне nginx.

Если же бекенд вернул 500 ошибку - это внутренняя ошибка бекенда,
повтор тут ничем не поможет, эту ошибку надо сразу вернуть клиенту.

Возврат 502 бывает в случае такой записи в логах:

connect() to unix:/run/php-fpm/www.sock failed (2: No such file or
directory) while connecting to upstream

Сокет /run/php-fpm/www.sock отсутствует во время перезапуска php-fpm.

> Если же речь о ребуте хоста php-fpm, то либо бэкенд в локальной сети и
> оказывается недоступен по arp-у, тогда EHOSTUNREACH возвращается после
> arp-овского таймаута (обычно это 3 секунды), если бэкенд в другой
> подсети, то обычно шлюз возвращает icmp[host-unreachable] по той же
> причине, через те же 2-3 секунды.

Речь идет о перезапуске php-fpm командой "systemctl restart php-fpm"
Если делать "systemctl reload php-fpm" - это не всегра срабатывает,
иногда после релоада php-fpm оказывается в нерабочем состоянии,
поэтому использую именно "systemctl restart php-fpm" для изменения
конфигурации php-fpm, тогда и случаются 502 ошибки с сайтами.

Кроме того, иногда, время от времени, бывает еще такая ошибка:
upstream timed out (110: Connection timed out) while reading response
header from upstream
- тогда клиенту возвращается 504 статус. Причину этих таймаутов найти
не могу, поэтому и хотелось бы сделать workaround средствами nginx.

>> Может быть как-то с помощью njs или nginx-module-perl или с помощью
>> ngx_http_upstream_module это можно сделать? Или тут единственно возможный
>> вариант - писать патч на С для решения этой задачи?
>
> Ох... да просто отрубить пакетным фильтром (файрволом) этот бэкенд
> на время всех манипуляций по перезапуску php-fpm. А когда запустится,
> открыть обратно. Конечно, proxy_connect_timeout подкрутить.
> И заскриптовать всё.

Там unix domain socket, какой пакетный фильтр может быть?
Кроме того, чем поможет отрубать этот бекенд, ведь он единственный?
(см. тему: Re: Configuring nginx to retry a single upstream server)
Будет точно так же 502 ошибка. А ведь именно этого я и хочу избежать.

P.S.

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

--
Best regards,
Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru