

WSO2 API Manager Deployment Overview¶

WSO2 API Manager consists of an API management layer and an integration layer. The API management layer contains several components, which you can use in your deployment according to your requirement. The integration layer includes either the Micro Integrator runtime (for services integration) and the Streaming Integrator runtime (for streaming requirements) or both runtimes.

You can select one of the following deployment patterns depending on the workload of each component and the traffic that is expected to each of the components and runtimes.

Standard HA deployment¶

This deployment consists of an API-M cluster with two nodes of the API-M runtime and two nodes each of the integration runtimes (Micro Integrator/Streaming Integrator). You can use this pattern if you expect to receive low traffic to your deployment.

Note

Two nodes of each component is used to ensure minimum high availability in all components.

API-M cluster¶

The API-M cluster consists of two All-in-One API-M nodes. See the following link for instructions on how to set up this cluster.

API-M Cluster with Minimum High Availability

Integration clusters¶

The integration cluster may be a Micro Integrator cluster or a Streaming Integrator cluster or two clusters of each. See the following links for instructions on how to set up this cluster.

Standard HA deployment with multitenancy¶

This deployment consists of two API-M nodes and two nodes each of the integration runtimes (Micro Integrator/Streaming Integrator) per tenant. You can use this pattern when traffic from different tenants in the API-M cluster needs to be handled in isolation. This deployment also allows you to direct the traffic of each tenant to a separate integration cluster.

Although API-M nodes are capable of handling in-jvm multitenancy, Micro Integrator/Streaming Integrator nodes are not. Therefore, to handle traffic to different tenants, you need to set up different clusters of the integration runtimes and configure traffic routing accordingly.

Note

The basic deployment suggests two nodes of each runtime to ensure minimum high availability. However, you can independently scale them depending on the resource requirements for each tenant.

API-M cluster¶

The API-M cluster consists of two All-in-One API-M nodes. See the following link for instructions on how to set up this cluster.

API-M Cluster with Minimum High Availability

Integration cluster¶

The integration cluster consists of two nodes of the integration runtime for each of the tenants in the API-M cluster. See the following links for instructions on how to set up this cluster.

Simple scalable deployment¶

This pattern allows you to scale the deployment on demand. The simple scalable deployment pattern shown below illustrates a deployment that uses minimum resources. However, this setup can easily be scaled.

You need to set up three clusters of the different components and runtimes as they have different scaling requirements.

Note

The basic deployment suggests two nodes of each runtime to ensure minimum high availability. However, you can independently scale them depending on the requirements.

API-M cluster¶

The API-M layer of this deployment consists of two clusters of API-M components as follows:

Control Plane Cluster	The APIM control plane consists of two nodes of the Control Pane API-M profile (Publisher, Devportal, Key Manager, Traffic Manager). The two node cluster is the simplest deployment for this pattern. If required you can scale the number of nodes.
Gateway Cluster	The Gateway profile of API-M is deployed as a separate cluster so that we can scale it to match the traffic requirements. The simplest deployment for this pattern consists of a two node Gateway cluster. If required you can scale the number of nodes.

To set up this cluster, see the instructions on Setting up a Distributed API-M deployment.

Integration cluster¶

The integration cluster consist of a minimum of two nodes of the integration runtime (Micro Integrator/Streaming Integrator). See the following links for instructions on how to set up this cluster.

Simple scalable deployment with Traffic Manager separation¶

This pattern allows you to scale the deployment on demand. The simple scalable deployment with Traffic Manager separation deployment pattern shown below illustrates a deployment that uses minimum resources. However, this setup can easily be scaled. This deployment pattern can be used only when you need to run the Traffic Manager nodes separately due to deployment complexities.

You need to set up three clusters of the different components and runtimes as they have different scaling requirements.

Note

The basic deployment suggests two nodes of each runtime to ensure minimum high availability. However, you can independently scale them depending on the requirements.

API-M cluster¶

The API-M layer of this deployment consists of two clusters of API-M components as follows:

Control Plane Cluster	The APIM control plane consists of two nodes of the Control Pane API-M profile (Publisher, Devportal, Key Manager, Traffic Manager). The two node cluster is the simplest deployment for this pattern. If required you can scale the number of nodes.
Gateway Cluster	The Gateway profile of API-M is deployed as a separate cluster so that we can scale it to match the traffic requirements. The simplest deployment for this pattern consists of a two node Gateway cluster. If required you can scale the number of nodes.
Traffic Manager Cluster	The Traffic Manager profile of API-M is deployed as a separate cluster so that we can scale it to match the traffic requirements. The simplest deployment for this pattern consists of a two node Traffic Manager cluster. If required you can scale the number of nodes.

To set up this cluster, see the instructions on Setting up a Distributed API-M deployment.

Integration cluster¶

The integration cluster consist of a minimum of two nodes of the integration runtime (Micro Integrator/Streaming Integrator). See the following links for instructions on how to set up this cluster.

Top