This documentation is for older WSO2 products. View documentation for the latest release.
API Manager Clustering Deployment Patterns - Clustering Guide 4.2.0 - WSO2 Documentation
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

WSO2 API Manager includes four main components as the Publisher, Store, Gateway, and Key Manager. In a stand-alone APIM setup, these components are deployed in a single sever. But, in a typical production setup, they need to be deployed in separate servers for better performance. Installing and configuring each or selected component/s in different servers is called a distributed setup.

The following topics introduce the main components of API manager and different ways to set them up in separate servers:

Main components of a distributed setup

The following diagram illustrates the main components of an API Manager distributed deployment.


Figure: Main components of an APIM distributed setup

Let's take a look at each component in the above diagram.

API Gateway

Responsible for securing, protecting, managing, and scaling API calls. For more information, see Architecture.

API Store

Enables consumers to self-register, discover API functionality, subscribe to APIs, evaluate them, and interact with API publishers. For more information, see Architecture. 

API Publisher

Enables API providers to easily publish their APIs, share documentation, provision API keys, and gather feedback on API features, quality, and usage. For more information, see Architecture. 

API Key Manager Server

Responsible for all security and key-related operations. For more information, see Architecture.

Login/Token API in the Gateway node should point to the token endpoint of Key Manager node. It's given as https://localhost:9443/oauth2endpoints/tokenIn a distributed setup it should be https://<IP of key manager node>:<port with offset of keymanager node>/oauth2endpoints/token.

Load Balancers

The distributed deployment setup depicted above requires two load balancers. We set up the first load balancer, which is an instances of WSO2 Elastic Load Balancer (ELB),  internally to manage the cluster. The second load balancer is set up externally to handle the requests sent to the clustered server nodes, and to provide failover and auto scaling.   As the second load balancer, you can use an instance of WSO2 ELB or a third-party product.

Shared Databases  

The distributed deployment setup depicted above share the following databases among the APIM components set up in separate server nodes.

  • User Manager Database : Stores information related to users and user roles. This information is shared among the Key Manager Server, Store, and Publisher. Users can access the Publisher for API creation and the Store for consuming the APIs.

  • API Manager Database : Stores information related to the APIs along with the API subscription details. The Key Manager Server uses this database to store user access tokens required for verification of API calls.
  • Registry Database : Shares information between the Publisher and Store. When an API is published through the Publisher, it is made available in the Store via the sharing registry database.

Message Flows  

The 3 main use cases of API Manager are API publishing, subscribing and invoking. Described below is how the message flow happens in these use cases.

Publishing APIs

A user assigned the publisher role has capability to publish APIs. This is done via the Publisher server. When an API is published in the API Publisher, the API Gateway must be updated with this API so that users can invoke it. Because we are using a clustered Gateway, all Gateway server nodes in the cluster are updated with the published API details, enabling any of these Gateway nodes to serve API calls that are received.

When an API is published, it is also pushed to the registry database, so that it can be made available on the store via the shared database.

Subscribing to APIs

A user with the subscriber role logs into the API Store and subscribes to an API. The user must then generate an access token to be able to invoke the API. When the subscriber requests to generate the token, a request is sent to the Key Manager Server cluster. The token is then generated, and the access token details are displayed to the subscriber via the Store.

Invoking APIs

Subscribed users can invoke an API to which they have subscribed. When the API is invoked, the request is sent to the API Gateway server cluster. The Gateway server then forwards the request to the Key Manager server cluster for verification. Once the request is verified, the Gateway connects to the back-end implementation and obtains the response, which is sent back to the subscriber via the Gateway server.

The diagram below summarizes these message flows.

Distributed deployment patterns

We can identify several distributed deployment patterns involving the API Manager components discussed before. The most commonly-used of these patterns are as follows.

Store and Publisher components in a single server node

The diagram below depicts a minimum deployment of API Manager component nodes. This pattern is for an internal store, so the Store and Publisher components are deployed on a single server node.


Figure: Store and Publisher components in a single server node

Minimum cluster with an external store

This pattern is similar to the previous one, except that the Store component node is deployed on an external network. The diagram below depicts a minimum deployment of the store.


Figure: Store component on an external network

All components in a clustered, internal setup

This pattern extends the individual component nodes and deploys them in a cluster for high availability. Each component node can be extended up to n number of server nodes based on the deployment load. This pattern is based on a complete internal deployment where all API component nodes are deployed internally. The diagram below depicts a minimum deployment of the components.


Figure: All components in an internal cluster

All components in a clustered setup with an external store

This pattern is similar to the one above and also provides high availability, but it considers the use of an external store. The diagram below depicts a minimum deployment of the components.


Figure: All components except the Store in an internal cluster

See Clustering the API Manager for information on how to configure these deployment patterns.

  • No labels