Escenarios de Business Process Choreographer para agrupación en clúster

Describe distintas opciones de configuración y consideraciones para los escenarios de Business Process Choreographer que utilizan clústeres.

Las ventajas principales de la utilización de los clústeres de WebSphere Process Server para instancias de Business Process Choreographer son:

Opciones de configuración

Puede configurar Business Process Choreographer de maneras distintas, ya que las configuraciones de clústeres acostumbran a ser muy complejas. Algunas de las opciones principales que deben tenerse en cuenta antes de empezar a crear servidores de aplicaciones se señalan en las descripciones siguientes:

Número de nodos de la célula de WebSphere Process Server
Uno o más. Todos los nodos se administran desde un solo gestor de despliegue.
Número de nodos de cada clúster de WebSphere Process Server
Uno o más. La agrupación en clúster horizontal de WebSphere puede aumentar la disponibilidad de servicios y la capacidad total de carga de trabajo.
Número de servidores de aplicaciones en cada nodo
Uno o más. La agrupación en clúster vertical de WebSphere Process Server puede aumentar la utilización de recursos.
Sistema principal de base de datos
  • Remoto, en un servidor dedicado
  • Local en uno de los servidores de aplicaciones del clúster
Se recomienda alojar la base de datos en un servidor dedicado, preferiblemente con una reserva dinámica.
Colas de mensajería de aplicaciones
  • Colas locales
  • Colas remotas
Conexión (mensajería por omisión)
Cuando se utiliza la mensajería por omisión, puede configurar los motores de mensajes en el mismo clúster o en un clúster remoto. Para Business Process Choreographer, debe usar el mismo enfoque utilizado para los demás componentes de WebSphere Process Server. Para obtener más detalles sobre los escenarios posibles, consulte Preparación de un servidor o clúster para dar soporte a las aplicaciones de servicio. La configuración recomendada consiste en que los motores de mensajería se ejecuten en un clúster distinto de aquél donde Business Process Choreographer está instalado. Esto es similar a la configuración del gestor de colas central que puede utilizarse con WebSphere MQ.
Conexión (gestores de colas de (WebSphere MQ)
  • Un gestor de colas central (remoto) que albergue las colas de los servidores de aplicaciones de un clúster. En general, se recomienda esta configuración.
  • Un gestor de colas local por servidor de aplicaciones. Esto no proporciona ninguna sustitución por anomalía y no se comparte la carga de trabajo entre procesos.
  • Dos gestores de colas locales por nodo y la agrupación en clúster de WebSphere MQ utilizados para equilibrar la carga de trabajo entre varios servidores de aplicaciones.

    La distribución de carga de trabajo entre distintas instancias de Business Process Choreographer exige que los gestores de colas que utilice el contenedor de procesos de empresa de cada servidor de aplicaciones sean miembros del mismo clúster de WebSphere MQ. Esta configuración no proporciona ninguna sustitución por anomalía y, en general, no se recomienda.

WebSphere MQ no se recomienda como proveedor de JMS si se utiliza un escenario en clúster.
Sistema de base de datos
Puede utilizar cualquier base de datos soportada excepto Cloudscape.
Servidores de reserva dinámica
Tiene las opciones siguientes para servidores de reserva dinámica:
  • Ninguno
  • Para la base de datos
  • Para un gestor de colas central

Tipos de clúster: este tema hace referencia a dos tipos distintos de clúster. Un clúster de WebSphere agrupa servidores de aplicaciones para que compartan la carga de trabajo y aumenten la disponibilidad de servicio. Un clúster de WebSphere MQ, conocido anteriormente como un clúster de MQSeries, agrupa gestores de colas de WebSphere MQ y puede utilizarse para alcanzar un equilibrio de carga de trabajo entre procesos.

Alta disponibilidad

Para alcanzar la alta disponibilidad de los servicios de Business Process Choreographer, tenga en cuenta los siguientes elementos:

Agrupación en clúster vertical para maximizar la utilización de recursos

Para mejorar el rendimiento, puede que tenga que crear varias instancias de servidor de aplicaciones en el mismo nodo para que Business Process Choreographer pueda utilizar los recursos del sistema disponibles.

Uso compartido de cargas de trabajo

Si desea que distintas instancias de Business Process Choreographer compartan las mismas cargas de trabajo, éstas deben utilizar una de las siguientes configuraciones de gestor de colas:
Gestor de colas central
Un gestor de colas central alberga las colas que necesita Business Process Choreographer. Todas las instancias de Business Process Choreographer del clúster de WebSphere leen los datos de las mismas colas.
Clúster de WebSphere MQ
Cada servidor de aplicaciones tiene dos gestores de colas. Un gestor de colas alberga colas locales y se utiliza para obtener mensajes, el otro gestor de colas no alberga ninguna cola y sólo se utiliza para colocar mensajes. Todos los gestores de colas de todas las instancias de Business Process Choreographer del clúster de WebSphere se convierten en miembros de un clúster de WebSphere MQ.

El resultado de colocar mensajes sólo en gestores de colas que no albergan colas es que los mensajes se distribuyen de forma uniforme en todos los gestores de colas get del clúster. Después de utilizar el asistente de instalación y configurar el contenedor de procesos de empresa en el clúster, debe cambiar manualmente las dos fábricas de conexiones por servidor de aplicaciones para que apunten a los gestores de colas get y put.

Base de datos de Business Process Choreographer

Se recomienda que la base de datos resida en un servidor dedicado, preferiblemente uno con una reserva dinámica. La base de datos puede estar en un servidor que esté fuera de la célula WebSphere, aunque el gestor de despliegue debe tener acceso a ella.

Al planificar la base de datos, tenga en cuenta los puntos siguientes:

Proveedor de JMS de mensajería por omisión de WebSphere

Business Process Choreographer puede utilizar la mensajería por omisión de WebSphere, que da soporte a la agrupación en clústeres, gestión de carga de trabajo y sustitución por anomalía.

Se da soporte a dos topologías:
  • Los recursos de mensajería están alojados en un clúster diferente de las aplicaciones. Es la topología recomendada, ya que proporciona posibilidades de sustitución por anomalía con una actividad general de administración baja. En el caso de WebSphere MQ, esta topología es similar al enfoque de gestor de colas central.
  • Los recursos de mensajería y las aplicaciones se albergan en el mismo clúster. Esta topología es ideal para el alto rendimiento, aunque requiere un mayor esfuerzo de administración, especialmente cuando se aplican cambios.

Para obtener más información sobre las consideraciones que se aplican cuando se utiliza la mensajería por omisión, consulte Creación de un entorno en clúster.

WebSphere MQ

Business Process Choreographer puede utilizar colas WebSphere MQ para recibir peticiones y enviar respuestas. WebSphere MQ no se recomienda como proveedor de JMS si se utiliza un escenario en clúster. Si utiliza WebSphere MQ, aún debe configurar la mensajería por omisión para SCA (Service Component Architecture), que Business Process Choreographer utiliza para la invocación de servicios entrantes y salientes. Cada servidor de aplicaciones que alberga Business Process Choreographer requiere una de las opciones siguientes:

Gestor de colas central

Al utilizar un gestor de colas central para todas las colas, la administración es más sencilla. Todos los contenedores clonados de tareas de usuario y procesos de empresa utilizan un gestor de colas. No obstante, la utilización de un gestor de colas central crea un punto único de anomalía que tiene que residir en un sistema de alta disponibilidad.

En la figura siguiente se muestran todos los servidores de aplicaciones de un clúster de WebSphere que utilizan un solo gestor de colas en otro servidor. Cada servidor de aplicaciones que aparezca con una contenedor de procesos de empresa puede tener también un contenedor de tareas de usuario.

En esta figura se muestran todos los servidores de aplicaciones del clúster WebSphere que utilizan un solo gestor de colas central en otro servidor.

Gestor de colas local sin agrupación en clúster de WebSphere MQ

Este ejemplo presenta la configuración de Business Process Choreographer estándar autónoma. Todos los contenedores de procesos de empresa tienen un gestor de colas local. Este enfoque no ofrece el uso compartido de carga de trabajo entre procesos ni la disponibilidad del servicio de sustitución por anomalía.

Agrupación en clústeres de WebSphere MQ

No se recomienda esta técnica compleja. Da soporte al uso compartido de cargas de trabajo entre procesos para los servicios de Business Process Choreographer en un clúster de WebSphere. Todos los procesos de empresa del clúster deben ejecutarse únicamente en UNIX, o sólo en estaciones de trabajo Windows; si realiza una combinación de servidores de UNIX y Windows, no funcionará.

Cada servidor de aplicaciones exige dos gestores de colas locales, uno para colocar (put) y otro para obtener (get) mensajes. Todos los gestores de colas se convierten en miembros del mismo clúster de WebSphere MQ. En los sistemas Windows, todos los gestores de colas deben utilizar el mismo protocolo de enlace. En los sistemas UNIX, los gestores de colas put y get deben utilizar protocolos diferentes. Por ejemplo, puede modificar las fábricas de conexiones de colas para que todos los gestores de colas put utilicen el protocolo de enlace (comunicaciones entre procesos) y todos los gestores de colas get utilicen el protocolo de cliente por omisión (TCP/IP).

En los sistemas Windows y UNIX, el uso del tipo de transporte de enlaces locales es aproximadamente un 5% más rápido que el uso del tipo de transporte de cliente, pero tiene el efecto de que debe detener todo el servidor de aplicaciones para detener el gestor de colas local de WebSphere MQ.

Cada contenedor de procesos de empresa del clúster de WebSphere debe personalizarse para reflejar sus propios gestores de colas.

Se recomienda que más de un gestor de colas del clúster de WebSphere MQ se convierta en un depósito de clústeres.

La figura siguiente muestra cómo los gestores de colas utilizados por los servidores de aplicaciones se agrupan en un clúster de WebSphere MQ. El clúster de gestores de colas de WebSphere MQ es paralelo al clúster de servidores de aplicaciones de WebSphere. Las peticiones se comparten entre las colas get del clúster.

En esta figura se muestra cómo los gestores de colas utilizados por los servidores de aplicaciones se agrupan en un clúster WebSphere MQ que funciona en paralelo al clúster WebSphere de servidores de aplicaciones. Las peticiones se comparten entre las colas get del clúster.

Cómo se crea el clúster de WebSphere

Existen unas cuantas secuencias distintas disponibles que se pueden seguir al crear un clúster para Business Process Choreographer. Se recomienda la secuencia siguiente:

  1. Cree un clúster utilizando la plantilla defaultProcessServer como plantilla de servidor para los miembros de clúster.
  2. Añada miembros al clúster.
  3. Habilite el clúster para aplicaciones de servicio.
  4. Configure Business Process Choreographer en el clúster.
  5. Si utiliza WebSphere MQ, y la configuración de WebSphere MQ es un clúster de gestores de colas locales de WebSphere MQ, debe modificar las fábricas de conexiones. Puesto que cada gestor de colas tiene un nombre distinto, debe modificar las fábricas de conexiones en cada uno de los servidores de aplicaciones clonados para reflejar sus diferencias exclusivas por lo que se refiere a la configuración del asistente de instalación de Business Process Choreographer estándar que abarca todo el clúster.
Conceptos relacionados
Business Process Choreographer y Network Deployment

Condiciones de uso |


(c) Copyright IBM Corporation 2005, 2006.
Este centro de información está basado en tecnología Eclipse (http://www.eclipse.org)