Clustering Patterns

The WSO2 ELB is now retired. Please set up your cluster with an alternative load balancer, preferably Nginx Plus. See Setting up a Cluster for more information.

Since all WSO2 products are built on the cluster-enabled Carbon platform, you can cluster most WSO2 products in a similar way, although there may be a few differences depending on the product that you use and the deployment pattern you have chosen. WSO2 Carbon version 4.0.0 onwards supports deployment models that consist of 'worker' nodes and 'management' nodes. A worker node is used to serve requests received by clients, whereas a management node is used to deploy and configure artifacts (web applications, services, proxy services, etc.).

This worker/manager deployment setup provides proper separation of concerns between a Carbon-based product's UI components, management console, and related functionality with its internal framework serving requests to deployment artifacts. Typically, the management nodes are in read-write mode and authorized to add new artifacts or make configuration changes, whereas the worker nodes are in read-only mode, authorized only to deploy artifacts and read configurations. This deployment model provides improved security, since its management nodes can be set up behind an internal firewall and only exposed to internal clients while only worker nodes can be exposed externally. Also, since the user interface is not loaded onto 'worker' nodes, the deployment model is more efficient in memory utilization.

You can select one of the following patterns based on your load coupled with your targeted expenditure.

The clustering deployment pattern you choose is very important, as your configurations will change based on the deployment pattern that you use. For the purposes of this worker/manager separation example, we have set the IP addresses of the WSO2 products in the clustering deployment patterns.

Worker/Manager clustering deployment pattern 1

This pattern involves two worker nodes within a cluster. Here the worker is in high availability mode while the manager is not. This pattern is suitable in situations where it is rare to deploy applications or modify a running application (hence you would need only a single management node). However, the application should run continuously, hence the worker nodes are in a cluster.

This mode is rarely used. The preferred mode is two management nodes in Active/Passive mode (as is the case in deployment pattern 2).

Worker/Manager clustering deployment pattern 2

This pattern has two manager nodes in one cluster and two worker nodes in a separate cluster. This is similar to deployment pattern 1, but the management node is in Active/Passive mode for high availability. Active/Active mode for a management node is generally not recommended, but if you want high availability for your data center and location based services, it is useful to set up Active/Active mode.

This pattern is useful in scenarios where the application deployment/modification might be frequent (hence you would need a cluster for the management node). However, the load you may have is less, which is why you would share a single load balancer with the worker cluster.

Worker/Manager clustering deployment pattern 3

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