Configuring Cluster Links

A cluster link connects nodes (either within a cluster or between two different clusters) and allows them to exchange topology information, subscriptions and data.

A cluster link is composed of:

  • one control channel
  • one client profile
  • one data channel per Message VPN

As shown here, a data channel is made up of a bridge and a queue:

For an external cluster link only, there is an additional bridge object, called a DMR bridge, that establishes the data channels between clusters (not shown).

To create a cluster link from the given node to a remote node, enter the following commands:

solace(configure)# routing
solace(configure/routing)# dynamic-message-routing
solace(...igure/routing/dynamic-message-routing)# cluster <cluster-name>
solace(...uting/dynamic-message-routing/cluster)# create link <node-name>

To configure an existing cluster link, enter the following command:

solace(...uting/dynamic-message-routing/cluster)# link <node-name>

To enable the cluster link, enter the following command:

solace(.../dynamic-message-routing/cluster/link)# no shutdown

Where:

<node-name> is the name of the remote node. As a special case, <node-name> may be the string #ACTIVE, which represents the link to the event broker currently active for the virtual router defined by this event broker’s active standby role. This special cluster link always exists, and cannot be removed.

If the remote node is an HA group, use the <node-name> of the primary event broker. In addition, when you configure the remote node connection parameters, provide details for both the primary and the backup (refer to Setting the Connection Address for the Remote Node).

The configuration tasks that you can perform for an existing link include:

If you are configuring DMR cluster links, and you have (or will have) replication enabled, ensure that your link settings follow the guidelines listed in Configuring Cluster Links with Replication.

Setting the Link Span

Links between nodes within the same cluster are called internal links, while links between nodes in different clusters are called external links. This quality of a link is called the link's span. Each end of the link must agree upon its span, or a topology error will occur. The default span of all links is external.

To configure the span of the cluster link, enter the following command:

solace(.../dynamic-message-routing/cluster/link)# span {internal | external}

Where:

internal specifies to connect to a node within the same cluster.

external specifies to connect to a node in a different cluster.

Setting the Link Initiator

While messages are exchanged in both directions over the link, the underlying TCP connection is only established by one side, depending on the value of initiator. Each end of the link must agree upon the initiator, or the link will be disabled. The default initiator is lexical.

To configure the initiator of the link's TCP connections, enter the following command:

solace(.../dynamic-message-routing/cluster/link)# initiator {lexical | local | remote}

Where:

lexical specifies that the node with the higher node-name initiates the connection.

local specifies that the local node initiates the connection. The other end of the link must specify remote.

remote specifies that the remote node initiates the connection. The other end of the link must specify local.

For production deployments, we recommend using the local and remote link initiator configurations.

Setting the Connection Address for the Remote Node

You can provide up to four addresses or fully qualified domain names (FQDNs) for each link, and each will be tried on a round-robin basis. Multiple addresses are required when the remote node may be implemented by multiple event brokers, for the purpose of redundancy and/or replication.

To configure the IP address and optional port that the remote node is reachable from, enter the following command:

solace(.../dynamic-message-routing/cluster/link)# connect-via <addr-port>

Where:

<addr-port> is the IP address or FQDN, and optional TCP port that the remote node is reachable from. For connecting to an appliance, the <addr-port> must resolve to the remote appliance's msg-backbone VRF. IPv4 addresses must be specified in the dotted decimal notation form, nnn.nnn.nnn.nnn. In SolOS version 9.12.0 and later, IPv6 formatted strings (RFC 5952) are supported, however, these addresses must be enclosed in square brackets. The port is specified as a decimal value from 0 to 65535. For example, a correctly formatted IPv4 address is: 192.168.100.1:55555. The same address in IPv6 fromat is [::ffff:c0a8:6401]:55555. If a port is unspecified, the defaults are 55555 for plain-text, 55003 for compressed, or 55443 for SSL. The FQDN can contain up to 253 characters.

Configuring a connect-via address is required only on the broker that initiates the connection.

Setting the Link Transport Method

Link transport may be encrypted, compressed, or both. While the choice to use encryption and compression is independent for every link, the control and data channels of each individual link share the same encryption and compression settings.

Enabling Compression

You can enable or disable compression on the link. Each end of the link must agree upon the choice of compression, or the link will act as if disabled. Compression is disabled by default.

To enable compression, enter the following command:

solace(.../dynamic-message-routing/cluster/link)# transport compressed

Enabling TLS/SSL Encryption

You can enable or disable encryption on the link. Each end of the link must agree upon the choice of encryption, or the link will act as if disabled. Encryption is disabled by default.

The cipher suites offered by the link on outgoing connections to the remote node are the same as the cipher suites configured globally that the sending node allows for incoming message backbone connections.

To enable TLS/SSL encryption, enter the following command:

solace(.../dynamic-message-routing/cluster/link)# transport ssl

Configuring Authentication on the Link

Each individual node is configured as to which forms of authentication are acceptable to it for any of its links (basic, client-certificate, or both). Credentials to be presented to the remote end are configured for clustering at the global scope (refer to Configuring Authentication on a Cluster), but may also be overridden on a per-link basis.

Setting the Authentication Scheme

You can configure the authentication scheme to be used by the link that initiates connections to the remote node. Links support basic and client-certificate authentication.

To configure the authentication scheme, enter the following commands:

solace(.../dynamic-message-routing/cluster/link)# authentication
solace(...e-routing/cluster/link/authentication)# auth-scheme {basic | client-certificate}

Where:

basic specifies to use basic authentication.

client-certificate specifies to use client-certificate authentication.

Setting a Password for Basic Internal Authentication

You can configure the password used to authenticate with the remote node. This password needs to be configured only on the side of the link which initiates the connection, and must match the expected password configured on the remote node. When this per-link password is not configured, the cluster’s password is used instead.

To configure a password to authenticate with the remote node, enter the following commands:

solace(.../dynamic-message-routing/cluster/link)# authentication
solace(...e-routing/cluster/link/authentication)# basic 
solace(...ing/cluster/link/authentication/basic)# password <password>

Where:

<password> specifies the password to authenticate with.

Configuring the Retry Connections for the Links

For event brokers using 10.8.1 and later, you can configure the number of retry attempts and wait time between retries for establishing a connection to the Message VPN on the remote DMR node.

For event brokers using 10.8.0 or earlier, the retry attempts and wait time default to 0 and 3 seconds, respectively and cannot be configured.

Configuration of the retry attempts and wait time between attempts is necessary when more attempts or more time is required to establish the connection. For example, if there are potential latency issues between your DMR nodes (e.g., due to large geographic distances), you may want to increase the retry wait time to allow for more time to establish the connection for the cluster link. For more information, see Configuring the Maximum Retry Attempts and Configuring the Wait Time to Before Retries

You also cannot configure the retry attempts or delay on the #ACTIVE link.

Configuring the Maximum Retry Attempts

You can enter the following CONFIG command to configure the maximum number of retries to the remote Message VPN on another DMR node before the next alternate remote destination is attempted. For example, if the retry count is set to 1, a total of two connection attempts is made for each alternate remote destination where you have the initial attempt and one retry.

To configure the number of retries, run the following CONFIG commands in the Solace CLI:

solace(configure/routing/dynamic-message-routing)# cluster <link-name> link <remote-node-name>
solace(configure/routing/dynamic-message-routing/cluster/link)# retry count <count>

Where:

<count> is an integer from 0 to 255 for the number of times to retry a connection. The default value is 0.

The no version of this command (no remote retry count) resets the number of retries attempted back to the default value.

Configuring the Wait Time to Before Retries

You can enter the following CONFIG command to configure the number of seconds to wait for the connection to be established before attempting a new connection using retry delay:

solace(configure/routing/dynamic-message-routing)# cluster <cluster-name> link <remote-node-name> 
solace(configure/routing/dynamic-message-routing/cluster/link)# retry delay <seconds>

Where:

<seconds> is an integer from 0 to 255 for the number of seconds to wait before retrying a connection. The default value is 3.

The no version of this command, resets the number of seconds to wait to the default value.

Setting the Window Size for the DMR Message Spool

To configure the window size of Guaranteed messages which can be outstanding to the remote node before acknowledgment is received by the local node, enter the following command:

solace(.../dynamic-message-routing/cluster/link)# message-spool
solace(...ge-routing/cluster/link/message-spool)# window-size <number>

Where:

<number> specifies the transport window size for Guaranteed messaging in number of messages.

Configuring Client Profiles for the Cluster Link

Cluster link client profiles are used to assign a common set of configuration properties for link connections that have been successfully authorized.

You can configure various attributes of the client profile used by each cluster link, including:

For more information about provisioning client profiles on PubSub+ event brokers, refer to Configuring Client Profiles.

Although cluster link client profiles share attributes with normal client profiles, they are different objects.

To configure cluster link client profile attributes enter the following command:

solace(.../dynamic-message-routing/cluster/link)# client-profile

Configuring a Cluster Link Queue

Cluster link queues are used to enqueue messages before they are sent over the data connection to neighbor nodes. These TCP transmit queues are used to manage the flow of data that is transmitted from the node over the links to its neighbors.

You can configure various attributes of cluster link queues, including:

For more information about provisioning queues on Solace PubSub+ event brokers, refer to Configuring Queues.

Although cluster link queues share attributes with normal queues, they are different objects.

To configure cluster link queue attributes enter the following command:

solace(.../dynamic-message-routing/cluster/link)# queue

The initial values set for various cluster link queue attributes may differ from the default settings of normal queues.

Setting Cluster Link Attributes

A cluster link attribute is a key-value pair that can be used to locate a DMR cluster link, for example when using client certificate matching rules. For more information, see Configuring Client Certificate Matching Rules.

To create a cluster link attribute enter the following command:

solace(.../dynamic-message-routing/cluster/link)# create attribute <name> <value>

Where:

<name> is the name of the attribute (of up to 64 characters).

<value> is the value of the attribute (of up to 256 characters).

the no version of this command, no attribute <name> <value>, removes the attribute.

The following example sets a cluster link attribute named span with a value of internal for the link. If an appropriate client certificate attribute filter is configured on the cluster, the event broker will apply any corresponding certificate matching conditions when this link attempts to authenticate with the remote node.

solace(.../dynamic-message-routing/cluster/link)# create attribute span internal