Как файлы cookie работают с балансерами непостоянной нагрузки

У нас есть приложение Drupal, которое использует sso для входа в систему.

Мы используем классические балансировщики нагрузки AWS (ELB), AWS сообщает нам, что на ELB нет постоянных сеансов.

То, что я пытаюсь выяснить, - это то, как cookie-файлы работают без постоянства на классических балансировщиках нагрузки.

Пример.com DNS указывает на ELB. Есть 2 сервера в пуле Server1 и Server2

То, что мы хотим сделать, - это если пользователь нажимает на свою домашнюю страницу, http://example.com/user/12345/скажем, на сервере 1, если он еще не вошел в систему, он перенаправляется на страницу sso http://example.com/user/login/sso, автоматически входит в систему и получает файл cookie, SESS<hexnumber>а затем перенаправляется обратно наhttp://example.com/user/12345/

Нам не разрешается добавлять какие-либо серверы сеансов (redis), что является гарантией того, что они будут оставаться на сервере 1 для обоих перенаправлений.

Насколько мне известно, при каждом обращении к «example.com» пользователь может оказаться на сервере 1 или 2.

Мой вопрос:

Если они получают cookie на server1, а затем перенаправляются на server2, как server2 узнает, что cookie уже назначен этому пользователю на server1?

Кажется, я думаю о себе в кругах. При работе с этим типом установки в прошлом с использованием LB без сохранения сеанса мы использовали сервер redis для хранения сеансов, и каждый запрос просматривал сервер redis для получения информации о сеансе.

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

Если cookie указывает на сеанс, то необходимо, чтобы и server1, и server2 имели какой-либо доступ к этому сеансу. Если сеансы не могут быть разделены между серверами, вам нужно заставить пользователя остаться на определенном сервере. Это можно легко сделать с помощью DNS и немного магии перезаписи URL:

• www.example.com указывает на оба сервера.
• www1.example.com указывает только на server1
• www2.example.com указывает только на server2

Используя набор простых правил перезаписи (ish) и cookie, пользователь может быть привязан к определенному серверу, что гарантирует сохранение его сеанса.

Вот еще несколько деталей.

DNS:

• example.com A 1.1.1.1, A 2.2.2.2
• www.example.com CNAME example.com
• www1.example.com A 1.1.1.1
• www2.example.com A 2.2.2.2

Перепишите правила:

• постоянное печенье: "бэкэнд"
• начальное соединение: «backend» не определено, установите «backend» на www1 или www2, в зависимости от того, какой сервер ответил, и перенаправьте на этот сервер. Файл cookie должен быть настроен на домен «example.com», таким образом он будет загружен как на www1, так и на www2.
• Если задано «backend», убедитесь, что его значение соответствует экземпляру сервера, и при необходимости перенаправьте.
• Убедитесь, что файл cookie сеанса определен в полном доменном имени сервера - то есть www1.example.com или www2.example.com.

Логика перезаписи должна быть определена на самом веб-сервере. Все современные веб-серверы имеют очень интересные языки переписывания, которые полностью способны реализовать эту функциональность.

Если вы не можете использовать базу данных управления сессиями, такую ​​как Elasticache Redis (Redis для простых сессий не должен стоить более 15 долларов в месяц), то следующим лучшим вариантом будет включение липких сессий на ELB;

https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html

Это заставит пользователей переходить к одному и тому же внутреннему узлу на протяжении всего сеанса. «Файл cookie, сгенерированный балансировщиком нагрузки» со временем жизни 900 секунд должен быть достаточно хорошим, но вы можете изменить это.