Versions Compared

Old Version 37

changes.mady.by.user Former user

Saved on

compared with

New Version 38

changes.mady.by.user Former user

Saved on

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

...

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.

    • Latest deployment patterns

    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:

    ...