WSO2 Carbon version 4.0.0 onwards supports an improved deployment model in which its architecture components are separated as 'worker' nodes and 'management' nodes. The management node(s) is used to deploy and configure artifacts (web applications, services, proxy services etc.) whereas the worker nodes are used to serve requests received by clients.
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 configuration. This deployment model is improved security-vise 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 UI-related OSGi bundles are not loaded to 'worker' nodes, the deployment model is more efficient in memory utilization.
A worker/manager separated cluster can typically be implemented in the following ways:
Separate Sub Clusters with One Load Balancer
This model consists of two sub cluster domains as worker domain and management domain. These sub domains take up load according to a defined load balancing algorithm and auto-scales according to the load on its nodes.
Single Cluster with two Load Balancers
This model consists of a single cluster, where a selected node works as both a worker and a manager. This worker node requires two load balancers and configured in read-write mode, while the other worker nodes are set up in read-only mode. The management node also should be a well-known member in the non-management worker nodes so that state replication and cluster messaging works.
Shown below is the minimum configuration instructions to cluster two WSO2 Data Service Server instances. The cluster consists of two sub cluster domains as worker/management and is fronted by a single load balancer. Altogether, we will be configuring three instances as follows:
Using similar instructions, this minimum configuration can be extended to include many worker/manager nodes into the cluster.
Setting up WSO2 Elastic Load Balancer Anchor elb elb
| elb | |
| elb |
1. Download and extract WSO2 ELB. This folder will be referred to as <elb-home>.
...
5. Start the WSO2 Elastic Load Balancer instace.
Management Node Configuration Anchor management management
| management | |
| management |
1. Download and extract the WSO2 DSS distribution. (Will be referred to as <manager-home>)
axis2.xml configuration
2. First, clustering should be enabled at axis2 level in order for management node to communicate with load balancer and the worker nodes. Open <manager-home>/repository/conf/axis2/axis2.xml and update the clustering configuration as follows:
...
| Code Block | ||
|---|---|---|
| ||
<members>
<member>
<hostName>127.0.0.1</hostName>
<port>4000</port>
</member>
</members> |
catalina-server.xml configuration
Since the WSO2 DSS management node is fronted by the WSO2 Load Balancer, the proxy ports associated with HTTP and HTTPS connectors should be configured. These proxy ports are the corresponding transport receiver ports opened by WSO2 LB (configured in transport listeners section in axis2.xml).
...
| Code Block | ||
|---|---|---|
| ||
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
port="9763"
proxyPort="8280">
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
port="9443"
proxyPort="8243"> |
carbon.xml configuration
7. Since multiple WSO2 Carbon-based products are run in same host, to avoid possible port conflicts, the port offset of <manager-home>/repository/conf/carbon.xml should be changed as follows.
...
12. Also, try deploying an artifact through the manager node. You should receive an error since the server looks for the worker node, which is not in the cluster yet. Although the request is issued through the management node, all requests are served by the worker node(s).
Worker Node Configuration Anchor worker worker
| worker | |
| worker |
1. Download and extract the WSO2 DSS distribution. (Will be referred to as <worker-home>)
axis2.xml configuration
Do the following modifications in addition to the changes done to aixs2.xml of the management node.
...
| Code Block | ||
|---|---|---|
| ||
<parameter name="properties">
<property name="backendServerURL" value="https://${hostName}:${httpsPort}/services/"/>
<property name="mgtConsoleURL" value="https://${hostName}:${httpsPort}/"/>
<property name="subDomain" value="worker"/>
</parameter> |
carbon.xml configuration
4. Since multiple WSO2 Carbon-based products are run in same host, to avoid possible port conflicts, the port offset of <worker-home>/repository/conf/carbon.xml should be changed as follows.
...