Consider the following before starting to use clusters:
The WebSphere MQ Explorer cannot directly administer WebSphere MQ for
z/OS queue managers at versions earlier than version 6.
To get the most out of clusters, all the queue managers in the network
must be on a platform that supports clusters. Until all your systems are on
platforms that support clusters, you might have queue managers outside a cluster
that cannot access your cluster queues without extra manual definitions.
If you merge two clusters with the same name, you cannot separate them
again. Therefore it is advisable to give all clusters a unique name.
If a message arrives at a queue manager but there is no queue
there to receive it, the message is put on the dead-letter queue as usual.
(If there is no dead-letter queue, the channel fails and retries, as described
in the WebSphere MQ Intercommunication book.)
The integrity of persistent messages is maintained. Messages are not duplicated
or lost as a result of using clusters.
Using clusters reduces system administration. Clusters make it easy to
connect larger networks with many more queue managers than you would be able
to contemplate using distributed queuing. However, as with distributed queuing,
there is a risk that you may consume excessive network resources if you attempt
to enable communication between every queue manager
in a cluster.
If you use the WebSphere MQ(R) Explorer, which presents the queue managers in a
tree structure, the view for large clusters may be cumbersome.
The Explorer GUI can administer a cluster with repository queue
managers on WebSphere MQ for z/OS Version 6, without the need for nominating
an additional repository on a separate system. For earlier versions of WebSphere
MQ on z/OS, the WebSphere MQ Explorer cannot administer a cluster with repository
queue managers. You must therefore nominate an additional repository on a
system that the WebSphere MQ Explorer can administer.
The purpose of distribution lists, which are supported on WebSphere MQ for AIX, iSeries, HP-UX, Solaris, Linux,
and Windows and MQSeries for Compaq Tru64 UNIX, Compaq NonStop Kernel, and HP OpenVMS, V5.1, is to use a single
MQPUT command to send the same message to multiple destinations. You can use
distribution lists in conjunction with queue manager clusters. However, in
a clustering environment all the messages are expanded at MQPUT time and so
the advantage, in terms of network traffic, is not so great as in a non-clustering
environment. The advantage of distribution lists, from the administrator's
point of view, is that the numerous channels and transmission queues do not
need to be defined manually.
If you are going to use clusters to balance your workload, examine your
applications to see whether they require messages to be processed by a particular
queue manager or in a particular sequence. Such applications are said to have message affinities. You might need to
modify your applications before you can use them in complex clusters.
If you use the MQOO_BIND_ON_OPEN option on an MQOPEN call to force messages
to be sent to a specific destination, and the destination queue manager is
not available, the messages are not delivered. Messages are not routed to
another queue manager because of the risk of duplication.
If a queue manager is to host a cluster's repository, you need to know
its host name or IP address. You have to specify this information in the CONNAME
parameter when you make the CLUSSDR definition on other queue managers joining
the cluster. If you were to use DHCP, the IP address would be subject to change
because DHCP can allocate a new IP address each time you restart a system.
Therefore, it would not be possible to specify the IP address in the CLUSSDR
definitions. Even if all your CLUSSDR definitions specified the hostname rather
than the IP address, the definitions would still not be reliable. This is
because DHCP does not necessarily update the DNS directory entry for the host
with the new address.
Note:
Unless you have installed software that
guarantees to keep your DNS directory up-to-date, you should not nominate
queue managers as full repositories if they are on systems that use DHCP.
Do not use generic names, for example VTAM(R) generic resources or Dynamic Domain Name
Server (DDNS) generic names as the connection names for your channels. If
you do, your channels might connect to a different queue manager than expected.
You can only GET from a local cluster queue, but you can PUT to any queue
in a cluster. If you open a queue to use the MQGET command, the queue manager
will only use the local queue.