Page Comparison

...

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 Application 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:

...

1. Download and extract the WSO2 asAS distribution. (Will be referred to as <manager-home>) 

...

10. Start the as instance in the management node.

...

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

...

<parameter name="domain">wso2.as.domain</parameter>
<parameter name="localMemberHost">as.cloud-test.wso2.com</parameter>
<parameter name="localMemberPort">4251</parameter>

...

<parameter name="properties">
    <property name="backendServerURL" value="https://${hostName}:${httpsPort}/services/"/>
    <property name="mgtConsoleURL" value="https://${hostName}:${httpsPort}/"/>
    <property name="subDomain" value="worker"/>
</parameter>

4. Add load balancer’s IP or host name. For example, 127.0.0.1 for Load Balancer and the local member port (4000) as defined in the axis2.xml of WSO2 LB before.

<members>
   <member>
      <hostName>127.0.0.1</hostName>
      <port>4000</port>
   </member>
</members>

carbon.xml configuration

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

<!-- Ports offset. This entry will set the value of the ports defined below to the define value + Offset. e.g. Offset=2 and HTTPS port=9443 will set the effective HTTPS port to 9445 -->

<Offset>2</Offset>

56. Update the HostName element as shown below. MgtHostName element is not needed since this node is designated as the worker node.

<HostName>as.cloud-test.wso2.com</HostName>

67. Next, configure the SVN-based deployment synchronizer to automatically check-out deployment artifacts from a common SVN repository. The worker nodes of a cluster SHOULD NOT commit (write) artifacts. Therefore, disable AutoCommit property in the deployment synchronizer configuration as follows:

<DeploymentSynchronizer>
       <Enabled>true</Enabled>
       <AutoCommit>false</AutoCommit>
       <AutoCheckout>true</AutoCheckout>
       <RepositoryType>svn</RepositoryType>
       <SvnUrl>http://10.100.3.115/svn/repos/as</SvnUrl>
       <SvnUser>wso2</SvnUser>
       <SvnPassword>wso2123</SvnPassword>
       <SvnUrlAppendTenantId>true</SvnUrlAppendTenantId>
</DeploymentSynchronizer>

 78. Start the worker product instance. The workerNode system property must be set to true when starting the workers in a cluster. For example,

sh wso2server.sh -DworkerNode=true

 89. Refer to the logs to ensure that the product instance has successfully joined the cluster. 

...