MQ

MQ

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  Uniform cluster questions

    Posted 10/25/21 06:04 PM

    I'm creating Helm charts to deploy a 3-node uniform cluster into our Kubernetes environment.  There are two repos in the cluster (QC90 & QC91).  The third member (QC92) is not a repo.  This appears to be working correctly in that when I run "dis chstatus(psinv*)" on each member I see all the expected sender and receiver channels there with status of RUNNING. 

    I have a few questions regarding the setup.

    1) When I run "dis chl(psinv*) conname" to display the connection names I see this.  Note the CONNAME value for the first sender channel is truncated.  Is this normal?  I know from the qm.ini file the CONNAME value I'm supplying has the full length, same as the others.


    2) For the two receiver channels I see the same channel name (PSINV_QC90) is used.  Is that correct?  I'm using this command to define these:

    DEFINE CHANNEL('+AUTOCL+_+QMNAME+') CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME('+CONNAME+') CLUSTER('+AUTOCL+') REPLACE


    3) (Perhaps more of a K8s question) Since I'm doing this in a Kubernetes environment should I deploy a Service for each MQ server instance in the Statefulset?  I currently have a single Service for the three.

    Thanks,
    Jim



    ------------------------------
    Jim Creasman
    ------------------------------


  • 2.  RE: Uniform cluster questions

    Posted 10/26/21 12:44 AM

    Hi Jim,

    1. The truncated CONNAME does look rather suspicious. Do you see the same truncation when you display the channel using a PCF based tool such as MQ Explorer (or MO71)? i.e. is the truncation at the presentation layer, or is that truly what the CONNAME is? You could also look at another view of the same data by issuing the following command:-

      DISPLAY CLUSQMGR(QC90) CHANNEL CONNAME

      The fact that the channel is running successfully does suggest only a display issue, unless the nameserver is able to resolve that hostname with or without the svc.cluster.local bit on the end! The port number of 1414 is redundant of course.

    2. It is quite normal and expected to only define one CLUSRCVR channel into each queue manager in a cluster and then to see every member of the cluster connect to that queue manager using that CLUSRCVR channel name. Generic receivers (as they are called) were a best practice long before cluster channels came along. Perhaps you are more familiar with the concept used by SVRCONN channels? You make one definition and then multiple client applications can come along and connect using that one channel name. Same is true for RCVR channels, and also for CLUSRCVR channels. One definition and multiple running instances (channel statuses). This is why channel status has helpful attributes such as RQMNAME and CONNAME to show which running instance you are looking at.

    3. I'm not a K8S expect so will leave your third question to someone who is, to answer.

    Cheers,
    Morag



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------



  • 3.  RE: Uniform cluster questions

    Posted 10/26/21 10:10 AM
    Thanks, Morag.  I'm thinking the truncation of the CONNAME is a display issue.  When I run the command you posted I see the full name:


    even though the channel command is still displaying the value as truncated.  The DNS would definitely not resolve if it were truncated at this point.  Maybe something for IBM to look into.


    Regarding the CONNAME value I read that the length limit for multi-cluster was 264 characters, but was only 64 for z/OS.  Given K8s generates these long host names will that be a concern if I'm defining a connection from MQ on z/OS over to the cluster nodes?  I can easily see these going over 64 chars in length. 

    In reviewing IBM's Helm charts I see they have logic to truncate the name at 63 characters in their HA cluster setup.  Wouldn't that prevent the connection from working?  I may need to dig in a bit more to understand exactly what their charts are doing with the truncated value.  Perhaps it's used elsewhere.

    Thanks,
    Jim

    ------------------------------
    Jim Creasman
    ------------------------------

    Original Message


  • 4.  RE: Uniform cluster questions

    Posted 10/27/21 05:50 AM

    Given that your CONNAME is 71 characters, then yes, this is indeed going to be a problem if you have a z/OS queue manager in your cluster. The CONNAME in a CLUSRCVR channel is sent to each cluster member repository to use to build its CLUSSDR channel back to that machine. Also, I think the z/OS limit is 48 characters.

    Do any K8s expects know whether there is a way to configure the length of generated connection names?

    Cheers,
    Morag



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------

    Original Message


  • 5.  RE: Uniform cluster questions

    Posted 10/27/21 03:08 AM
    Hi Jim,

    I have nothing to add to Morag's response with respect to the channel connames, but I can comment on the k8s service piece.

    If you had a single queue manager across multiple machines (Native HA for example) then you would want a single service definition, which would load balance to a working instance).

    If you had several queue managers (but not a uniform cluster) and you wanted the service to load balance incoming client connection requests across the available queue managers, then you would want to have a single service. However, this wouldn't work for queue manager or cluster channels, only for client connections.

    For a uniform cluster, I believe you will need a separate service for each member of the cluster, since they are all separately addressable queue managers. The service definition provides the hostname for the queue manager, and you need separate ones so that dynamic balancing of the client connections can be performed. You also need the cluster channels to be able to form connections, and if you have channels coming in from other queue managers, they need to be able to reach the queue managers too.

    It seems odd to me that you would have the 3 instances in a single stateful set. I would have expected each MQ queue manager to have its own stateful set, but I haven't tried to set up a uniform cluster in k8s myself, so that might be a misconception on my part.

    Regards,

    ------------------------------
    Neil Casey
    Senior Consultant
    Syntegrity Solutions
    Melbourne, Victoria
    IBM Champion (Cloud) 2019-21
    ------------------------------



  • 6.  RE: Uniform cluster questions

    Posted 10/28/21 05:40 AM
    Hi Jim,

    I'd suggest raising a ticket for the truncated CONNAME so we can take a look at it properly. Which release are you using?

    Cheers, Matt

    ------------------------------
    Matthew Whitehead
    ------------------------------



  • 7.  RE: Uniform cluster questions

    Posted 10/29/21 08:51 AM
    Matt,

         This is the version info from the server:


    Jim

    ------------------------------
    Jim Creasman
    ------------------------------

    Original Message


Related Content