+

Search Tips | Advanced Search

Plan for distributed publish/subscribe network

We can create a network of queue managers where subscriptions created on one queue manager will receive matching messages published by an application connected to another queue manager in the network. To choose a suitable topology, we need to consider we requirements for manual control, network size, frequency of change, availability and scalability.


Before starting

This task assumes that you understand what distributed publish/subscribe networks are, and how they work. For a technical overview, see Distributed publish/subscribe networks.


About this task

There are three basic topologies for a publish/subscribe network:

  • Direct routed cluster
  • Topic host routed cluster
  • Hierarchy

For the first two topologies, the starting point is an IBM MQ cluster configuration. The third topology can be created with or without a cluster. SeePlan for distributed queues and clustersfor information about planning the underlying queue manager network.

A Direct routed cluster is the simplest topology to configure when a cluster is already present. Any topic that you define on any queue manager is automatically made available on every queue manager in the cluster, and publications are routed directly from any queue manager where a publishing application connects, to each of the queue managers where matching subscriptions exist. This simplicity of configuration relies on IBM MQ maintaining a high level of sharing of information and connectivity between every queue manager in the cluster. For small and simple networks (that is, a small number of queue managers, and a fairly static set of publishers and subscribers) this is acceptable. However, when used in larger or more dynamic environments the overhead might be prohibitive. SeeDirect routing in publish/subscribe clusters.

A Topic host routed cluster gives the same benefit as a direct routed cluster, by making any topic that you define on any queue manager in the cluster automatically available on every queue manager in the cluster. However, topic host routed clusters require you to carefully choose the queue managers that host each topic, because all information and publications for that topic pass through those topic host queue managers. This means that the system does not have to maintain channels and information flows between all queue managers. However it also means that publications might no longer be sent directly to subscribers, but might be routed through a topic host queue manager. For these reasons additional load might be put on the system, especially on the queue managers hosting the topics, so careful planning of the topology is required. This topology is particularly effective for networks that contain many queue managers, or that host a dynamic set of publishers and subscribers (that is, publishers or subscribers that are frequently added or removed). Additional topic hosts can be defined to improve availability of routes and to horizontally scale publication workload. SeeTopic host routing in publish/subscribe clusters.

A Hierarchy requires the most manual configuration to set up, and is the hardest topology to modify. We must manually configure the relationships between each queue manager in the hierarchy and its direct relations. After relationships are configured, publications will (as for the previous two topologies) be routed to subscriptions on other queue managers in the hierarchy. Publications are routed using the hierarchy relationships. This allows very specific topologies to be configured to suit different requirements, but it can also result in publications requiring many hops through intermediate queue managers to reach the subscriptions. There is always only one route through a hierarchy for a publication, so availability of every queue manager is critical. Hierarchies are typically only preferable where a single cluster cannot be configured; for example when spanning multiple organizations. SeeRouting in publish/subscribe hierarchies.

Where necessary, the above three topologies can be combined to solve specific topographical requirements. For an example, see Combining the topic spaces of multiple clusters.

To choose a suitable topology for the distributed publish/subscribe network, we need to consider the following broad questions:

  • How big will your network be?
  • How much manual control do we need over its configuration?
  • How dynamic will the system be, both in terms of topics and subscriptions, and in terms of queue managers?
  • What are your availability and scalability requirements?
  • Can all queue managers connect directly to each other?


Procedure

  • Estimate how big your network needs to be.
    1. Estimate how many topics we need.
    2. Estimate how many publishers and subscribers you expect to have.
    3. Estimate how many queue managers will be involved in publish/subscribe activities. See alsoPublish/subscribe clustering: Best practices, especially the following sections:

    If your network will have many queue managers, and handle many publishers and subscribers, you probably need to use a topic host routed cluster or a hierarchy. Direct routed clusters require almost no manual configuration, and can be a good solution for small or static networks.

  • Consider how much manual control we need over which queue manager hosts each topic, publisher or subscriber.
    1. Consider whether some of our queue managers are less capable than others.
    2. Consider whether the communication links to some of our queue managers are more fragile than to others.
    3. Identify cases where you expect a topic to have many publications and few subscribers.
    4. Identify cases where you expect a topic to have many subscribers and few publications.

    In all topologies, publications are delivered to subscriptions on other queue managers. In a direct routed cluster those publications take the shortest path to the subscriptions. In a topic host routed cluster or a hierarchy, you control the route that publications take. If your queue managers differ in their capability, or have differing levels of availability and connectivity, we will probably want to assign specific workloads to specific queue managers. We can do this using either a topic host routed cluster or a hierarchy.

    In all topologies, co-locating the publishing applications on the same queue manager as the subscriptions whenever possible minimizes overheads and maximizes performance. For topic host routed clusters, consider putting publishers or subscribers on the queue managers that host the topic. This removes any extra hops between queue managers to pass a publication to a subscriber. This approach is particularly effective in cases where a topic has many publishers and few subscribers, or many subscribers and few publishers. See, for example, Topic host routing using centralized publishers or subscribers.

    See alsoPublish/subscribe clustering: Best practices, especially the following sections:

  • Consider how dynamic the network activity will be.
    1. Estimate how frequently subscribers will be added and removed on different topics.

      Whenever a subscription is added or removed from a queue manager, and it is the first or last subscription for that specific topic string, that information is communicated to other queue managers in the topology. In a direct routed cluster and a hierarchy, this subscription information is propagated to every queue manager in the topology whether or not they have publishers on the topic. If the topology consists of many queue managers, this might be a significant performance overhead. In a topic host routed cluster, this information is only propagated to those queue managers that host a clustered topic that maps to the subscription's topic string.

      See also the Subscription change and dynamic topic strings section ofPublish/subscribe clustering: Best practices.

      Note: In very dynamic systems, where the set of many unique topic strings is rapidly and constantly being changed, it might be best to switch the model to a publish everywhere mode. See Subscription performance in publish/subscribe networks.
    2. Consider how dynamic the queue managers are in the topology.

      A hierarchy requires each change in queue manager in the topology to be manually inserted or removed from the hierarchy, with care taken when changing queue managers at higher levels in the hierarchy. Queue managers in a hierarchy typically also use manually configured channel connections. We must maintain these connections, adding and removing channels as queue managers are added and removed from the hierarchy.

      In a publish/subscribe cluster, queue managers are automatically connected to any other queue manager that is required when they first join the cluster, and automatically become aware of topics and subscriptions.

  • Consider your route availability and publication traffic scalability requirements.
    1. Decide whether we need to always have an available route from a publishing queue manager to a subscribing queue manager, even when a queue manager is unavailable.
    2. Consider how scalable we need the network to be. Decide whether the level of publication traffic is too high to be routed through a single queue manager or channel, and whether that level of publication traffic must be handled by a single topic branch or can be spread across multiple topic branches.
    3. Consider whether we need to maintain message ordering.

    Because a direct routed cluster sends messages directly from publishing queue managers to subscribing queue managers, we do not need to consider the availability of intermediate queue managers along the route. Similarly, scaling to the intermediate queue managers is not a consideration. However, as previously mentioned, the overhead of automatically maintaining channels and information flows between all queue managers in the cluster can significantly affect performance, especially in a large or dynamic environment.

    A topic host routed cluster can be tuned for individual topics. We can ensure that each branch of the topic tree that has a considerable publication workload is defined on a different queue manager, and that each queue manager is sufficiently performant and available for the expected workload for that branch of the topic tree. We can also improve availability and horizontal scaling further by defining each topic on multiple queue managers. This allows the system to route around unavailable topic host queue managers, and to workload balance publication traffic across them. However, when you define a given topic on multiple queue managers, you also introduce the following constraints:

    We cannot configure high availability or scalability of routing in a hierarchy through multiple routes.

    See also the Publication traffic section ofPublish/subscribe clustering: Best practices.

  • Based on these calculations, use the links provided to help you decide whether to use a topic host routed cluster, a direct routed cluster, a hierarchy, or a mixture of these topologies.


What to do next

You are now ready to configure your distributed publish/subscribe network.

  • Designing publish/subscribe clusters
    There are two basic publish/subscribe cluster topologies: direct routing and topic host routing. Each has different benefits. When you design your publish/subscribe cluster, choose the topology that best fits your expected network requirements.
  • Routing in publish/subscribe hierarchies
    If your distributed queue manager topology is a publish/subscribe hierarchy, and a subscription is made on a queue manager, by default a proxy subscription is created on every queue manager in the hierarchy. Publications received on any queue manager are then routed through the hierarchy to each queue manager that hosts a matching subscription.
  • Distributed publish/subscribe system queues
    Four system queues are used by queue managers for publish/subscribe messaging. You need to be aware of their existence only for problem determination and capacity planning purposes.

Parent topic: Architectures based on multiple queue managers


Related information

Last updated: 2020-10-04