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. |
| Developer Portal | 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 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. |
For more information on the above, see the main components of a distributed system.
API Manager uses the following internal datastores to store temporary internal system data required by the local instance of the API Manager.
-
Carbon database - Stores general internal data related to the product.
-
Message Broker database - Stores the product's message broker related data.
Note
Product users should not configure the above datastores to use an external RDBMS. These datastores will be managed locally by the respective product instance.
Additionally, API Manager uses the following databases, which are shared among the server nodes. These are responsible for storing user-specific application data.
- 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.
- Shared database - Stores information related to users and API metadata. In previous versions of API Manager a distinction was made between the user management database(used to store users and user roles) and the registry database(used to store API metadata). But now the Shared database will unify these requirements under one single database instance. This helps to reduce the complexity of the deployment. The Shared database user related information is accessed by the Key Manager Server, Developer Portal, and Publisher. The Shared database API metadata is accessed by the Publisher and Developer Portal. Optionally if you are planning to create this setup for a multi-tenanted environment (create and work with tenants), the Gateway and Key Manager components will also need to access API metadata in this database. The Shared database is also referred to as WSO2_SHARED_DB and shareddb.
WSO2 API Manager components use the databases as follows:
API Manager
|
Shared Database
|
|
|---|---|---|
Publisher |
Used |
Used |
Developer Portal |
Used |
Used |
Key Manager |
Used |
Used |
Gateway |
Not used |
Used (in multi-tenancy mode/ in multiple gateway mode when Google Analytics is used) |
| Traffic Manager | Used | Used |
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 two databases are connected to the relevant components respectively. The entire setup is also fronted by a load balancer.
Click here for more details on default communication ports among components.
Open port among profiles
| Client | Server | Port | Description |
|---|---|---|---|
| Gateway | Key Manager | 9443 | Token validation, authorize endpoint, block condition, and revoke tokens. |
| Gateway | Analytics Worker | 7612 | Publishing analytics events |
| Gateway | Analytics Worker | 7712 | Authenticate to publishing analytics events |
| Gateway | Traffic Manager | 9611 | Publishing throttling events |
| Gateway | Traffic Managerr | 9711 | Authenticate to publishing throttling events |
| Publisher | Traffic Manager | 9443 | Deploying throttling policy via admin portal |
| Publisher | Traffic Manager | 9611 | Publishing events like block condition, token revocation |
| Publisher | Traffic Manager | 9711 | Authenticate to publishing events |
| Publisher | Gateway | 9443 | Deploy API artifacts |
| Publisher | Analytics Worker | 7612 | Publishing alert analytics events |
| Publisher | Analytics Worker | 7712 | Authenticate to publishing alert analytics events |
| Publisher | Analytics Worker | 7444 | Fetch all the generated alerts |
| Dev Portal | Key Manager | 9443 | Register auth app and generate app keys |
| Dev Portal | Gateway | 8243 | Token endpoint and revoke endpoint |
| Dev Portal | Analytics Worker | 7612 | Publishing alert analytics events |
| Dev Portal | Analytics Worker | 7712 | Authenticate to publishing alert analytics events |
| Analytics Dashboard | Analytics Worker | 9444 | Deploy business rules |
| Analytics Dashboard | Publisher | 9443 | Use admin and Publisher REST APIs |
| Analytics Dashboard | Dev Portal | 9443 | Use Dev Portal portal REST APIs |
| Publisher | Key Manager | 9443 | Scope Management (Create,Update,Delete) |
| Server | Port | Description |
|---|---|---|
| Key Manager | 9443 | Token endpoint and identity REST APIs/web apps |
| Gateway | 8243 | Gateway nio HTTPS |
| Gateway | 8280 | Gateway nio HTTP |
| Gateway | 8099 | Gateway WS(Web socket) |
| Gateway | 9099 | Gateway WSS(web socket secure) |
| Publisher | 9443 | Publisher portal, Admin and Publisher REST API |
| Dev Portal | 9443 | Dev portal and REST API |
| Analytics Dashboard | 9643 | Analytics dashboard and business rule portals |