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
-
Melden Sie sich bei Ihrem Google-Konto an.
Wenn Sie noch kein Konto haben, melden Sie sich hier für ein neues Konto an.
-
Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.
-
Die Abrechnung für das Cloud-Projekt muss aktiviert sein. So prüfen Sie, ob die Abrechnung für Ihr Projekt aktiviert ist.
- Aktivieren Sie die Compute Engine 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.
Öffnen Sie Cloud Shell.
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
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
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
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
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
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
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
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
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.
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
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.
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
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
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
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
.
Initialisieren Sie den vertrauenswürdigen GlusterFS-Pool auf
mq-1
und prüfen Siemq-2
:gcloud compute ssh mq-1 \ --zone=us-central1-c \ --command='sudo mkdir -p /data/gv0 && sudo gluster peer probe mq-2' \ -- -t
Initialisieren Sie den vertrauenswürdigen GlusterFS-Pool auf
mq-2
und prüfen Siemq-1
:gcloud compute ssh mq-2 \ --zone=us-central1-b \ --command='sudo mkdir -p /data/gv0 && sudo gluster peer probe mq-1' \ -- -t
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
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
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
Ü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
.
Initialisieren Sie den vertrauenswürdigen GlusterFS-Pool auf
mq-3
und prüfen Siemq-4
:gcloud compute ssh mq-3 \ --zone=us-central1-a \ --command='sudo mkdir -p /data/gv0 && sudo gluster peer probe mq-4' \ -- -t
Initialisieren Sie den vertrauenswürdigen GlusterFS-Pool auf
mq-4
und prüfen Siemq-3
:gcloud compute ssh mq-4 \ --zone=us-central1-f \ --command='sudo mkdir -p /data/gv0 && sudo gluster peer probe mq-3' \ -- -t
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
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
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
Ü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.
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
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"
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
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.
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
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.
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.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.Den Status Ihres Load-Balancers finden Sie in der Cloud Console auf der Seite Load-Balancing.
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.
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'"
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.
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
Ü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
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
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
Wenn Sie dazu aufgefordert werden, authentifizieren Sie sich, indem Sie das zuvor erstellte Anwendungspasswort eingeben. In dieser Anleitung lautet das Passwort
APPPass1!
.Wenn Sie die Ausgabe target queue is APP.QUEUE.1 sehen, senden Sie eine Testnachricht an die Warteschlange. Dazu geben Sie
abcdef
ein.Senden Sie eine weitere Testnachricht und geben Sie 123456 ein.
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
Ü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).
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
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
Ü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.
Halten Sie in Cloud Shell die Instanz
mq-3
an:gcloud compute instances stop mq-3 \ --zone=us-central1-a
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
- Wechseln Sie in der Cloud Console zur Seite Ressourcen verwalten.
- Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
- 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