This documentation is for WSO2 API Manager 2.1.0. View documentation for the latest release.

All docs This doc

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Removed the older deployment patterns based on email request

...

WSO2 API Manager deployment patterns

Warning

Note the following:

The following 5 patterns illustrate

the latest

the deployment patterns

for

 for WSO2 API Manager.

We

 We have NOT yet released the Puppet Modules for these 5

new patterns. 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.If you want to try out API-M deployment with Puppet, you need to use one of the older API-M deployment

patterns

. For more information, see Using Puppet Modules to Set up WSO2 API-M

.

...

Table of Content Zone
locationtop
typeflat

Pattern 1

Single node (all-in-one) deployment.

You can use this pattern when you are working with a low throughput.

Pattern 2

Deployment 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 3

Fully 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 5

Internal 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
locationtop
typeflat

Pattern 0

Single node deployment.

Multiexcerpt include
MultiExcerptNamepattern0
PageWithExcerptUsing Puppet Modules to Set up WSO2 API-M with Pattern 0

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 1

Single node deployment.

Multiexcerpt include
MultiExcerptNamepattern1
PageWithExcerptUsing Puppet Modules to Set up WSO2 API-M with Pattern 1

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 2

Single node deployment, which has all WSO2 API-M components in one instance, with Analytics.

Multiexcerpt include
MultiExcerptNamepattern2
PageWithExcerptUsing Puppet Modules to Set up WSO2 API-M with Pattern 2

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 wso2am-analytics server instance. This pattern uses external MySQL databases. You can use the H2 database when using API-M with Analytics, however, in a production scenario it is advised to use another DBMS other than H2.

Pattern 3

Gateway worker/manager separation.

Multiexcerpt include
MultiExcerptNamepattern3
PageWithExcerptUsing Puppet Modules to Set up WSO2 API-M with Pattern 3

This pattern consists of a fully distributed WSO2 API-M setup (including a Gateway cluster of one manager and one worker) with a single wso2am-analytics server instance. This pattern uses external MySQL databases. 

Pattern 4

Fully distributed WSO2 API-M setup with a single wso2am-analytics server.

Multiexcerpt include
MultiExcerptNamepattern4
PageWithExcerptUsing Puppet Modules to Set up WSO2 API-M with Pattern 4

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 wso2am-analytics server instance. You can have the gateway environments in any preferred environment (e.g., local-area network (LAN) and demilitarized zone (DMZ)).

Pattern 5

Gateway worker/manager separation. Gateway worker and Key Manager in the same node.

Multiexcerpt include
MultiExcerptNamepattern5
PageWithExcerptUsing Puppet Modules to Set up WSO2 API-M with Pattern 5

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 wso2am-analytics server instance and it uses external MySQL databases. 

Pattern 6

Gateway worker/manager separation. Store in the same node as the Publisher.

Multiexcerpt include
MultiExcerptNamepattern6
PageWithExcerptUsing Puppet Modules to Set up WSO2 API-M with Pattern 6

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 wso2am-analytics server instance and it uses external MySQL databases. 

Pattern 7

WSO2 Identity Server acts as a Key Manager node for the WSO2 API Manager.

Multiexcerpt include
MultiExcerptNamepattern7
PageWithExcerptUsing Puppet Modules to Set up WSO2 API-M with Pattern 7

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
keycache
keycache

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:

...