Multi-Node Routing

The Multi-Node Routing (MNR) feature allows multiple Solace PubSub+ message brokers (that is, nodes) to be networked together so that Direct messages published from clients connected to one message broker can be delivered to clients connected to the other message brokers. This effectively distributes the message routing load across multiple message brokers in the network, resulting in aggregate message forwarding rates across the network that exceed the capacity of any one message broker.

Note   
  • The Multi-Node Routing feature is for use with Direct messages only. Multi‑Node Routing does not route Guaranteed messages between message brokers.
  • Network-wide load balancing with (Deliver-To-One) DTO, when used in conjunction with Multi-Node Routing, is not supported. A single node will always give priority to locally-connected clients when load balancing. Only when there are no available local clients eligible for DTO delivery will the message broker pass the DTO request to downstream message brokers. In such scenarios, no attempt will be made to load balance amongst multiple neighboring message brokers.

Multi-node Routing uses the Solace Content Shortest Path First (CSPF) protocol to link neighbor message brokers and allow them to discover the complete message-routing network topology to which they belong. Message brokers can then determine which neighbor would be the optimal node for the forwarding of messages addressed to specific destination message brokers. This topology discovery is continuous and dynamically updated as message brokers within the network go on or offline.

Multi-Node Routing also uses the Subscription Management Routing Protocol (SMRP) to enable linked neighbor message brokers to propagate topic subscriptions added by clients of one message broker throughout the message‑routing network. This allows messages that are published to one message broker to be routed to other message brokers that also have connected clients interested in those topics.

By default, the data and routing traffic carried over Multi-Node Routing links is carried in plain text over TCP. Data compression can optionally be applied on these links. However, if you will be transmitting sensitive data in the messages sent between message brokers, Transport Layer Security (TLS)/ Secure Sockets Layer (SSL) encryption can be applied to the Multi-Node Routing linksʼ data channels.

Note   
  • Compression is only available on plain-text over SMF client connections to the neighbor message broker; compression is not available on TLS/SSL encryption is used for the data connections (that is, secure/encrypted client connections) to the neighbor.
  • TLS/SSL encryption is only supported on the data links between Solace PubSub+ appliances. It is not currently supported for Solace PubSub+ software message brokers.

Multi-Node Routing Compared to Message VPN Bridging

Messages published on one message broker can also be delivered to another networked message broker through the use of Message VPN Bridging. However there are some fundamental operational differences between the Multi-Node Routing and Message VPN Bridging. The table below lists some of the differences between the two.

Comparing Multi-Node Routing and VPN Bridging

 

Multi-Node Routing

Message VPN Bridging

Supports Direct Messaging

Yes.

Yes.

Supports Guaranteed Messaging

No.

Yes.

Only links between Message VPNs with the same names

Yes.

No. Bridges can link Message VPNs with the same or different names.

All subscriptions in a Message VPN are used for topic matching

Yes.

No. Only those subscriptions manually added to a bridge or queue associated with a bridge are used.

Topic subscriptions are static

No. Topic subscriptions are dynamically updated as clients add or remove subscriptions.

Yes. Administrators manually add subscriptions to bridges (Direct) or queues associated with bridges (Guaranteed).

Supports linking of Message VPNs of different names

No. Only Message VPNs with the same name on separate message brokers can be linked.

Yes. Message VPNs with different names can be linked.

Supports linking of Message VPNs on the same message broker

No.

Yes. Message VPNs on the same message broker can be linked if they have different names.

Supports data compression on links Yes. Yes.
Supports TLS/SSL encryption on links Yes (appliance only). Yes.

Note that both features can be used together in a messaging network when carefully deployed. For more information on Message VPN Bridging, refer to Message VPN Bridge Fundamentals.

After considering the differences between Multi-Node Routing and Message VPN Bridging shown in the preceding table, some general recommendations on when to use each feature are provided below.

You should use Multi-Node Routing when:

  • Guaranteed Messaging is not required
  • Message VPNs span multiple message brokers, with the same Message VPN names on each message broker
  • there is no need to limit the advertised subscriptions in a Message VPN (that is, subscriptions can be advertised to all message brokers in the network)

Other Multi-Node Routing advantages:

  • very simple to configure—the only configuration required is identifying the neighbor links between message brokers and identifying which Message VPNs should advertise their subscriptions into the network
  • uses a common name for the Message VPN across the network
  • dynamically discovers the message brokers that are part of the same Message VPN
  • dynamically reroutes around failed or offline message brokers or failed inter-message broker links
  • guarantees a loop-free forwarding topology at all times
  • automatically propagates subscriptions for the Message VPN between message brokers in the network
  • subscriptions are automatically withdrawn from the network if all clients who subscribed to the topic have disconnected from the message broker

You should use Message VPN Bridging when:

  • Guaranteed Messaging is required
  • you need to connect two distinct Message VPNs
  • you need to carefully control which subscriptions get advertised between Message VPNs on the message brokers

Note:  When you use Message VPN bridging, be careful with complex network messaging configurations to ensure a loop-free forwarding topology and that subscriptions on bridge links do not attract excessive traffic for which there are no interested clients on the local message broker.

Related Provisioning and Configuration Information

For information on how to configure and manage routing links and how to enable subscriptions to be exported over those links, refer to Multi-Node Routing Management.

Linking Message Brokers

A routing link defines the route for connectivity between message brokers. When building a messaging network, administrators must explicitly configure the routing links between message broker neighbors. Using these bi-directional links, those neighbors are then able to exchange network topology using the CSPF protocol and subscription information using SMRP. These configured neighbor links allow Direct messages published by clients to travel between neighbors on their way to the final subscriber clients.

Compression can optionally used on neighbor message broker data connections (only data connections are affected).

Note:  Both ends of a message routing link must be configured. That is, to link message brokers A and B, there must be a neighbor configuration in A for B, and a neighbor configuration in B for A.

Multiple bi-directional routing links can be used to route messages between message brokers in your network for load balancing or redundancy, and the routing protocols that are used will calculate the shortest path (as defined by link costs). Routes with lower link costs are preferred over those with higher link costs. If there are multiple routing links with equal cost paths, then a route with less hops will be chosen as the preferred route.

Where alternative routes are possible, an administrator can assign explicit link costs to indicate the best inter-neighbor message route. The rationale for assigning a higher link cost to a particular route could be based on considerations such as the speed, latency, or monetary cost of the underlying communication link.

Routing Link Cost Examples

To prefer one route over another (for example, to specify a default link), you can change the routing link costs to set the preferred message route.

In the example shown in Routing Link Cost—Example 1, there are four bi-directional routing links available between message brokers A, B, C, and D:

  • A-B routing link
  • B-C routing link
  • B-D routing link
  • C-D routing link

If the cost associated with the A-B routing link is set to 150, and the cost associated with the three other routing links is set to 100, messages routed from message broker A to C travel from message broker A to message broker B and then on to message broker C.

Routing Link Cost—Example 1
Routing Link Cost-Example 1

However, as shown in Routing Link Cost Example 2 , if the cost associated with the A-B routing link is set to 150, while the cost associated with the B-C routing link is set to 250, and the cost associated with the C-D and B-D routing links is set to 100, messages routed from message broker A to C travel from message broker A to Site B, on to message broker D, and then to message broker C. Such a cost configuration may be desirable in cases where, for example, two message broker sites in one city are connected by a high-speed link, while other overseas message broker sites are connected by low-speed links.

Routing Link Cost Example 2
Routing Link Cost—Example 2

Subscription Propagation and Management

When multiple-node routing is used, topic subscriptions and matching messages are only distributed between matching Message VPNs. This means that a message broker with a topic subscription in one message VPN can only receive matching messages from a neighbor message broker that were published to a Message VPN of the same name. For example if a message was published to Message VPN Blue on Router A, that message may be delivered to a client on Router B with a matching topic subscription in a Message VPN Blue, but it may not be delivered to a client on Router B with a matching topic subscription in a Message VPN Green.

Topic subscriptions can be added by external clients and internal clients (for example, the internal client of the Message VPN, #client). When external client subscriptions are associated with a specific virtual router name; internal client subscriptions are associated with a physical message broker name.

Exporting Topic Subscriptions

Each Message VPN has a topic subscription export policy associated with it, which controls whether or not topic subscriptions on the Message VPN get advertised to other message brokers in the network. The default policy is to not export subscriptions.

To receive messages from other message brokers, the subscription export policy in a Message VPN must be set to export subscriptions. This causes all subscriptions added locally to the Message VPN to be dynamically propagated to the other message brokers in the network. A covering set of subscriptions for point-to-point (P2P) Inboxes is also exported. It helps avoid race conditions between messaging traffic and subscription propagation in cases such as request/reply messaging.