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

Utilisez le simulateur de coût pour générer une estimation des coûts en fonction de votre utilisation prévue.

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 Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

   Remarque : Si vous ne comptez pas conserver les ressources créées dans cette procédure, créez un projet au lieu de sélectionner un projet existant. Après avoir suivi ces étapes, vous pouvez supprimer le projet. Cela entraîne la suppression de toutes les ressources qui lui sont associées.

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

3. Assurez-vous que la facturation est activée pour votre projet 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.

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 Équilibrage de charge dans Cloud Console.

   OUVRIR LA PAGE "ÉQUILIBRAGE DE CHARGE"

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

   

   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 projet

Attention : La suppression d'un projet aura les effets suivants :
• Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour ce tutoriel et que vous le supprimez, vous supprimerez également tout autre travail effectué dans le projet.
• Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé que vous souhaitez utiliser à l'avenir. Pour conserver les URL qui utilisent l'ID de projet, telle qu'une URL appspot.com, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'ensemble du projet.
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.

Étape suivante

• Apprenez-en plus sur IBM MQ.
• Découvrez les configurations haute disponibilité d'IBM MQ.
• Apprenez-en plus sur les équilibreurs de charge internes.
• Obtenez davantage d'informations sur GlusterFS.
• Testez d'autres fonctionnalités de Google Cloud. Découvrez nos tutoriels.