API-M Distributed Deployment - Overview

Before deploying WSO2 API Manager (WSO2 API-M), let's understand how the WSO2 API-M distributed deployment works. According to the recommended deployment patterns, a distributed deployment includes API-M server nodes that separately run the API-M profiles. An API-M profile is a server instance that only runs specific components of the API-M server.

API-M Profiles

Listed below are the different profiles available in WSO2 API Manager.

Profile Description
Gateway Profile

Only starts the components related to the API Gateway.

This profile starts the back-end features for data processing.
Control Plane Profile Starts all the API-M components (Traffic Manager, Key Manager, Publisher, Developer Portal) excluding the Gateway.
Traffic Manager Profile Only starts the Traffic Manager component.

Databases used by API-M profiles

When you run the API-M server as separate profiles, databases are used as shown below.

API Manager
database

apimgtdb

WSO2_AM_DB

Shared Database

shareddb

WSO2_SHARED_DB

Control Plane profile

Used

Used

Gateway profile

Not used

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

Gateway Profile - shared_db configuration

Note that the registry data source should not be completely removed from the gateway node, although the shared_db is not required for certain use cases. During server initialization, the user core and registry modules rely on the registry and user store pointing to the default H2 shared db or the H2-based carbon DB. Therefore, ensure that at least the registry and user store configurations are appropriately set.

API-M Components

Listed below are the five components in the API-M server. When you run the recommended API-M profiles, the components (from the below list) that are required for operating the functionalities related to each profile are used.

Component Description
Gateway Responsible for securing, protecting, managing, and scaling API calls.
Key Manager Responsible for all security and key-related operations.
Traffic Manager Used to make a decision on throttling. It also works as an event hub for broadcasting controller events such as throttling events, block conditions, revoke token retrieval events, API events, API policy events, application events, application policy events, application keys events, subscription events, and subscription policy events.
Publisher Enables API providers to easily publish their APIs, share documentation, provision API keys, and gather feedback on API features, quality, and usage.
Developer Portal Enables consumers to self-register, discover API functionality, subscribe to APIs, evaluate them, and interact with API publishers.

Understanding the distributed deployment

In a typical distributed deployment, all API-M components (excluding the API-M Gateway) run in the Control Plane. However, you have the option of separating the Traffic Manager from the Control Plane. With this, there are two patterns under which we can configure a distributed deployment for API-M. They are as follows.

Simple Scalable Deployment

The following diagram depicts how the Control Plane and Gateway profiles communicate in a distributed deployment setup, and also the database connections of each node. To learn how to configure this deployment, refer configuring a distributed API-M deployment.

Distributed deployment

Simple Scalable Deployment with Traffic Manager Separation

The following diagram depicts how the Control Plane, Traffic Manager, and Gateway profiles communicate in a distributed deployment setup. It also depicts the database connections of each node. Separating out the Traffic Manager Component from the Control plane might be needed if any deployment complexities are present in your environment. To learn how to configure this deployment, refer configuring a distributed API-M deployment.

Distributed deployment

What's Next?

Top