Nodes and Clusters
API Gateway supports clustering to achieve horizontal scalability and reliability. The following figure illustrates an API Gateway cluster consisting of multiple API Gateway nodes.
Each API Gateway cluster node holds all the API Gateway components including UI, the API Gateway package running in webMethods Integration Server, and an API Gateway Data Store instance for storing assets. A load balancer distributes the incoming requests to the cluster nodes. The synchronization of the nodes is performed through a Terracotta server array and API Gateway Data Store clustering that is defined across the API Gateway Data Store instances.
Note:
API Gateway does not require an external RDBMS for clustering.
As each node of an API Gateway cluster offers the same functionality, nodes can be added or removed from an existing cluster. The synchronization of any new node happens automatically. The synchronization includes configuration items, and runtime assets like APIs, policies, and applications. The synchronized runtime assets become active automatically.
The minimum requirements to achieve high availability in API Gateway are as follows:
Two
API Gateway instances.
Three
API Gateway Data Store instances.
Two Terracotta Server instances (Active-Passive).
Note:
Though only two
API Gateway instances are sufficient, Software AG recommends the usage of three instances. If you use only two
API Gateway instances, then you must have an additional API Gateway Data Store instance (Elasticsearch). The three Elasticsearch instances are required to form a proper Elasticsearch cluster to avoid split-brain scenario.
If you have
API Gateway Advanced Edition instances, clustering the
API Gateway instances requires clustering of Elasticsearch and clustering of
API Gateway nodes using Terracotta.
If you have
API Gateway Standard Edition instances, clustering the
API Gateway instances does not require clustering using Terracotta. The API Gateway nodes just have to connect to Elasticsearch cluster.
When you use one Terracotta server for multiple product clusters (for example, API Gateway cluster, Integration Server cluster) in parallel, provide unique names for each cluster in order to avoid conflicts.
