La configuración de destinos JMS (Queues o Topics) en un clúster WebLogic requiere de una configuración especial para ser transparente tanto para los Productores como para los Consumidores. Los Productores son aquellas aplicaciones cliente que producen los mensajes JMS, mensajes que llevan información que debe procesarse en otra aplicación o sistema, mientras que los consumidores son aquellas aplicaciones cliente que consumen los mensajes JMS para procesar la información.
La mejor forma para proveer un destino, Queue o Topic, en un clúster WebLogic es a través de la configuración de destinos distribuidos (Distributed Destinations), los cuales:
- Funcionan sobre múltiples servidores JMS
- Balancean las peticiones para producir y consumir los mensajes JMS, distribuyendo las peticiones a los distintos miembros del clúster
- Proporcionan un nivel de tolerancia a fallas, permitiendo continuar la operación después de una fallan de un miembro del clúster
- Al igual que los Queues o Topics no distribuidos, se puede tener acceso a través de JNDI, así como el resto de sus propiedades (quotas, persistencia, Unit Of Order, etc.)
La siguiente figura presenta la Arquitectura de este concepto.
Como se puede observar, un Destino Distribuido representa en realidad un conjunto de destinos, de esta manera el Destino Distribuido puede funcionar asignándose a uno o más servidores JMS, a uno o más servidores manejados, o a un clúster; y aquí viene un punto de la configuración JMS.
Es recomendable realizar el despliegue de los destinos distribuidos (Distributed Queue o Distributed Topic) a servidores JMS específicos en lugar de hacerlo al clúster, para ello utilizamos el mecanismo de Subdeployment. Si asignamos el destino distribuido a un clúster, este se instalará en cada uno de los servidores JMS asignados a dicho clúster, derivando en uso de recursos de manera innecesaria. A través de un Subdeployment, podemos asignar los destinos a servidores JMS específicos los cuales estarán dedicados y pueden ser configurados para asegurar el mejor rendimiento necesario para los mensajes JMS que por ellos pasen.
Bajo ciertas condiciones se puede realizar el despliegue directamente al clúster, sin afectar el rendimiento del mismo.
Despliegue de Colas y Topics Distribuidos
A continuación presento los dos procedimientos mencionados para la configuración de destinos distribuidos en clúster WebLogic realizados sobre un versión WebLogic 12c, sin embargo también pueden ser considerados para una versión 11g.
Despliegue a Clúster
1. Ingresar a la Consola de Administración WebLogic
2. Ir a Services > Messaging > JMS Server
3. Crear un servidor JMS, lo nombramos JMSServer_ms1; Dejamos el Persistent Store en blanco, los mensajes se mantendrán en memoria.
Para mantenerlos en el sistema de archivos generamos un Persistent Store de tipo File, para mantenerlos en una Base de Datos lo generamos de tipo JDBC.
4. Lo asignamos a uno de los servidores manejados de nuestro clúster.
5. Repetimos pasos 3 y 4 para crear un servidor JMS asignado a otro servidor manejado de nuestro clúster.
6. Ir a Services > Messaging > JMS Modules para crear un Módulo JMS
7. Creamos el Módulo JMS y lo asignamos a nuestro clúster. Habilitamos la opción para pasar a crear recursos (Would you like to add resources to this JMS system module?)
8. Creamos un Connection Factory
9. Le damos un nombre y un nombre JNDI
10. Aceptar la asignación por default y terminar. De esta manera la Connection Factory hereda el target del propio módulo JMS.
11. Crear un destino tipo Queue en el mismo módulo JMS
12. Le damos un nombre y un nombre JNDI
13. Aceptar la asignación por default y terminar, también se hereda del módulo JMS.
Nótese aquí la desventaja de este procedimiento.
14. Podemos comprobar que los recursos JMS ya se encuentran habilitados revisando el árbol JNDI de cualquier de los servidores manejados del clúster. Usamos el link View JNDI Tree disponible en la configuración de los servidores WebLogic.
15. Vamos al módulo JMS que acabamos de crear y damos clic sobre el destino distribuido.
16. Seleccionamos la pestaña Monitoring y comprobamos que nuestro destino se encuentra funcionando en los servidores de nuestro clúster.
Personalizamos la tabla para ver más detalles.
A partir de aquí nuestro destino esta listo, proporcionamos el JNDI de nuestro Connection Factory y Destino Distribuido al equipo de desarrolladores, o en otro caso, establecemos los nombre JNDI que ellos nos proporcionaron.
3. Crear un servidor JMS, lo nombramos JMSServer_ms1; Dejamos el Persistent Store en blanco, los mensajes se mantendrán en memoria.
Para mantenerlos en el sistema de archivos generamos un Persistent Store de tipo File, para mantenerlos en una Base de Datos lo generamos de tipo JDBC.
4. Lo asignamos a uno de los servidores manejados de nuestro clúster.
5. Repetimos pasos 3 y 4 para crear un servidor JMS asignado a otro servidor manejado de nuestro clúster.
6. Ir a Services > Messaging > JMS Modules para crear un Módulo JMS
7. Creamos el Módulo JMS y lo asignamos a nuestro clúster. Habilitamos la opción para pasar a crear recursos (Would you like to add resources to this JMS system module?)
8. Creamos un Connection Factory
9. Le damos un nombre y un nombre JNDI
10. Aceptar la asignación por default y terminar. De esta manera la Connection Factory hereda el target del propio módulo JMS.
11. Crear un destino tipo Queue en el mismo módulo JMS
12. Le damos un nombre y un nombre JNDI
13. Aceptar la asignación por default y terminar, también se hereda del módulo JMS.
Nótese aquí la desventaja de este procedimiento.
14. Podemos comprobar que los recursos JMS ya se encuentran habilitados revisando el árbol JNDI de cualquier de los servidores manejados del clúster. Usamos el link View JNDI Tree disponible en la configuración de los servidores WebLogic.
15. Vamos al módulo JMS que acabamos de crear y damos clic sobre el destino distribuido.
16. Seleccionamos la pestaña Monitoring y comprobamos que nuestro destino se encuentra funcionando en los servidores de nuestro clúster.
Personalizamos la tabla para ver más detalles.
A partir de aquí nuestro destino esta listo, proporcionamos el JNDI de nuestro Connection Factory y Destino Distribuido al equipo de desarrolladores, o en otro caso, establecemos los nombre JNDI que ellos nos proporcionaron.
Despliegue a Servidores JMS (Subdeployment) - Recomendado
Procedimiento para despliegue a Servidores JMS a través de Subdeployment. A diferencia del procedimiento anterior, en este realizamos el despliegue de nuestro módulo JMS y sus recursos en un servidor JMS especifico determinado por un Subdeployment.
1. Ingresar a la Consola de Administración WebLogic
2. Generar un servidor JMS para cada servidor manejado de nuestro clúster
3. Crear modulo JMS asignándolo al clúster
4. Entramos al módulo y vamos a la pestaña de despliegues secundarios (Subdeployments). A continuación creamos un Subdeployment y lo asignamos en los servidores JMS previamente creados.
5. Crear una Connection Factory y asignarla al clúster
6. Crear un destino distribuido, establecer nombre y JNDI
7. Seleccionar la opción avanzada de asignación (Advanced Targeting)
8. Seleccionar el despliegue secundario previamente generado, y terminar. Automáticamente los servidores JMS son habilitados.
A partir de aquí los mensajes dirigidos a nuestro Queue distribuido serán procesados únicamente por los servidores JMSServer_ms1 y JMSServer_ms2, a diferencia de la configuración anterior, en el que los mensajes se depósitos de nuestro destino se mantienen en cada servidor JMS asignado al clúster.
Configuración Adicional
Comprueba que la Connection Factory tiene deshabilitada la opción de afinidad de servidor (Server Affinity) y se encuentra habilitada la opción de balanceo (Load Balancing Enabled) para asegurar que las peticiones se balancean apropiadamente a los miembros del clúster.
Para un mayor nivel de alta disponibilidad, los servidores JMS deben asignarse a destinos migrables (Migratable Targets), aprovechando el mecanismo de Service Migration proporcionado por WebLogic.
Hasta pronto.
Para un mayor nivel de alta disponibilidad, los servidores JMS deben asignarse a destinos migrables (Migratable Targets), aprovechando el mecanismo de Service Migration proporcionado por WebLogic.
Hasta pronto.
