Load Balancing with a Non-Clustered Group of Integration Servers
Integration Servers can receive messages from the same messaging provider in a load-balanced manner if the Integration Servers are connected to the messaging provider as a non-clustered group. In a non-clustered group, multiple Integration Servers act as a single messaging client but are not members of a cluster.
Note:
In addition to the term “non-clustered group,” the terms “stateless cluster” and “external cluster” are sometimes used to describe the situation in which a group of Integration Servers function in a manner similar to a cluster but are not part of a configured cluster.
Integration Servers can receive messages from the same messaging provider in a load-balanced manner if the Integration Servers are connected to the messaging provider as a non-clustered group.
To receive messages in a load-balanced fashion, each Integration Server must:
Connect to the same messaging provider. A group of non-clustered
Integration Servers can receive messages in a load-balanced fashion from
Universal Messaging or
Broker. The messaging connection aliases should be the same on each
Integration Server.
Use the same client group. When
Broker is the messaging provider, each
Integration Server must use the same client group. Use the
Integration Server Administrator to specify the client group for your
Integration Servers. For instructions, see
Creating a Broker Connection Alias.
Have the same triggers. To receive message in a load-balanced manner, the non-clustered
Integration Servers must act as a single messaging client, which includes having the same document subscriptions. For information about configuring
webMethods messaging triggers, see
webMethods Service Development Help.
Integration Servers in a non-clustered group can also share a document history database and a cross-reference database without being in an Integration Server cluster.
Note:
A stateless cluster of Integration Servers does not use a Terracotta Server Array.