16

Я немного смущен в связи с использованием липкой сессии на веб-сервисах Amazon. Когда я разворачиваю свое java-приложение с помощью Amazon Elastic Beanstalk, я могу выбрать включение липкости сессии, а затем указать период истечения срока действия cookie.Сессионная липкость на веб-сервисах Amazon

Мое приложение использует файлы cookie для сеанса (JSESSIONID), а также для других мелочей. Большая часть веб-сайта доступна только после входа в систему (для управления ею используется Spring). На веб-сайте будет работать до 25 небольших экземпляров EC2.

Должен ли я разрешать сессионную липкость? Если я не включил его, значит ли это, что я мог быть удален из системы, потому что балансировщик нагрузки взял меня на другой сервер (а не на сервер, который прошел проверку подлинности)? Если я включу личность сеанса, я выйду из системы, когда сервер, прошедший проверку подлинности, отключится? В принципе, почему и когда я должен использовать липкость сеанса?

спасибо.

+0

Session липкости можно в приложении узла на AWS расслоения плотного ?? –

ответ

21

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

Да

Если я включаю сеанса липкость, я получаю вход, когда сервер, который получает аутентификацию меня закрыли?

Да

При использовании Elastic Beanstalk с типичной Java веб-приложение, я думаю, вы определенно хотите, чтобы активировать сеанс липкости. В противном случае каждый HTTP-запрос из браузера пользователя может быть перенаправлен на другой сервер.

Чтобы обойти проблему срыва сеанса пользователя, когда сервер «застрял» на закрытии, вам нужно будет посмотреть в Tomcat session replication. Это не то, что Elastic Beanstalk поставляется с коробкой, к сожалению, поэтому, чтобы настроить репликацию сеанса, вам нужно будет создать пользовательский Elastic Beanstalk AMI для вашего приложения. Кроме того, вам нужно будет использовать реализацию репликации сеанса Tomcat that does not rely on multicast, поскольку многоадресная рассылка недоступна в AWS или любой другой облачной среде, о которой я знаю. Примером реализации, которая не полагается на многоадресную рассылку, является та, которая использует базу данных (например, Amazon RDS) или сервер memcached (например, Amazon Elastic Cache), чтобы сделать сеансы доступными для нескольких экземпляров Tomcat.

Также обратите внимание, что пользовательский интерфейс Elastic Beanstalk позволяет вам разрешать HTTP-файлы, созданные с помощью балансировки нагрузки. Однако после того, как Elastic Beanstalk создал балансировщик нагрузки, вы можете войти в консоль EC2 и изменить настройки балансировки нагрузки, чтобы переключить его на HTTP-файлы, созданные приложением, и затем сообщить ему, чтобы использовать cookie «JSESSIONID».

+0

Большое спасибо за ваш исчерпывающий ответ, @mbaird. Я настроил репликацию сеанса в Tomcat с помощью базы данных MySQL. Я следовал этому руководству: http://www.intelligrape.com/blog/2010/07/21/tomcat-6-session-persistence-through-jdbcstore/. Он отлично работает, когда есть один экземпляр EC2. Когда есть два (или более), он переходит в цикл переадресации при входе в систему. Он 302 перенаправляется на домашнюю страницу снова и снова. Каждый раз, когда он перенаправляется, сервер устанавливает cookie с другим JSESSIONID.У вас есть идея, почему это происходит? Спасибо! – satoshi

+3

Настройка «memcached-session-manager» для работы с Amazon ElastiCache решила проблему. Спасибо! – satoshi