Балансировка нагрузки, Spring Security, ConcurrentSessionFilter

У меня есть установка приложения Spring 2.5.6/Flex, работающая с Spring Security 2.0.4. Недавно балансировщик нагрузки (Foundry ServerIron 4g http://www.foundrynet.com/products/a...ems/si-4g.html) был введен в действие, и теперь я получаю междоменные ошибки. По сути, балансировщик нагрузки отправляет запрос к myloadbalancer.abc.com, а myrealserver1.abc.com возвращается в качестве доменного имени. Безопасность Spring каким-то образом перенаправляет запрос на реальный сервер. Как я могу обойти это?

Также ConcurrentSessionFilter больше не работает. Приложение настроено на отключение одновременных входов в систему, но эта функция перестала работать после того, как приложение было помещено за балансировщиком нагрузки. Я полагаю, что несколько серверов приложений Oracle также объединены в кластер. Я никогда раньше не имел дело с кластеризацией или балансировщиками нагрузки и не знал, что программное обеспечение должно быть написано по-разному в определенных областях.

Для меня это звучит как отдельные проблемы, но мне нужна помощь для обоих.


person Dan Polites    schedule 03.02.2009    source источник


Ответы (1)


Что касается вашей второй проблемы:

Если ConcurrentSessionFilter перестал работать (т. е. больше не предотвращает одновременные сеансы), это может быть связано с контейнерами кластерных приложений с закрепленными сеансами.

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

Теперь Spring Security ConcurrentSessionController работает, сопоставляя сеансы принципалам. Сам контроллер полагается на HttpSessionEventPublisher отправку ApplicationEvents при запуске и завершении пользовательских сеансов.

Все будет работать нормально, если кто-то, намеревающийся открыть более одного сеанса, окажется на том же узле, у которого уже открыт сеанс. HttpSessionEventPublisher информирует механизм параллельного сеанса о создании сеанса, и аутентификация завершится ошибкой, поскольку с этим пользователем уже связан сеанс. Однако на другом узле для этого пользователя еще нет сеанса, поэтому ConcurrentSessionController не жалуется, и вход в систему выполнен успешно.

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

person Nils Wloka    schedule 15.03.2009