Kbase 19317: SonicMQ: Administration of an Interbroker Environment
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/04/2000 |
|
SUMMARY:
This solution reflects corrections that relate to SonicMQ 2000 administration in an interbroker (cluster) environment as described in the "Installation and Administration Guide" (Dec, 1999).
EXPLANATION:
Security within an interbroker environment is managed centrally at a configuration server (a SonicMQ broker configured for this purpose - see existing documentation).
However physical queues (used in point-to-point messaging) and durable subscriptions (pub/sub messaging) from a user's perspective, are managed at individual nodes within a cluster. The implication is that to manage the physical queues and durable subscriptions you must connect to the server that hosts them in order to perform administration using SonicMQ Explorer or the Admin shell.
Queues:
Physical queues are maintained locally at each broker in an
interbroker environment. Messages destined for a named queue are
not forwarded to similarly named queues that exist in other
brokers within a cluster. When you administratively clear the
messages in a named queue on a broker within a interbroker
environment, similarly named queues in other brokers within the
interbroker environment are not cleared.
Unlike the description in the Administration Guide, when you
connect to an interbroker enabled broker that is not a
configuration server, you see a "Queues" node. From this node,
you can manage the physical queues at this broker.
If security is enabled, you have the ability to configure quality
of protection (QoP) and access control (ACL) information for
queues (including "wildcard security" - see existing documentation).
In the situation where you are connected to a non-configuration
broker, the security requests that are sent to that
non-configuration broker are forwarded to the inter-broker
configuration server (the non-configuration broker acts as a
security proxy for the configuration server).
Thus when security is enabled and you use Explorer or Admin to
create a queue on a non-configuration broker, two actions are
taken; the physical queue is created at the non-configuration
broker and the security details for the queue name are stored at
the configuration server. If you create a queue with the same
name at another broker in the interbroker environment, the new
queue security details override those that were previously
defined.
Topics & Durable Subscriptions:
Durable subscriptions are maintained locally at each broker in an
interbroker environment. In order to honor durable subscriptions
across brokers within a cluster, special internal subscriptions
are created. These special internal subscriptions are neither
visible nor do they require maintenance through the
administration tools.
Unlike the description in the Administration Guide, when you
connect to an interbroker-enabled broker that is not a
configuration server, you see a "Topics" node. From this node you
can manage the durable subscriptions at this broker.
If security is enabled, you have the ability to configure quality
of protection (QoP) and access control (ACL) information for
topics. The same security proxy functionaility that is described
for queues (above) applies to topic security.
The proxy capabilities described in the sections above ("Queues"
and "Topics & Durable Subscriptions") imply the need for some
administration overhead when you manage security from a
non-confiuration broker. For example, Explorer node navigation
might seem slower than that on a configuration server.