LINUX.ORG.RU

NGINX - работа в кластере, резервирование сессий

 


2

2

Всем привет, подскажите, есть ли в NGINX, настроенном для балансировки, возможность резервирования сессий ?

Пример:

Есть NGINX (балансировщик), собранный в кластер для отказоустойчивости, пусть будет, active-passive. Активный узел падает, но пассивный за счет того, что имеет информацию о сессиях такую же как активная нода, подхватывает существующие сессии. Т.е. не прерывая их.

Не нашел упоминанию данного механизма в документации. Есть только про синхронизацию конфигураций узлов в кластере, а про сессии что-то ничего не нашел....

А сессиями разве не занимается нижестоящий сервис ?
Для этих делов пользуют memcache,redis и тому подобные штуки.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Сразу скажу, я не силен в балансировщиках. У нас используются древние циски в качестве них. Два балансировщика собраны в кластер, на каждом из них хранится состояние сессий. И в случае отказа одного из балансировщиков в кластере другой подхватывает сессии и продолжает их обрабатывать. Как-то так, вот я и ищу подобный функционал(возможность) в NGINX.

Как пример, вот описание этого механизма в статье на хабре для Апача, так называемая репликация сессий: https://habr.com/ru/post/190196/

Выдержка из статьи:

«Схема работы следующая: все запросы, ранее отправляемые непосредственно на http/https коннектор JBoss-а, теперь должны обращаться к веб-серверу (Apache). Apache настраивается таким образом, чтобы «знать» о существовании «за его спиной» двух серверов приложений. При первом обращении клиента к Системе, веб-сервер выбирает один из серверов приложений (Узел-1) и перенаправляет запрос к нему. Создается сессия, в нее добавляется Cookie, которая в дальнейшем используется веб-сервером для того, чтобы «приклеить» все последующие запросы того же клиента к выбранному серверу приложений. Узел-1, обрабатывающий запросы клиента, при создании/изменении сессии реплицирует её состояние на остальные узлы кластера, где они и висят мёртвым грузом, пока что не принося никакой пользы.»

strelok00
() автор топика
Ответ на: комментарий от goingUp

Спасибо за ссылку.

Да, именно такой вариант и нужен sticky/persistence, когда конкретные пользователи направляются на конкретные сервера. Однако здесь есть нюансы, в особенности с работой по ip hash:

1. Хэш формируется на основе первых трех октетов ip адреса. Мы используем балансировку внутри ЦОДа и адреса находятся в одной подсети (локальной).

2. Не поддерживается https.

strelok00
() автор топика
Ответ на: комментарий от strelok00

Хэш формируется на основе первых трех октетов ip адреса.

ip адреса клиента, а не ваших серверов

2. Не поддерживается https.

Да, терминировать https нужно будет на nginx

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)

Нужно больше балансировщиков.
Подними IPVS под Nginx

zolden ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.