Examinando los IBM MQ Uniform Clusters

Los IBM MQ Uniform Clusters abordan una debilidad común en los diseños de clusters tradicionales: las aplicaciones pueden reconectarse tras una interrupción, pero no se redistribuyen automáticamente de forma que mantengan la capacidad de consumo alineada con la colocación de mensajes.

En un Uniform Cluster, los queue managers se configuran para comportarse como un único servicio lógico. IBM MQ utiliza entonces el balanceo a nivel de aplicaciones para mover las conexiones de clientes hacia una distribución uniforme, lo que constituye la diferencia fundamental respecto al enrutamiento de mensajes en un cluster tradicional.

Este artículo explica los conceptos fundamentales de los Uniform Clusters y apunta a un laboratorio de referencia, una demo basada en Docker mantenida en GitHub donde se puede observar el comportamiento del balanceo directamente.

1. Qué cubre este artículo

• Por qué existen los Uniform Clusters y cómo difieren de los clusters tradicionales
• Las condiciones arquitectónicas que requieren
• Lo que no resuelven por sí solos
• Dónde ejecutar el laboratorio práctico

2. Por qué importan los Uniform Clusters

Para comprender los Uniform Clusters, es útil contrastarlos con el clustering IBM MQ tradicional.

2.1 Enrutamiento en clusters tradicionales

En un cluster tradicional, el balanceo de carga se centra principalmente en el enrutamiento de mensajes.

Si una aplicación conectada a QM1 abre una cluster queue como APP.QUEUE, IBM MQ decide adónde va cada operación de put. Si la queue existe tanto en QM1 como en QM2, los mensajes se distribuyen según las reglas de workload del cluster MQ, lo que a menudo resulta en una división equitativa.

Esto parece correcto hasta que cambia la ubicación de los consumidores.

Considera esta secuencia:

1. Cuatro consumidores están conectados a QM1 y cuatro a QM2.
2. QM2 queda fuera de servicio por mantenimiento.
3. Sus consumidores se reconectan a QM1.
4. QM2 regresa.
5. Los productores empiezan a enviar la mitad de los mensajes de vuelta a QM2.

En ese punto, todos los consumidores pueden estar aún conectados a QM1, mientras que algunos mensajes residen ahora en QM2. Esos mensajes quedan efectivamente bloqueados hasta que los consumidores se reconecten allí o un administrador intervenga.

2.2 Qué cambian los Uniform Clusters

Los Uniform Clusters resuelven esto re-balanceando aplicaciones, no solo mensajes.

En lugar de asumir que los consumidores acabarán reconectándose al lugar correcto, IBM MQ trabaja activamente para distribuir de forma equitativa las aplicaciones cliente con capacidad de reconexión entre los miembros del cluster. El balanceador rastrea qué aplicaciones están conectadas a cada queue manager y las mueve una a una hacia una distribución uniforme.

2.3 Qué significa "balanceado" en la práctica

La definición de cluster balanceado en IBM MQ no es necesariamente una división estrictamente igual. No evalúes el balanceo solo por el número bruto de conexiones por queue manager. El BALANCED(YES) en la salida de DISPLAY APSTATUS es el indicador en el que hay que fijarse.

3. Requisitos arquitectónicos fundamentales

Los Uniform Clusters dependen de algunos prerrequisitos:

3.1 Configuración de auto-clustering

Dos stanzas de qm.ini impulsan la configuración automática de un queue manager en un Uniform Cluster: AutoCluster y AutoConfig. Ambas se aplican en cada arranque del queue manager y se usan con los Uniform Clusters.

AutoCluster define la participación en el cluster. Los atributos Repository1Name y Repository2Name identifican dos repositorios completos que actúan como puntos de contacto de bootstrap: un queue manager en arranque los contacta para descubrir y unirse al cluster. Cualquiera de los atributos puede nombrar al propio queue manager en arranque. Todos los queue managers del cluster comparten la misma stanza:

AutoCluster:
   Type=Uniform
   ClusterName=UNICLUS
   Repository1Name=QM1
   Repository1Conname=QM1(1414)
   Repository2Name=QM2
   Repository2Conname=QM2(1414)

Cuando un queue manager arranca con esta stanza, IBM MQ crea automáticamente los canales de cluster necesarios. No se requieren definiciones de canales manuales.

AutoConfig gestiona la aplicación automática de scripts MQSC y configuraciones ini suplementarias en cada arranque. Acepta una ruta a un fichero o a un directorio donde se aplican todos los ficheros .mqsc o .ini:

AutoConfig:
   MQSCConfig=/etc/mqm/config.mqsc
   IniConfig=/etc/mqm/config.ini
   ConfigTimeout=120

Así es como las colas, canales y otros objetos se definen de forma consistente en todos los queue managers del cluster, especialmente en deployments en contenedores donde la configuración debe reproducirse en cada arranque.

El fichero MQSC referenciado por MQSCConfig debe contener como mínimo una definición de canal receptor de cluster (CLUSRCVR). Esta definición describe cómo el resto de miembros del cluster se conectan a cada queue manager y sirve de plantilla para conectarse a cualquier miembro. Un único fichero puede funcionar de forma idéntica en todos los queue managers mediante variables de sustitución que IBM MQ resuelve en el arranque:

Un ejemplo mínimo:

DEFINE CHANNEL('+AUTOCL+_+QMNAME+') CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME('+CONNAME+') CLUSTER('+AUTOCL+') REPLACE

Como +QMNAME+ se sustituye en tiempo de ejecución, el nombre del canal es único por queue manager aunque el fichero sea compartido. +AUTOCL+ y +CONNAME+ hacen igualmente genéricos el nombre del cluster y la dirección de conexión.

ConfigTimeout establece cuánto tiempo (en segundos) espera el queue manager a que se complete la auto-configuración antes de aceptar conexiones de aplicaciones. El comportamiento por defecto es sin timeout: el queue manager no queda disponible hasta que todos los comandos de configuración hayan finalizado. IBM desaconseja configurar este atributo salvo que sea necesario, porque las aplicaciones podrían conectarse antes de que existan los objetos que necesitan.

3.2 Crear los queue managers

Cada queue manager se crea con un único comando crtmqm que configura todo en el momento de la creación. Los flags hacen referencia a los ficheros definidos en la sección 3.1:

Todos los queue managers del cluster usan un comando casi idéntico — solo difieren el nombre del queue manager y su CONNAME:

crtmqm -p 1414 -ii /shared/uniclus.ini -ic /shared/uniclus.mqsc -iv CONNAME=QMA.host(1414) QMA
strmqm QMA

crtmqm -p 1414 -ii /shared/uniclus.ini -ic /shared/uniclus.mqsc -iv CONNAME=QMB.host(1414) QMB
strmqm QMB

Cuando cada queue manager arranca, IBM MQ ejecuta tres pasos automáticamente:

1. El fichero ini se aplica al qm.ini, añadiendo la stanza AutoCluster.
2. IBM MQ comprueba si este queue manager está nombrado en la stanza AutoCluster como uno de los repositorios completos. Si lo está, lo convierte en repositorio completo (equivalente a ALTER QMGR REPOS(NombreCluster)); en caso contrario, se convierte en repositorio parcial (ALTER QMGR REPOS(' ')).
3. Cuando se procesa la definición del canal CLUSRCVR, IBM MQ define automáticamente canales sender de cluster desde este queue manager hacia cada repositorio completo en la stanza AutoCluster (excluyendo el queue manager local si él mismo es un repositorio completo). Los canales sender heredan sus atributos del canal receiver de cluster local.

3.3 Las conexiones de cliente son obligatorias

Las aplicaciones deben usar conexiones de cliente sobre TCP/IP. No pueden participar en el balanceo del Uniform Cluster a través de enlaces locales porque estos fijan la aplicación al mismo espacio de proceso que el queue manager, lo que impide el movimiento transparente a otro queue manager.

3.4 Las aplicaciones deben soportar reconexión

El balanceador funciona desconectando una aplicación de su queue manager actual y permitiéndole reconectarse a uno diferente. Para que esto sea transparente, la aplicación debe:

• Estar construida con el comportamiento de reconexión habilitado, por ejemplo usando MQCNO_RECONNECT
• Tener un nombre de aplicación definido, por ejemplo a través de MQAPPLNAME
• Mantener las transacciones suficientemente cortas para que el cliente pueda moverse de forma segura en un límite de transacción

Si no se cumplen esas condiciones, la aplicación puede conectarse y funcionar, pero se comportará como una conexión legada fija y el balanceador no la moverá.

3.5 Client Channel Definition Table

Las aplicaciones cliente se conectan al cluster a través de una Client Channel Definition Table (CCDT). La CCDT lista todos los queue managers del cluster para que el cliente tenga alternativas si alguno no está disponible. El ejemplo a continuación muestra una CCDT en JSON para un cluster de tres nodos:

{
  "channel": [
    {
      "name": "UNI.SVRCONN",
      "type": "clientConnection",
      "connectionManagement": {
        "defaultReconnect": "yes",
        "affinity": "none"
      },
      "clientConnection": {
        "connection": [
          {"host": "qm1-host", "port": 1414},
          {"host": "qm2-host", "port": 1414},
          {"host": "qm3-host", "port": 1414}
        ],
        "queueManager": "*UNICLUS"
      }
    }
  ]
}

Establecer affinity como none garantiza que el cliente no se fije al primer queue manager al que se conecta, lo cual es necesario para que el balanceador pueda moverlo posteriormente.

4. Monitorización del balanceo de aplicaciones

IBM MQ proporciona el comando DISPLAY APSTATUS para observar el estado del balanceo en un Uniform Cluster. La documentación de referencia completa está en Monitoring application balancing.

4.1 Vista a nivel de cluster

Ejecuta esto en cualquier queue manager del cluster para obtener una imagen agregada:

DISPLAY APSTATUS('NombreAplicacion') TYPE(APPL) BALANCED CLUSTER COUNT MOVCOUNT

4.2 Perspectiva de queue manager

Ejecuta esto para ver el número de conexiones y la movilidad de las instancias en un queue manager específico:

DISPLAY APSTATUS('NombreAplicacion') TYPE(LOCAL) CONNS MOVABLE IMMREASN IMMCOUNT

4.3 Por qué una aplicación no se está rebalanceando

Si BALANCED(NO) persiste o MOVCOUNT es inferior al esperado, comprueba IMMREASN en cada queue manager. Los valores más comunes son:

Las causas más comunes en nuevas implementaciones de Uniform Clusters son RECONNECT y APPNAME. Ambas indican que la aplicación no fue construida ni configurada para participar en el balanceo. Consulta Applications not balancing correctly en la documentación de IBM MQ para la lista completa de códigos de motivo y pasos de resolución.

5. Lo que los Uniform Clusters no resuelven solos

Los Uniform Clusters mejoran la conectividad y el balanceo de aplicaciones, pero no eliminan la frontera de almacenamiento entre queue managers.

Cada queue manager sigue siendo propietario de sus propios datos de mensajes. Si QM1 falla, las aplicaciones pueden reconectarse en otro lugar, pero los mensajes persistentes que estaban solo en QM1 quedan inaccesibles hasta que ese nodo regrese o una tecnología de alta disponibilidad separada proteja su almacenamiento.

Por eso los Uniform Clusters se combinan frecuentemente con:

• Multi-Instance Queue Managers: dos instancias del mismo queue manager compartiendo un sistema de archivos en red, con failover automático
• Native HA: un grupo de queue managers con replicación tripartita donde un standby asume automáticamente

Los Uniform Clusters mejoran el balanceo de las aplicaciones en el cluster. No hacen, por sí solos, que el almacenamiento local de mensajes de cada nodo esté disponible instantáneamente desde otros nodos.

6. Ejecutar el laboratorio práctico

Utiliza el repositorio de demostración de Uniform Clusters en GitHub:

github.com/ibm-messaging/mq-uniform-clusters

El repositorio incluye varias demos, incluyendo la que nos interesa aquí (demo/Docker), que arranca un Uniform Cluster de tres nodos e incluye aplicaciones cliente de ejemplo para demostrar el balanceo.

7. Conclusión

Los clusters MQ tradicionales son eficaces en el enrutamiento de mensajes a nivel de mensaje, pero dejan la colocación de las aplicaciones en gran medida fuera del ámbito del propio cluster. Los IBM MQ Uniform Clusters cierran esa brecha combinando clientes con capacidad de reconexión, identidad de aplicación y queue managers auto-agrupados en una plataforma de mensajería que reequilibra las conexiones a medida que el cluster se expande o se recupera de una interrupción.

Esto hace que los Uniform Clusters sean especialmente atractivos en entornos elásticos como Kubernetes, donde los cambios en el diseño de la infraestructura son esperados y no excepcionales.

8. Documentación IBM útil

• IBM MQ Uniform Clusters overview
• How automatic balancing uses automatic reconnect
• Influencing application re-balancing in uniform clusters
• Monitoring application balancing
• MQ clients: Client Channel Definition Table (CCDT)
• JSON CCDT examples
• IBM MQ Uniform Clusters GitHub repository