Прикрепленные сеансы AWS Network Load Balancer не работают

В моей учетной записи AWS у меня в настоящее время есть балансировщик сетевой нагрузки (TCP), указывающий на два экземпляра Ec2 в 2 зонах доступности (веб-серверах), на каждой из которых работает tomcat, это указывает на один экземпляр Ec2, который является сервером / базой данных приложений.

На NLB включены липкие сеансы, поэтому, когда я получаю доступ к веб-серверам из Chrome на одной вкладке, все работает нормально, и весь мой пользовательский трафик отправляется на один веб-сервер. Когда я открываю новую вкладку, кажется, что начинается новый сеанс, и мой пользовательский трафик может быть отправлен либо на веб-сервер 1, либо на веб-сервер 2. Если он отправляется на другой веб-сервер, меня просят снова войти в систему. Цель состоит в том, чтобы весь трафик пользователя направлялся через один веб-сервер.

Кто-нибудь знает, почему липкие сеансы в AWS Network Load Balancer не работают должным образом? Или я неправильно это понял.


amazon-web-services amazon-ec2 amazon-elb load-balancing aws-elb
person Sts01    schedule 03.07.2020    source источник
comment
Работает ли просмотр в инкогнито? Вы проверили эти соображения: docs.aws.amazon.com/elasticloadbalancing/latest/network/?   -  person Chris Williams    schedule 03.07.2020
comment
NLB не использует файлы cookie для прикрепленных сеансов. Я думаю, что новая вкладка означает новое соединение, поэтому она привязана к новой цели. ALB будет более подходящим, поскольку он использует файлы cookie для липких сеансов.   -  person Marcin    schedule 03.07.2020
comment
Я думаю, что NLB - единственный выбор здесь, поскольку я прохожу через частную ссылку (конечную точку для NLB).   -  person Sts01    schedule 03.07.2020
comment
Только что сделал несколько тестов в режиме инкогнито. К сожалению, все еще не сработало   -  person Sts01    schedule 03.07.2020

Ответы (2)


arrow_upward
1
arrow_downward

Из Как работает эластичная балансировка нагрузки :

С помощью балансировщиков сетевой нагрузки узел балансировки нагрузки, который получает соединение, использует следующий процесс:

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

  • Протокол
  • Исходный IP-адрес и исходный порт
  • IP-адрес назначения и порт назначения
  • Порядковый номер TCP

Направляет каждое отдельное TCP-соединение к единственной цели в течение всего срока действия соединения. TCP-соединения от клиента имеют разные исходные порты и порядковые номера и могут быть направлены на разные цели.

Я подозреваю, что, когда вы открываете другую вкладку, он может отправлять трафик с другого порта, что приводит к сбою закрепления. Честно говоря, я не уверен, как липкость будет работать на уровне 4, поскольку он не может использовать файлы cookie для запоминания липкости. У него определенно нет концепции пользователя, потому что уровень 4 не может использовать файлы cookie, поэтому нет возможности снова распознать пользователя.

person John Rotenstein    schedule 03.07.2020
comment
Речь идет о липких сессиях, которые вообще не рассматриваются в справочной документации. - person Ted Bigham; 09.04.2021

arrow_upward
0
arrow_downward

Привязка к NLB должна работать до тех пор, пока вы не установили TLS для слушателя.

https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#sticky-sessions

Обратите внимание, что балансировка нагрузки работает на основе простой маршрутизации IP-адресов. Таким образом, если все ваши клиенты находятся за одними и теми же блоками адресов (например, маршрутизацией NAT), это вызовет дисбаланс.

person Lee Jensen    schedule 04.02.2021