replicación de sesión tomcat sin multidifusión

Question

planeo usar 2 servidores raíz dedicados alquilados en un proveedor de alojamiento. esas máquinas ejecutarán Tomcat 6 en un clúster. si agregaré máquinas adicionales más adelante, es poco probable que se pueda acceder a ellas con multidifusión, ya que estarán ubicadas en diferentes subredes.

¿Es posible ejecutar Tomcat sin multidifusión? todos los tutoriales para agrupación de tomcat 6 incluyen latidos de corazón de multidifusión. ¿Existen alternativas a SimpleTcpCluster?

¿O son otras alternativas más apropiadas en esta situación?

Answer 1

Sin control sobre la distancia entre ambos servidores (pueden estar en dos centros de datos diferentes) y sin una línea dedicada de comunicación entre servidores, prefiero ejecutarlos a través de DNS de turno rotativo o un equilibrador de carga que redirige a los clientes a cualquiera www1.yourdomain.xxx o www2.yourdomain.xxx y maneja la comunicación del servidor con cuidado.

Si los servidores se están comunicando fuertemente entre sí, puede cambiar la arquitectura, optimice el infierno de su aplicación para que se ajuste a "quot"; en un servidor (al menos por un tiempo) o busque un alojamiento dedicado con control sobre la ubicación, la distancia y el cableado de sus servidores. De lo contrario, su comunicación entre servidores, latidos, etc., utilizaría el mismo canal que los clientes que se comunican con él (por ejemplo, el mismo segmento de red), lo que podría ralentizar a todos.

Si realmente estás esperando tanta carga, supongo que hay al menos algo de dinero involucrado, ¿no? Utilícela sabiamente y use sus habilidades de configuración para problemas más difíciles que configurar la agrupación en clúster distribuida sin control o líneas dedicadas.

Answer 2

Al ver el comentario a la pregunta después de haber dado mi otra respuesta, estoy confundido acerca de cuál es tu pregunta ... ¿Se trata de la replicación de la sesión? ¿Comunicación grupal? Podría ser mejor plantear su problema en lugar de la solución planificada que tiene problemas en sí misma.

Presentaré algunos problemas posibles junto con respuestas rápidas:

Su aplicación es intensiva en CPU / RAM

• Perfílelo, optimícelo, inténtelo de nuevo
• Compre un servidor más grande / mejor

Su aplicación es intensiva en ancho de banda

• el uso de la agrupación de cheapo que mencionó en su pregunta probablemente la empeorará, ya que el mismo canal (oculto) se usa para la comunicación entre servidores y para la comunicación cliente-servidor.
• Es posible que pueda separar diferentes tipos de ancho de banda, por ejemplo, al tener contenido dinámico servido desde un servidor diferente al contenido estático: no es necesario que haya comunicación entre servidores aquí

Su aplicación requiere mucho almacenamiento

• obtener un servidor más grande
• vaya a un alojamiento dedicado y coloque tantos discos giratorios como necesite
• vea si otros modelos (como el almacenamiento de Amazon S3) podrían funcionar para usted

Es probable que tu aplicación esté recortada con una barra

• determine cuáles de los factores anteriores (u otros) determinan los límites de su aplicación, corríjalos.

¿Solo necesitas replicación de sesión?

• La interfaz de Tomcats SessionManager es pequeña y se puede implementar / ampliar fácilmente. Úsalo para cualquier replicación de sesión que te guste. Consulte la StandardManager documentación e implementación para más información

Más ideas

• busque configuraciones más flexibles como EC2 (amazon), ofertas de googles u otras configuraciones de computación en la nube. Hacer uso de su propio almacenamiento en la nube e instalaciones de comunicación entre servidores. Tenga cuidado de no depender demasiado de esta infraestructura.

Ciertamente he olvidado algo, pero esto podría proporcionar algún punto de partida. Sea más concreto sobre la naturaleza de su problema subyacente para obtener mejores respuestas :)

Answer 3

Estoy intentando implementar el Servidor de autenticación central (CAS) de yale y me gustaría agruparlo para redundancia, porque esta es una pieza crítica de la infraestructura. CAS requiere que la sesión se replique, porque después de que un usuario inicie sesión en la aplicación A y navegue a la aplicación B que participa en el dominio de inicio de sesión único, la aplicación B envía una solicitud a CAS para determinar si el usuario tiene un "ticket" activo . Como no hay ningún dispositivo para indicar a la aplicación B a qué nodo debe dirigirse para validar el ticket, todos los tickets activos en un nodo deben replicarse en todos los nodos del clúster. En otras palabras, la adherencia de la sesión no es una solución aquí, porque la aplicación B, al validar el ticket en la cookie del usuario, no conoce el Id. De sesión de la sesión original en la aplicación A durante la cual el usuario inició sesión.

Por lo tanto, CAS requiere que la sesión se replique en todos los nodos. El requisito de que la red sea compatible con la multidifusión agrega una sobrecarga no trivial y hace que este enfoque sea un poco más pesado de implementar. He probado este proyecto en google code:

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

que parece muy útil y sencillo de implementar (al menos en un sistema operativo Linux), pero desafortunadamente solo proporciona una conmutación por error de sesión, y no es una solución de replicación de sesión.

Answer 4

Solo use http://code.google.com/p/memcached-session -manager / . Funciona muy bien Lo estamos utilizando durante años para esta configuración con 20 servidores Tomcat que comparten sesiones. Puede tener uno o dos servidores memcached para manejar la replicación de la sesión.