Replicación entre regiones de IBM MQ en la práctica

Native HA de IBM MQ utiliza replicación síncrona y protege un gestor de colas contra fallos dentro del mismo sitio. La replicación entre regiones (CRR) añade un segundo grupo Native HA y copia de forma asíncrona los datos del registro de recuperación, proporcionando un destino de recuperación ante desastres en otra ubicación que puede estar distante.

Este artículo crea la topología completa en un host Docker utilizando una máquina virtual Linux Intel/AMD64 o Docker Desktop en macOS. El laboratorio utiliza seis contenedores IBM MQ: tres instancias en un grupo denominado london y tres instancias en un grupo denominado rome. Londres comienza con el rol Live, mientras que Roma comienza con el rol Recovery.

La configuración en una única máquina virtual es deliberadamente compacta y permite estudiar los roles de grupo, el quórum, la replicación protegida por TLS, el trabajo pendiente de recuperación y una conmutación planificada sin aprovisionar primero dos centros de datos.

Limitaciones del laboratorio: esta topología demuestra el comportamiento de MQ, no la resiliencia real de la infraestructura. Los seis contenedores comparten un host Docker, un subsistema de almacenamiento y un dominio de fallo. IBM presenta Kubernetes o Red Hat OpenShift como la infraestructura compatible para contenedores con Native HA CRR y recomienda utilizar el operador de IBM MQ. Utilice este laboratorio de Docker Compose únicamente para aprender los conceptos básicos.

1. Qué construye este laboratorio

La topología final es:

IBM MQ CRR topología con Londres como grupo Live de tres instancias y Roma como grupo de recuperación de tres instancias

Cada grupo contiene tres instancias del mismo gestor de colas, CRRQM.

Dentro de cada grupo, Native HA utiliza replicación de registros sincrónicos y quórum.
Entre grupos, CRR utiliza replicación de registros asincrónica.
Sólo el grupo Live acepta la carga de trabajo de la solicitud.
El líder de recuperación recibe datos de registro, pero no acepta conexiones normales desde la aplicación MQ.
Una transición planificada coordina ambos grupos y espera a que se sincronicen sus registros.

Este laboratorio valida los siguientes elementos:

Ambos grupos nativos HA alcanzan el quórum.
Londres elige un administrador de colas activo.
Roma elige un líder de recuperación.
Los grupos se conectan entre sí mediante TLS.
Se transmite un mensaje persistente al grupo de recuperación.
Un cambio planificado hace que Roma forme parte del grupo Live sin perder el mensaje.

2. Requisitos y limitaciones importantes

Utilice uno de estos entornos:

Una máquina virtual Intel/AMD64 (uname -m debería mostrar x86_64), o
Un Mac con Docker Desktop, incluido Apple Silicon con la compatibilidad Rosetta de Docker Desktop habilitada

Asignar:

Al menos 12 GB RAM; 16 GB es más cómodo
Al menos 30 GB de espacio libre en disco
Acceso a Internet para icr.io
Docker Engine y Docker Compose v2 ya instalados. Las instrucciones de instalación se pueden encontrar en el Apéndice A.

Requisito de arquitectura: La imagen prediseñada de IBM MQ Advanced for Developers que se utiliza aquí es linux/amd64. No utilice un ARM64 Linux VM para esta práctica de laboratorio. En Apple Silicon, Docker Desktop administra el AMD64 dentro de su propio VM Linux.

El CRR necesita más almacenamiento que una implementación nativa normal de HA.

Este artículo utiliza la imagen IBM MQ Advanced for Developers. Su licencia restringe el uso de desarrollo en una máquina de desarrollador. La producción CRR requiere el derecho IBM MQ avanzado adecuado o el complemento IBM MQ nativo HA y la replicación entre regiones.

El laboratorio fija la imagen de desarrollo IBM MQ 10.0 en lugar de usar latest. Fijar 10.0.0.0-r2 hace que el ejercicio sea repetible y garantiza que las características Native HA CRR para Linux utilizadas a continuación estén presentes.

3. Cree la carpeta del laboratorio y descargue IBM MQ

Cree una carpeta de trabajo vacía:

mkdir -p "$HOME/mq-crr-lab/config" "$HOME/mq-crr-lab/tls"
cd "$HOME/mq-crr-lab"

Mantenga la imagen de desarrollador MQ 10.0 actual para Compose y expórtela a comandos en el shell actual:

cat > .env <<'EOF'
MQ_IMAGE=icr.io/ibm-messaging/mq:10.0.0.0-r2
EOF

set -a
. ./.env
set +a

printf 'MQ image: <%s>\n' "$MQ_IMAGE"

Los corchetes en el resultado deben contener la referencia de la imagen completa. Docker Compose lee .env automáticamente. Después de abrir una nueva terminal, regrese a la carpeta de laboratorio y vuelva a cargar la variable antes de usar los comandos independientes docker pull o docker run:

cd "$HOME/mq-crr-lab"
set -a
. ./.env
set +a

Verifique que Container Registry IBM esté resuelto y sea accesible:

case "$(uname -s)" in
  Linux) getent ahosts icr.io ;;
  Darwin) dscacheutil -q host -a name icr.io ;;
esac
curl -I https://icr.io/v2/

Se espera una respuesta HTTP 401 Unauthorized de /v2/. Esto prueba que DNS, TCP, TLS y el punto final de registro están funcionando. No se requiere autenticación para obtener la imagen pública.

Obtener la imagen:

docker pull --platform linux/amd64 "$MQ_IMAGE"

Si Docker en Linux informa un error transitorio lookup icr.io ... no such host a pesar de que las dos comprobaciones anteriores funcionan, reinicie el demonio e inténtelo nuevamente:

sudo systemctl restart docker
docker pull --platform linux/amd64 "$MQ_IMAGE"

En macOS, use Docker Desktop > Solucionar problemas > Reiniciar Docker Desktop y repita el comando de extracción.

Confirme la versión MQ en la imagen:

docker run --rm --platform linux/amd64 --entrypoint dspmqver "$MQ_IMAGE"

El resultado debería mostrar IBM MQ versión 10.0.0.0.

Antes de iniciar seis instancias, demuestre que se puede iniciar correctamente un administrador de colas en este host. Estos comandos suponen que docker version funciona sin sudo.

docker rm -f mq-platform-test >/dev/null 2>&1 || true

docker run -d --name mq-platform-test \
  --platform linux/amd64 \
  -e LICENSE=accept \
  -e MQ_QMGR_NAME=PLATFORMQM \
  "$MQ_IMAGE"

MQ_READY=0
for attempt in $(seq 1 60); do
  if docker exec mq-platform-test \
      dspmq -m PLATFORMQM 2>/dev/null | grep -Fq 'STATUS(Running)'; then
    MQ_READY=1
    break
  fi
  printf '.'
  sleep 3
done
printf '\n'

if [ "$MQ_READY" -eq 1 ]; then
  echo "PLATFORMQM is running."
  docker exec mq-platform-test dspmq -m PLATFORMQM
  docker logs --tail 20 mq-platform-test
  docker rm -f mq-platform-test
else
  echo "The test queue manager did not become ready within three minutes."
  docker logs --tail 100 mq-platform-test
  echo "The container was left running for diagnosis."
fi

El estado del Administrador de colas se verifica con el comando dspmq.

4. Por qué utilizamos TLS en el laboratorio

IBM MQ requiere TLS para la replicación de registros entre grupos nativos HA. El TLS dentro de cada grupo de tres instancias es opcional pero recomendado. Para que el ejercicio sea manejable, las seis instancias utilizan el mismo certificado autofirmado y almacén de claves.

Esta simplificación sólo es adecuada para escenarios de laboratorio.

Cree la base de datos de claves utilizando las herramientas MQ que ya están presentes en la imagen del contenedor:

docker run --rm --platform linux/amd64 --user 0 \
  -v "$PWD/tls:/work" \
  --entrypoint /bin/bash \
  "$MQ_IMAGE" -lc '
    set -e
    runmqakm -keydb -create \
      -db /work/keystore.kdb \
      -pw passw0rd \
      -stash
    runmqakm -cert -create \
      -db /work/keystore.kdb \
      -pw passw0rd \
      -label nha-qm-replication \
      -dn "CN=CRRQM-REPLICATION" \
      -size 2048
    chmod 644 /work/keystore.*
  '

Revisa los archivos:

ls -l tls/keystore.*

La ruta del almacén de claves utilizada por MQ omite el sufijo .kdb, por lo que la configuración hará referencia a /etc/mqm/tls/keystore.

5. Cree las dos configuraciones nativas HA

Cada instancia necesita su propio nombre NativeHALocalInstance. De lo contrario, todas las instancias de un grupo utilizarán la misma lista de miembros y direcciones del grupo de recuperación.

Cree un pequeño script auxiliar que escriba los seis archivos de configuración:

cat > make-config.sh <<'SCRIPT'
#!/usr/bin/env bash
set -euo pipefail

mkdir -p config

write_london() {
  local instance=$1
  cat > "config/${instance}.ini" <<EOF
NativeHALocalInstance:
    Name=${instance}
    GroupName=london
    GroupRole=Live
    GroupLocalAddress=(9415)
    CipherSpec=ANY_TLS12
    GroupCipherSpec=ANY_TLS12
    CertificateLabel=nha-qm-replication
    KeyRepository=/etc/mqm/tls/keystore
NativeHAInstance:
    Name=london1
    ReplicationAddress=london1(9414)
NativeHAInstance:
    Name=london2
    ReplicationAddress=london2(9414)
NativeHAInstance:
    Name=london3
    ReplicationAddress=london3(9414)
NativeHARecoveryGroup:
    GroupName=rome
    ReplicationAddress=rome1(9415),rome2(9415),rome3(9415)
    Enabled=Yes
EOF
}

write_rome() {
  local instance=$1
  cat > "config/${instance}.ini" <<EOF
NativeHALocalInstance:
    Name=${instance}
    GroupName=rome
    GroupRole=Recovery
    GroupLocalAddress=(9415)
    CipherSpec=ANY_TLS12
    GroupCipherSpec=ANY_TLS12
    CertificateLabel=nha-qm-replication
    KeyRepository=/etc/mqm/tls/keystore
NativeHAInstance:
    Name=rome1
    ReplicationAddress=rome1(9414)
NativeHAInstance:
    Name=rome2
    ReplicationAddress=rome2(9414)
NativeHAInstance:
    Name=rome3
    ReplicationAddress=rome3(9414)
NativeHARecoveryGroup:
    GroupName=london
    ReplicationAddress=london1(9415),london2(9415),london3(9415)
    Enabled=Yes
EOF
}

for instance in london1 london2 london3; do
  write_london "$instance"
done

for instance in rome1 rome2 rome3; do
  write_rome "$instance"
done
SCRIPT

chmod +x make-config.sh
./make-config.sh

Revise un archivo de cada grupo:

cat config/london1.ini
cat config/rome1.ini

Los atributos importantes de CRR son:

Atributo	Propósito
`GroupName`	Identifica el grupo local de tres instancias.
`GroupRole`	Solicita el comportamiento `Live` o `Recovery`.
`GroupLocalAddress`	Abre el punto final de replicación de grupo a grupo local.
`GroupCipherSpec`	Requiere TLS para conexión entre grupos.
`NativeHARecoveryGroup`	Nombra el otro grupo y enumera las direcciones a través de las cuales MQ puede encontrarlo.

Nombres como london y rome describen ubicaciones en lugar de funciones. Esto es importante porque los roles se invertirán durante la transición.

6. Cree la configuración del objeto MQ

Cree una cola persistente y un canal de cliente. Las definiciones de objetos se aplican cuando se inicia Queue Manager Live por primera vez y luego se replican con los datos de Queue Manager.

cat > config/20-config.mqsc <<'EOF'
DEFINE QLOCAL('CRR.TEST.QUEUE') DEFPSIST(YES) REPLACE
DEFINE CHANNEL('DEV.APP.SVRCONN') CHLTYPE(SVRCONN) REPLACE
ALTER CHANNEL('DEV.APP.SVRCONN') CHLTYPE(SVRCONN) MCAUSER('mqm')
ALTER QMGR CHLAUTH(DISABLED)
ALTER QMGR CONNAUTH('')
REFRESH SECURITY(*) TYPE(CONNAUTH)
EOF

Las modificaciones anteriores tienen como objetivo desactivar los mecanismos de seguridad para simplificar la demostración en el laboratorio. Nunca los utilices como modelo de seguridad de producción.

7. Cree la topología Docker Compose

El archivo Docker Compose es compartido por Intel/AMD64 Linux y Docker Desktop en macOS. platform: linux/amd64 es nativo de VM Linux y selecciona la ruta de ejecución de AMD64 desde Docker Desktop en Apple Silicon. Los datos de Queue Manager utilizan volúmenes con nombre de Docker para evitar diferencias de propiedad en la ruta del host. Los montajes de enlace compartidos de solo lectura utilizan la opción de SELinux z, que Compose ignora en plataformas donde SELinux no está habilitado.

Los servicios no publican puertos MQ en el host. Cada comando utilizado para las validaciones se ejecuta a través de docker exec, y los nativos HA y CRR se comunican a través de la red privada de Docker. Esto evita colisiones con otro contenedor local MQ que ya usa uno de los puertos (ejemplo: 1414).

Abra un editor de texto y pegue el siguiente contenido para crear el archivo docker-compose.yaml:

services:
  london1:
    container_name: crr-london1
    hostname: london1
    image: ${MQ_IMAGE:-icr.io/ibm-messaging/mq:10.0.0.0-r2}
    platform: linux/amd64
    environment:
      LICENSE: "accept"
      MQ_QMGR_NAME: "CRRQM"
      MQ_NATIVE_HA: "true"
      MQ_NATIVE_HA_INSTANCE_NAME: "london1"
    volumes:
      - london1-data:/mnt/mqm
      - ./config/london1.ini:/etc/mqm/nativeha.ini:ro,z
      - ./config/20-config.mqsc:/etc/mqm/20-config.mqsc:ro,z
      - ./tls:/etc/mqm/tls:ro,z
    networks: [crrnet]

  london2:
    container_name: crr-london2
    hostname: london2
    image: ${MQ_IMAGE:-icr.io/ibm-messaging/mq:10.0.0.0-r2}
    platform: linux/amd64
    environment:
      LICENSE: "accept"
      MQ_QMGR_NAME: "CRRQM"
      MQ_NATIVE_HA: "true"
      MQ_NATIVE_HA_INSTANCE_NAME: "london2"
    volumes:
      - london2-data:/mnt/mqm
      - ./config/london2.ini:/etc/mqm/nativeha.ini:ro,z
      - ./config/20-config.mqsc:/etc/mqm/20-config.mqsc:ro,z
      - ./tls:/etc/mqm/tls:ro,z
    networks: [crrnet]

  london3:
    container_name: crr-london3
    hostname: london3
    image: ${MQ_IMAGE:-icr.io/ibm-messaging/mq:10.0.0.0-r2}
    platform: linux/amd64
    environment:
      LICENSE: "accept"
      MQ_QMGR_NAME: "CRRQM"
      MQ_NATIVE_HA: "true"
      MQ_NATIVE_HA_INSTANCE_NAME: "london3"
    volumes:
      - london3-data:/mnt/mqm
      - ./config/london3.ini:/etc/mqm/nativeha.ini:ro,z
      - ./config/20-config.mqsc:/etc/mqm/20-config.mqsc:ro,z
      - ./tls:/etc/mqm/tls:ro,z
    networks: [crrnet]

  rome1:
    container_name: crr-rome1
    hostname: rome1
    image: ${MQ_IMAGE:-icr.io/ibm-messaging/mq:10.0.0.0-r2}
    platform: linux/amd64
    environment:
      LICENSE: "accept"
      MQ_QMGR_NAME: "CRRQM"
      MQ_NATIVE_HA: "true"
      MQ_NATIVE_HA_INSTANCE_NAME: "rome1"
    volumes:
      - rome1-data:/mnt/mqm
      - ./config/rome1.ini:/etc/mqm/nativeha.ini:ro,z
      - ./config/20-config.mqsc:/etc/mqm/20-config.mqsc:ro,z
      - ./tls:/etc/mqm/tls:ro,z
    networks: [crrnet]

  rome2:
    container_name: crr-rome2
    hostname: rome2
    image: ${MQ_IMAGE:-icr.io/ibm-messaging/mq:10.0.0.0-r2}
    platform: linux/amd64
    environment:
      LICENSE: "accept"
      MQ_QMGR_NAME: "CRRQM"
      MQ_NATIVE_HA: "true"
      MQ_NATIVE_HA_INSTANCE_NAME: "rome2"
    volumes:
      - rome2-data:/mnt/mqm
      - ./config/rome2.ini:/etc/mqm/nativeha.ini:ro,z
      - ./config/20-config.mqsc:/etc/mqm/20-config.mqsc:ro,z
      - ./tls:/etc/mqm/tls:ro,z
    networks: [crrnet]

  rome3:
    container_name: crr-rome3
    hostname: rome3
    image: ${MQ_IMAGE:-icr.io/ibm-messaging/mq:10.0.0.0-r2}
    platform: linux/amd64
    environment:
      LICENSE: "accept"
      MQ_QMGR_NAME: "CRRQM"
      MQ_NATIVE_HA: "true"
      MQ_NATIVE_HA_INSTANCE_NAME: "rome3"
    volumes:
      - rome3-data:/mnt/mqm
      - ./config/rome3.ini:/etc/mqm/nativeha.ini:ro,z
      - ./config/20-config.mqsc:/etc/mqm/20-config.mqsc:ro,z
      - ./tls:/etc/mqm/tls:ro,z
    networks: [crrnet]

networks:
  crrnet:
    name: mq-crr-network

volumes:
  london1-data:
  london2-data:
  london3-data:
  rome1-data:
  rome2-data:
  rome3-data:

Valide el archivo Docker Compose:

docker compose config --quiet
docker compose pull

8. Inicie el grupo London Live

Si ejecutó alguna versión anterior de esta práctica de laboratorio, ejecute el siguiente código. Elimina los seis contenedores de laboratorio, sus volúmenes de datos de Queue Manager y los contenedores restantes.

docker compose down -v --remove-orphans

docker rm -f \
  crr-london1 crr-london2 crr-london3 \
  crr-rome1 crr-rome2 crr-rome3 \
  2>/dev/null || true

docker network rm mq-crr-network 2>/dev/null || true

La opción -v elimina todos los mensajes y estados de ejecuciones anteriores de administradores de colas. Úselo aquí para reiniciar el entorno del laboratorio.

Genere nuevamente los seis archivos INI y valídelos. La segunda verificación debería mostrar No host ports published:

./make-config.sh
docker compose config --quiet

if docker compose config | grep -q 'published:'; then
  echo "ERROR: remove every ports: section from docker-compose.yaml"
  docker compose config | grep -n -A 3 -B 2 'published:'
  exit 1
else
  echo "No host ports published"
fi

Esta comprobación evita que un archivo Docker Compose antiguo conserve asignaciones como 1414:1414. El laboratorio no requiere ningún puerto de host: la validación usa docker exec, mientras que los nativos HA y CRR usan la red privada de Docker.

Inicie el grupo de Londres para que pueda establecer el estado inicial de los administradores de colas:

docker compose up -d london1 london2 london3

Supervise el proceso de arranque:

docker compose logs --tail=40 london1 london2 london3

Confirme que los contenedores todavía se están ejecutando:

docker compose ps -a london1 london2 london3

Luego verifique el estado del Administrador de colas y el estado nativo HA para cada instancia.

for c in crr-london1 crr-london2 crr-london3; do
  echo "== $c =="
  docker exec "$c" dspmq -m CRRQM -o status
  docker exec "$c" dspmq -m CRRQM -o nativeha
done

Después de arrancar, espere obtener un ROLE(Active), dos ROLE(Replica), QUORUM(3/3), GRPNAME(london) y GRPROLE(Live).

Almacene el nombre del contenedor activo:

LONDON_ACTIVE=$(
  for c in crr-london1 crr-london2 crr-london3; do
    docker exec "$c" dspmq -m CRRQM -o nativeha | \
      grep -q 'ROLE(Active)' && echo "$c" && break
  done
)
echo "London active instance: $LONDON_ACTIVE"

Tan pronto como LONDON_ACTIVE no esté vacío, muestre los registros del grupo CRR local y remoto:

docker exec "$LONDON_ACTIVE" dspmq -m CRRQM -o nativeha -g

Confirme que la cola de prueba existe:

printf 'DISPLAY QLOCAL(CRR.TEST.QUEUE) CURDEPTH DEFPSIST\n' | \
  docker exec -i "$LONDON_ACTIVE" runmqsc CRRQM

Si LONDON_ACTIVE está vacío, espere 20 segundos, repita el comando e inspeccione la sección de solución de problemas a continuación.

9. Inicie el grupo Recovery Rome

Comienza el segundo grupo:

docker compose up -d rome1 rome2 rome3

Consulta tu estado:

for c in crr-rome1 crr-rome2 crr-rome3; do
  echo "== $c =="
  docker exec "$c" dspmq -m CRRQM -o status
  docker exec "$c" dspmq -m CRRQM -o nativeha
done

Espere hasta que una instancia de Rome muestre ROLE(Leader), las otras muestren ROLE(Replica) y el grupo muestre GRPNAME(rome), GRPROLE(Recovery) y QUORUM(3/3).

La primera sincronización puede tardar porque Roma debe establecer su copia de recuperación. Repita este comando hasta que la conexión del grupo sea normal:

docker exec "$LONDON_ACTIVE" dspmq -m CRRQM -o nativeha -g

La sección relacionada con el grupo de recuperación eventualmente debería incluir valores equivalentes a:

GRPNAME(rome) GRPROLE(Recovery) CONNGRP(yes) GRSTATUS(Normal) BACKLOG(0) INSYNC(yes)

10. Confirmar replicación protegida por TLS

Busque en los registros del Administrador de colas enlaces nativos HA:

docker exec "$LONDON_ACTIVE" grep -E \
  'AMQ3305I|secure connection|certificate DN' \
  /var/mqm/qmgrs/CRRQM/errors/AMQERR01.LOG || true

Debería ver mensajes sobre conexiones seguras y el certificado DN CN=CRRQM-REPLICATION.

Si los dos grupos no pueden conectarse entre sí, inspeccione todos los registros de errores recientes para MQ:

for c in crr-london1 crr-london2 crr-london3 crr-rome1 crr-rome2 crr-rome3; do
  echo "== $c =="
  docker exec "$c" tail -n 25 \
    /var/mqm/qmgrs/CRRQM/errors/AMQERR01.LOG 2>/dev/null || true
done

11. Colocar un mensaje persistente en Londres

Publicar un mensaje en Queue Manager Live:

printf 'Message written in London before the CRR switchover\n\n' | \
  docker exec -i "$LONDON_ACTIVE" /opt/mqm/samp/bin/amqsput CRR.TEST.QUEUE CRRQM

Comprueba tu profundidad:

printf 'DISPLAY QLOCAL(CRR.TEST.QUEUE) CURDEPTH\n' | \
  docker exec -i "$LONDON_ACTIVE" runmqsc CRRQM

Antes de cambiar de función, confirme nuevamente que el estado de recuperación muestre BACKLOG(0) y INSYNC(yes):

docker exec "$LONDON_ACTIVE" dspmq -m CRRQM -o nativeha -g

El mecanismo CRR es asíncrono, por lo que la colocación exitosa del mensaje en Londres no prueba por sí sola que Roma ya tenga el registro de registro correspondiente. BACKLOG(0) y INSYNC(yes) son comprobaciones importantes antes de una transición controlada.

12. Ejecute una transición CRR planificada

Una transición planificada coordina ambos grupos y espera a que se sincronicen los registros de recuperación. Este proceso es diferente de una conmutación por error de emergencia, donde el sitio Live original no está disponible y puede haber cierta pérdida de datos o riesgo de división del cerebro.

Pídale a London que pase de Live a Recovery:

cat > set-role.sh <<'SCRIPT'
#!/usr/bin/env bash
set -euo pipefail

from_role=$1
to_role=$2
shift 2

for file in "$@"; do
  grep -q "GroupRole=$from_role" "$file" || {
    echo "$file does not request GroupRole=$from_role" >&2
    exit 1
  }
  sed "s/GroupRole=$from_role/GroupRole=$to_role/" "$file" > "$file.tmp"
  mv "$file.tmp" "$file"
done
SCRIPT

chmod +x set-role.sh
./set-role.sh Live Recovery \
  config/london1.ini config/london2.ini config/london3.ini
docker compose restart london1 london2 london3

Verifique el estado de Londres hasta que muestre una transición de recuperación pendiente:

for c in crr-london1 crr-london2 crr-london3; do
  docker exec "$c" dspmq -m CRRQM -o nativeha
done

Ahora pídele a Roma que asuma el estado Vivo:

./set-role.sh Recovery Live \
  config/rome1.ini config/rome2.ini config/rome3.ini
docker compose restart rome1 rome2 rome3

Durante el proceso de coordinación, los grupos pueden reportar Pending recovery y Pending live. Espere a que Roma elija una instancia activa:

ROME_ACTIVE=""
for attempt in $(seq 1 30); do
  ROME_ACTIVE=$(
    for c in crr-rome1 crr-rome2 crr-rome3; do
      docker exec "$c" dspmq -m CRRQM -o nativeha | \
        grep -q 'ROLE(Active)' && echo "$c" && break
    done
  )
  [ -n "$ROME_ACTIVE" ] && break
  sleep 5
done
echo "Rome active instance: $ROME_ACTIVE"

Ver el estado final del grupo:

docker exec "$ROME_ACTIVE" dspmq -m CRRQM -o nativeha -g

Roma debería mostrar ahora GRPROLE(Live) y Londres debería mostrar GRPROLE(Recovery).

13. Demuestre que el mensaje fue propagado

Lee el mensaje del nuevo grupo Live:

docker exec -i "$ROME_ACTIVE" /opt/mqm/samp/bin/amqsget CRR.TEST.QUEUE CRRQM

La salida debe contener:

Message written in London before the CRR switchover

Esto demuestra que:

Londres aceptó un mensaje persistente.
El nativo HA realizó protección dentro del grupo de Londres.
CRR copió de forma asincrónica el registro de recuperación correspondiente a Rome.
La transición planificada sincronizó los grupos antes de cambiar de roles.
Roma activó el mismo Administrador de colas y expuso el mensaje.

14. Regreso a Londres (estado inicial)

Para restaurar las funciones originales, primero solicite que el grupo Live actual, Roma, se convierta en Recuperación:

./set-role.sh Live Recovery \
  config/rome1.ini config/rome2.ini config/rome3.ini
docker compose restart rome1 rome2 rome3

Luego solicite que Londres se convierta en Live:

./set-role.sh Recovery Live \
  config/london1.ini config/london2.ini config/london3.ini
docker compose restart london1 london2 london3

Supervise ambos grupos hasta que Londres vuelva a tener una instancia ROLE(Active) y Roma tenga una instancia ROLE(Leader):

for c in crr-london1 crr-london2 crr-london3 crr-rome1 crr-rome2 crr-rome3; do
  echo "== $c =="
  docker exec "$c" dspmq -m CRRQM -o nativeha
done

15. ¿Por qué este laboratorio no fuerza una conmutación por error no planificada?

Una conmutación por error no planificada de CRR es una decisión de recuperación ante desastres, no simplemente otro reinicio del contenedor. Si no se puede acceder al grupo en vivo, el grupo de recuperación no puede demostrar que tiene todos los registros finales o que el grupo anterior permanecerá detenido. Por lo tanto, forzar el grupo de recuperación Live puede introducir:

un punto de recuperación distinto de cero
pérdida de mensajes que existían sólo en el sitio fallido
dos copias activas independientemente del mismo Administrador de colas
datos particionados o situación de cerebro dividido que debe resolverse más adelante

Lo que podemos hacer de forma segura en un entorno con el mismo Host es la transición planeada anteriormente. Estudie los procedimientos de conmutación por error no planificada y cerebro dividido según lo documentado por IBM antes de probar la promoción forzada y utilice dominios de error separados al hacerlo.

16. Solución de problemas

El comando de estado `-g` no muestra nada

La salida dspmq -o nativeha -g a nivel de grupo está vacía cuando MQ no considera que el Administrador de colas sea parte de un grupo nativo HA. Ejecute estas comprobaciones sin redirigir la salida del error:

docker compose ps -a london1 london2 london3

for c in crr-london1 crr-london2 crr-london3; do
  echo "== $c: MQ status =="
  docker exec "$c" dspmq -m CRRQM -o status
  docker exec "$c" dspmq -m CRRQM -o nativeha
done

Si la salida a nivel de instancia dice ROLE(Not configured), verifique qué recibió el primer contenedor y qué aplicó MQ:

docker inspect crr-london1 \
  --format '{{range .Config.Env}}{{println .}}{{end}}' | grep '^MQ_'

docker exec crr-london1 cat /etc/mqm/nativeha.ini
docker exec crr-london1 grep -n -A12 -E \
  '^NativeHA(LocalInstance|Instance|RecoveryGroup):' \
  /var/mqm/qmgrs/CRRQM/qm.ini

docker compose logs --tail=150 london1 london2 london3

No continúe con Roma hasta que los tres comandos a nivel de instancia de Londres muestren un ROLE(Active), dos ROLE(Replica) y quórum. Si estos contenedores se inicializaron antes de que la configuración nativa HA fuera correcta, utilice el procedimiento de limpieza siguiente para recrear los volúmenes de datos.

Un contenedor termina durante la inicialización

Verifique los registros de sos:

docker compose ps -a
docker compose logs --tail=100 london1

Las causas comunes incluyen memoria insuficiente, un almacén de claves ilegible, un archivo INI con formato incorrecto o la reutilización de volúmenes de datos creados con diferentes configuraciones.

Los grupos permanecen desconectados

Confirme que Docker DNS resuelva los seis nombres de servicios:

docker exec crr-london1 getent hosts rome1 rome2 rome3
docker exec crr-rome1 getent hosts london1 london2 london3

Confirme que los archivos TLS estén visibles:

docker exec crr-london1 find /etc/mqm/tls -maxdepth 1 \
  -name 'keystore.*' -ls
docker exec crr-rome1 find /etc/mqm/tls -maxdepth 1 \
  -name 'keystore.*' -ls

Luego, inspeccione AMQERR01.LOG en los líderes del grupo en busca de certificados, CipherSpec o errores de conexión.

Un grupo no alcanza el quórum

Los tres miembros de este grupo deben estar ejecutándose y ser capaces de resolverse entre sí en el puerto 9414:

docker compose ps
docker exec crr-london1 getent hosts london2 london3

Un cambio de rol no surte efecto

Verifique que los tres archivos INI del grupo soliciten la misma función:

grep GroupRole config/*.ini

El rol a asumir es una decisión grupal. La mayoría debe solicitar la misma transición y los dos grupos deben coordinarse para una transición planificada.

Empezar de nuevo desde un estado limpio

Si se trata de un laboratorio desechable y los datos de inicio no son coherentes, elimine los contenedores y los volúmenes antes de volver a intentarlo:

docker compose down -v --remove-orphans
docker rm -f \
  crr-london1 crr-london2 crr-london3 \
  crr-rome1 crr-rome2 crr-rome3 \
  2>/dev/null || true
docker network rm mq-crr-network 2>/dev/null || true

./make-config.sh
docker compose config --quiet
docker compose config | grep -q 'published:' && {
  echo "ERROR: remove every ports: section from docker-compose.yaml"
  exit 1
}

docker compose up -d london1 london2 london3
docker compose ps -a

Utilice down -v solo cuando desee eliminar intencionalmente todos los datos de los administradores de colas. Los tres contenedores de Londres deben mostrar Up.

17. Lo que demuestra el laboratorio

Los HA y CRR nativos resuelven problemas relacionados pero diferentes:

Capa	Replicación	Objetivo principal	Transición
Nativo HA dentro de Londres o Roma	Sincrónico	Sobrevivir a una instancia o a un error de almacenamiento local	Elección automática de líder
CRR entre Londres y Roma	Asíncrono	Recuperar el administrador de colas en otra región	Cambio de función controlado por el operador

El grupo de recuperación no es un segundo administrador de colas. Es una copia protegida del mismo Administrador de colas lógico, mantenida a partir de los datos del registro de recuperación y promovida a través de una transición de roles controlada.

La infraestructura de un único VM hace visibles estos mecanismos, pero un diseño real debe distribuir las seis instancias en dos regiones, aislar los dominios de falla para el almacenamiento y la conexión en red, dimensionar el sitio de recuperación para soportar la carga de producción completa, exponer puntos finales estables a los clientes, automatizar el monitoreo y ensayar procedimientos planificados y no planificados.

18. Procedimiento de limpieza

Elimine los seis contenedores, la red Docker y los volúmenes de Queue Manager:

docker compose down -v

Elimine los archivos de laboratorio:

cd "$HOME"
rm -rf "$HOME/mq-crr-lab"

La imagen IBM MQ permanece en la caché de imágenes local. Elimínelo sólo si ya no lo necesita:

docker image rm icr.io/ibm-messaging/mq:10.0.0.0-r2

Apéndice A. Instalación de Docker y Docker Compose

Motor Docker Linux

Identifique su distribución de Linux antes de elegir las instrucciones de instalación:

. /etc/os-release
echo "$ID $VERSION_ID"

En Ubuntu o Debian, utilice el repositorio oficial de Docker APT. Los repositorios de distribución de Linux no proporcionan consistentemente docker-compose-plugin.

(
set -e

. /etc/os-release
case "$ID" in
  ubuntu)
    DOCKER_DIST=ubuntu
    DOCKER_CODENAME=${UBUNTU_CODENAME:-$VERSION_CODENAME}
    ;;
  debian)
    DOCKER_DIST=debian
    DOCKER_CODENAME=$VERSION_CODENAME
    ;;
  *)
    echo "This APT block supports Ubuntu and Debian, not $ID."
    exit 1
    ;;
esac

sudo apt-get update
sudo apt-get install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL "https://download.docker.com/linux/$DOCKER_DIST/gpg" \
  -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

ARCH=$(dpkg --print-architecture)
sudo tee /etc/apt/sources.list.d/docker.sources >/dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/$DOCKER_DIST
Suites: $DOCKER_CODENAME
Components: stable
Architectures: $ARCH
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt-get update
apt-cache policy docker-ce docker-compose-plugin
sudo apt-get install -y \
  docker-ce \
  docker-ce-cli \
  containerd.io \
  docker-buildx-plugin \
  docker-compose-plugin

sudo systemctl enable --now docker
)

Los paréntesis realizan la instalación en una subcapa. set -e detiene la instalación si falla un comando, en lugar de continuar con systemctl y generar el mensaje Unit file docker.service does not exist. No deja habilitado el modo de salida de errores en su shell interactivo. Para otras distribuciones de Linux, siga las instrucciones de instalación de Docker para esa distribución en lugar de adaptar los comandos APT.

Si su usuario de Linux no tiene permiso para acceder a Docker, agréguelo al grupo docker:

sudo usermod -aG docker "$USER"
newgrp docker

Herramientas de verificación:

docker version
docker compose version
uname -m

Linux VM debería informar x86_64.

Escritorio Docker en macOS

Instale el escritorio Docker. Docker Desktop ya incluye Docker Engine, Docker CLI y Compose v2.

En Apple Silicon, abra Docker Desktop > Configuración > General:

Seleccione Apple Virtualization Framework como administrador de la máquina virtual.
Habilite Usar Rosetta para la emulación x86_64/amd64 en Apple Silicon.

En Configuración > Recursos, asigne al menos 12 GB RAM. Aplique los cambios y reinicie Docker Desktop.

Verifique la inicialización de los contenedores Docker, Compose, AMD64 y docker exec:

docker version
docker compose version
docker run --rm --platform linux/amd64 alpine:3.21 uname -m
docker run -d --name amd64-exec-test --platform linux/amd64 alpine:3.21 sleep 60
docker exec amd64-exec-test uname -m
docker rm -f amd64-exec-test

Ambos comandos deben devolver x86_64. Si el inicio del contenedor o docker exec devuelve exec format error, verifique dos veces el administrador de máquina virtual de Docker Desktop y la configuración de Rosetta antes de iniciar la práctica de laboratorio MQ.

Menú

Replicación entre regiones de IBM MQ en la práctica

1. Qué construye este laboratorio

2. Requisitos y limitaciones importantes

3. Cree la carpeta del laboratorio y descargue IBM MQ

4. Por qué utilizamos TLS en el laboratorio

5. Cree las dos configuraciones nativas HA

6. Cree la configuración del objeto MQ

7. Cree la topología Docker Compose

8. Inicie el grupo London Live

9. Inicie el grupo Recovery Rome

10. Confirmar replicación protegida por TLS

11. Colocar un mensaje persistente en Londres

12. Ejecute una transición CRR planificada

13. Demuestre que el mensaje fue propagado

14. Regreso a Londres (estado inicial)

15. ¿Por qué este laboratorio no fuerza una conmutación por error no planificada?

16. Solución de problemas

El comando de estado `-g` no muestra nada

Un contenedor termina durante la inicialización

Los grupos permanecen desconectados

Un grupo no alcanza el quórum

Un cambio de rol no surte efecto

Empezar de nuevo desde un estado limpio

17. Lo que demuestra el laboratorio

18. Procedimiento de limpieza

Apéndice A. Instalación de Docker y Docker Compose

Motor Docker Linux

Escritorio Docker en macOS

Documentación útil

Más en esta área

Replicación entre regiones de IBM MQ en la práctica

1. Qué construye este laboratorio

2. Requisitos y limitaciones importantes

3. Cree la carpeta del laboratorio y descargue IBM MQ

4. Por qué utilizamos TLS en el laboratorio

5. Cree las dos configuraciones nativas HA

6. Cree la configuración del objeto MQ

7. Cree la topología Docker Compose

8. Inicie el grupo London Live

9. Inicie el grupo Recovery Rome

10. Confirmar replicación protegida por TLS

11. Colocar un mensaje persistente en Londres

12. Ejecute una transición CRR planificada

13. Demuestre que el mensaje fue propagado

14. Regreso a Londres (estado inicial)

15. ¿Por qué este laboratorio no fuerza una conmutación por error no planificada?

16. Solución de problemas

El comando de estado -g no muestra nada

Un contenedor termina durante la inicialización

Los grupos permanecen desconectados

Un grupo no alcanza el quórum

Un cambio de rol no surte efecto

Empezar de nuevo desde un estado limpio

17. Lo que demuestra el laboratorio

18. Procedimiento de limpieza

Apéndice A. Instalación de Docker y Docker Compose

Motor Docker Linux

Escritorio Docker en macOS

Documentación útil

Más en esta área

Artículos de IBM MQ

El comando de estado `-g` no muestra nada