Cluster farm

The B2Bi cluster farm is an installation architecture in which the operations of multiple B2Bi clusters are linked together through a coordinating server. This architecture provides the following benefits:


The cluster farm provides dramatically increased message throughput compared to single-cluster installations.

High availability

The cluster farm provides improved server availability compared to single-cluster installations.


A cluster farm is highly extendable, through the simple addition of clusters.


As in single-cluster architectures, the B2Bi cluster farm assures the unique identity and serial order of consumed messages. Received acknowledgements are correctly linked to the original sent messages, regardless of the originating cluster.

How does a cluster farm work?

A B2Bi cluster farm comprises:

  • Multiple independent B2Bi clusters – Each cluster has its own shared file system and database.
  • A single farm server – This is a central (high-available) component which provides the shared layer of services between the clusters.

The following figure provides a basic view of cluster farm architecture:

B2Bi cluster farm architecture.

The B2Bi clusters and the farm server are independent servers. It is recommended that you co-locate the cluster and farm server on the same site to reduce latency to a minimum.

All message processing occurs in the B2Bi clusters. The central farm server does not process data.

The farm server is a light server that runs in active/active (high-availablity) mode. It requires a small, fast disk drive. This server runs the essential tasks that must be shared by all clusters.

Load balancers are required:

  • At the front end of the cluster farm server to ensure access to the farm server from each cluster node
  • For incoming traffic to the farm of B2Bi clusters, to route incoming traffic across clusters

In a traditional B2Bi cluster, the cluster owns a complete set of tasks, as illustrated in the following figure:

Example of tasks residing on a non-farm cluster.

In a cluster farm architecture, each B2Bi cluster delegates a certain part of its tasks to the farm server, as illustrated in the following figure:

Cluater tasks delegated to the farm server.

This enables the farm server to coordinate the production activities of the clusters so that they can process messages in parallel. The farm server:

  • Provides unique IDs for the X12, EDIFACT and TRADACOMS messages that are enveloped in the farm, regardless of the cluster the message is processed on
  • Correlates sent messages and message responses (acknowledgements and receipts)
  • Checks for message duplication



A group of servers that together offer a higher computing capacity for a particular goal than an individual server.

Farm server

A B2Bi central (high-availability) server component that provides shared services among the clusters. Only one farm server can run at a given time in a cluster farm.

Farm architecture

The combination of the B2Bi clusters with a farm server.


A B2Bi server configured in a failover architecture. Multiple clusters can run in a cluster farm.

How do I install a B2Bi cluster farm?

A B2Bi cluster farm requires the use of two installers:

B2Bi Server installer

Installs B2Bi clusters. When you run this installer, you have a Farm cluster participant option. When you install a B2Bi cluster with this option, additional logic is activated which enables the cluster to cooperate with other clusters through the shared farm server.

The participation of a cluster can be changed after the initial installation, by running the installer in "configure mode". Any B2Bi cluster can be configured to either run independently or as part of a cluster farm.

Farm Server installer

Installs the farm server. You install a single instance of the farm server for a B2Bi cluster farm.

For details of cluster farm installation, see the B2Bi Installation Guide.

Processing and monitoring characteristics

  • The processing state and history of a message are typically shared within a cluster but not beyond the cluster that processes it.
  • The farm architecture does not change the characteristics of a B2Bi cluster. Each cluster can still comprise one or more nodes.
  • If the processing of a message fails (due to issues in the processing cluster), the message is not automatically redirected to another processing cluster.
  • For monitoring, each processing cluster only captures its own processing history. End-to-end visibility must be provided by a cross-product monitoring tool such as Sentinel.

Monitoring and tracking

Each processing cluster only captures and logs its own processing history. For end-to-end tracking of message-processing events across clusters, the use of Sentinel is recommended.

The following graphic illustrates a cluster environment with Sentinel integrated:


  • The network connection to the farm server cluster is a possible single point of failure.
  • Asynchronous enveloping is not supported. Only single documents and “Map entire Interchange” type flows can be deployed.
  • Each cluster only logs information about its own messages. EDI correlation (waiting for ack) is only visible in Sentinel.
  • Sequential and serial processing are guaranteed only within a cluster.
  • The synchronization of configurations between clusters must be performed manually through the deployment of whole system backups or peer networking.
  • Centralized start / stop / status commands are not provided for this release.
  • Centralized pickup management is not provided for this release.

Related topics

Related Links