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.
Listed below are the different profiles available in WSO2 API Manager.
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.
Control Plane profile
Used (in multi-tenancy mode/ in multiple gateway mode when Google Analytics is used)
|Traffic Manager profile||Used||Used|
Gateway Profile -
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.
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.
|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.
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.
- Find out more about running API-M profiles.
- See the instructions on configuring a distributed API-M deployment.
- See the instructions on configuring a distributed API-M deployment with Traffic Manager separated.