WSO2 API Manager includes five main components as the Publisher, Store, Gateway, Traffic Manager and Key Manager. In a stand-alone APIM setup, these components are deployed in a single server. However, 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.
...
.
This topic includes the following sections.
...
WSO2 API Manager deployment patterns
Warning |
---|
The following 5 patterns illustrate the latestthe deployment patterns forfor WSO2 API Manager. WeWe have NOT yet released the Puppet Modules for these 5 newpatterns. These deployment patterns have been designed by reviewing and refining the 7 older API-M deployment patterns in order to provide a more simplified set of patterns that meet the most required production use cases. |
Latest deployment patterns
Table of Content Zone | ||||
---|---|---|---|---|
| ||||
Pattern 1Single node (all-in-one) deployment. You can use this pattern when you are working with a low throughput. Pattern 2Deployment with a separate Gateway and separate Key Manager. You can use this pattern when you require a high throughput scenario that requires a shorter token lifespan. Pattern 3Fully distributed setup. You can use this pattern to maintain scalability at each layer and higher flexibility at each component. Pattern 4 Internal and external (on-premise) API Management. You can use this pattern when you require a separate internal and external API Management with separated Gateway instances. Pattern 5Internal and external (public and private cloud) API Management. You can use this pattern when you wish to maintain a cloud deployment as an external API Gateway layer. |
Older deployment patterns
Table of Content Zone | ||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||
Pattern 0Single node deployment.
Figure: All-in-one instance This pattern consists of a stand-alone API-M setup with a single node deployment. This pattern uses the embedded H2 databases. Pattern 1Single node deployment.
Figure: All-in-one instance This pattern consists of a stand-alone WSO2 API-M setup with a single node deployment. This pattern uses external RDBMS (e.g., MySQL databases). The only difference between pattern-0 and pattern-1 is that pattern-0 uses embedded H2 databases and pattern-1 is configured to use external RDBMS. Pattern 2Single node deployment, which has all WSO2 API-M components in one instance, with Analytics.
Figure: All-in-one instance with analytics This pattern consists of a stand-alone WSO2 API-M setup with a single node deployment and with a single Pattern 3Gateway worker/manager separation.
This pattern consists of a fully distributed WSO2 API-M setup (including a Gateway cluster of one manager and one worker) with a single Pattern 4Fully distributed WSO2 API-M setup with a single wso2am-analytics server.
This pattern consist of a fully distributed API-M setup including two Gateway clusters, where each has one manager and one worker, with a single Pattern 5Gateway worker/manager separation. Gateway worker and Key Manager in the same node.
This pattern consists of a distributed WSO2 API-M setup including a Gateway cluster of one manager and one worker and the Gateway worker is merged with the Key Manager. It also consists of a single Pattern 6Gateway worker/manager separation. Store in the same node as the Publisher.
This pattern consists of a distributed WSO2 API-M setup (including a Gateway cluster of one manager and one worker) of which the Publisher is merged with the Store. It also consists of a single Pattern 7WSO2 Identity Server acts as a Key Manager node for the WSO2 API Manager.
This pattern consists of a stand-alone WSO2 APIM setup with a single node deployment. The pattern uses external MySQL databases. The only difference of this pattern from pattern-1 is that this uses WSO2 Identity Sever as the Key Manager. |
Clustering Gateways and Key Managers with key caching
Anchor | ||||
---|---|---|---|---|
|
For key validation, the Gateway can usually handle 3,000 transactions per second, whereas the Key Manager can only handle 500 transactions per second. To improve performance, the key cache is enabled on the Gateway by default, which allows the system to handle 3,000 transactions per second. However, if you need better security, you can enable the cache on the Key Manager instead. Note the following about clustering with key caching:
...