Назад | Перейти на главную страницу

Как избежать 502 Bad Gateway при циклическом перезапуске процесса веб-сервера

У меня есть балансировщик нагрузки / обратный прокси-сервер (nginx или cherokee, не имеет значения, какой), развернутый на моем сервере, и он указывает на несколько фоновых процессов веб-сервера (либо gunicorn, либо cherrypy, неважно какой) в настройке с циклическим перебором .

Чтобы минимизировать время простоя, у меня есть сценарий перезапуска веб-сервера, который убивает определенный процесс веб-сервера (из, скажем, 8 процессов), а затем немедленно запускает его снова; а затем переходит к следующему процессу веб-сервера (убить его, а затем запустить снова), поэтому в любой момент времени для моего обратного прокси всегда будет доступно как минимум 7 процессов, на которые он мог бы указать.

Это круто; но есть ли способ «усовершенствовать» этот процесс, чтобы я вообще не получал 502 Bad gateway? 502 шлюз происходит, когда пользователь оказывается на сайте и использует процесс веб-сервера, который временно убивается и восстанавливается.

Очевидно, причина, по которой мне нужен сценарий перезапуска, заключается в развертывании нового кода Python в моем приложении Python (работающем на Gunicorn или Cherrypy).

Зачем ты убиваешь пушечного рога? Просто отправьте ему SIGHUP, как любой другой хорошо работающий процесс Unix, и он с радостью перезагрузится без потери соединений.

nginx должен делать это из коробки. proxy_next_upstreamпо умолчанию error timeout установка передаст запрос следующему члену вышестоящего блока, если выбранный исходный сервер недоступен.

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

Использовать apache httpd вместо.

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