Déployer un cluster de gestionnaires de files d'attente IBM MQ à disponibilité élevée sur Compute Engine avec GlusterFS

Ce tutoriel vous guide tout au long du processus de déploiement d'un cluster de gestionnaires de files d'attente IBM MQ à disponibilité élevée à l'aide de Compute Engine sur Google Cloud. MQ transporte les données entre ces points via un système de mise en file d'attente qui assure la distribution en cas de défaillance du réseau ou de l'application.

Ce tutoriel est utile si vous êtes un architecte d'entreprise, un administrateur système, un développeur ou un ingénieur DevOps qui souhaite déployer un cluster de gestionnaires de files d'attente IBM MQ à disponibilité élevée sur Google Cloud.

Pour ce tutoriel, nous partons du principe que vous connaissez bien les éléments suivants :

  • Ubuntu Server 16.04
  • IBM MQ
  • Compute Engine
  • Équilibrage de charge des services réseau

Objectifs

  • Créer les instances Compute Engine
  • Créer les règles de pare-feu
  • Créer les équilibreurs de charge internes
  • Configurer le système de fichiers partagé GlusterFS
  • Configurer chaque nœud du cluster
  • Configurer le cluster pour la haute disponibilité
  • Tester le cluster

Coûts

Ce tutoriel utilise des composants facturables de Google Cloud, dont :

  • Compute Engine
  • Mise en réseau

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût.

Avant de commencer

  1. Connectez-vous à votre compte Google.

    Si vous n'en possédez pas déjà un, vous devez en créer un.

  2. Dans Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Cloud.

    Accéder à la page de sélection du projet

  3. Vérifiez que la facturation est activée pour votre projet Google Cloud. Découvrez comment vérifier que la facturation est activée pour votre projet.

  4. Activez Compute Engine API.

    Activer l'API

Une fois que vous avez terminé ce tutoriel, évitez de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Architecture

Pour créer un déploiement hautement disponible et adaptable d'IBM MQ, cette solution combine des clusters de gestionnaires de files d'attente et des gestionnaires de files d'attente multi-instances. Ces derniers s'exécutent dans une configuration avec une instance active et une instance de secours, en partageant les données de configuration et d'état au moyen d'un volume partagé. Les gestionnaires de files d'attente en cluster partagent les informations de configuration via un canal réseau et peuvent équilibrer la charge des messages entrants. Toutefois, l'état des messages n'est pas partagé entre les deux gestionnaires de files d'attente.

En utilisant les deux modèles de déploiement, vous pouvez obtenir une redondance au niveau des gestionnaires de files d'attente, puis procéder au scaling en répartissant la charge sur un ou plusieurs gestionnaires de files d'attente.

Dans ce tutoriel, vous allez créer deux gestionnaires de files d'attente, appelés A et B. Pour chaque gestionnaire de files d'attente, créez un nœud principal et un nœud de secours (mq-1 et mq-2 pour le gestionnaire de files d'attente A, et mq-3 et mq-4 pour le gestionnaire de files d'attente B). Afin d'acheminer le trafic vers les instances principales, vous utilisez des équilibreurs de charge internes, un pour chaque gestionnaire de files d'attente. Les clients et les éditeurs sont dirigés vers les adresses de l'équilibreur de charge comme s'il s'agissait des adresses directes des gestionnaires de files d'attente. Les gestionnaires de files d'attente communiquent également entre eux via les équilibreurs de charge internes.

Les gestionnaires de files d'attente IBM MQ multi-instances nécessitent un espace de stockage partagé. Dans ce tutoriel, vous utilisez GlusterFS, un système de fichiers distribué et adaptable, en tant que système de fichiers partagé entre les nœuds de chaque gestionnaire de files d'attente multi-instance.

Architecture du système multi-instance MQ

Créer les instances Compute Engine

Créez maintenant les ressources de calcul requises dans le cadre de ce tutoriel. Les instances Compute Engine mq-1 et mq-2 seront respectivement le nœud principal et le nœud de secours du gestionnaire de files d'attente A, et mq-3 et mq-4 seront respectivement le nœud principal et le nœud de secours du gestionnaire de files d'attente B. Vous devez également créer des groupes d'instances non gérés pour chaque instance, car elles se trouvent dans des zones différentes. Vous associerez ces groupes à l'équilibreur de charge ultérieurement.

  1. Ouvrez Cloud Shell.

    Accéder à Cloud Shell

  2. Créez un script de démarrage pour les instances de calcul MQ :

    cat << 'EOF' >  mqstartup.sh
    #!/bin/bash
    
    if [ -f /root/INSTALLATION_DONE ]; then
      echo "Skipping because installation completed."
      exit 0
    fi
    
    # Docker installation
    
    apt-get install -y apt-transport-https ca-certificates curl software-properties-common
    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
    add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
    apt-get update
    apt-get install -y docker-ce
    
    # GlusterFS installation
    
    apt-get install -y glusterfs-server
    
    # Format and mount the persistent disk
    
    mkdir -p /data
    mkfs.ext4 -m 0 -F -E lazy_itable_init=0,lazy_journal_init=0,discard /dev/sdb
    mount -o discard,defaults /dev/sdb /data
    
    touch /root/INSTALLATION_DONE
    EOF
    
  3. Créez une instance Compute Engine pour le nœud principal du gestionnaire de files d'attente A :

    gcloud compute instances create mq-1 \
        --zone=us-central1-c \
        --machine-type=n1-standard-1 \
        --image-family=ubuntu-1604-lts \
        --image-project=ubuntu-os-cloud \
        --boot-disk-size=10GB \
        --boot-disk-type=pd-standard \
        --boot-disk-device-name=mq-1 \
        --create-disk=mode=rw,size=10,type=projects/${DEVSHELL_PROJECT_ID}/zones/us-central1-c/diskTypes/pd-ssd,name=gluster-disk-1 \
        --tags=ibmmq \
        --metadata-from-file startup-script=mqstartup.sh
    
  4. Créez un groupe d'instances non géré, puis ajoutez l'instance :

    gcloud compute instance-groups unmanaged create mq-group-1 \
        --zone=us-central1-c
    
    gcloud compute instance-groups unmanaged add-instances mq-group-1 \
        --zone=us-central1-c \
        --instances=mq-1
    
  5. Créez une instance Compute Engine pour le nœud de secours du gestionnaire de files d'attente A :

    gcloud compute instances create mq-2 \
        --zone=us-central1-b \
        --machine-type=n1-standard-1 \
        --image-family=ubuntu-1604-lts \
        --image-project=ubuntu-os-cloud \
        --boot-disk-size=10GB \
        --boot-disk-type=pd-standard \
        --boot-disk-device-name=mq-2 \
        --create-disk=mode=rw,size=10,type=projects/${DEVSHELL_PROJECT_ID}/zones/us-central1-b/diskTypes/pd-ssd,name=gluster-disk-2 \
        --tags=ibmmq \
        --metadata-from-file startup-script=mqstartup.sh
    
  6. Créez un groupe d'instances non géré, puis ajoutez l'instance :

    gcloud compute instance-groups unmanaged create mq-group-2 \
        --zone=us-central1-b
    
    gcloud compute instance-groups unmanaged add-instances mq-group-2 \
        --zone=us-central1-b \
        --instances=mq-2
    
  7. Créez une instance Compute Engine pour le nœud principal du gestionnaire de files d'attente B :

    gcloud compute instances create mq-3 \
        --zone=us-central1-a \
        --machine-type=n1-standard-1 \
        --image-family=ubuntu-1604-lts \
        --image-project=ubuntu-os-cloud \
        --boot-disk-size=10GB \
        --boot-disk-type=pd-standard \
        --boot-disk-device-name=mq-3 \
        --create-disk=mode=rw,size=10,type=projects/${DEVSHELL_PROJECT_ID}/zones/us-central1-a/diskTypes/pd-ssd,name=gluster-disk-3 \
        --tags=ibmmq \
        --metadata-from-file startup-script=mqstartup.sh
    
  8. Créez un groupe d'instances non géré, puis ajoutez l'instance :

    gcloud compute instance-groups unmanaged create mq-group-3 \
        --zone=us-central1-a
    
    gcloud compute instance-groups unmanaged add-instances mq-group-3 \
        --zone=us-central1-a \
        --instances=mq-3
    
  9. Créez une instance Compute Engine pour le nœud de secours du gestionnaire de files d'attente B :

    gcloud compute instances create mq-4 \
        --zone=us-central1-f \
        --machine-type=n1-standard-1 \
        --image-family=ubuntu-1604-lts \
        --image-project=ubuntu-os-cloud \
        --boot-disk-size=10GB \
        --boot-disk-type=pd-standard \
        --boot-disk-device-name=mq-4 \
        --create-disk=mode=rw,size=10,type=projects/${DEVSHELL_PROJECT_ID}/zones/us-central1-f/diskTypes/pd-ssd,name=gluster-disk-4 \
        --tags=ibmmq \
        --metadata-from-file startup-script=mqstartup.sh
    
  10. Créez un groupe d'instances non géré, puis ajoutez l'instance :

    gcloud compute instance-groups unmanaged create mq-group-4 \
        --zone=us-central1-f
    
    gcloud compute instance-groups unmanaged add-instances mq-group-4 \
        --zone=us-central1-f \
        --instances=mq-4
    

Créer les règles de pare-feu

Pour que les nœuds du cluster puissent communiquer entre eux et recevoir le trafic de l'équilibreur de charge, vous devez créer les règles de pare-feu appropriées.

  1. Créez une règle de pare-feu pour autoriser le trafic entre les nœuds du cluster :

    gcloud compute firewall-rules create ibmmq-transport \
        --allow=tcp:1414 \
        --target-tags ibmmq \
        --source-tags ibmmq
    
  2. Créez une règle de pare-feu pour autoriser le trafic des vérificateurs d'état vers les gestionnaires de files d'attente :

    gcloud compute firewall-rules create fw-allow-health-checks \
        --allow=tcp:1414 \
        --target-tags ibmmq \
        --source-ranges 35.191.0.0/16,130.211.0.0/22
    

Configurer l'équilibreur de charge TCP interne

Créez maintenant l'équilibreur de charge interne qui surveille les quatre instances pour déterminer les deux instances principales opérationnelles et acheminer le trafic vers celles-ci.

  1. Créez la vérification d'état :

    gcloud compute health-checks create tcp hc-tcp-1414 \
        --description="Health check: TCP 1414" \
        --check-interval=2s \
        --timeout=2s \
        --healthy-threshold=2 \
        --unhealthy-threshold=2 \
        --port=1414
    
  2. Créez les services de backend :

    gcloud compute backend-services create mqm-svc-a \
        --load-balancing-scheme internal \
        --region us-central1 \
        --health-checks hc-tcp-1414 \
        --protocol tcp
    
    gcloud compute backend-services create mqm-svc-b \
        --load-balancing-scheme internal \
        --region us-central1 \
        --health-checks hc-tcp-1414 \
        --protocol tcp
    
  3. Ajoutez les groupes d'instances non gérés aux services de backend :

    gcloud compute backend-services add-backend mqm-svc-a \
        --instance-group mq-group-1 \
        --instance-group-zone us-central1-c \
        --region us-central1
    
    gcloud compute backend-services add-backend mqm-svc-a \
        --instance-group mq-group-2 \
        --instance-group-zone us-central1-b \
        --region us-central1
    
    gcloud compute backend-services add-backend mqm-svc-b \
        --instance-group mq-group-3 \
        --instance-group-zone us-central1-a \
        --region us-central1
    
    gcloud compute backend-services add-backend mqm-svc-b \
        --instance-group mq-group-4 \
        --instance-group-zone us-central1-f \
        --region us-central1
    
  4. Créez la règle de transfert :

    gcloud compute forwarding-rules create mqm-svc-a-forwarding-rule \
        --load-balancing-scheme internal \
        --ports 1414 --network default \
        --address 10.128.0.100 \
        --region us-central1 \
        --backend-service mqm-svc-a
    
    gcloud compute forwarding-rules create mqm-svc-b-forwarding-rule \
        --load-balancing-scheme internal \
        --ports 1414 \
        --network default \
        --address 10.128.0.101 \
        --region us-central1 \
        --backend-service mqm-svc-b
    

Créer et installer le volume GlusterFS pour le gestionnaire de files d'attente A

Dans ce tutoriel, vous utilisez le système de fichiers distribué GlusterFS en tant qu'espace de stockage partagé entre les nœuds d'un gestionnaire de files d'attente. Vous allez maintenant configurer GlusterFS pour le gestionnaire de files d'attente A en le déployant sur les instances mq-1 et mq-2.

  1. Initialisez le pool de confiance GlusterFS sur mq-1 en vérifiant mq-2 :

    gcloud compute ssh mq-1 \
        --zone=us-central1-c \
        --command='sudo mkdir -p /data/gv0 && sudo gluster peer probe mq-2' \
        -- -t
    
  2. Initialisez le pool de confiance GlusterFS sur mq-2 en vérifiant mq-1 :

    gcloud compute ssh mq-2 \
        --zone=us-central1-b \
        --command='sudo mkdir -p /data/gv0 && sudo gluster peer probe mq-1' \
        -- -t
    
  3. Démarrez la réplication de GlusterFS :

    gcloud compute ssh mq-2 \
        --zone=us-central1-b \
        --command='sudo gluster volume create mq-data replica 2 mq-1:/data/gv0 mq-2:/data/gv0 && sudo gluster volume start mq-data' \
        -- -t
    
  4. Montez le volume partagé sur mq-2 :

    gcloud compute ssh mq-2 \
        --zone=us-central1-b \
        --command='sudo mkdir -p /mnt/mqm_glusterfs && sudo mount -t glusterfs mq-1:/mq-data /mnt/mqm_glusterfs' \
        -- -t
    
  5. Montez le volume partagé sur mq-1 :

    gcloud compute ssh mq-1 \
        --zone=us-central1-c \
        --command='sudo mkdir -p /mnt/mqm_glusterfs && sudo mount -t glusterfs mq-1:/mq-data /mnt/mqm_glusterfs' \
        -- -t
    
  6. Vérifiez l'état du volume partagé :

    gcloud compute ssh mq-1 \
        --zone=us-central1-c \
        --command='sudo gluster volume info'
    

    À l'exception de l'ID du volume, le résultat est semblable à ce qui suit :

    Volume Name: mq-data
    Type: Replicate
    Volume ID: ad63f6df-8469-4f30-9282-5a285d1a2b87
    Status: Started
    Number of Bricks: 1 x 2 = 2
    Transport-type: tcp
    Bricks:
    Brick1: mq-1:/data/gv0
    Brick2: mq-2:/data/gv0
    Options Reconfigured:
    performance.readdir-ahead: on
    

Créer et installer le volume GlusterFS pour le gestionnaire de files d'attente B

Vous allez maintenant configurer GlusterFS pour le gestionnaire de files d'attente B en le déployant sur les instances mq-3 et mq-4.

  1. Initialisez le pool de confiance GlusterFS sur mq-3 en vérifiant mq-4 :

    gcloud compute ssh mq-3 \
        --zone=us-central1-a \
        --command='sudo mkdir -p /data/gv0 && sudo gluster peer probe mq-4' \
        -- -t
    
  2. Initialisez le pool de confiance GlusterFS sur mq-4 en vérifiant mq-3 :

    gcloud compute ssh mq-4 \
        --zone=us-central1-f \
        --command='sudo mkdir -p /data/gv0 && sudo gluster peer probe mq-3' \
        -- -t
    
  3. Démarrez la réplication de GlusterFS :

    gcloud compute ssh mq-4 \
        --zone=us-central1-f \
        --command='sudo gluster volume create mq-data replica 2 mq-3:/data/gv0 mq-4:/data/gv0 && sudo gluster volume start mq-data' \
        -- -t
    
  4. Montez le volume partagé sur mq-4 :

    gcloud compute ssh mq-4 \
        --zone=us-central1-f \
        --command='sudo mkdir -p /mnt/mqm_glusterfs && sudo mount -t glusterfs mq-3:/mq-data /mnt/mqm_glusterfs' \
        -- -t
    
  5. Montez le volume partagé sur mq-3 :

    gcloud compute ssh mq-3 \
        --zone=us-central1-a \
        --command='sudo mkdir -p /mnt/mqm_glusterfs && sudo mount -t glusterfs mq-3:/mq-data /mnt/mqm_glusterfs' \
        -- -t
    
  6. Vérifiez l'état du volume partagé :

    gcloud compute ssh mq-3 \
        --zone=us-central1-a \
        --command='sudo gluster volume info'
    

    À l'exception de l'ID du volume, le résultat suivant s'affiche :

    Volume Name: mq-data
    Type: Replicate
    Volume ID: ad63f6df-8469-4f30-9282-5a285d1a2b87
    Status: Started
    Number of Bricks: 1 x 2 = 2
    Transport-type: tcp
    Bricks:
    Brick1: mq-3:/data/gv0
    Brick2: mq-4:/data/gv0
    Options Reconfigured:
    performance.readdir-ahead: on
    

Initialiser le gestionnaire de files d'attente A

Vous allez maintenant exécuter une série de commandes sur mq-1. Celles-ci définissent le nom du gestionnaire de files d'attente, l'espace de stockage partagé, les canaux de communication entrant et sortant, l'authentification et l'autre gestionnaire de files d'attente se trouvant dans le cluster.

  1. Dans Cloud Shell, exécutez un conteneur MQ temporaire sur mq-1, puis connectez-vous à celui-ci :

    gcloud compute ssh mq-1 \
        --zone=us-central1-c \
        --command='sudo docker run -it --entrypoint=/bin/bash --env LICENSE=accept --env MQ_QMGR_NAME=A --volume /mnt/mqm_glusterfs:/mnt/mqm --network host --name=ibmmq-init --rm=true  ibmcom/mq:latest ' \
       -- -t
    
  2. Saisissez les définitions de cluster et de file d'attente :

    mkdir -p /mnt/mqm/data
    chown mqm:mqm /mnt/mqm/data
    /opt/mqm/bin/crtmqdir -f -s
    su mqm -c "cp /etc/mqm/web/installations/Installation1/servers/mqweb/*.xml /var/mqm/web/installations/Installation1/servers/mqweb/"
    su mqm -c "crtmqm -q -p 1414 $MQ_QMGR_NAME"
    su mqm -c "strmqm -x"
    
  3. Configurez le gestionnaire de files d'attente A pour le clustering :

    echo "
    * Define the full repository for the cluster
    ALTER QMGR REPOS(GCP)
    
    * Define backstop rule for channel auth
    SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) DESCR('Back-stop rule - Blocks everyone') ACTION(REPLACE)
    
    * Clustering channels and listeners
    DEFINE LISTENER(A_LS) TRPTYPE(TCP) CONTROL(QMGR)
    
    DEFINE CHANNEL(GCP.A) CHLTYPE(CLUSRCVR) CONNAME('10.128.0.100') CLUSTER(GCP) REPLACE
    DEFINE CHANNEL(GCP.B) CHLTYPE(CLUSSDR) CONNAME('10.128.0.101') CLUSTER(GCP) REPLACE
    
    SET CHLAUTH('GCP.A') TYPE (QMGRMAP) QMNAME(B) USERSRC(CHANNEL) ADDRESS('*')" | runmqsc $MQ_QMGR_NAME
    
  4. Configurez la file d'attente, le canal et l'autorisation de l'application :

    echo "
    * Application queues
    DEFINE QLOCAL('APP.QUEUE.1') DEFBIND(NOTFIXED) CLWLUSEQ(ANY) CLUSTER(GCP) REPLACE
    
    * Application topics
    DEFINE TOPIC('APP.BASE.TOPIC') TOPICSTR('app/') REPLACE
    
    * Application connection authentication
    DEFINE AUTHINFO('APP.AUTHINFO') AUTHTYPE(IDPWOS) CHCKCLNT(REQDADM) CHCKLOCL(OPTIONAL) ADOPTCTX(YES) REPLACE
    ALTER QMGR CONNAUTH('APP.AUTHINFO')
    REFRESH SECURITY(*) TYPE(CONNAUTH)
    
    * Application channels
    DEFINE CHANNEL('APP.SVRCONN') CHLTYPE(SVRCONN) MCAUSER('app') REPLACE
    SET CHLAUTH('APP.SVRCONN') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(CHANNEL) CHCKCLNT(REQUIRED) DESCR('Allows connection via APP channel') ACTION(REPLACE)
    
    * Application auth records
    SET AUTHREC GROUP('mqclient') OBJTYPE(QMGR) AUTHADD(CONNECT,INQ)
    SET AUTHREC PROFILE('APP.**') GROUP('mqclient') OBJTYPE(QUEUE) AUTHADD(BROWSE,GET,INQ,PUT)
    SET AUTHREC PROFILE('APP.**') GROUP('mqclient') OBJTYPE(TOPIC) AUTHADD(PUB,SUB)" | runmqsc $MQ_QMGR_NAME
    
    exit
    

Initialiser le gestionnaire de files d'attente B

Vous allez maintenant exécuter une série de commandes semblables sur mq-3. Celles-ci définissent les mêmes informations pour le second gestionnaire de files d'attente, à savoir son nom, l'espace de stockage partagé, les canaux de communication entrant et sortant, l'authentification et l'autre gestionnaire de files d'attente se trouvant dans le cluster.

  1. Dans Cloud Shell, exécutez un conteneur MQ temporaire sur mq-3, puis connectez-vous à celui-ci :

    gcloud compute ssh  mq-3 \
        --zone=us-central1-a \
        --command='sudo docker run -it --entrypoint=/bin/bash --env LICENSE=accept --env MQ_QMGR_NAME=B --volume /mnt/mqm_glusterfs:/mnt/mqm --network host --name=ibmmq-init --rm=true ibmcom/mq:latest' \
        -- -t
    
  2. Saisissez les définitions de cluster et de file d'attente. (Il s'agit de la version consolidée des étapes 2 à 4 de la procédure que vous avez exécutée pour le gestionnaire de files d'attente A.)

    mkdir -p /mnt/mqm/data
    chown mqm:mqm /mnt/mqm/data
    /opt/mqm/bin/crtmqdir -f -s
    su mqm -c "cp /etc/mqm/web/installations/Installation1/servers/mqweb/*.xml /var/mqm/web/installations/Installation1/servers/mqweb/"
    su mqm -c "crtmqm -q -p 1414 $MQ_QMGR_NAME"
    su mqm -c "strmqm -x"
    
    echo "
    * Define the full repository for the cluster
    ALTER QMGR REPOS(GCP)
    
    * Define backstop rule for channel auth
    SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) DESCR('Back-stop rule - Blocks everyone') ACTION(REPLACE)
    
    * Clustering channels and listeners
    DEFINE LISTENER(B_LS) TRPTYPE(TCP) CONTROL(QMGR)
    
    DEFINE CHANNEL(GCP.B) CHLTYPE(CLUSRCVR) CONNAME('10.128.0.101') CLUSTER(GCP) REPLACE
    DEFINE CHANNEL(GCP.A) CHLTYPE(CLUSSDR) CONNAME('10.128.0.100') CLUSTER(GCP) REPLACE
    
    SET CHLAUTH('GCP.B') TYPE (QMGRMAP) QMNAME(A) USERSRC(CHANNEL) ADDRESS('*')
    
    * Application queues
    DEFINE QLOCAL('APP.QUEUE.1') DEFBIND(NOTFIXED) CLWLUSEQ(ANY) CLUSTER(GCP) REPLACE
    
    * Application topics
    DEFINE TOPIC('APP.BASE.TOPIC') TOPICSTR('app/') REPLACE
    
    * Application connection authentication
    DEFINE AUTHINFO('APP.AUTHINFO') AUTHTYPE(IDPWOS) CHCKCLNT(REQDADM) CHCKLOCL(OPTIONAL) ADOPTCTX(YES) REPLACE
    ALTER QMGR CONNAUTH('APP.AUTHINFO')
    REFRESH SECURITY(*) TYPE(CONNAUTH)
    
    * Application channels
    DEFINE CHANNEL('APP.SVRCONN') CHLTYPE(SVRCONN) MCAUSER('app') REPLACE
    SET CHLAUTH('APP.SVRCONN') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(CHANNEL) CHCKCLNT(REQUIRED) DESCR('Allows connection via APP channel') ACTION(REPLACE)
    
    * Application auth records
    SET AUTHREC GROUP('mqclient') OBJTYPE(QMGR) AUTHADD(CONNECT,INQ)
    SET AUTHREC PROFILE('APP.**') GROUP('mqclient') OBJTYPE(QUEUE) AUTHADD(BROWSE,GET,INQ,PUT)
    SET AUTHREC PROFILE('APP.**') GROUP('mqclient') OBJTYPE(TOPIC) AUTHADD(PUB,SUB)" | runmqsc $MQ_QMGR_NAME
    
    exit
    

Démarrer IBM MQ en mode haute disponibilité

Maintenant que les gestionnaires de files d'attente sont initialisés, vous pouvez démarrer le cluster IBM MQ.

  1. Dans Cloud Shell, démarrez le gestionnaire de files d'attente A sur mq-1 :

    gcloud compute ssh  mq-1  \
        --zone=us-central1-c \
        --command="sudo docker run -it --entrypoint=/bin/bash --env LICENSE=accept --env MQ_QMGR_NAME=A  --volume /mnt/mqm_glusterfs:/mnt/mqm --publish 1414:1414 --network host --name=ibmmq-node --rm=true -d ibmcom/mq:latest -c 'echo app:APPPass1! | chpasswd && su mqm -c \"strmqm -x\"; tail -f /dev/null'"
    

    Pour les besoins de ce tutoriel, dans cette commande, définissez AppPass1! comme mot de passe pour l'application utilisateur.

  2. Démarrez le gestionnaire de files d'attente A sur mq-2 :

    gcloud compute ssh  mq-2  \
        --zone=us-central1-b \
        --command="sudo docker run -it --entrypoint=/bin/bash --env LICENSE=accept --env MQ_QMGR_NAME=A --volume /mnt/mqm_glusterfs:/mnt/mqm --publish 1414:1414 --network host --name=ibmmq-node --rm=true -d ibmcom/mq:latest -c 'echo app:APPPass1! | chpasswd && su mqm -c \"strmqm -x\"; tail -f /dev/null'"
    

    Dans cette commande, définissez AppPass1! comme mot de passe pour l'application utilisateur.

  3. Pour vérifier l'état de votre équilibreur de charge, accédez à la page Load balancing (Équilibrage de charge) dans Cloud Console.

    ACCÉDER À LA PAGE "ÉQUILIBRAGE DE CHARGE"

  4. Dans la liste, sélectionnez l'équilibreur de charge mqm-svc-a.

    Page de la console relative aux équilibreurs de charge, montrant mq-group1 et mq-group2

    Lorsque l'équilibreur de charge mqm-svc-a indique qu'il dispose d'un groupe d'instances opérationnel (comme illustré dans la capture d'écran ci-dessus), vous êtes prêt à passer à l'étape suivante.

  5. Dans Cloud Shell, démarrez le gestionnaire de files d'attente B sur mq-3 :

    gcloud compute ssh mq-3 \
        --zone=us-central1-a \
        --command="sudo docker run -it --entrypoint=/bin/bash --env LICENSE=accept --env MQ_QMGR_NAME=B --volume /mnt/mqm_glusterfs:/mnt/mqm --publish 1414:1414 --network host --name=ibmmq-node --rm=true -d ibmcom/mq:latest -c 'echo app:APPPass1! | chpasswd && su mqm -c \"strmqm -x\"; tail -f /dev/null'"
    
  6. Démarrez le gestionnaire de files d'attente B sur mq-4 :

    gcloud compute ssh mq-4 \
        --zone=us-central1-f \
        --command="sudo docker run -it --entrypoint=/bin/bash --env LICENSE=accept --env MQ_QMGR_NAME=B --volume /mnt/mqm_glusterfs:/mnt/mqm --publish 1414:1414 --network host --name=ibmmq-node --rm=true -d ibmcom/mq:latest -c 'echo app:APPPass1! | chpasswd && su mqm -c \"strmqm -x\"; tail -f /dev/null'"
    

Vérifier le cluster

Avant de tester votre déploiement, vous devez vous assurer que les gestionnaires de files d'attente A et B communiquent correctement.

  1. Dans Cloud Shell, connectez-vous au conteneur IBM MQ sur mq-3 :

    gcloud compute ssh mq-3 \
        --zone=us-central1-a \
        --command="sudo docker exec -it ibmmq-node /bin/bash" \
        -- -t
    
  2. Vérifiez l'état des canaux de communication du cluster :

    echo "DISPLAY CHSTATUS(*)" | runmqsc $MQ_QMGR_NAME && exit
    

    Si tout fonctionne correctement, le résultat ressemble à ceci :

    5724-H72 (C) Copyright IBM Corp. 1994, 2018.
    Starting MQSC for queue manager B.
    
         1 : display chstatus(*)
    AMQ8417I: Display Channel Status details.
       CHANNEL(GCP.B)                          CHLTYPE(CLUSRCVR)
       CONNAME(10.128.0.2)                     CURRENT
       RQMNAME(A)                              STATUS(RUNNING)
       SUBSTATE(RECEIVE)
    AMQ8417I: Display Channel Status details.
       CHANNEL(GCP.A)                          CHLTYPE(CLUSSDR)
       CONNAME(10.128.0.100(1414))             CURRENT
       RQMNAME(A)                              STATUS(RUNNING)
       SUBSTATE(MQGET)           XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
    One MQSC command read.
    No commands have a syntax error.
    All valid MQSC commands were processed.
    

Envoyer des messages au cluster

Vous allez maintenant tester le cluster. Pour ce faire, envoyez deux messages à une file d'attente nommée APP.QUEUE.1 à l'aide de l'exemple d'application fourni par IBM dans l'image Docker.

Envoyer des messages de test au gestionnaire de files d'attente B

  1. Dans Cloud Shell, connectez-vous au conteneur IBM MQ sur mq-3 :

    gcloud compute ssh mq-3 \
        --zone=us-central1-a \
        --command="sudo docker exec -it ibmmq-node /bin/bash" \
        -- -t
    
  2. Dans l'interface système du terminal, lancez l'application émettrice du message se connectant au gestionnaire de files d'attente B :

    MQSAMP_USER_ID=app /opt/mqm/samp/bin/amqsput APP.QUEUE.1 B
    
  3. Lorsque vous y êtes invité, authentifiez-vous en saisissant le mot de passe d'application que vous avez créé précédemment (APPPass1! dans ce tutoriel).

  4. Lorsque le texte target queue is APP.QUEUE.1 (la file d'attente cible est APP.QUEUE.1) s'affiche, envoyez un message de test à la file d'attente en saisissant abcdef.

  5. Envoyez un autre message de test en saisissant 123456.

  6. Appuyez sur Entrée pour quitter l'application émettrice du message.

    La sortie ressemble à ceci :

    Sample AMQSPUT0 start
    Enter password: *********
    target queue is APP.QUEUE.1
    abcdef
    123456
    
    Sample AMQSPUT0 end
    
  7. Vérifiez qu'un message est en cours de transfert dans le gestionnaire de files d'attente B :

    echo "display qstatus(APP.QUEUE.1)" | runmqsc $MQ_QMGR_NAME | grep CURDEPTH
    

    Un seul message est en cours de transfert, car l'équilibrage de charge IBM MQ a acheminé l'autre message vers le gestionnaire de files d'attente A, comme décrit plus bas.

  8. Fermez la connexion SSH :

    exit
    

    Le résultat suivant s'affiche :

    CURDEPTH(1)                             IPPROCS(0)
    

    Un seul message est en cours de transfert dans le gestionnaire de files d'attente B, même si vous avez envoyé deux messages à l'étape précédente. Cela est dû au fait qu'IBM MQ équilibre la charge des messages entre les gestionnaires de files d'attente et que le second message a été envoyé au gestionnaire de files d'attente A.

Vérifier les messages en cours de transfert dans le gestionnaire de files d'attente A

  1. Dans Cloud Shell, connectez-vous au conteneur IBM MQ sur mq-1 :

    gcloud compute ssh mq-1 \
        --zone=us-central1-c \
        --command="sudo docker exec -it ibmmq-node /bin/bash" \
        -- -t
    
  2. Dans la fenêtre du terminal, vérifiez qu'un message est en cours de transfert dans le gestionnaire de files d'attente A :

    echo "display qstatus(APP.QUEUE.1)" | runmqsc $MQ_QMGR_NAME | grep CURDEPTH
    

    Le résultat suivant s'affiche :

    CURDEPTH(1)                             IPPROCS(0)
    

Tester la haute disponibilité des gestionnaires de files d'attente

Vous allez maintenant arrêter l'instance mq-3, puis vérifier que mq-4 devient bien l'instance principale du gestionnaire de files d'attente B.

  1. Dans Cloud Shell, arrêtez l'instance mq-3 :

    gcloud compute instances stop mq-3 \
        --zone=us-central1-a
    
  2. Vérifiez que l'instance mq-4 est devenue l'instance principale. Pour ce faire, vérifiez qu'elle est opérationnelle du point de vue de l'équilibreur de charge :

    gcloud compute backend-services get-health mqm-svc-b \
        --region=us-central1
    

    Un résultat semblable à celui-ci s'affiche :

    backend: https://www.googleapis.com/compute/v1/projects/ibmmq1/zones/us-central1-a/instanceGroups/mq-group-3
    status:
          kind: compute#backendServiceGroupHealth---backend: https://www.googleapis.com/compute/v1/projects/ibmmq1/zones/us-central1-f/instanceGroups/mq-group-4
    status:
          healthStatus:
        - healthState: HEALTHY
        instance: https://www.googleapis.com/compute/v1/projects/ibmmq1/zones/us-central1-f/instances/mq-4
        ipAddress: 10.128.0.5
        port: 80
        kind: compute#backendServiceGroupHealth
    

Passer à l'environnement de production

Dans ce tutoriel, vous avez utilisé IBM MQ Advanced for Developers. Avant de passer à l'environnement de production, examinez les autres licences et ensembles de fonctionnalités disponibles. Avant le déploiement en production, vous devez également consulter la documentation d'IBM sur l'exécution d'IBM MQ dans un conteneur.

Effectuer un nettoyage

Une fois que vous avez terminé ce tutoriel, vous pouvez procéder au nettoyage des ressources que vous avez créées sur Google Cloud afin qu'elles ne soient plus comptabilisées dans votre quota et qu'elles ne vous soient plus facturées. Dans les sections suivantes, nous allons voir comment supprimer ou désactiver ces ressources.

Supprimer le projetfrontend servers

  1. Dans Cloud Console, accédez à la page Gérer les ressources.

    Accéder à la page Gérer les ressources

  2. Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer .
  3. Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

Étapes suivantes