amzshar

.
. IBM WebSphere MQ v6.0
. Chapter 5.3 IBMWebSphereMQ Clusters
.

=== What is a MQ Cluster ? ===
1. A Cluster is a collection of Queue Managers that may be on different platforms,
　but typically serve a common application.
2. Every Queue Manager can make the Queues that they host available to every
　other Queue Manager in the Cluster, without the need (Remote) Queue definitions.
3. Cluster specific objects remove the need for explicit CHANNEL definitions and
　Transmission Queues for each destination Queue Manager.
4. The Queue Managers in a Cluster will often take on the role of a client or a server.
　The servers will host the Queues that are available to the members of the Cluster,
　also running applications that process these messages and generate responses.
　The clients PUT messages to the servers Queues and may receive back response messages.
5. Queue Managers in a Cluster will normally communicate directly with each other,
　although typically, many of the client sysetms will never have a need to communicate
　with other client systems.


=== Cluster Support Objects ===

======================================================
[QM1]————————————
　∣Cluster Transmission Queue∣
　∣　　　　　　　[ Cluster-Sender CHANNEL ] →→ [QM3]
　∣Local Appication Queues 　∣　　　　　　　　　　↙
　∣　　　　　　　　　　　　∣　　　　[QM2]　　↙
　∣Cluster Command Queue　∣ 　　↙　　　　　↙
　∣　　　　　　　　[ Cluster-Receiver CHANNEL ] ← [QM4]
　∣Cluster Repository Q　　　∣
　　—————————————
======================================================

1. Cluster Repository (Queue) :
　- A collection of information about the Queue Managers that are members of a Cluster,
　　including Queue Manager names, their CHANNELs, the Queues they host and so forth.
　- This repository information is exchanged through messages sent to a Queue called
　　SYSTEM.CLUSTER.COMMAND.QUEUE and stored on a Queue with the fixed name
　　SYSTEM.CLUSTER.REPOSITORY.QUEUE
　- Repositories may be full or partial - more about this on the next visual. Each Cluster
　　Queue Manager must have at least one connection to another Queue Manager that
　　owns a full repository.

2. Cluster-Sender CHANNEL :
　- A CHANNEL definition of the TYPE(CLUSSDR) on which a Cluster Queue Manager can
　　send messages to another Queue Manager in the Cluster that holds a full repository.
　　This CHANNEL is used to notify the repository of any changes of the Queue Manager's
　　status, for example the addition or removal of a Queue. It is only used for the initial contact
　　with the first full repository Queue Manager. From this one the Local Queue Manager learns
　　whatever it needs to know.
　- Note : Application messages will be sent by auto-defined sender CHANNELs that are
　　created during operation based on repository information from other Cluster Queue Managers

3. Cluster-Receiver CHANNEL :
　- A CHANNEL definition of the TYPE(CLUSRCVR) on which a Cluster Queue Manager can
　　receive messages from within the Cluster. Though the definition of this object a
　　Queue Manager is advertised to the other Queue Managers in the Cluster, thus enabling
　　them to auto-define their appropriate CLUSSDR CHANNELs for this Queue Manager.
　- You need at least one Cluster-Receiver CHANNEL for each Cluster Queue Manager.

4. Cluster Transmission Queue :
　- All the messages from the Queue Manager to any other Queue Manager in the Cluster
　　are locally put to this Queue named SYSTEM.CLUSTER.TRANSMIT.QUEUE
　- It must exist in each Cluster Queue Manager

5. Cluster Queue :
　- A Cluster Queue is a Queue that is hosted by a Cluster Queue Manager and made available
　　to Queue Managers in the Cluster. The Local Queue is either preexisting or created on the
　　Local Queue Manager and to play a role in the Cluster the Local Queue definition specifies
　　the Cluster name of the definition. The other Queue Managers can see this Queue and use
　　it to put messages to it without the use of Remote Queue definition. The Cluster can be
　　advertised in more than one Cluster.


=== More About Repositories ===
1. Each Cluster Queue Manager has to have a Local Queue called
　SYSTEM.CLUSTER.REPOSITORY.QUEUE where all Cluster related information is stored.
2. At least one (but for availability reasons preferably 2 or more) Cluster Queue Managers have
　to hold full repositories; that means a complete set of information about every
　Queue Manager in the Cluster.
3. For each Cluster Queue Manager, a Cluster-Sender CHANNEL has to be predefined that
　connects to one of the repository Queue Managers.
4. Repository Queue Managers (sometimes simply called repositories) must be fully
　interconnected with each other and positioned in the network so as to give a
　high level of availability.
5. Normal Queue Managers build up and maintain a partial repository that contains information
　about those Queue Managers and Queue that are of iterest to it. This information may be
　updated and extended during operation through inquirles of a full repository.

※ 每個 Cluster 至少兩個 Queue Manager.
※ 每個 Cluster 至少兩個 Full Repository.
※ 一個 QM 只能擔任某一個 Cluster 的 Fully Repository.

※ 當用 MQ-Explorer ---> Cluster-Receiver CHANNEL connection name : hostname(1414)


=== Setting Up a Cluster ===
1. QM1 is made a full repository Queue Manager for the Cluster named CLUS_A3 :
　ALTER QMGR REPOS(CLUS_A3)
　
　DEFINE CHANNEL(TO.QM1) +
　　CHLTYPE(CLUSRCVR) CONNAME(...) +
　　CLUSTER(CLUS_A3) DESCR('To other Repository')
　
　DEFINE QLOCAL(QUEUE1) CLUSTER(CLUS_A3)

2. A Queue Manager may be associated to more than one Cluster at time.
　The same is true for Queues and CHANNELs :
　- In this case a NAMELIST object has to be created with multiple Cluster names as
　　single entries.
　- Then with all DEFINE commands , the name of this namelist has to be referenced
　　instead of the Cluster name, and the REPOS attribute of the ALTER QMGR comand
　　changes to REPONL.


=== WorkLoad Balancing Attributes === (CLWL)

※ CLUSTER "CLUS_A3"
==========================================================================
　MQOPEN QNAME(TARGET.Q)
　　↓　　　　　　　　↗ [QM2 ] TARGET.Q ↘
　[ QM1 ] →CLW EXIT → [ QM3 ] TARGET.Q → DEF QL(TARGET.Q) CLUSTER(CLUS_A3)
　　　　　　　　　　　↘ [QM4 ] TARGET.Q ↗
　ALTER QMGR CLWEXIT(myexit)
==========================================================================

1. Queue attributes :
　- CLWLPRTY　　(Cluster WorkLoad priority)
　- CLWLUSEQ　　(use Local Queue)

2. Queue Manager attributes :
　- CLWLUSEQ　　(use Local Queue)

3. CHANNEL attributes :
　- CLWLPRTY　　(priority)
　- CLWLWGHT　　(weight to a CHANNEL, 1 ~ 99)
　- NETPRTY　　　(network priority)


=== Continuous Operations ===
1. MQOPEN(TARGET.Q) MQOO_BIND_NOT_FIXED, MQPUT , MQPUT ... MQPUT
※ MQOO_BIND_NOT_FIXED 才能 Load Balance, 若是 On Open 就只會固定送到某QM

2. The Queue Attribute DEFBIND determaines whether or not rerouting will be performed
　while a Queue is opened.
　- DEFBIND(NOTFIXED)　with a round-robin distribution of messages to all TARGER.Qs
　　in the Cluster.
　- DEFBIND(OPEN)　the destination Q is selected at MQOPEN time and will not be
　　changed until MQCLOSE.


=== Cluster Related Queue Manager Attributes ===
1. REPOS(ClusterName)
2. REPOSNL(NamelistName)
3. CLWLDATA(32 char max string)
4. CLWLEXIT(Cluster WorkLoad exit name)
5. CLWLLEN(max # of bytes of message data passwd to Cluster WorkLoad exit)


=== Controlling Clusters - Cluster Commands ===
1. SUSPEND QMGR　- Removes a QM from a Cluster temporarily.
2. RESUME QMGR　- Reinstates a SUSPENDed QM.
3. REFRESH CLUSTER(clustername)　- 強制讓Cluster Sync一次.
4. RESET CLUSTER(clustername) 　- QM退出, 當亂掉時, 清除用
5. RESET CLUSTER(clustername)
　　QMNAME(QMname) ACTION(FORCEREMOVE) QUEUES(NO)
6. RESET CLUSTER(clustername)
　　QMID(QMid) ACTION(FORCEREMOVE) QUEUES(NO)


=== Controlling Clusters - DISPLAY CLUSQMGR ===
1. DISPLAY CLUSQMGR(*) CLUSTER(name) CHANNEL(name)
returns :
　CLUSDATE　/　CLUSTIME
　　- the date and time when the Definition became available to the Local QMGR.
　DEFTYPE　- how the luster QMGR was defined.
　QMTYPE　- function of QMGR in Cluster, provides FULL or PARTIAL repository service.
　QMID　- internalygenerated unique QMGR name.
　STATUS　- the current status of CHANNEL for QMGR.
　SUSPEND　- yes or no as a result of a SUSPEND QMGR cmd.

2. The DISPLAY CLUSMGR command returns cluster information about Queue Manager
　in a Cluster which is stored in the Local SYSTEM.CLUSTER.REPOSITORY.QUEUE
Definition Type may be :
　CLUSSDR　- as a Cluster-Sender CHANNEL from an explicit definition.
　CLUSSDRA　- as a Cluster-Sender by auto-definition.
　CLUSSDRB　- as a Ckuster-Sender CHANNEL, both from an explicit definition
　　　　　　　　and by auto-definition.
　CLUSRCVR　- as a Cluster-Receiver CHANNEL.


=== Cluster Related Queue Considerations ===
1. Special DISPLAY option :
　DISPLAY QUEUE CLUSINFO
2. Cluster Alias Queue :
　DEF QA(PUBLIC) TARGET(LOCAL.Q) CLUSTER(ITALY)
3. Cluster Queue Manager Aliases :
　DEF QR(ROME) RNAME() RQMNAME(PISA) XMITQ(XQ) CLUSTER(ITALY)

4. Most types of Queues may be defined as Cluster Queues, and as a consequence,
　be advertised to all Queue Managers in the Cluster, just as for Local Queues.
　- Alias Queues　may be made available to the Cluster simply by adding
　　　　　　　　　the CLUSTER keyword to the definition.
　- Queue Manager Aliases　advertised to the Cluster may be of the same value as
　　　　　　　　　for traditional distributed Queueing.
　- Remote Queues　are not intend to be advertised to a Cluster, because one of the
　　　　　　　　　benefits of Clusters is that Remote Queue definitions are no loger
　　　　　　　　　required. Remote Queues, however, can have a Cluster attribute.
　　　　　　　　　They can be used to attach a Queue Manager that does not
　　　　　　　　　support clusting.
　- Model Queues　(and hence Temporary Dynamic Queues) cannot have a Cluster
　　　　　　　　　attribute.

5. Effect of ALTERing Queue definitions :
　- ALTER QUEUE(XXX) PUT(INHIBITED)
　　will stop messages being put to that instance of a Queue and also mark it as being
　　put inhibited throughout the Cluster. If applicable, this will cause messages to be
　　sent to other instances of the queue.
　- ALTER QUEUE(XXX) CLUSTER('　')
　　will take a Queue out of its Clusters and stop other Queue Managers from sending
　　messages to it but still allow messages to be put to it from the Local Queue Manager.