Насколько я понимаю из документации NGINX Plus, их Load Balancing будет маршрутизировать в обход серверов, которые упали или перегружены, и что Session Persistence пытается поддерживать тот же сервер для данного сеанса. Кажется, что эти два варианта могут стать взаимоисключающими, когда сервер падает в середине сеанса. Есть ли указание на сбой сервера, чтобы мы знали, что может быть потеря данных из-за переключения на другой сервер (который может не иметь изменений в сеансе) или он переключается тихо?
Это специально для связи по протоколу TCP/UDP, а не HTTP.
решение1
Кажется, что эти два понятия могут стать взаимоисключающими.
Да. Это не проблема, характерная только для nginx. Наилучшим решением будет реплицировать/обеспечить высокую доступность данных сеанса, но это нелегко прикрутить к существующему сервису, который не был хорошо спланирован.
Что вы хотите, чтобы nginx делал при сбое сервера, реализующего сеанс? Переключение на любой другой сервер? Переключение на определенный сервер? Ваши серверы парами? Что-то еще? Остановка сеанса, так как он находится в неопределенном состоянии... Есть так много вариантов.
Что касается сообщений об ошибках, то здесь есть 2 части. Одна из них — мониторинг: кому-то нужно сообщить, что что-то сломалось/нужно починить. Это не работа Nginx. Это должен делать ваш стек мониторинга. Вторая часть — сообщить клиенту, что что-то не работает. Nginx не знает, что он должен вернуть товар на полки/повторно применить изменение DNS. Это работа протокола, который вы используете, и приложения. Хотя есть проблемы с синхронизацией, большинство сетевых протоколов используют обмен короткими сообщениями запрос/ответ для обеспечения видимости состояния сервера на клиенте. В случае (большинства) баз данных это очень четко определено явным сообщением «COMMIT» от клиента. Но подумайте, что произойдет, если клиент скажет «COMMIT» и не получит ответа?
Это специально для связи по протоколу TCP/UDP, а не HTTP.
Как и @PersionGulf, я бы рекомендовал использовать HAProxy для балансировки нагрузки без HTTP / HA TCP через nginx. В последний раз, когда я проверял, он не может делать UDP.
Не указано, как это работает при отказе.
Это несложно проверить.