Agrupación de una aplicación Java EE sin estado con Glassfish en Amazon AWS

Question

¿Cuál es la mejor forma de implementar una aplicación Java EE 6 sin estado en un entorno distribuido para lograr una alta disponibilidad y escalabilidad? Mi aplicación es apátrida. Por lo tanto, no necesito para replicar cualquier estado de sesión (sesión HTTP, EJB con estado habas, etc.)

En concreto, me gustaría saber lo siguiente:

• qué necesito el capacidades de clustering de Glassfish 3.1 (dado que no necesito replicar el estado de la sesión)?
• Uso mucho las colas JMS y los beans controlados por mensajes. ¿Cómo configuro JMS para que funcione en un entorno agrupado?
• También estoy usando el servicio de temporizador EJB. ¿Cómo funciona eso en un entorno agrupado? ¿Hay algo que deba hacer además de usar una base de datos compartida para almacenar temporizadores (y no la base de datos Derby integrada)?

Planeo usar Amazon AWS (RDS con implementación multi AZ, equilibrio de carga elástico, EC2).

Answer 1

Estoy en una situación similar, y actualmente estoy descubriendo qué agrupación de GF puede hacer/no hacer por mí.

Re 1) ¿He de las capacidades de clustering de Glassfish 3.1

Desde sus EJB son sin estado, que no es necesario un grupo GF para la replicación de sesiones/estado (como se dice a sí mismo). Puede configurar múltiples instancias independientes y desplegar su aplicación individualmente. Sin embargo, incluso en una aplicación sin estado, considero que los beneficios de un clúster GF valen la pena, desde un punto de vista administrativo.

El GF Cluster se asegurará de que la configuración se aplique automáticamente a todas las instancias. JNDI se replica automáticamente. Las aplicaciones se implementan automáticamente. Es un solo comando escalar y agregar una instancia adicional; poco tiempo después, su clúster se amplía y la nueva instancia se configura, despliega, inicia y está lista para funcionar. Para mí, ese es el paraíso administrativo y razón suficiente para usar un clúster GF cada vez que tengo más de 1 instancia.

Una cosa para tener en cuenta (y estoy luchando con esto mal por el momento) podría ser una caché L2 distribuida/coordinada, en caso de que su aplicación esté hablando con una base de datos.

Re 2) ... ¿Cómo configuro JMS para que funcione en un entorno agrupado?

No estoy seguro Entiendo su pregunta ... Si desea tener un agente de mensajes de alta disponibilidad fuera de GF, deberá configurarlo en consecuencia y administrarlo usted mismo. Por ejemplo, ActiveMQ tiene varias formas de configurar clustering/HA/scale-out. Si usa el OpenMQ proporcionado por GF, la configuración de un clúster GF también proporciona un intermediario de mensajes en clúster. Fuera de la caja.

Pero la agrupación de intermediarios es un tema en sí mismo, y no debe subestimarse. Es posible que necesite pensar en la persistencia y en un almacén de mensajes compartidos, sin importar si utiliza un intermediario externo o el bróker proporcionado por GF y agrupado.

Si JMS es una parte tan integral de su aplicación, recomendaría la atención adecuada para el bróker. Probablemente no usaría GF-broker, sino que tendría un broker-cluster separado (separación de preocupaciones, por ejemplo, puede actualizar GF/broker independientemente el uno del otro).

Re 3) Servicio de temporizador EJB ... ¿Hay algo que necesite hacer además de usar una base de datos compartida para almacenar temporizadores?

Si necesita temporizadores para disparar automáticamente sólo una vez en su grupo de (appserver-) casos, creo que hace agrupación necesidad GF (además de la base de datos compartida por supuesto). De lo contrario, no veo cómo cada instancia debería saber si debería disparar o no. Sin embargo, esto se prueba fácilmente ...

tl; dr

• Uso GF agrupación para ahorrar en el trabajo de administración
• uso de un agente externo, bien entendido-alta disponible mensaje
• Usar una base de datos compartida para sus temporizadores EJB

Answer 2

Mi perspectiva sobre sus respectivos puntos:

1) replicación de sesiones es una parte de la gestión de clusters, no es el objetivo de crear entorno de servidor agrupado. Los beneficios que obtiene de la agrupación son:

• escalabilidad mejorada
• mayor disponibilidad
• Mayor flexibilidad Los efectos secundarios de la agrupación son aumento de la complejidad de la infraestructura, de diseño adicional y los requisitos del código, etc. Así que si estás Al pensar en la agrupación, su decisión debe ser impulsada por los factores como qué tan escalable, disponible y flexible quiere que sea su aplicación.

2) Puede utilizar Apache ActiveMQ con su servidor glassfish para hacer que su JMS funcione en un entorno agrupado.

3) Creo que debería ser suficiente compartida DB

Answer 3

Usted probablemente necesitará un marco EJB grado industrial si realmente quiere que su aplicación se ejecute sin problemas .... Sin embargo, ciertamente no se limitan a glassfish solo. ¡Lo importante es recordar que EJB es una especificación que no está necesariamente limitada a ninguna implementación!

1) ¿Necesito las capacidades de clúster de Glassfish 3.1 (dado que no necesito replicar el estado de la sesión)?

NO que sin duda no lo hace. Si su aplicación es apátrida, Glassfish no será necesario.

2) Uso mucho JMS Queues y Message Driven Beans. ¿Cómo configuro JMS para que funcione en un entorno agrupado?

JBoss es una opción aquí. Los servicios de clúster de I JBOSS simplemente reelegen nuevos nodos maestros para administrar los mensajes si uno se cae, por lo que la disponibilidad está garantizada.

3) También estoy usando el servicio de temporizador EJB. ¿Cómo funciona eso en un entorno agrupado? ¿Hay algo que deba hacer además de usar un DB compartido para almacenar temporizadores (y no el DB Derby incorporado)?

sincronización puede agruparse de forma transparente si el uso de cualquiera de las implementaciones O WebLogic EJB Jboss. En este caso, no creo que necesite una base de datos integrada: los frameworks pueden manejar esto directamente: .