Configuración y administración de brokers de múltiples instancias para alta disponibilidad en IBM WebSphere Message Broker - Parte 1

En este artículo se describen brókeres de múltiples instancias, una característica introducida en WebSphere Message Broker V7 que facilita la configuración en entornos de alta disponibilidad. La función se basa en los gestores de colas de varias instancias de WebSphere MQ V7.0.1, que proporcionan múltiples instancias de un gestor de colas residentes en servidores físicos independientes para proporcionar una configuración de alta disponibilidad. En WebSphere MQ, la configuración del gestor de colas multi-instancia se encuentra alojado en almacenamiento de red compartida, de modo que si el gestor de colas activo falla, otra instancia asume automáticamente la configuración del gestor de colas que se detuvo y se activa. Del mismo modo, en Message Broker V7 y V8, la configuración de un bróker se encuentra alojado en almacenamiento en red para habilitar la función de alta disponibilidad.

Ashwin Gupta, Technical Sales Specialist, IBM

Ashwin Gupta es System Software Engineer en el equipo de prueba de WebSphere Message Broker. Ya lleva cuatro años trabajando con las diferentes versiones de WebSphere Message Broker. Se recibió de Ingeniero Electrónico en el Indian Institute of Technology de Roorkee. Para ponerse en contacto con Ashwin, escríbale a:gupta.ashwin@in.ibm.com



Rahul Gupta, Advisory IT Specialist, IBM

Rahul Gupta is an Advisory IT Specialist with IBM Global Technology Services. He is a Certified SOA Architect with eight years experience in IBM messaging technologies, and currently, he works as a middleware consultant for various clients in North America. His core experience is in lab testing, performance tuning, and development for WebSphere Message Broker and WebSphere MQ. He has been a speaker on messaging-related topics at various WebSphere conferences, and has been recognized as an inventor by the IBM Innovation Community. He has also authored IBM Redbooks and developerWorks articles on messaging and application infrastructure. You can contact Rahul at rahul.gupta@us.ibm.com.



Venkatesh Murugan, Technical Services Professional, IBM

Venkatesh Nainar Murugan is a Technical Services Professional and has worked as a WebSphere MQ and WebSphere Message Broker Specialist with IBM India for 1 1/2 years. He currently works on the administration and support of WebSphere MQ and WebSphere Message Broker on various platforms. His previous experience includes designing, developing, and testing these products. You can contact Venkatesh at n.venkatesh@in.ibm.com.



11-03-2013

Introduction

Este artículo describe las poderosas capacidades recientemente agregadas en IBM® WebSphere® Message Broker (de aquí en adelante llamado Message Broker) para gestionar fallas y proveer una alta disponibilidad (HA). Se revisará cómo crear y configurar gestores de cola y brókeres multi-instancia. Este artículo también proveerá una guía paso a paso para el desarrollo y prueba de un ambiente Message Broker HA. La audiencia para este artículo incluye arquitectos TI y especialistas de TI senior que diseñen soluciones SOA y requieran implementar soluciones ESB de alta disponibilidad.

Para entender la funcionalidad multi-instancia de Message Broker V7 (en adelante llamada bróker MI), primero debe entender cómo funciona el gestor de colas multi-instancia (en adelante gestor de colas MI). Este artículo presenta una revisión conceptual del gestor de colas MI y las tareas requeridas para administrarlo, seguido de una demostración sobre cómo conmutar entre las diferentes instancias. Posteriormente, se describirán los conceptos de bróker MI, incluyendo su configuración y prueba de alta disponibilidad.

Gestor de colas multi-instancia

El término gestor de colas MI se refiere a la combinación de instancias activas y standby de gestores de colas que comparten sus datos y bitácoras. El gestor de colas MI proteje las aplicaciones contra la falla de procesos de gestor de colas proveyendo una instancia de gestor de colas activa en un servidor y otra instancia en standby en otro servidor, lista para tomar el control automáticamente en caso de que la instancia activa falle. La replicación de las instancias de gestor de colas provee un mecanismo efectivo para mejorar la disponibilidad de los procesos de gestión de colas.

Los ejemplos en este artículo se han creado con base en using WebSphere MQ y Message Broker, sobre tres servidores con Red Hat Enterprise Linux 5.0. La figura 1 muestra la ubicación de los componentes de gestión de colas y bróker MI distribuidos en los tres servidores:

Figura 1. Esquema general de gestor de colas y bróker MI
Overview of MI queue manager and MI broker components

Los tres servidores son:

wmbmi1.in.ibm.com
Aloja la primera instancia activa del gestor de colas MI BCOLESBQM y la instancia activa de bróker MI BCOLESBBRK.
wmbmi2.in.ibm.com
Aloja la instancia duplicada de respaldo (standby) del gestor de colas MI BCOLESBQM y la instancia duplicada de respaldo de bróker MI BCOLESBBRK.
wmbmi3.in.ibm.com
Aloja el sistema de almacenamiento en red compartido /mqha, basado en NFS V4.

Aunque no es obligatorio ejecutar en servidores separados la instancia de respaldo y el sistema de almacenamiento compartido, es recomendable para evitar que el gestor de colas falle debido a un problema de hardware. En el ejemplo se instaló WebSphere MQ en dos servidores: wmbmi1.lab.bcol.com para el gestor de colas MI principal y wmbmi2.lab.bcol.com para el gestor de colas MI de respaldo. Como se muestra en la figura 1, la instancia activa de BCOLESBQM ejecuta en wmbmi1.lab.bcol.com; la otra instancia ejecuta como standby en wmbmi2.lab.bcol.com y no hace procesamiento activo, manteniéndose listo para tomar el control en caso de falla de la instancia activa.

A continuación se describen las tareas de administración de estos gestores de cola MI.

Configurando el sistema de archivos en red

Un gestor de colas MI usa el sistema de archivos para gestionar las instancias del gestor de colas. El gestor de colas automatiza la conmutación por falla utilizando una combinación de bloqueos en el sistema de archivos que contienen la información de datos y de bitácoras de las colas. Antes de la versión V7.0.1, WebSphere MQ no soportaba acceso a almacenamiento en red como un sistema de archivos compartido. Si los datos de un gestor de colas se almacenaban en un sistema de archivos en red, usted debía asegurar que esos datos estuvieran disponibles solamente para una de las instancias del gestor de colas y que las demás instancias del gestor de colas no los accedieran simultáneamente. La situación mejoró en WebSphere MQ V7.0.1: los gestores de colas ahora adquieren bloqueos de lectura/escritura para proveer acceso a sus datos; en un momento dado, solo una instancia del gestor de colas posee acceso a los datos, eliminando las “lecturas sucias”.

Antes de configurar NFS, usted debe asegurar que los identificadores de usuario (uid) y los identificadores de grupo (gid) de los usuarios sean iguales para todos los servidores en los que reciden las instancias del gestor de colas MI -- wmbmi1.lab.bcol.com, wmbmi2.lab.bcol.com y wmbmi3.lab.bcol.com, en nuestro ejemplo. Esto también aplica para el servidor NFS. En Linux y Unix, el uid utilizado para correr comandos WebSphere MQ y WebSphere Message Broker debe ser miembro de los grupos mqbrkrs y mqm, y los gids UNIX para estos grupos debe ser el mismo en todos los sistemas. Así mismo, debe asegurar que los uids y sus correspondientes gids sean los mismos en todos los sistemas e iguales al uid que creó la primera instancia del gestor de colas. Cambie los uids y gids en Linux o UNIX con precaución, porque hacerlo afecta los permisos sobre archivos que estos usuarios tienen en el sistema. Cambiar un uid o gid hace que la propiedad de todos los archivos que los usuarios afectados tenían previamente queden asignados al número entero que representaba originalmente a estos usuarios o grupos. El administrador del sistema debe asegurar que la propiedad de los archivos y directorios afectados sean restaurados manualmente.

En este ejemplo, el usuario mqm administra el gestor de colas MI y el bróker MI. Si necesita cambiar los valores de uid y gid para el usuario mqm, use los comandos en el listado 1 y luego reinicie el sistema:

Listado 1. Cambiando los uid y gid para el usuario mqm en los servidores
[mqm@wmbmi1.in.ibm.com]$ cat /etc/passwd | grep mqm
mqm:x:500:501:MQSeries User:/home/mqm:/bin/bash
[mqm@wmbmi2.in.ibm.com]$ cat /etc/passwd | grep mqm
mqm:x:500:501:MQSeries User:/home/mqm:/bin/bash
[mqm@wmbmi3.in.ibm.com]$ cat /etc/passwd | grep mqm
mqm:x:500:501:MQSeries User:/home/mqm:/bin/bash

Adicionalmente, también se requiere establecer el uid y gid del grupo mqm para que sea idéntico en todos los sistemas. Cree directorios para datos y bitácora en una carpeta común compartida llamada /mqha. Asegúrese de que el propietario de la carpeta mqha sea el usuario y grupo mqm y que los permisos estén rwx tanto para el usuario como para el grupo. Esto lo puede lograr ejecutando los comandos en el listado 2 como root en wmbmi3.lab.bcol.com:

Listado 2. Creando y estableciendo propiedad para las carpetas compartidas bajo /mqha
[root@wmbmi3.in.ibm.com]$ mkdir -p /mqha/WMQ/IBMESBQM/data
[root@wmbmi3.in.ibm.com]$ mkdir -p /mqha/WMQ/IBMESBQM/logs
[root@wmbmi3.in.ibm.com]$ mkdir -p /mqha/WMB/IBMESBBRK
[root@wmbmi3.in.ibm.com]$ chown -R mqm:mqm /mqha
[root@wmbmi3.in.ibm.com]$ chmod -R ug+rwx /mqha

Ahora usted debe configurar el servidor NFS en wmbmi3.lab.bcol.com y arrancarlo. Adicione la línea del listado 3 al archivo /etc/exports:

Listado 3. Configurando el servidor NFS
/mqha *(rw,fsid=0,no_wdelay,sync)

Arranque el servidor NFS ejecutando el comando en el listado 4 como root en wmbmi3.lab.bcol.com:

Listado 4. Arrancando el servidor NFS
/etc/init.d/nfs start

Si el servidor NFS ya está arriba, refrésquelo usando el comando en el listado 5:

Listado 5. Refrescando el servidor NFS
exportfs -ra

Ahora debe tener una carpeta compartida /mqha en wmbmi3.lab.bcol.com que puede ser montada en ambos servidores , wmbmi1.lab.bcol.com y wmbmi2.lab.bcol.com. Use el siguiente comando en el listado 6 para validar que la carpeta compartida /mqha sea visible desde ambos servidores:

Listado 6. Validando que /mqha esté montado
showmount –e wmbmi3.in.ibm.com

Si la salida del comando en el listado 6 es negativo, debe montar la carpeta compartida en los servidores de gestor de colas. Para ello, ejecute el comando en el listado 7 como root en ambos servidores:

Listado 7. Montando el sistema de archivos exportado
mount -t nfs4 -o hard,intr wmbmi3.in.ibm.com:/ /mqha

No todos los protocolos de bloqueo de los sistemas de archivos de red son robustos, dado que algunos de ellos están configurados para obtener el máximo rendimiento más que para ofrecer integridad de datos. Ejecute el comando amqmfsck para probar si su sistema de archivos de red soporta apropiadamente el control de acceso que el gestor de colas necesita:

  • Ejecute amqmfsck sin ninguna opción en cada sistema para verificar los mecanismos básicos de bloqueo.
  • Ejecute amqmfsck en ambos servidores de WebSphere MQ simultáneamente usando la opción -c para verificar la escritura concurrente sobre un mismo directorio.
  • Ejecute amqmfsck en ambos servidores de WebSphere MQ simultáneamente usando la opción -w para verificar la espera por liberación de bloqueos en un directorio.

Para que WebSphere MQ trabaje confiablemente, el sistema de archivos compartido debe proveer:

  • Integridad de escritura de datos
  • Garantía de acceso exclusivo a los archivos
  • Liberación de bloqueos ante evento de falla

Si el sistema de archivos no provee estas características, las carpetas de datos y bitácoras del gestor de colas pueden dañarse cuando el sistema de archivos se use en una configuración MI. Actualmente NFS V4 provee estas facilidades, de manera que es el sistema de archivos que se utilizará en este ejemplo.

Creación de un gestor de colas multi-instancia

Arranque por crear un gestor de colas MI en el primer servidor, wmbmi1.lab.bcol.com. Conéctese con el usuario mqm y ejecute el comando en el listado 8:

Listado 8. Creando un gestor de colas
crtmqm -md /mqha/WMQ/IBMESBQM/data -ld /mqha/WMQ/IBMESBQM/logs IBMESBQM

Una vez que el gestor de colas esté creado, liste las propiedades de este gestor de colas usando el comando en el listado 9:

Listado 9. Listando las propiedades del gestor de colas
[mqm@wmbmi1.in.ibm.com]$ dspmqinf -o command IBMESBQM

addmqinf -s QueueManager -v Name=IBMESBQM -v Directory=IBMESBQM -v Prefix=/var/mqm –v 
DataPath=/mqha/WMQ/IBMESBQM/data/IBMESBQM

Copie la salida del comando dspmqinf y péguelo en la consola del segundo servidor, wmbmi2.lab.bcol.com y ejecútelo bajo el usuario mqm, como se muestra en el listado 10:

Listado 10. Configurando wmbmi2.lab.bcol.com
[mqm@wmbmi2.in.ibm.com]$ addmqinf -s QueueManager  -v Name=IBMESBQM
-v Directory=IBMESBQM -v Prefix=/var/mqm -v DataPath=/mqha/WMQ/IBMESBQM/data/IBMESBQM

WebSphere MQ configuration information added.

Ahora liste los gestores de colas en ambos servidores usando el comando dspmq en cada uno. El resultado debe ser similar al del listado 11:

Listado 11. Listando los gestores de colas en ambos servidores
[mqm@wmbmi1.in.ibm.com]$ dspmq
QMNAME(IBMESBQM)                                          STATUS(Ended immediately)

[mqm@wmbmi2.in.ibm.com]$ dspmq
QMNAME(IBMESBQM)                                          STATUS(Ended immediately)

El gestor de colas MI BCOLESBQM ha sido creado en ambos servidores, wmbmi1.lab.bcol.com y wmbmi2.lab.bcol.com.

Arranque y etenido de gestores de colas multi-Instancia

Arrancar un gestor de colas en modo multi-instancia es tan sencillo como arrancar un gestor de colas convencional. Para arrancar las instancias de gestores de colas en cualquier orden, ejecute el comando strmqm con el parámetro -x, como se muestra en el listado 12:

Listado 12. Arrancando el gestor de colas en modalidad multi-instancia
[mqm@wmbmi1.in.ibm.com]$ strmqm -x IBMESBQM
WebSphere MQ queue manager 'IBMESBQM' starting.
5 log records accessed on queue manager 'IBMESBQM' during the log replay phase.
Log replay for queue manager 'IBMESBQM' complete.
Transaction manager state recovered for queue manager 'IBMESBQM'.
WebSphere MQ queue manager 'IBMESBQM' started.

[mqm@wmbmi2.in.ibm.com]$ strmqm -x IBMESBQM
WebSphere MQ queue manager 'IBMESBQM' starting.
A standby instance of queue manager 'IBMESBQM' has been started. The active
instance is running elsewhere.

El gestor de colas en wmbmi1.lab.bcol.com se arrancó primero y posteriormente se arrancó en wmbmi2.lab.bcol.com. Por esto, BCOLESBQM arranca como instancia activa en wmbmi1, y procesa todos los requerimientos de entrada, mientras que la instancia en wmbmbi2 arranca en modo standby, listo para tomar el control si la instancia activa falla. La instancia activa tiene garantizado el acceso exclusivo a los datos y bitácora del gestor de colas, mientras que el standby espera por obtener dichos permisos; si la instancia en standby obtiene acceso exclusivo, se convierte en instancia activa.

Usted podrá arrancar el gestor de colas multi-instancia en los disferentes servidores como si fuera un gestor de colas de una sola instancia. Para ello podrá usar el comando strmqm (sin la opción -x), pero en este caso, el gestor de colas del primer servidor arrancará normalmente pero los demás no podrán arrancar en modalidad standby. Si se hace un intento de arrancar más de una instancia, el usuario recibirá una respuesta informando que la instancia de gestor de colas no puede arrancar en modalidad standby.

Sólo dos instancias de gestor de colas pueden ejecutar simultáneamente: una activa y otra standby. Si ambas instancias se arrancan simultáneamente, WebSphere MQ no tiene control sobre cual de las instancias será la instancia activa; esto lo determina el servidor de NFS. La primera instancia que adquiera acceso exclusivo a los datos del gestor de colas será la que tome el rol de activa.

Ahora que el gestor de colas ha arrancado, proceda a crear y arrancar un escucha (listener) para las aplicaciones que se conectarán al gestor de colas activo BCOLESBQM, como se muestra en el listado 13. Todos los comandos de administración en el listado 13 se deben ejecutar desde el gestor de colas activo:

Listado 13. Creación y arranque de un escucha en el gestor de colas activo
[mqm@wmbmi1.in.ibm.com]$ runmqsc IBMESBQM

5724-H72 (C) Copyright IBM Corp. 1994, 2009.  ALL RIGHTS RESERVED.

Starting MQSC for queue manager IBMESBQM.

define listener(IBMESBLISTENER) trptype(tcp) port(1414) control(qmgr)

     1 : define listener(IBMESBLISTENER) trptype(tcp) port(1414) control(qmgr)

AMQ8626: WebSphere MQ listener created.
START LISTENER(IBMESBLISTENER)

     2 : START LISTENER(IBMESBLISTENER)

AMQ8021: Request to start WebSphere MQ Listener accepted.

Hay dos maneras de parar un gestor de colas MI que haya arrancado. La primera es conmutando las instancias activa y standby usando el comando endmqm con la opción -s. Si ejecuta endmqm -s IBMESBQM en la instancia activa, estará conmutando el control hacia la instancia standby. El comando endmqm -s apaga la instancia activa sin apagar la instancia standby. El bloqueo de acceso exclusivo sobre los datos y bitácoras del gestor de datos se liberan, y la instancia standby toma el control.

La segunda opción es parar ambas instancias del gestor de colas, la activa y la standby. Si ejecuta el comando endmqm IBMESBQM en la instancia activa – sin la opción -s detendrá ambas instancias.

Si está ejecutando mútiples instancias del gestor de colas y decide que no requiere hacerlo, entonces podrá optar por detener solamente la instancia standby usando el comando endmqm con la opción -x. La instancia standby no servirá como standby, pero la instancia activa seguirá en ejecución.

Borrado de un gestor de colas multi-instancia

Para borrar múltiples instancias de un gestor de colas se requiere que primero se borren las referencias de los otros gestores de colas. Ejecute el comando rmvmqinf en todos los servidores que tienen la definición del gestor de colas, como se muestra en el listado 14:

Listado 14. Borrando referencias a un gestor de colas
rmvmqinf IBMESBQM

A continuación, debe borrar el gestor de colas en el servidor que contiene la instancia activa. Ejecute el comando dltmqm como se muestra en el listado 15:

Listado 15. Borrando la instancia en el gestor de colas activo
dltmqm IBMESBQM

Usted no necesita correr este comando en la misma máquina en la que el gestor de colas fue creado; puede correrlo desde cualquier servidor donde esté definido el gestor de colas. También podrá borrar el gestor de colas MI ejecutando dltmqm IBMESBQM en ambos servidores.

Organización del sistema de archivos del gestor de colas multi-instancia

La figura 2 muestra la representación jerárquica del sistema de archivos /mqha del gestor de colas MI. Los objetos y bitácoras activas del gestor de colas se almacenan en esta estructura de archivos:

Figura 2. Representación jerárquica del sistema de archivos de un gestor de colas MI
Hierarchical representation of MI queue manager file system

Administración de un gestor de colas multi-instancia

El Explorador WebSphere MQ no puede correr localmente en más de una instancia de un gestor de colas MI. Se requiere configurar el Explorador WebSphere MQ para administrar gestores de colas remotamente. Seleccione el menú Queue Managers => Add Remote Queue Manager para adicionar conexiones a un gestor de colas MI, como se muestra en la figura 3:

Figura 3. Navegador del Explorador WebSphere MQ
WebSphere MQ Explorer Navigator

Se desplegará el asistentes Add Queue Manager. Escriba el nombre del gestor de colas y seleccione el método de conexión apropiado, como se muestra en la figura 4:

Figura 4. Asistente Add Queue Manager
Add Queue Manager wizard

Presione Next cuando haya completado sus elecciones.

A continuación, deberá proveer detalles de coneción para los gestores de cola standby e instruir al Explorador WebSphere MQ para que haga una auto-reconexión al gestor de colas activo en caso de falla. La figura 5 ilustra la forma de configurarlo apropiadamente:

Figura 5. Configurando un gestor de colas MI en el asistente Add Queue Manager wizard
Setting up an MI queue manager on the Add Queue Manager wizard

Si no se requieren más configuraciones en el cliente, presione Finish. El Explorador WebSphere MQ se conectará a la instancia activa del gestor de colas, como se ilustra en la figura 6. Recuerde que en esta configuración de ejemplo, el gestor de colas activo reside en el servidorwmbmi1.lab.bcol.com:

Figura 6. Gestor de colas activo conectado en el navegador de MQ Explorer
Connected active queue manager in MQ Explorer Navigator

El próximo paso lógico es verificar la funcionalidad de reconexión ejecutando una conmutación por falla en el gestor de colas BCOLESBQM.

Conmutación entre instancias de un gestor de colas multi-instancia

Puede ejecutar una prueba de conmutación por falla (failover) del gestor de colas MI BCOLESBQM en un ambiente controlado. Más adelante, en este artículo, verá una prueba más rigurosa para observar la situación en caso de falla de red o de energía. La conmutación controlada puede producirse deteniendo el gestor de colas activo y observando si el gestor de colas standby adquiere los bloqueos sobre los archivos en la carpeta /mqha y toma el control.

Antes de ejecutar el comando que detiene la instancia activa del gestor de colas MI, es importante que identifique el servidor activo. Lo puede hacer usando el comando dspmq con el indicador -x. En el listado 16, se muestra que en nuestro ejemplo, el gestor de colas BCOLESBQM está ejecutando como activo en el servidor wmbmi1.lab.bcol.com y como standby en wmbmi2.lab.bcol.com:

Listado 16. Identificación de la ubicación de la instancia activa
[mqm@wmbmi1.in.ibm.com$ dspmq -x

    QMNAME(IBMESBQM)                                          STATUS(Running)
    INSTANCE(wmbmi1.in.ibm.com) MODE(Active)
    INSTANCE(wmbmi2.in.ibm.com) MODE(Standby)

[mqm@wmbmi2.in.ibm.com]$ dspmq -x

    QMNAME(IBMESBQM)                                          STATUS(Running as standby)
    INSTANCE(wmbmi1.in.ibm.com) MODE(Active)
    INSTANCE(wmbmi2.in.ibm.com) MODE(Standby)

Ahora que conoce dónde está ejecutando la instancia activa, puede detenerla. En nuestro caso, detenemos con el comando endmqm -s IBMESBQM en wmbmi1.lab.bcol.com, como se muestra en el listado 17:

Listado 17. Deteniendo el servidor de colas activo
[mqm@wmbmi1.in.ibm.com]$ endmqm -s IBMESBQM
Quiesce request accepted. The queue manager will stop when all outstanding work
is complete, permitting switchover to a standby instance.

[mqm@wmbmi1.in.ibm.com]$ dspmq -x

QMNAME(IBMESBQM)                                          STATUS(Running elsewhere)
    INSTANCE(wmbmi2.in.ibm.com) MODE(Active)

[mqm@wmbmi2.in.ibm.com]$ dspmq -x

QMNAME(IBMESBQM)                                          STATUS(Running)
    INSTANCE(wmbmi2.in.ibm.com) MODE(Active)

En el listado 17 arriba, puede ver que el gestor de colas BCOLESBQM se detuvo en wmbmi1.lab.bcol.com y ahora está ejecutando como activo en wmbmi2.lab.bcol.com. Así, la prueba muestra que BCOLESBQM conmutó del primer servidor al segundo. También puede comprobar este hecho desde el Explorador WebSphere MQ, que también se reconectó a la instancia activa del gestor de colas, que ahora está en wmbmi2.lab.bcol.com, como se muestra en la figura 7:

Figure 7. Reconección automática después de una conmutación por falla
WebSphere MQ Explorer demonstrating auto-reconnect after failover

Ahora sólo hay una instancia del gestor de colas en funcionamiento, y no habrán más conmutaciones si se llega a presentar una falla. Para restaurar el servidor de colas standby, ejecute el comando strmqm -x IBMESBQM en wmbmi1.lab.bcol.com. Esto hará que el gestor de colas BCOLESBQM continúe ejecutando activamente en wmbmi2.lab.bcol.com y pasivamente en wmbmi1.lab.bcol.com. Para verificar que la conmutación funcione adecuadamente en el sentido contrario y restaurar el orden de ejecución, repita los procedimientos en esta sección.

Bróker multi-Instancia

La característica de bróker MI del Message Broker trabaja con WebSphere MQ en una de dos posibilidades. Que cada instancia del bróker esté incluido en un servicio WebSphere MQ de manera que, cuando el gestor de colas conmute, el bróker arranque automáticamente en el nodo standby. Esta característica está disponible en Message Broker V7.0.0.1 (Fix Pack 1).

Puede configurar brókeres MI con la opción -d en los comandos mqsicreatebroker y mqsiaddbrokerinstance, donde el valor de la opción es defined si desea crear el bróker dentro del servicio WebSphere MQ o undefined si desea que el servicio de bróker sea independiente al del gestor de colas. Cuando crea la instancia bróker la opción -d, dado que el gestor de colas ya está arrancado, el bróker se crea pero no arrancará hasta tanto el gestor de colas sea reiniciado.

Opcionalmente, el bróker standby puede correr continuamente en un modo semi-inicializado , esperando que el gestor de colas standby asociado tome el control.

En esta sección, usted creará un bróker MI BCOLESBBRK en el sistema ejemplo, usando el gestor de colas MI BCOLESBQM que previamente configuró. Para hacerlo, necesitará usar el mismo usuario (mqm) y requerirá que dicho usuario sea miembro del grupo mqbrkrs. Asegúrese de que el gid del grupo mqbrkrs sea el mismo en los diferentes servidores. A continuación se describen las tareas para administrar el bróker MI:

Creación de un bróker multi-instancia

Hay tres conjuntos de acciones que deben ejecutarse para configurar Message Broker en modo multi-instancia:

  1. Crear un directorio de trabajo compartido en un servidor NFS
  2. Crear un gestor de colas MQ MI
  3. Crear un bróker MI

En la sección anterior, usted configuró unas carpetas compartidas y un gestor de colas MI, así que nos moveremos directamente al tercer paso. Primero debemos verificar el servidor en el que está ejecutando el gestor de colas activo; esto se hace con el comando dspmq -x. En nuestra configuración, el gestor de colas activo está en wmbmi1.lab.bcol.com, así que crearemos la instancia de bróker activa en este servidor. El comando usado para crear un bróker es mqsicreatebroker, como se muestra en el listado 18:

Listado 18. Creación de un bróker
[mqm@wmbmi1.in.ibm.com]$ mqsicreatebroker IBMESBBRK -q IBMESBQM -e /mqha/WMB/IBMESBBRK

AMQ8110: WebSphere MQ queue manager already exists.
The setmqaut command completed successfully.
The setmqaut command completed successfully.
BIP8071I: Successful command completion.

Una vez que la instancia activa del bróker se ha creado, cree la instancia standby en wmbmi2.lab.bcol.com usando el comando mqsiaddbrokerinstance:

Listado 19. Creando la instancia standby del bróker
mqsiaddbrokerinstance IBMESBBRK -e /mqha/WMB/IBMESBBRK

El comando mqsiaddbrokerinstance se usa para crear un bróker MI en un servidor UNIX/Linux o Windows donde el Message Broker haya sido instalado. El comando mqsiaddbrokerinstance se usa para adicionar una instancia de bróker a cualquier servidor adicional en el que se requiera soporte multi-instancia. El comando exige que el usuario haya previamente creado un bróker habilitado para multi-instance en un primer servidor usando mqsicreatebroker. La sintaxis para este comando varía según el sistema operativo:

  • Windows:mqsiaddbrokerinstance <nombreBroker> -e <carpetaDeTrabajoCompartida> -w <rutaDeTrabajo> -i <usuarioDeServicio> -a <contraseñaDeServicio>
  • UNIX/Linux:mqsiaddbrokerinstance <nombreBroker> -e <carpetaDeTrabajoCompartida> -w <rutaDeTrabajo>

Aquí, la opción -w es opcional en ambos casos. Esta opción indica la carpeta en la cual los archivos de trabajo específicos de esta instancia de bróker deberán almacenarse localmente en el servidor, cuando la instancia esté ejecutando. En sistemas Linux y UNIX, el uid usado para ejecutar este comando debe ser miembro de los grupos mqbrkrs y mqm. Asegúrese que los uid y gid de mqbrkrs sean iguales en todos los sistemas. El listado 20 muestra la salida del comando mqsiaddbrokerinstance en wmbmi2.lab.bcol.com:

Listado 20. Salida de mqsiaddbrokerinstance
[mqm@wmbmi2.in.ibm.com]$ mqsiaddbrokerinstance IBMESBBRK -e /mqha/WMB/IBMESBBRK

AMQ7272: WebSphere MQ configuration information already exists.
BIP8071I: Successful command completion.

Arrancando y parando un bróker multi-instancia

Ahora que ha creado instancias duplicadas del bróker BCOLESBBRK en ambos servidores, el próximo paso es arrancarlas. Una ejecutará como activa y la otra como standby, con base en el estado de las instancias de sus correspondientes gestores de colas BCOLESBQM. Arranque los brókeres usando el comando mqsistart en ambos servidores, como se muestra en el listado 21:

Listado 21. Arrancando las instancias de broker
[mqm@wmbmi1.in.ibm.com]$ mqsistart IBMESBBRK

BIP8096I: Successful command initiation. Check the system log to ensure that the component
started without problems and that it continues to run without problems.

[mqm@wmbmi2.in.ibm.com]$ mqsistart IBMESBBRK

BIP8236I: A standby instance of Broker IBMESBBRK has been started against the standby
queue manager IBMESBQM. The active broker instance and active queue manager instance
are running elsewhere. The multi-instance broker has started in standby mode. The broker
will not become active until the current active broker instance and active queue manager
instance end, or are stopped.  No action required.

El bróker BCOLESBBRK arranca como activo en wmbmi1.lab.bcol.com y como standby en wmbmi2.lab.bcol.com. Los procesos del bróker ejecutan como activos y pasivos como se describió arriba, pero primero se requiere crear un grupo de ejecución en el bróker activo en wmbmi1.lab.bcol.com usando el comando mqsicreateexecutiongroup IBMESBBRK -e IBMESBEG:

Listado 22. Creando un grupo de ejecución
[mqm@wmbmi1.in.ibm.com]$ mqsicreateexecutiongroup IBMESBBRK -e IBMESBEG

BIP1124I: Creating execution group 'IBMESBEG' on broker 'IBMESBBRK'...
BIP1117I: The execution group was created successfully.
The broker has initialized the execution group.
BIP8071I: Successful command completion.

[mqm@wmbmi1.in.ibm.com]$ ps -eaf | grep –I IBMESBEG

mqm        364 32622 17 20:00 ?        00:00:07 DataFlowEngine 
       IBMESBBRK 9a38eebe-2701-0000-0080-ad888bea8d47 IBMESBEG

Una vez que el grupo de ejecución se ha creado, arrancará automáticamente. Lo podrá verificar usando el comando ps y haciendo un grep para la cadena IBMESBEG (que sería el nombre del grupo de ejecución). Ahora que el bróker y el DataFlowEngine están en funcionamiento en la instancia activa, puede examinar los procesos que están ejecutando en las instancias activa y standby. En el nodo activo, encontrará los siguientes procesos del bróker:

  • bipservice
  • bipbroker
  • biphttplistener
  • Un DataFlowEngine por cada grupo de ejecución creado en cada bróker.

En el nodo standby, encontrará los siguientes procesos del bróker:

  • bipservice (en modo standby)
  • bipbroker (en modo standby)

Puede ver los detalles para el sistema ejemplo en el listado 23:

Listado 23. Procesos que corren en los nodos activo y standby
[mqm@wmbmi1.in.ibm.com]$ ps -eaf | grep IBMESBBRK

mqm      364        32622       1 20:00 ?        00:00:07 
        DataFlowEngine IBMESBBRK 9a38eebe-2701-0000-0080-ad888bea8d47 IBMESBEG
mqm      32617    1               0 19:56 ?        00:00:00 bipservice IBMESBBRK
mqm      32622     32617      0 19:56 ?        00:00:02 bipbroker IBMESBBRK
mqm      32665     32622      0 19:56 ?        00:00:01 biphttplistener IBMESBBRK

[mqm@wmbmi2.in.ibm.com]$ ps -eaf | grep IBMESBBRK

mqm      31916     1              0 20:04 ?        00:00:00 bipservice IBMESBBRK
mqm      31921     31916      0 20:04 ?        00:00:00 bipbroker IBMESBBRK

Es importante conocer cómo detener un bróker MI. Usando el comando mqsistop con el nombre del bróker se terminará un bróker MI o una instancia de bróker. No ocurrirá ninguna conmutación (switchover) cuando se usa este comando. Los comandos deben ejecutarse en ambos servidores por separado para bajar las instancias activa y standby del bróker.

Borrando un broker multi-instancia

En este punto del ejercicio usted no va a borrar ningún bróker MI, pero es importante conocer cómo se borran en caso de que lo requiera. El orden de borrado de un bróker MI y sus instancias asociadas es importante y debe usar los comandos correctos para cada paso del proceso. Aquí está un resumen de cómo se hace:

  1. Detenga el bróker MI BCOLESBBRK en el nodo activo.
  2. Detenga el bróker MI BCOLESBBRK en el nodo pasivo.
  3. Remueva la instancia de bróker BCOLESBBRK en el nodo standby usando el comando mqsiremovebrokerinstance IBMESBBRK.
  4. Remueva la instancia de broker BCOLESBBRK en el nodo activo usando el comando mqsideletebroker IBMESBBRK.

Organización del sistema de archivos de un bróker multi-instancia

La figura 8 muestra una representación jerárquica del sistema de archivos /mqha del bróker MI. Los componentes del bróker y la información específica de registro se encuentran en estas carpetas:

Figura 8. Representación jerárquica de un sistema de archivos para bróker MI
Hierarchical representation of an MI broker file system

Respaldando y restaurando un bróker multi-instancia

No se requieren técnicas especiales para respaldar y restaurar un bróker MI. Puede ejecutar estas tareas en la forma usual, usando los comandos en el listado 24 en la instancia activa:

Listado 24. Respaldando y restaurando un bróker
mqsibackupbroker  IBMESBBRK -d /backup/WMB
mqsirestorebroker IBMESBBRK -d /backup/WMB  -a <archive file name>

El comando mqisbackupbroker detecta que se trata de un bróker MI y respalda el registro y configuración para la ruta de trabajo compartida del bróker. Así mismo, mqsirestorebroker restaura el registro y configuración de la ruta de trabajo compartida del bróker. Ejecute el comando de respaldo en la instancia activa del bróker. Mientras utilice el comando de restauración, detenga todos los brókeres para los que esté restaurando las rutas de trabajo compartidas (las instancias activa y pasiva). Si ejecuta este comando cuando un bróker relevante esté activo, el resultado puede ser impredecible.

Conmutación por falla entre brókeres multi-instancia

Antes de arrancar con esta sección, debemos aclarar lo que significa failover (conmutación por falla) en el contexto del bróker MI. Cuando un gestor de colas falla por cualquier razón, esto causará que el bróker asociado falle; en esta situación, el Message Broker conmutará a la instancia standby. En ese momento, la instancia previamente activa del bróker quedará en modo standby y la instancia standby quedará activa. El bróker MI confía en el estado del gestor de colas MI.

Considere dos escenarios de conmutación: un escenario de conmutación controlada y un escenario de conmutación no controlada debido a un corte de energía o una falla en la red.

Conmutación controlada en un bróker multi-instancia

Comience la prueba de conmutación controlada por verificar el estado del bróker MI en wmbmi1.lab.bcol.com, para confirmar que está activo. Puede hacerlo usando el comando en el listado 25. Deberá tener un resultado parecido al mostrado en ese listado:

Listado 25. Verificando el estado de BCOLESBBRK en wmbmi1.lab.bcol.com
[mqm@wmbmi1 .in.ibm.com]$ mqsilist
                                
BIP1295I: Broker 'IBMESBBRK' is a multi-instance broker running in active mode on 
multi-instance queue manager 'IBMESBQM'.
BIP8071I: Successful command completion

Haga lo mismo para el gestor de colas, según el listado 26:

Listado 26. Verificando el estado de BCOLESBQM en wmbmi1.lab.bcol.com
[mqm@wmbmi1 ~]$ dspmq –m IBMESBQM  –x

QMNAME(IBMESBQM) STATUS(Running)  INSTANCE(wmbmi1.in.ibm.com) MODE(Active)
INSTANCE(wmbmi2.in.ibm.com) MODE(Standby)

Ahora ejecute los mismos comandos en wmbmi2.lab.bcol.com. Deberá obtener un resultado similar al del listado 27 y 28, indicando que las instancias del gestor de colas y del bróker están en standby.

Listado 27. Verificando el estado de BCOLESBBRK en wmbmi2.lab.bcol.com
[mqm@wmbmi2 .in.ibm.com]$ mqsilist

BIP1294I: Broker 'IBMESBBRK' is a multi-instance broker running in standby mode on 
multi-instance queue manager 'IBMESBQM'. More information will be available when the
broker instance is active. 
BIP8071I: Successful command completion.
Listado 28. Verificando el estado de BCOLESBQM en wmbmi2.lab.bcol.com
[mqm@wmbmi2.in.ibm.com]$ dspmq –m IBMESBQM  –x

QMNAME(IBMESBQM) STATUS(Running as standby) INSTANCE(wmbmi2.in.ibm.com)  
MODE(Standby) INSTANCE(wmbmi1.in.ibm.com)  MODE(Active)

Ahora, de regreso en wmbmi1.lab.bcol.com, detenga la instancia activa de BCOLESBQM, como se muestra en el listado 29:

Listado 29. Deteniendo la instancia activa de BCOLESBQM
[mqm@wmbmi1 ~]$ endmqm -s IBMESBQM

Quiesce request accepted. The queue manager will stop when all outstanding work is 
complete, permitting switchover to a standby instance.

Ahora verifique su estado, como se muestra en el listado 30. La salida debe indicar que la instancia que originalmente estaba en standby es ahora la activa:

Listado 30. Confirmando que BCOLESBQM se ha detenido en wmbmi1.lab.bcol.com
[mqm@wmbmi1.in.ibm.com]$ dspmq -m IBMESBQM –x 

QMNAME(IBMESBQM) STATUS(Running elsewhere) INSTANCE(wmbmi2.in.ibm.com)  MODE(Active)

Use el comando en el listado 31 para mostrar el estado del bróker BCOLESBBRK. Verá que este dejó de ejecutar en wmbmi1.lab.bcol.com:

Listado 31. Confirmando que BCOLESBBRK dejó de funcionar en wmbmi1.lab.bcol.com
[mqm@wmbmi1.in.ibm.com]$ mqsilist

BIP1292I: The multi-instance Broker 'IBMESBBRK' on multi-instance queue manager 'IBMESBQM'
has stopped.
BIP8071I: Successful command completion.

Ahora regrese a wmbmi2.lab.bcol.com. Ejecute el comando en el listado 32 para confirmar que la instancia BCOLESBQM está ahora activa:

Listado 32. Confirmando que BCOLESBQM está ahora activo en wmbmi2.lab.bcol.com
[mqm@wmbmi2.in.ibm.com]$ dspmq -m IBMESBQM –x 

QMNAME(IBMESBQM) STATUS(Running) INSTANCE(wmbmi2.in.ibm.com)  MODE(Active)

Para finalizar, utilice el comando en el listado 33 para confirmar que BCOLESBBRK también está activo en wmbmi2.lab.bcol.com:

Listado 33. Confirmando que BCOLESBBRK está activo en wmbmi2.lab.bcol.com
[mqm@wmbmi2 ~]$ mqsilist

BIP1295I: Broker 'IBMESBBRK' is a multi-instance broker running in active mode on 
multi-instance queue manager 'IBMESBQM'.
BIP8071I: Successful command completion.

Con BCOLESBQM y BCOLESBBRK activos en wmbmi2.lab.bcol.com, la conmutación de un servidor en otro se ha completado.

Falla no controlada debido a una interrupción eléctrica o una falla de red

En la sección anterior, observamos cómo puede conmutarse el servicio de un servidor a otro en forma controlada. ¿Pero qué pasa cuando un servidor se detiene abruptamente o cuando se desconecta de la red? Las características de alta disponibilidad del Message Broker pueden manejar este escenario. Para probarlo, crearemos un escenario en tiempo real con un flujo de mensajes en el grupo de ejecución BCOLESBEG en el bróker BCOLESBBRK. Cree y despliegue un flujo de mensajes muy sencillo (figura 9) con los siguientes nodos:

  • Nodo MQInput (IBMESB_IN)
  • Nodo Compute (Copy Message)
  • Nodo MQOutput (IBMESB_OUT)
Figura 9. Flujo de Mensajes
Diagram of the message flow

Las colas de entrada y de salida (BCOLESBQM_IN e BCOLESBQM_OUT) serán persistentes, lo que significa que todos los mensajes que lleguen a esas colas se harán persistentes. Esto evitará la pérdida de mensajes durante la falla.

En esta sección, verá que la conexión del cliente también sobrevivirá a la conmutación. Este cliente pondrá mensajes en la cola de entrada BCOLESBQM_IN del gestor de colas BCOLESBQM.

El programa amqsphac es un programa ejemplo provisto con WebSphere MQ; puede usarlo para verificar el estado de la conexión del flujo de mensajes con el gestor de colas. El programa se mantiene escribiendo mensajes en la cola e informando sobre el estado de la operación de escritura en la cola (put). El listado 34 muestra el resultado de ejecutar este programa desde antes de causar la detención no controlada del servidor wmbmi1.lab.bcol.com hasta cuando wmbmi2.lab.bcol.com toma el control del servicio fallido:

Listado 34. Salida amqsphac que muestra la conmutación por falla en acción
[mqm@wmbmi2.in.ibm.com]$ amqsphac  IBMESBQM_IN  IBMESBQM

Sample AMQSPHAC start
target queue is IBMESBQM_IN
message <Message 1>
// La aplicación cliente está conectada aquí
// y está escribiendo mensajes en la cola de entrada con éxito
message <Message 2>
message <Message 3>
message <Message 4>
message <Message 5>
message <Message 6>
message <Message 7>
message <Message 8>
message <Message 9>
message <Message 10>
message <Message 11>
message <Message 12>
message <Message 13>
message <Message 14>
message <Message 15>
// el servidor wmbmi1 server se cayó aquí y la conexión con el cliente se perdió
20:41:53 : EVENT : Connection Reconnecting (Delay: 168ms)    
20:41:54 : EVENT : Connection Reconnecting (Delay: 1220ms)
20:41:55 : EVENT : Connection Reconnecting (Delay: 2324ms)
20:41:57 : EVENT : Connection Reconnecting (Delay: 4494ms)
20:42:02 : EVENT : Connection Reconnecting (Delay: 8731ms)
20:42:10 : EVENT : Connection Reconnecting (Delay: 19732ms)
// el servidor wmbmi2 server tomó el control aquí y se hizo activo
20:42:31 : EVENT : Connection Reconnected
//   El cliente restableció la conexión con el gestor de colas
message <Message 16>
//   La aplicación cliente sigue escribiendo mensajes exitosamente en la cola
message <Message 17>
message <Message 18>
message <Message 19>
message <Message 20>

El listado 34 muestra el resultado de nuestra prueba de falla de red cuando desconectamos el cable de red del servidor activo. El gestor de colas standby BCOLESBQM en wmbmi2.lab.bcol.com se hizo activo y BCOLESBBRK se hizo bróker activo en menos de dos minutos. El cliente automáticamente se reconectó al gestor de colas activo. El cliente amqsphac produjo 20 mensajes, los cuales fueron procesados por y puestos en la cola BCOLESB_OUT por el flujo de copia de mensajes. Aquí está la salida:

Listado 35. Salida que demuestra la conmutación exitosa
 [mqm@wmbmi2.in.ibm.com]$ dspmq –m IBMESBQM  -x

QMNAME(IBMESBQM)                                          STATUS(Running)
    INSTANCE(wmbmi2.in.ibm.com) MODE(Active)

[mqm@wmbmi2.in.ibm.com]$ echo "DISPLAY QLOCAL(IBMESBQM_OUT) CURDEPTH" | runmqsc IBMESBQM

5724-H72 (C) Copyright IBM Corp. 1994, 2009.  ALL RIGHTS RESERVED.
Starting MQSC for queue manager IBMESBQM.
     1 : DISPLAY QLOCAL(IBMESBQM_OUT) CURDEPTH
AMQ8409: Display Queue details.
   QUEUE(IBMESBQM_OUT)                     TYPE(QLOCAL)
   CURDEPTH(20)
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.

Limitación del Explorador de Message Broker

Hay una limitación cuando se usa el Explorador de WebSphere Message Broker para examinar la instancia standby de un bróker MI. Si bien, se puede listar y ver todas las instancias en un gestor de colas MI en el explorador y conmutar la conexión del explorador al gestor de colas standby en caso de falla, no podrá listar o ver las instancias de un bróker MI standby en el explorador durante un failover.

Conclusiones y próximos pasos

TEste artículo muestra los conceptos básicos de una arquitectura de gestor de colas MI y bróker MI y explica cómo crear, configurar, gestionar y probar estos componentes MI para alta disponibilidad. El sistema descrito incluyó una instancia activa de gestor de colas y de broker y una pasiva. Eso representa una arquitectura active-passive para diseñar soluciones de mensajería altamente disponible. Hay otro tipo de arquitectura HA llamada activa-activa en la cual se configuran múltiples conjuntos de gestores de cola y brókeres MI traslapados en un clúster WebSphere MQ. La Parte 2 de este arículo describirá este nuevo escenario HA en detalle.

Recursos

  • WebSphere MQ resources
  • WebSphere Message Broker resources
    • WebSphere Message Broker developer resources page
      Recursos técnicos que ayudan en el uso de WebSphere Message Broker para conectividad, transformación de datos universal e integración a nivel empresarial de servicios, aplicaciones y plataformas desiguales para darle poder a su SOA.
    • WebSphere Message Broker product page
      Descripción de producto, noticias, información sobre entrenamiento, información sobre soporte y más.
    • WebSphere Message Broker V8 information center
      Portal Web con documentación sobre WebSphere Message Broker V7, con información conceptual, tareas y material de referenci para la instalación, configuración y uso de ambientes WebSphere Message Broker.
    • What's new in WebSphere Message Broker V8
      WebSphere Message Broker V7 provee conectividad universal con la abilidad de enrutar y transformar mensajes desde cualquier parte hacia cualquier parte. Por medio de su modelo de programación sencillo y potente interfaz de gestión operativa, facilita el desarrollo, despliegue y mantenimiento de la integración de aplicaciones complejas. Este artículo describe las principales mejoras de la V7.
    • Download free trial version of WebSphere Message Broker V8
      WebSphere Message Broker V7 es un ESB construido para proveer una conexión y transformación universal para ambientes de TI heterogéneos. Distribuye información y datos generados por eventos del negocio en tiempo real, a personas, aplicaciones y dispositivos a traves de su empresa extendida y más allá.
    • WebSphere Message Broker documentation library
      Especificaciones y manuales de WebSphere Message Broker.
    • WebSphere Message Broker forum
      Obtenga respuestas para sus preguntas técnicas y comparta sus experiencias con otros usuarios de WebSphere Message Broker.
    • WebSphere Message Broker support page
      Una base de datos de problemas de soporte y sus soluciones, así como recursos, arreglos, seguimiento de problemas y más.
  • WebSphere resources
    • developerWorks WebSphere developer resources
      Información técnica y recursos para desarrolladores que usan los productos WebSphere. developerWorks WebSphere provee descargas, información sobre cómo se hace, recursos de soporte y una biblioteca técnica gratis con más de 2000 artículos técnicos, tutoriales, mejores prácticas, Redbooks IBM y manuales de producto en línea.
    • developerWorks WebSphere application integration developer resources
      Artículos sobre cómo se hace, descargas, tutoriales, educación, información de productos, y otros recursos que le ayudan a construir sus aplicaciones de conectividad y soluciones de integración de negocios en WebSphere.
    • Most popular WebSphere trial downloads
      Descargas de prueba gratuitas de productos clave en la familia WebSphere.
    • WebSphere forums
      Foros específicos de producto donde puede encontrar respuesta a sus preguntas técnicas y compartir sus experiencias con otros usuarios WebSphere.
    • WebSphere on-demand demos
      Baje, vea y aprenda sobre los productos y tecnologías relacionadas con WebSphere que le pueden ayudar a su compañía.
    • developerWorks WebSphere weekly newsletter
      El resumen de noticias de developerWorks le provee de información sobre los últimos artículos en aquellos temas que son de su interés. Además de WebSphere, podrá selecciona temas de Java, Linux, Open source, Rational, SOA, Web services, y otros. Suscríbase ahora y diseñe su esquema de notificaciones personalizado.
    • WebSphere-related books from IBM Press
      Conveniente sistema de órdenes en línea a través de Barnes & Noble.
    • WebSphere-related events
      Conferencias, trade shows, Webcasts, y otros eventos alrededor del mundo de interés para los desarrolladores de WebSphere.
  • Recursos developerWorks

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere
ArticleID=964108
ArticleTitle=Configuración y administración de brokers de múltiples instancias para alta disponibilidad en IBM WebSphere Message Broker - Parte 1
publish-date=03112013