WSO2 Carbon version 4.0.0 onwards supports deployment models that consist of 'worker' nodes and 'manager' nodes. A worker node serves requests received by clients, whereas a manager node deploys and configures artifacts (web applications, services, proxy services, etc.).
This worker/manager deployment setup provides proper separation of concerns between a WSO2 product's UI components, management console, and related functionality with its internal framework that serves requests to deployment artifacts. Typically, the management nodes are in read-write mode and authorized to make configuration changes. The worker nodes are in read-only mode and authorized only to deploy artifacts and read configurations. This deployment model provides improved security as you can set up the manager nodes behind an internal firewall, exposed only to internal clients, while the worker nodes are exposed externally. Also, since the user interface is not loaded into 'worker' nodes, this deployment model is more efficient in utilizing memory.toc
Why separate the worker and manager nodes
The separation is to ensure that the manager node is secure, generally behind a firewall that only allows admin access. Other advantages of this separation include:
...
Since all WSO2 products are built on the cluster-enabled Carbon platform, you can cluster most WSO2 products in the same way, depending on which deployment pattern you use. The process of separating the worker and manager nodes depends on the worker/manager clustering pattern you choose. You can select one of the following patterns based on your load and the targeted expenditure.
| Note |
|---|
Your configuration changes depending on which clustering deployment pattern you choose. Although we use WSO2 API Manager (APIM) in the examples, the concepts apply equally to other WSO2 products as well. |
...
This pattern has two manager nodes in one sub-domain and two worker nodes in a separate sub-domain. The manager and worker sub-domains are part of a single WSO2 product cluster domain. Both sub-domains use their own load balancer while existing within the same cluster. Multiple load balancers result in several unique configuration steps, so please ensure that you follow the relevant steps carefully. This pattern is similar to deployment pattern 2. However, the application/modification load (or any other administrative load) might be high, so there is a dedicated load balancer for the manager cluster to prevent this load from affecting the load of the worker cluster.
