Configuring Cluster Links with Replication
When you create cluster links to the members of a replication group, the data channels are shared between those two links. This creates a situation where the link settings can conflict with each other. This is explained in detail below.
Shared Data Channels
As described in Configuring Cluster Links, a DMR cluster link is composed of:
- one control channel
- one client profile
- one data channel per Message VPN. A data channel is made up of a bridge and a queue.
If a cluster link goes to a node that is part of a replication group, then that link's data channels are shared with the link to the other node of the replication group. Because of this, the pair of links share a single bridge per Message VPN, and single link queue per Message VPN.
Consider the example shown in the following diagram:
- Each region (depicted by a gray oval) is a separate DMR cluster.
- In each region there are two nodes, each of which consists of one High-Availability (HA) pair.
- Each node in the network is connected to every other node by a DMR link:
- Nodes between clusters (regions, in this example) are connected by external DMR links
- Nodes within the same cluster (for example, Seattle and San Jose) are connected by internal DMR links.
- The cluster links from San Jose to Toronto (red) and Montreal (blue) share the same set of data channels (green; one per message VPN), but each link has its own control channel and client profile. This is illustrated in the green detail view.
Configuring Links with Shared Data Channels
Because a channel is not directly configured, but rather is constructed based on the settings in its parent link, a shared data channel must be set up based on the combined configurations of the two parent links. In many cases the two configurations can be combined in a compatible manner. However, this not true for all settings, and it is possible to have conflicts.
If there is a conflict between the links, the links will be operationally DOWN. The show cluster <cluster-name-pattern> link *
command will indicate the conflicting attribute in the Reason
field.
The following table details the settings where conflicts can occur:
Link Setting | Details |
---|---|
authenticationScheme |
The bridge as a whole must have a single authentication scheme. That is, both links must use the same authentication scheme. |
initiator |
The initiator must be consistent between both links, so that initiation happens the same way regardless of which DR mate is active. |
span | The topology relationship (internal orexternal ) for both links between a node and a remote DR-pair must be the same. |
queueDeadMsgQueue queueEventSpoolUsageThreshold queueMaxDeliveredUnackedMsgsPerFlow queueMaxMsgSpoolUsage queueMaxRedeliveryCount queueMaxTtl queueRejectMsgToSenderOnDiscardBehavior queueRespectTtlEnabled |
These values are associated with the single shared queue, and therefore must be the same for both links. |
egressFlowWindowSize |
This value is associated with the single shared queue; this setting must be the same for both links. |