Balancing the number of integration servers

An IBM® Integration Bus integration node supports any number of integration servers, there is no finite limit. Practical limitations such as the amount of real memory or swap-space, do force a maximum limit to ensure continued levels of service.

Large systems typically have under 100 integration servers. An integration node with over 100 integration servers is considered 'very large', and it is recommended to review the strategy that is used to create integration servers and assign message flows to them. The number of integration servers that are used does not affect the amount of either virtual memory or real memory that is used by an individual integration server. However, the number of integration servers does have a strong effect on the amount of real memory that is required by the integration node. It is therefore necessary balance business requirements against performance requirements when you calculate how many integration servers are required.

Just because an integration server can host hundreds of message flows, it is not always a good idea for it to do so. For example, if the integration server fails, many applications are lost until the integration server is restarted. And that restart time increases significantly the more message flows that the integration server hosts.

Strategy

It is good operating practice to have a strategy in place to control the assignment of message flows to integration servers. A number of schemes are commonly used, such as:
  • Limit message flows for one business application to one integration server: Large business applications might require multiple integration servers depending on the number of message flows for the business area.
  • Assign message flows together when they have the same hours of availability: There is little point in assigning flows for the online day and the batch activities at night into the same integration server; it is not possible to shut down the integration server without interrupting the service of one set of flows.
  • Assign 'high profile' flows to their own integration server: When you use a high profile or high performance application for example, assign their message flows to their own integration server. Specific tuning and configuration can then be applied to just those high profile components, and the loss or maintenance of lower priority flows does not affect these ones.
  • Use general utility integration servers to host many less important flows.
  • In a deployment with many integration nodes, avoid deploying all message flows to all integration nodes. Instead, use some integration nodes for processing specific applications only. By deploying everything everywhere, the memory usage rises considerably, so this pattern reduces that usage. When you have message flows that you know use large amounts of memory, try to assign them to the lowest number of integration servers as possible. This assignment reduces the number of integration servers that become large and use more memory, and therefore reduces the amount of real memory that is required.

Whichever strategy you use, plan for future expansion and ensure that the topography still works when hundreds more services are added. Decisions that are made in 'the early days' often do not scale when hundreds more services are added, and the demand for more real memory becomes a problem.