为什么我的集群不尊重CLWLPRTY？

时间：2018-12-06 15:44:06

标签： ibm-mq

我有以下设置：

  • 集群中的四个MQ队列管理器（QM1（完整存储库），QM2（完整存储库），QM3（部分存储库），QM4（部分存储库） ）
  • 所有群集发送方/接收方通道具有相同的等级和优先级
  • 每个队列管理器都有一个非集群别名队列（ALIAS.TO.CLQ）
  • ALIAS.TO.CLQ的基础对象为ALIAS.TO.FLOW，它是一个集群别名队列
  • ALIAS.TO.FLOW有一个基础对象L.TO.FLOW，它是一个本地队列。
  • 四个队列管理器中的每个都配置为CLWLUSEQ(ANY)。
  • 集群别名队列的DEFBIND为NOT FIXED。消息是由IIB（MQ输出节点）编写的，我相信这很荣幸-尽管我也看到使用MQ Explorer或RFHUtil的行为相同。
  • 消息由MQ输出节点放置，而没有指定队列管理器名称
  • 四个群集别名队列中的每个队列都有不同的CLWLPRTY，但有相同的CLWLRANK。

此配置的目的是强制消息由相同的本地队列接收，无论消息最初放置在哪个队列管理器中。如果该队列管理器不可用，则应使用第二高的优先级，依此类推。

我发现的问题是，对于四个队列管理器中的三个，CLWLPRTY被兑现，并且消息被路由到优先级最高的队列管理器。但是，在本身具有最高优先级的队列管理器上，消息被路由到第二高优先级。而不是在优先级最高的同一队列管理器上使用该队列。

如果我更改哪个队列管理器具有第二高的优先级，则消息总是从具有最高优先级的队列管理器那里路由-因此，这不仅仅是巧合。如果两个队列实例共享最高优先级，则它将永远不会在同一队列管理器中选择一个。似乎总是喜欢去集群。

这是怎么回事，无论消息放在何处，我如何才能始终遵守优先级？我已经查看了IBM文档（https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.ref.con.doc/q082390_.html）中的“集群工作负载管理算法”页面，但是看不到哪里出了问题。

-更新-

我尝试以相同的格式创建新的一组队列，但仅在一个集群队列管理器上-因此，ALIAS.TEST-> AL.TEST（集群，但仅存在一个实例） -> L.TEST。当我放到ALIAS.TEST时，收到一条错误消息：

  

发出了MQOPEN或MQPUT1调用，将别名队列指定为目标，但是别名队列定义中的BaseObjectName解析为不是本地队列或远程队列本地定义的队列。 （AMQ4480）     发出了MQOPEN或MQPUT1调用，将别名队列指定为目标，但是别名队列定义中的BaseObjectName解析为不是本地队列或远程队列本地定义的队列。 （AMQ4480）

     

严重性：20（错误）

     

响应：更正队列定义。

但是我可以毫无问题地进入AL.TEST队列。

-编辑-

好的，为什么会发生呢？https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.pro.doc/q003120_.html

  

别名不能直接解析为同一队列管理器上的另一个别名。

那么我该如何获得想要的行为？

1 个答案:

答案 0 :(得分：1)

基于以下流程，每个IIB实例将其放入本地队列管理器：

IIB1 -> QM1 -> QLOCAL(L.TO.FLOW) CLWLRANK(0) CLWLPRTY(4) CLWLUSEQ(ANY)
IIB2 -> QM2 -> QLOCAL(L.TO.FLOW) CLWLRANK(0) CLWLPRTY(3) CLWLUSEQ(ANY)
IIB3 -> QM3 -> QLOCAL(L.TO.FLOW) CLWLRANK(0) CLWLPRTY(2) CLWLUSEQ(ANY)
IIB4 -> QM4 -> QLOCAL(L.TO.FLOW) CLWLRANK(0) CLWLPRTY(1) CLWLUSEQ(ANY)

*假定所有四个CLWLRANK通道上的CLWLPRTY，NETPRTY和CLUSRCVR在所有四个队列管理器上都是相同的。

四个IIB实例中任何一个的消息PUT将始终流到具有最高CLWLPRTY的可用队列。

从群集工作负载管理算法的角度来看，队列实例可能不可用，原因有很多。我已引用了本文结尾处的知识中心，该中心提供了该算法的详细说明。两种常见原因是：

  1. 队列管理器已关闭

  2. 队列为PUT(DISABLED)

每个IIB实例将仅从与该IIB实例也连接的同一队列管理器上的本地队列GET起。在上述设置中，这意味着在正常情况下，如果所有四个队列管理器都启动，则只有连接到QM1的IIB实例将接收消息。

在IBM MQ v9.0知识中心页面“ Reference>Configuration reference>IBM MQ cluster commands>Workload balancing in clusters>The cluster workload management algorithm”中找到了什么可以使队列实例不可用，我提供了适用于您的问题中所述设置的内容：

  

该算法逐步遵循以下规则来消除   可能目的地列表中的目的地。

     
      

  1. 如果指定了队列或主题名称：

         

    a。尽可能消除未启用的队列   目的地。

    2.   
     

     
      

  1. 在选择队列时，如果结果队列集包含队列的本地实例，则通常使用本地实例。的   如果这三个条件之一，则使用队列的本地实例   是真的：

         
        

    • 对于使用CLWLUSEQ（ANY）定义的本地定义的队列，或者   从队列管理器继承相同的设置，以下   在适用的更广泛的条件下，这些点是正确的：

           

      a。根据与队列在同一群集中的本地定义的CLUSRCVR通道的状态，选择本地队列。   将此状态与CLUSSDR通道的状态进行比较，   会将消息带到同名的远程定义的队列。

           

      例如，与队列在同一群集中有一个CLUSRCVR。该CLUSRCVR的状态为STOPPING，而其他队列   群集中具有相同名称的状态为RUNNING或INACTIVE。

           

      在这种情况下，将选择远程通道，并且不使用本地队列。

           

      b。根据CLUSRCVR通道数选择本地队列，并与状态相同的CLUSSDR通道进行比较，   将消息带到相同的远程定义的队列   名称。

           

      例如，在与队列相同的群集中有四个CLUSRCVR通道和一个CLUSSDR通道。所有频道都一样   不活动或正在运行的状态。

           

      因此，有五个通道可供选择，还有两个队列实例。五分之四（80％）的消息发送到   本地队列。

      •   
    2.   
     

     
      

  1. 如果仅保留队列或主题的远程实例，则优先选择恢复的队列管理器而不是挂起的队列管理器。

    2.   

  2. 如果队列或主题的多个远程实例剩余，则包括所有不活动或正在运行的通道。状态   常量列出了：

         
        

    • MQCHS_INACTIVE

      •   

    • MQCHS_RUNNING

      •   
    3.   

  3. 如果没有剩余的队列或主题的远程实例，则所有处于绑定，初始化，启动或停止状态的通道   包括在内。状态常量列出如下：

         
        

    • MQCHS_BINDING

      •   

    • MQCHS_INITIALIZING

      •   

    • MQCHS_STARTING

      •   

    • MQCHS_STOPPING

      •   
    4.   

  4. 如果没有队列或主题的远程实例，则将包括所有正在再次尝试的通道。状态常数列出：

         
        
    • MQCHS_RETRYING
      •   
    5.   

  5. 如果没有剩余的队列或主题的远程实例，则包括处于请求，暂停或停止状态的所有通道。状态常数   列出：

         
        

    • MQCHS_REQUESTING

      •   

    • MQCHS_PAUSED

      •   

    • MQCHS_STOPPED

      •   
    6.   
相关问题
最新问题