This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Understanding the Distributed Deployment of WSO2 API-M

Before understanding how to deploy WSO2 API Manager (WSO2 API-M), let's understand the WSO2 API-M distributed deployment better.

Understanding the WSO2 API-M architecture

WSO2 API Manager uses the following main components:

Publisher

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

Store

Enables consumers to self-register, discover API functionality, subscribe to APIs, evaluate them, and interact with API publishers.

Key Manager

Responsible for all security and key-related operations.

Gateway

Responsible for securing, protecting, managing, and scaling API calls. 

Traffic ManagerUsed to make a decision on throttling.

For more information on the above, see the main components of a distributed system.

Additionally, API Manager uses the following databases, which are shared among the 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. The User Manager database is also referred to as WSO2UM_DB and userdb.
  • 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 that are used for verification of API calls. The API Manager database is also referred to as WSO2_AM_DB and apimgtdb.
  • 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 shared registry database. Although you would normally share information between the Publisher and Store components only, if you are planning to create this setup for a multi-tenanted environment (create and work with tenants), it is required to share the information in this database between the Gateway and Key Manager components as well. The Registry database is also referred to as WSO2REG_DB and regdb.
  • Message Broker database - Traffic Manager uses this database as the message store for broker when advanced throttling is used. The Message Broker DB is also referred to as WSO2_MB_STORE_DB and  mbstoredb.

WSO2 API Manager components use the databases as follows:


 

API Manager
database

apimgtdb

WSO2_AM_DB

User Manager
Database

userdb

WSO2UM_DB

Registry Database


regdb

WSO2REG_DB

Message Broker
Database

mbstoredb

WSO2_MB_STORE_DB

Publisher

Used

Used

Used

Not used

Store

Used

Used

Used

Not used

Key Manager

Used

Used

Used (in multi-tenancy mode)

Not used

Gateway

Not used

Used (in multi-tenancy mode)

Used (in multi-tenancy mode/ in multiple gateway mode when Google Analytics is used)

Not used
Traffic ManagerNot usedNot usedNot usedUsed

Notes

  • Although the Gateway does not use the WSO2 API Manager database and the WSO2 Message Broker database, the default connections are required; therefore, do not remove the default configurations in the <API-M_HOME>/repository/conf/datasources/master-datasources.xml file. These connections should be your default database (H2 database).
  • The Gateway node creates a connection at the start-up with the WSO2 API Manager database, but this connection will not be used later on.
  • If you have more than one Traffic Manager node, each Traffic Manager node must have its own Message Broker database (WSO2_MB_STORE_DB).This database does not necessarily have to be maintained outside of the container for each Traffic Manager node. WSO2_MB_STORE_DB can be implemented as a local DB inside the pod since the data stored is temporary.

When we consider a distributed deployment of WSO2 API Manager, we have the option of separating the five components and clustering each component as needed. Let's look more closely at how the API Manager components are deployed separately.

Understanding the distributed deployment

In the following diagram, the five components are set up in a distributed deployment, and the five databases are connected to the relevant components respectively. The entire setup is also fronted by a load balancer. 

In a clustered setup, if the Key Manager is NOT fronted by a load balancer, you have to set the KeyValidatorClientType element to ThriftClient in the <API-M_HOME>/repository/conf/api-manager.xml file, to enable Thrift as the communication protocol. You need to configure this in all the Gateway and Key Manager components.