Integration Server 10.15 | Clustering Guide | Installation and Setup | Installing and Setting Up the Integration Servers in a Stateful or Stateless Cluster | Server Environment
 
Server Environment
All Integration Servers that you want to include in a cluster must be of the same release and at the same patch level. However, the Integration Servers can be on different operating systems; for example, one server on Windows, one on UNIX, and one on Linux.
Software AG recommends that you maintain the same environment for all servers in a cluster. For server clustering to work effectively, you should keep the following the same on all servers in the cluster:
*Each server should have the same set of licensed capabilities.
*All servers should have the same packages of services. For a service to execute on any server in the cluster, that service must exist in the same package on every server in the cluster.
Important:
Identically named MQTT triggers and MQTT connection aliases should not exist on each node in the cluster. Furthermore, MQTT connection aliases in a cluster should all use unique connection client IDs. No duplicate connection client IDs should be used. The cluster limitations are because the MQTT specification does not support multiple clients sharing a subscription. Identical MQTT triggers share the same subscriptions and the same connection client ID. The connection client ID of the MQTT trigger is the connection client ID value of the MQTT connection alias plus the trigger name.
Note:Software AG recommends that you use webMethods Deployer or the package replication functionality in the Integration Server Administrator to copy packages to other servers in the cluster, instead of using Designer to copy them. For information about webMethods Deployer, see the webMethods Deployer User’s Guide. For information about package replication, see webMethods Integration Server Administrator’s Guide.
*Each server should have the same user accounts. The server uses user account information to authenticate clients. When a server redirects a request to an alternate server, the alternate server re-authenticates the user using the credentials supplied to the original server. If authentication fails, the request fails.
*Access to services should be the same on all servers. Integration Server uses group information and ACLs to determine whether a client has access to a service. All Integration Servers should have the same groups with the same group membership. Services should be protected by the same ACLs. The ACLs should identify the same Allow Groups and Deny Groups.
If a request is redirected to a server that denies access to the requested service, the request will fail.
*Each server should have the same public caches. One of the purposes of clustering is to allow a session to be directed to any server within a cluster and for the session to be processed the same way. Some of that processing may involve caching, in which case the same caches, with identical configurations, need to be on each server in the cluster.
Note:Software AG recommends that you use webMethods Deployer to copy cache managers and caches to other servers in the cluster.
*Each server should have the same event subscriptions. Integration Server saves information for event types and event subscriptions in the eventcfg.bin file. This file is generated the first time you start an Integration Server and is located in the following directory: Integration Server_directory /instances/instance_name/config. Copy this file from one server to another to duplicate event subscriptions on all servers in the cluster.
*Clock time must be the same on all servers. The clocks on all machines in the Integration Server cluster must be synchronized for scheduled jobs to work properly in a cluster.
*Each Integration Server should connect to the same messaging providers. All servers should use the same messaging connection aliases to connect to the same messaging providers (Broker and/or Universal Messaging). Each messaging connection alias with the same name must use the same client prefix. Furthermore, each Broker connection alias must use the same client group.
*Each server should connect to the same set of databases. For example, if you are using the audit database to store audit data, all servers must connect to the same audit database. If you are using a back-end database for application-related data, all servers must connect to the same back-end database.
*Each server should have its own diagnostic port. If you plan to troubleshoot using the diagnostic port, you must configure a diagnostic port for each server in the cluster. The diagnostic port can access only the Integration Server on which it is defined. For more information about the diagnostic port, see Adding an HTTP Diagnostic Port.
*Each server should have its own Tspace. If you want the Integration Servers in a cluster to temporarily store large documents in a hard disk drive space rather than keep them in memory, you must define a different Tspace for each Integration Server in a cluster.
*In a stateful cluster, every server must point to the same Terracotta Server Array . The Integration Servers must use the same Terracotta Server Array URLs and the same cluster name. Session timeout and time-to-live should be the same on all servers. If it is not the same, session lifetime will be unpredictable. For more information about using Terracotta with the cluster, see Using Terracotta as the Caching Software for a Stateful Cluster.