Hochverfügbaren IBM MQ-Warteschlangenmanagercluster in Compute Engine mit GlusterFS bereitstellen

In dieser Anleitung wird beschrieben, wie Sie einen hochverfügbaren IBM MQ-Warteschlangenmanagercluster mit Compute Engine in Google Cloud bereitstellen. MQ transportiert Daten zwischen diesen Punkten über ein Warteschlangensystem, das die Zustellung im Falle eines Netzwerk- oder Anwendungsfehlers gewährleistet.

Diese Anleitung ist nützlich, wenn Sie ein Unternehmensarchitekt, Systemadministrator, Entwickler oder Devops-Entwickler sind und einen hochverfügbaren IBM MQ-Warteschlangenmanagercluster in Google Cloud erstellen möchten.

Für diese Anleitung wird vorausgesetzt, dass Sie mit den folgenden Themen vertraut sind:

• Ubuntu-Server 16.04
• IBM MQ
• Compute Engine
• Load-Balancing für Netzwerkdienste

Ziele

• Erstellen der Compute Engine-Instanzen
• Erstellen der Firewallregeln
• Erstellen der internen Load-Balancer
• Konfigurieren des freigegebenen GlusterFS-Dateisystems
• Konfigurieren der einzelnen Knoten des Clusters
• Konfigurieren des Clusters für Hochverfügbarkeit
• Testen des Clusters

Kosten

In dieser Anleitung werden kostenpflichtige Komponenten von Google Cloud verwendet, darunter:

• Compute Engine
• Netzwerk

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung erstellen.

Hinweise

1. Melden Sie sich bei Ihrem Google-Konto an.

   Wenn Sie noch kein Konto haben, melden Sie sich hier für ein neues Konto an.

2. Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

   Hinweis: Wenn Sie die Ressourcen, die Sie in diesem Verfahren erstellen, nicht behalten möchten, erstellen Sie ein Projekt, anstatt ein vorhandenes Projekt auszuwählen. Wenn Sie fertig sind, können Sie das Projekt löschen und dadurch alle mit dem Projekt verknüpften Ressourcen entfernen.

   Zur Projektauswahl

3. Die Abrechnung für das Cloud-Projekt muss aktiviert sein. So prüfen Sie, ob die Abrechnung für Ihr Projekt aktiviert ist.

4. Aktivieren Sie die Compute Engine API.

   Aktivieren Sie die API

Nach Abschluss dieser Anleitung können Sie weitere Kosten durch Löschen von erstellten Ressourcen vermeiden. Weitere Informationen finden Sie im Abschnitt Bereinigen.

Architektur

Zum Erstellen eines hochverfügbaren und skalierbaren Deployments von IBM MQ kombiniert diese Lösung Warteschlangenmanagercluster mit Multi-Instanz-Warteschlangenmanagern. Diese werden in einer Aktiv/Standby-Konfiguration ausgeführt und verwenden ein freigegebenes Volume, um Konfigurations- und Zustandsdaten freizugeben. Geclusterte Warteschlangenmanager geben Konfigurationsdaten über einen Netzwerkkanal frei und können ein Load-Balancing für eingehende Nachrichten durchführen. Der Nachrichtenstatus wird jedoch nicht zwischen den beiden Warteschlangenmanagern freigegeben.

Wenn beide Deployment-Modelle zusammen verwendet werden, können Sie Redundanz auf der Ebene des Warteschlangenmanagers erreichen und dann durch Verteilung der Last auf einen oder mehrere Warteschlangenmanager skalieren.

In dieser Anleitung erstellen Sie zwei Warteschlangenmanager, die als A und B bezeichnet werden. Für jeden Warteschlangenmanager erstellen Sie einen primären Knoten und einen Stand-by-Knoten (mq-1 und mq-2 für Warteschlangenmanager A, mq-3 und mq-4 für Warteschlangenmanager B). Sie verwenden für jeden Warteschlangenmanager jeweils einen internen Load-Balancer, um Traffic an die primären Instanzen weiterzuleiten. Nutzer und Publisher werden auf die Adressen der Load-Balancer verwiesen. Für sie erscheinen die Adressen als die direkten Adressen der Warteschlangenmanager. Die Warteschlangenmanager kommunizieren miteinander über die internen Load-Balancer.

IBM MQ-Multi-Instanz-Warteschlangenmanager erfordern freigegebenen Speicher. In dieser Anleitung verwenden Sie GlusterFS, ein verteiltes, skalierbares Dateisystem, als freigegebenes Dateisystem zwischen den Knoten jedes Multi-Instanz-Warteschlangenmanagers.

Compute Engine-Instanzen erstellen

Sie erstellen jetzt die für diese Anleitung erforderlichen Computing-Ressourcen. Die Compute Engine-Instanzen mq-1 und mq-2 sind der primäre und der Stand-by-Knoten für den Warteschlangenmanager A. mq-3 und mq-4 sind der primäre und der Stand-by-Knoten für den Warteschlangenmanager B. Da sie sich in verschiedenen Zonen befinden, erstellen Sie für jede Instanz auch nicht verwaltete Instanzgruppen. Sie fügen die nicht verwalteten Instanzgruppen später dem Load-Balancer hinzu.

1. Öffnen Sie Cloud Shell.

   Zu Cloud Shell

2. Erstellen Sie ein Startskript für die MQ-Compute-Instanzen:

   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. Erstellen Sie eine Compute Engine-Instanz für den primären Knoten des Warteschlangenmanagers 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. Erstellen Sie eine nicht verwaltete Instanzgruppe und fügen Sie die Instanz hinzu:

   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. Erstellen Sie eine Compute Engine-Instanz für den Standby-Knoten des Warteschlangenmanagers 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. Erstellen Sie eine nicht verwaltete Instanzgruppe und fügen Sie die Instanz hinzu:

   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. Erstellen Sie eine Compute Engine-Instanz für den primären Knoten des Warteschlangenmanagers 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. Erstellen Sie eine nicht verwaltete Instanzgruppe und fügen Sie die Instanz hinzu:

   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. Erstellen Sie eine Compute Engine-Instanz für den Standby-Knoten des Warteschlangenmanagers 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. Erstellen Sie eine nicht verwaltete Instanzgruppe und fügen Sie die Instanz hinzu:

    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
    

Firewallregeln erstellen

Damit die Knoten im Cluster miteinander kommunizieren und Traffic vom Load-Balancer empfangen können, müssen Sie die entsprechenden Firewallregeln erstellen.

1. Erstellen Sie eine Firewallregel, die Traffic zwischen den Knoten des Clusters zulässt:

   gcloud compute firewall-rules create ibmmq-transport \
       --allow=tcp:1414 \
       --target-tags ibmmq \
       --source-tags ibmmq
   

2. Erstellen Sie eine Firewallregel, die Traffic von den Systemdiagnosen zu den Warteschlangenmanagern zulässt:

   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
   

Internen TCP-Load-Balancer einrichten

Sie erstellen jetzt den internen Load-Balancer, der die vier Instanzen überwacht, um die beiden fehlerfreien primären Instanzen zu ermitteln und den Traffic an sie weiterzuleiten.

1. Erstellen Sie die Systemdiagnose:

   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. Erstellen Sie die Back-End-Dienste:

   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. Fügen Sie den Back-End-Diensten die nicht verwalteten Instanzgruppen hinzu:

   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. Erstellen Sie die Weiterleitungsregel:

   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
   

GlusterFS-Volume für den Warteschlangenmanager A erstellen und bereitstellen

In dieser Anleitung verwenden Sie das verteilte GlusterFS-Dateisystem als zwischen den Knoten eines Warteschlangenmanagers freigegebenen Speicher. Richten Sie jetzt GlusterFS für den Warteschlangenmanager A ein und erstellen Sie es auf den Instanzen mq-1 und mq-2.

1. Initialisieren Sie den vertrauenswürdigen GlusterFS-Pool auf mq-1 und prüfen Sie 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. Initialisieren Sie den vertrauenswürdigen GlusterFS-Pool auf mq-2 und prüfen Sie 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. Starten Sie die GlusterFS-Replikation:

   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. Stellen Sie das freigegebene Volume auf mq-2 bereit:

   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. Stellen Sie das freigegebene Volume auf mq-1 bereit:

   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. Überprüfen Sie den Status des freigegebenen Volumes:

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

   Mit Ausnahme der Volume-ID sieht die Ausgabe so aus:

   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
   

GlusterFS-Volume für den Warteschlangenmanager B erstellen und bereitstellen

Richten Sie jetzt GlusterFS für den Warteschlangenmanager B ein und erstellen Sie es auf den Instanzen mq-3 und mq-4.

1. Initialisieren Sie den vertrauenswürdigen GlusterFS-Pool auf mq-3 und prüfen Sie 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. Initialisieren Sie den vertrauenswürdigen GlusterFS-Pool auf mq-4 und prüfen Sie 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. Starten Sie die GlusterFS-Replikation:

   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. Stellen Sie das freigegebene Volume auf mq-4 bereit:

   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. Stellen Sie das freigegebene Volume auf mq-3 bereit:

   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. Überprüfen Sie den Status des freigegebenen Volumes:

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

   Mit Ausnahme der Volume-ID wird Folgendes ausgegeben:

   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
   

Warteschlangenmanager A initialisieren

Sie führen jetzt eine Reihe von Befehlen auf mq-1 aus, die den Namen des Warteschlangenmanagers, den freigegebenen Speicher, die Kanäle für eingehende und ausgehende Kommunikation, die Authentifizierung und den anderen Warteschlangenmanager im Warteschlangenmanagercluster definieren.

1. Führen Sie in Cloud Shell einen temporären MQ-Container auf mq-1 aus und stellen Sie eine Verbindung zu ihm her:

   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. Geben Sie Cluster- und Warteschlangendefinitionen ein:

   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. Konfigurieren Sie den Warteschlangenmanager A für das Clustern:

   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. Konfigurieren Sie die Anwendungswarteschlange, den Kanal und die Autorisierung:

   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
   

Warteschlangenmanager B initialisieren

Sie führen jetzt eine Reihe von Befehlen auf mq-3 aus, die dieselben Informationen für den zweiten Warteschlangenmanager definieren: den Namen des Warteschlangenmanagers, den freigegebenen Speicher, die Kanäle für eingehende und ausgehende Kommunikation, die Authentifizierung und den anderen Warteschlangenmanager im Warteschlangenmanagercluster.

1. Führen Sie in Cloud Shell einen temporären MQ-Container auf mq-3 aus und stellen Sie eine Verbindung zu ihm her:

   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. Geben Sie Cluster- und Warteschlangendefinitionen ein. (Dies ist eine konsolidierte Version der Schritte 2 bis 4 aus dem Verfahren, das Sie für Warteschlangenmanager A ausgeführt haben.)

   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
   

IBM MQ im Hochverfügbarkeitsmodus starten

Nach der Initialisierung der Warteschlangenmanager können Sie den IBM MQ-Cluster starten.

1. Starten Sie in Cloud Shell den Warteschlangenmanager A auf 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'"
   

   Für diese Anleitung legen Sie in diesem Befehl AppPass1! als Passwort für die Nutzeranwendung fest.

2. Starten Sie den Warteschlangenmanager A auf 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'"
   

   In diesem Befehl legen Sie AppPass1! als Passwort für die Nutzeranwendung fest.

3. Den Status Ihres Load-Balancers finden Sie in der Cloud Console auf der Seite Load-Balancing.

   Zur Seite "Load-Balancing"

4. Wählen Sie in der Liste den Load-Balancer mqm-svc-a aus.

   

   Wenn der Load-Balancer mqm-svc-a eine fehlerfreie Instanzgruppe anzeigt (wie oben im Screenshot), können Sie mit dem nächsten Schritt fortfahren.

5. Starten Sie in Cloud Shell den Warteschlangenmanager B auf 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. Starten Sie den Warteschlangenmanager B auf 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'"
   

Cluster überprüfen

Bevor Sie Ihr Deployment testen, müssen Sie überprüfen, ob Warteschlangenmanager A und Warteschlangenmanager B korrekt kommunizieren.

1. Stellen Sie in Cloud Shell eine Verbindung zum IBM MQ-Container auf mq-3 her:

   gcloud compute ssh mq-3 \
       --zone=us-central1-a \
       --command="sudo docker exec -it ibmmq-node /bin/bash" \
       -- -t
   

2. Überprüfen Sie den Status der Clusterkommunikationskanäle:

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

   Wenn alles korrekt funktioniert, sieht die Ausgabe so aus:

   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.
   

Nachrichten an den Cluster senden

Sie testen jetzt den Cluster dadurch, dass Sie zwei Nachrichten an eine Warteschlange mit dem Namen APP.QUEUE.1 senden. Verwenden Sie dazu eine von IBM im Docker-Image bereitgestellte Beispielanwendung.

Testnachrichten an den Warteschlangenmanager B senden

1. Stellen Sie in Cloud Shell eine Verbindung zum IBM MQ-Container auf mq-3 her:

   gcloud compute ssh mq-3 \
       --zone=us-central1-a \
       --command="sudo docker exec -it ibmmq-node /bin/bash" \
       -- -t
   

2. Starten Sie in der Terminal-Shell die Anwendung zum Senden von Nachrichten und geben Sie als Verbindung Warteschlangenmanager B an:

   MQSAMP_USER_ID=app /opt/mqm/samp/bin/amqsput APP.QUEUE.1 B
   

3. Wenn Sie dazu aufgefordert werden, authentifizieren Sie sich, indem Sie das zuvor erstellte Anwendungspasswort eingeben. In dieser Anleitung lautet das Passwort APPPass1!.

4. Wenn Sie die Ausgabe target queue is APP.QUEUE.1 sehen, senden Sie eine Testnachricht an die Warteschlange. Dazu geben Sie abcdef ein.

5. Senden Sie eine weitere Testnachricht und geben Sie 123456 ein.

6. Drücken Sie die Eingabetaste, um die Anwendung zum Senden von Nachrichten zu beenden.

   Die Ausgabe sieht so aus:

   Sample AMQSPUT0 start
   Enter password: *********
   target queue is APP.QUEUE.1
   abcdef
   123456
   
   Sample AMQSPUT0 end
   

7. Überprüfen Sie, ob im Warteschlangenmanager B gerade eine Nachricht in Bearbeitung ist:

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

   Es wird gerade nur eine Nachricht bearbeitet, da das IBM MQ-Load-Balancing die andere Nachricht an den Warteschlangenmanager A weitergeleitet hat (was später beschrieben wird).

8. Schließen Sie die SSH-Verbindung:

   exit
   

   Die folgende Ausgabe wird angezeigt:

   CURDEPTH(1)                             IPPROCS(0)
   

   Warteschlangenmanager B bearbeitet gerade eine Nachricht, obwohl Sie im vorherigen Schritt zwei Nachrichten gesendet haben. Der Grund hierfür ist, dass das IBM MQ-Load-Balancing die Nachrichten zwischen den Warteschlangenmanagern verteilt und die zweite Nachricht an den Warteschlangenmanager A gesendet wurde.

Nachrichten während der Bearbeitung im Warteschlangenmanager A überprüfen

1. Stellen Sie in Cloud Shell eine Verbindung zum IBM MQ-Container auf mq-1 her:

   gcloud compute ssh mq-1 \
       --zone=us-central1-c \
       --command="sudo docker exec -it ibmmq-node /bin/bash" \
       -- -t
   

2. Überprüfen Sie im Terminalfenster, ob im Warteschlangenmanager A gerade eine Nachricht bearbeitet wird:

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

   Die folgende Ausgabe wird angezeigt:

   CURDEPTH(1)                             IPPROCS(0)
   

Hochverfügbarkeit des Warteschlangenmanagers testen

Fahren Sie jetzt die Instanz mq-3 herunter und prüfen Sie, ob mq-4 für den Warteschlangenmanager B zur primären Instanz wird.

1. Halten Sie in Cloud Shell die Instanz mq-3 an:

   gcloud compute instances stop mq-3 \
       --zone=us-central1-a
   

2. Prüfen Sie, ob mq-4 jetzt die primäre Instanz ist. Prüfen Sie dazu, ob sie aus Sicht des Load-Balancers als fehlerfrei gemeldet wird:

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

   Die Ausgabe sieht in etwa so aus:

   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
   

Zur Produktion übergehen

In dieser Anleitung haben Sie IBM MQ Advanced für Entwickler verwendet. Bevor Sie zur Produktion übergehen, sollten Sie andere verfügbare Lizenzierungen und Funktionsmerkmale durchgehen. Sie sollten auch die Dokumentation von IBM zur Ausführung von IBM MQ in einem Container lesen, bevor Sie es für die Produktion bereitstellen.

Bereinigen

Nachdem Sie die Anleitung abgeschlossen haben, können Sie die in Google Cloud erstellten Ressourcen bereinigen, damit sie keine kostenpflichtigen Kontingente verbrauchen. In den folgenden Abschnitten erfahren Sie, wie Sie diese Ressourcen löschen oder deaktivieren.

Projekt löschen

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:
• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für diese Anleitung ein bereits bestehendes Projekt verwendet haben, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
• Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.
1. Wechseln Sie in der Cloud Console zur Seite Ressourcen verwalten.

   Zur Seite „Ressourcen verwalten“

2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

Nächste Schritte

• Weitere Informationen zu IBM MQ
• Weitere Informationen zu IBM MQ-Hochverfügbarkeitskonfigurationen
• Weitere Informationen zu internen Load-Balancern
• Mehr über GlusterFS erfahren
• Weitere Google Cloud-Features mit unseren Anleitungen testen