Маршрутизация NGINX на основе ошибок ответа сервера 200

Question

Моя цель - настроить объект (ы) потока nginx в конфигурации для маршрутизации запросов в резервную копию восходящего потока в случае сбоя при определенных проверках работоспособности (2/3)

Проверки работоспособности, хотя и специфические, я считаю, не должно быть проблемой:

-TCP 1212 наличие

-TCP 1912 наличие

-HTTP GET на 7078 /?

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

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

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

Есть ли способ сделать это в конфигах NGINX или я слишком тонко выкладываю?

Answer 1

Модуль восходящего потока NGINX будет выполнять за вас пассивные проверки работоспособности, то есть он будет реагировать на сбои подключения и, при необходимости, переключаться на резервные серверы при необходимости. В некоторой степени этого может быть достаточно для вас.

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

Если вам действительно нужны такие активные проверки работоспособности, вы все равно можете сделать это вне NGINX. Один из подходов может быть таким:

1. поместите свои апстримы в отдельные конфи и include один из них там, где он вам нужен
2. использовать ncat и / или curl в ежеминутной работе cron, чтобы выполнять важные для вас тесты
3. если когда-либо эти тесты не пройдут, отключите восходящие конфигурации и скажите NGINX выполнить перезагрузку с нулевым временем простоя

Вы можете быстро переключать conf mv переименовать правильный, чтобы он соответствовал include, вам не придется ничего переписывать.