AWS Elasticache Tomcat failover - предпочтительнее для первичного Tomcat?

Question

Я запускаю свое приложение с помощью установки AWS - Tomcats работает за балансировщиком упругих нагрузок (ELB) на экземплярах EC2, с защитой memcached Elasticache с несколькими узлами. Я настроил свое веб-приложение для хранения данных сеанса в Elasticache, чтобы серверы Tomcat были доступны для пользователя (т. Е. Когда Tomcat отключается, пользователь не выходит из системы, но их запросы просто обслуживаются другим доступным Кот). Он работает так, как ожидалось, за исключением одного интересного случая, который я заметил во время тестирования.

Когда я закрыл Tomcat, который в настоящее время запускает приложение, через некоторое время другой Tomcat начинает обслуживать запросы, и пользователь остается включенным. Однако, когда я перезапускаю остановленный Tomcat, приложение переключается с его текущий Tomcat для запуска на ранее остановленном экземпляре, чего я не ожидал - я думал, что приложение будет продолжать работать на новом Tomcat до тех пор, пока оно не будет остановлено, а затем оно попытается снова переключиться.

Я искал объяснения этого поведения, и некоторые источники указали, что это может быть проблема конфигурации ELB, но не упоминает, какой вариант конфигурации может вызвать эту «привилегированную первичную» обработку. В настоящее время мой ELB настроен на липкие сеансы и использует AppCookieStickinessPolicy с именем cookie для JSESSIONID. До сих пор все мои Tomcats проживали в той же зоне доступности (us-east-1b). Есть идеи? Это типичное поведение липкости?

EDIT: Документация Amazon здесь: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-sticky-sessions.html, кажется, прямо опровергает поведение, которое я наблюдал.

Если экземпляр выходит из строя или становится нездоровым, балансировки нагрузки перестает запросы маршрутизации к этому экземпляру, и выбирает новый здоровый экземпляр на основе существующего алгоритма балансировки нагрузки. Балансировщик нагрузки рассматривает сеанс как «застрявший» к новому здоровому экземпляру и продолжает запросы маршрутизации к этому экземпляру, даже если неудавшийся экземпляр возвращается.

Answer 1

Я наблюдал за этим поведением в течение многих лет в производственной системе, которой я управляю, которая не находится на амазонке. Я думаю, что это поведение по умолчанию memcached-session-manager tomcat использует для репликации сеанса удаленный кеш.

Такое же поведение наблюдается, когда я теряю узел tomcat. Tomcat отправляется в memcached для сеанса и плавно взаимодействует с клиентом в другом поле, и когда исходная коробка возвращается, пользователь возвращается к коробке, в которой они были.

Я не мог сказать вам, является ли он настраиваемым, но мы запускаем минимально настроенную настройку здесь, и это похоже на поведение MSM по умолчанию.