Just a couple of errata from our call and/or some follow-up:
1. On the call, if I recollect correctly, it was asked how we deploy accounting and statistics to MQ in CP4I.
I think we said this could be done with MQSC as ConfigMaps. I just wanted to point out that, in addition, this is also configurable from the MQ dashboard.
2. What about circular or linear logging? Despite what I stated, this can be enabled using configmaps/secrets and the QMGR properties relating to this are also configurable from the dashboard.
apiVersion: v1
kind: ConfigMap
metadata:
name: mqsc-ini-example
data:
example.ini: |
Log:
LogPrimaryFiles=15
LogSecondaryFiles=25
LogFilePages=16384
LogType=LINEAR
LogBufferPages=0
LogPath=/MQHA/EDIMQ1D/log/EDIMQ1D/
LogWriteIntegrity=TripleWrite
LogManagement=Manual
3. For the multi-instance deployment of MQ in CP4I how do we license and meter the standby pod?
In the licensing service, the standby pod for a multi-instance queue manager will appear as a full MQ pod, and administrators will need to manually identify their usage of standby instances. This is because the same metering annotations apply to each instance.
4. Capturing must gather for support cases:
I have reached out to the support team on this one and am still waiting for a response. I think the answer, as alluded to you on the call, is that you can turn trace on through the dashboard, but the dashboard doesn't offer a way to capture support case full diagnostic. I think that is a good suggestion and will continue to pursue it with the development team.
However, just to expand and clarify what I said on the call. My understanding is that, you can run runmqras from within the pod and use this to ftp data directly to the case. As always, you should also gather and capture any dat the support team request in your specific case. Please see the following support link in respect of runmqras:
Using the IBM MQ runmqras command to collect diagnostic data5. MQ clustering in CP4I:
In case this was not clear on the call, you can run MQ clusters in CP4i. When doing this, the recommendation is to deploy all queue managers in with a PVC - this is because it is important that queue managers in a cluster retain their clustering information over restarts of the pod. A series of single resilient queue managers for example to support uniquely named queue managers within the cluster. Each will need a uniquely addressable port.
With respect to whether this is recommended: As long as you are managing cluster queue managers in all of recommended ways, and have a use case for clustering, this is a reasonable deployment in CP4I. Perhaps the reason why this question comes up is that we often think of dynamically scalable and disposable pods in the form of replica sets - such deployments do not work well with clustering.
6. MQ latency (and performance) in a container or OCP.
I think I covered the point about latency costs broadly. Bottom line is that you should expect these when communicating between what are probably now smaller deployments of code (possibly micro-services). In the first place due to this granularity, this introduces extra chattiness (whether deployed in containers or not), and secondly there is an additional potential overhead associated with the pod and any sidecars (such as istio).
With regard comparative performance between MQ in CP4i (or containers) and traditional platforms, I had a quick look around to see what we had on performance. Firstly, I direct you to our ever updated performance reports where we do have some links on performance measurements against different environments for MQ (including OCP). For example,
http://ibm-messaging.github.io/mqperf/openshift/OCP4.2-InternalMessaging.pdfI also found a link to some Docker container tests conducted by
Sam Massey last year, that may be of interest.
https://community.ibm.com/community/user/imwuc/viewdocument/jms-performance-tests-in-a-docker-c?CommunityKey=b382f2ab-42f1-4932-aa8b-8786ca722d55
------------------------------
Justin Deane
------------------------------
Original Message:
Sent: Tue December 08, 2020 03:26 PM
From: Justin Deane
Subject: Chat with IBM Expert Labs – Understand MQ deployments on Cloud Pak for Integration
IBM MQ has been supported in Docker containers for several years, but there are powerful new features now offered by cloud platforms like CP4I, which provides new ways of approaching solution architectures. Some of the architectural considerations are: statefulness, persistence/durability, availability, scalability (dynamic versus static), message ordering, load balancing, affinity.
Some of the options available include multi-instance queue managers, single resilient queue managers, homogeneous collections of queue managers.
This session will explore these various considerations and options.
Please join me and @ASHLIN JOSEPH on Wednesday, December 9th at 10 AM ET for Chat with IBM Expert Labs – Understand MQ deployments on Cloud Pak for Integration webinar.
Include your questions below and register to watch here.
------------------------------
Justin Deane
------------------------------