Репликация сессии Tomcat без многоадресной рассылки

Question

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

возможно ли запустить tomcat без многоадресной рассылки? Все учебные пособия по кластеризации tomcat 6 включают многоадресный пульс. Есть ли альтернативы SimpleTcpCluster?

или другие альтернативы более уместны в этой ситуации?

Answer 1

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

Я изложу некоторые возможные проблемы вместе с быстрыми ответами:

Ваше приложение интенсивно использует CPU / RAM

• Профилируйте его, оптимизируйте, попробуйте снова
• Купить больший / лучший сервер

Ваше приложение интенсивно использует пропускную способность

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

Ваше приложение требует много памяти

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

Ваша заявка может быть с косой чертой

• определите, какие из вышеперечисленных факторов (или другие) определяют пределы вашего приложения, исправьте это.

Вам просто нужна репликация сеанса?

• Интерфейс Tomcats SessionManager небольшой и может быть легко реализован / расширен. Используйте его для любой репликации сеанса, которая вам нравится. См. StandardManager документацию и реализацию для получения дополнительной информации

Больше идей

• посмотрите на более гибкие настройки, такие как EC2 (amazon), предложения googles или другие настройки облачных вычислений. Используйте свои собственные облачные хранилища и средства связи между серверами. Будьте осторожны, чтобы не слишком зависеть от этой инфраструктуры.

Я, конечно, кое-что забыл, но это может послужить отправной точкой. Будьте более конкретными о природе вашей основной проблемы, чтобы получить лучшие ответы:)

Answer 2

Без контроля расстояния между обоими серверами (они могут находиться в двух разных центрах обработки данных) и без выделенной линии связи между серверами, я бы предпочел запустить их через циклический DNS или распределитель нагрузки, который перенаправляет клиентов на www1.yourdomain.xxx или www2.yourdomain.xxx и тщательно обрабатывайте взаимодействие с сервером.

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

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

Answer 3

Я пытаюсь развернуть Йельский центральный сервер аутентификации (CAS), и я хотел бы кластеризовать его для избыточности, потому что это критически важный элемент инфраструктуры. CAS требует, чтобы сеанс реплицировался, потому что после того, как пользователь входит в приложение A и переходит к приложению B, которое участвует в домене единого входа, приложение B отправляет запрос в CAS, чтобы определить, есть ли у пользователя активный «билет» , Поскольку нет устройства, которое указывало бы приложению B, к какому узлу оно должно обратиться к себе для проверки билета, все активные билеты в одном узле должны быть реплицированы на все узлы в кластере. Другими словами, прилипание сеанса здесь не является решением, поскольку приложение B при проверке заявки в файле cookie пользователя не знает идентификатор сеанса исходного сеанса в приложении A, во время которого пользователь вошел в систему.

Таким образом, CAS требует, чтобы сеанс реплицировался на все узлы. Требование о том, что сеть поддерживает многоадресную рассылку, добавляет нетривиальные издержки и делает этот подход более сложным для развертывания. Я проверил этот проект на Google Code:

http://code.google.com/p/memcached-session-manager

, который кажется очень полезным и простым в развертывании (по крайней мере, в ОС Linux), но, к сожалению, обеспечивает только восстановление после отказа сеанса и не является решением для репликации сеанса.

Answer 4

Просто используйте http://code.google.com/p/memcached-session-manager/. Работает отлично. Мы используем его годами для этой установки с 20 серверами Tomcat, которые совместно используют сессии. Вы можете иметь один или два сервера memcached для управления репликацией сеанса.