Bridging to Remote Event Brokers That Use Redundancy

You can establish Message VPN bridge connections to remote PubSub+ software event brokers and appliances when they are deployed in a redundant configuration to provide fault tolerance.

There are three different redundancy models:

To keep the examples simple, not all configuration commands required to create a bridge are shown in this section—only those commands that are unique to the redundancy models being discussed are shown.

Bridging to Remote Software Event Brokers Versus Appliances

The process of bridging to remote event brokers that use redundancy is similar between software event brokers and appliances. The differences are as follows:

  • Appliances support IP address take-over. Therefore, an event broker that is initiating the bridge connection always connects to the same address regardless of which appliance is active from the remote appliances that use redundancy.

  • With software event brokers, the primary and backup event brokers that form a redundant group have unique IP addresses, and a host list must be used to connect to the active event broker. The event broker that is initiating the bridge connection tries to connect to the first address on this host list. If it doesn't connect, it tries the second address, and so on. When configuring a bridge to a remote software event broker that is in a redundant configuration, you must configure the host list for the remote redundant group (see Configuring a Host List for Software Event Brokers).

Configuring a Host List for Software Event Brokers

Configuring a host list specifies the IP addresses that an event broker uses to initiate a bridge connection to remote software event brokers in a redundant configuration. To configure this host list, you can repeat the following command up to four times on the bridge so that up to four distinct Remote Message VPNs can be configured:

create message-vpn <vpn-name> {router <virtual-router-name> | connect-via <addr> [interface <phys-intf>]}

Where: 

  • <vpn-name> is the remote Message VPN name.

  • <virtual-router-name> is the name of the virtual remote router where the Message VPN is located.

  • <addr> [interface <phys-intf> is the IP address (and optional port) where the remote router should be reached. This IP address can be a static or virtual address of the remote router. For bridges that are looping back to a Message VPN on this router, use the 127.0.0.1 IP address (for example, 192.1.2.3:12345).

Each combination of <vpn-name> and either <virtual‑router-name> or <addr> <phys-intf> must be unique, and a mixture of the two possible combinations is not allowed.

This creates an internal host list, which provides potential redundant hosts for the bridge. When adding a new host source entry, it is appended to the end of the existing host list. Its position can be modified through the connect-order Remote Message VPN Bridge CONFIG command (see Configuring Connect Orders).

Bridging With Event Brokers Using Active/Standby Redundancy

The figure below shows a pair of event brokers (solace2 and solace3) that have been configured to operate in an active/standby configuration. Message VPN Green on solace1 is configured with a VPN bridge connection to Message VPN Yellow on solace2, so that Message VPN Green can receive messages from VPN Yellow.

If solace2 goes offline for any reason, solace3 takes over for the primary IP addresses of solace2, and provides service for all of the Message VPNs on solace2.

VPN Bridging with Active/Standby Redundancy

Illustration depicting the concepts described in the surrounding text.

No special configuration is needed on solace1 to make use of this redundancy model. The solace1 event broker is simply configured with a bridge connection from Message VPN Green (primary), to Message VPN Yellow on solace2, connecting through the primary address of solace2 (or the Domain Name System [DNS] name corresponding to that primary address):

solace1(configure)# create bridge To-Yellow message-vpn Green primary
solace1(configure/bridge)# create remote message-vpn Yellow connect-via solace2

To have Message VPN Yellow on solace2 connect to Message VPN Green on solace1, solace2 needs to be configured with a bridge connection from Message VPN Yellow (primary) to Message VPN Green on solace1 connecting through the primary address of solace1 (or the DNS name corresponding to that primary address).

When Config-Sync is enabled for both event brokers in the redundant pair, the configuration parameters between them are automatically synchronized. Therefore, a bridge connection from Message VPN Yellow (backup) on solace3 to Message VPN Green on solace1 is also created.

Bridging With N+1 Redundancy Using Alternate Remote Connections

The figure below shows a set of event brokers (solace2, solace3, and solace4) deployed in an N+1 redundancy configuration. The solace4 event broker acts as a backup event broker for the Message VPNs configured on the solace2 and solace3 event brokers. In this configuration, clients connecting to solace2 use the hostlist feature in the PubSub+ Messaging APIs to connect to solace4, if solace2 is unreachable. Similarly, clients connecting to solace3 use the host list feature to connect to solace4, if solace3 is unreachable.

Message VPN Green on solace1 is configured with a bridge connection to Message VPN Yellow on solace2 so that it can receive messages from Message VPN Yellow.

In this case, the Message VPN bridge on the solace1 event broker must be configured with multiple “remote” parameters, to identify the fallback connection for the bridge if the primary connection cannot be established:

solace1(configure)# create bridge To-Yellow message-vpn Green primary
solace1(configure/bridge)# create remote message-vpn Yellow connect-via solace2
solace1(configure/bridge/remote)# connect-order 1
solace1(configure/bridge/remote)# exit
solace1(configure/bridge)# create remote message-vpn Yellow connect-via solace4

solace2(configure/bridge/remote)# connect-order 2

Bridging with N+1 Redundancy Using Alternate Remote Connections

Illustration depicting the concepts described in the surrounding text.

To guard against situations whereby a temporary loss of connectivity to solace2 causes the bridge connection to be inadvertently established to solace4, it is recommended that the remote retry count and remote retry delay Bridge VPN CONFIG command parameters for the bridge be set to a sufficiently high value to debounce any transient network outages that may occur.

Alternatively, many network operators choose to administratively disable through the shutdown command the Message VPNs on the backup event broker, and only enable through the no shutdown command a particular backup instance of a VPN when the primary event broker for that VPN has gone offline. However, such a policy increases failover times substantially, since manual intervention is required to bring the backup VPN instances online.

In cases where VPN Yellow on solace2 wishes to connect to Message VPN Green on solace1, the solace2 and solace4 event brokers need to be configured with a bridge connection to Message VPN Green on solace1:

Since active/standby redundancy is not being used in this case, the bridge connection is a primary connection on both the solace2 and solace4 event brokers.

solace2(configure)# create bridge To-Green message-vpn Yellow primary
solace2(configure/bridge)# create remote message-vpn Green connect-via solace1

solace4(configure)# create bridge To-Green message-vpn Yellow primary
solace4(configure/bridge)# create remote message-vpn Green connect-via solace1

For such a configuration, it's strongly recommended that the Message VPNs on the backup event broker be administratively disabled through the shutdown command under normal operating conditions, and only enabled for activation when the primary event broker has failed. Otherwise, the Message VPN bridges on the backup event broker always attract traffic from the event brokers to which they are connected, even when the Message VPNs are on standby, and do not have active subscribers connected to them.

Bridging With N+1 Redundancy Using DNS Redirection

The N+1 redundancy model when using DNS redirection is virtually identical to the redundancy model that makes use of alternate remote connections, as shown in the figure above. However, when using DNS redirection, the same event broker DNS name is used at all times, so there is no need to configure an alternate connection. The configuration on the solace1 event broker becomes the following:

solace1(configure)# create bridge To-Yellow message-vpn Green primary
solace1(configure/bridge)# create remote message-vpn Yellow connect-via solace2
solace1(configure/bridge/remote)# exit

The disadvantage of this redundancy approach is that in a failover scenario, the network operator must reconfigure DNS, such that requests for the address of solace2 return the IP address of solace4.

All the recommendations around shutdown of the Message VPNs on the backup event broker discussed in Bridging With N+1 Redundancy Using Alternate Remote Connections apply also to redundancy using DNS redirection.