Page Comparison

...

See instructions on setting up databases for installing and creating WSO2_USER_DB, REGISTRY_DB, REGISTRY_LOCAL1 and REGISTRY_LOCAL2. In addition to that, you need to create the BPS_DB and the BPMN_DB.

Create the BPS_DB and BPMN_DB databases using the following commands, where <BPS_HOME> is the path to any of the BPS instances you installed, and username and password are the same as those you specified in the previous steps:

Code Block

language	none

mysql> create database BPS_DB;
mysql> use BPS_DB;
mysql> source <BPS_HOME>/dbscripts/bps/bpel/create/mysql.sql;
mysql> grant all on BPS_DB.* TO username@localhost identified by "password";
 
mysql> create database BPMN_DB;
mysql> use BPMN_DB;
mysql> source <BPS_HOME>/dbscripts/bps/bpmn/create/activiti.mysql.create.engine.sql;
mysql> source <BPS_HOME>/dbscripts/bps/bpmn/create/activiti.mysql.create.history.sql;
mysql> source <BPS_HOME>/dbscripts/bps/bpmn/create/activiti.mysql.create.identity.sql;
mysql> grant all on BPMN_DB.* TO username@localhost identified by "password";

On the first BPS node, open <BPS_HOME>/repository/conf/datasources/master-datasources.xml and configure the data sources to point to the WSO2_USER_DB, WSO2_REGISTRY_DB, and REGISTRY_LOCAL1 databases (change the username, password, and database URL as needed for your environment). Repeat this configuration on the second BPS node, this time configuring the local registry to point to REGISTRY_LOCAL2. For details on how to do this, see the Setting up the Database topic.

On each BPS node, open <BPS_HOME>/repository/conf/datasources/bps-datasources.xml, and configure the connection to the BPS database as follows (change the driver class, database URL, username, and password as needed for your environment):

Code Block

language	xml

 <datasource>
            <name>BPS_DS</name>
            <description></description>
            <jndiConfig>
                <name>bpsds</name>
            </jndiConfig>
            <definition type="RDBMS">
                <configuration>
                    <url>jdbc:mysql://localhost:3306/BPS_DB</url>
                    <username>root</username>
                    <password>root</password>
                    <driverClassName>com.mysql.jdbc.Driver</driverClassName>
                    <testOnBorrow>true</testOnBorrow>
                    <validationQuery>SELECT 1</validationQuery>
                    <validationInterval>30000</validationInterval>
                    <useDataSourceFactory>false</useDataSourceFactory>
	             <defaultAutoCommit>true</defaultAutoCommit>
 	             <maxActive>100</maxActive>
                    <maxIdle>20</maxIdle>
	             <maxWait>10000</maxWait>
                </configuration>
            </definition>
  </datasource>

Note
Note: The entry `<defaultAutoCommit>true</defaultAutoCommit>` is set to `true`. This is an important setting for the BPEL engine. You must do this for each node in the cluster.

On each BPS node, open the <BPS_HOME>/repository/conf/datasources/activiti-datasources.xml file and add the relevant entries.

Code Block

language	xml

<datasource>
            <name>ACTIVITI_DB</name>
            <description>The datasource used for activiti engine</description>
            <jndiConfig>
                <name>jdbc/ActivitiDB</name>
            </jndiConfig>
            <definition type="RDBMS">
                <configuration>
                    <url>jdbc:mysql://localhost:3306/BPMN_DB</url>
                    <username>root</username>
                    <password>root</password>
                    <driverClassName>com.mysql.jdbc.Driver</driverClassName>
                    <maxActive>50</maxActive>
                    <maxWait>60000</maxWait>
                    <testOnBorrow>true</testOnBorrow>
                    <validationQuery>SELECT 1</validationQuery>
                    <validationInterval>30000</validationInterval>
                </configuration>
            </definition>
</datasource>

On each BPS node, open <BPS_HOME>/repository/conf/registry.xml and configure the registry mounts. Registry mount path is used to identify the type of registry. For example ”/_system/config” refers to configuration registry and "/_system/governance" refers to governance registry. The following is an example configuration for BPS registry mounting. Leave the configuration for local registry as it is and add the following new entries.

Code Block

title	Registry configuration for BPS manager node

<dbConfig name="wso2bpsregistry">
  <dataSource>jdbc/WSO2RegistryDB</dataSource>
</dbConfig>

<remoteInstance url="https://localhost:9443/registry">
  <id>instanceid</id>
  <dbConfig>wso2bpsregistry</dbConfig>
  <readOnly>false</readOnly>
  <enableCache>true</enableCache>
  <registryRoot>/</registryRoot>
  <cacheId>root@jdbc:mysql://localhost:3306/REGISTRY_DB</cacheId>
</remoteInstance>

<mount path="/_system/config" overwrite="true">
  <instanceId>instanceid</instanceId>
  <targetPath>/_system/bpsConfig<config</targetPath>
</mount>

<mount path="/_system/governance" overwrite="true">
  <instanceId>instanceid</instanceId>
  <targetPath>/_system/governance</targetPath>
</mount>

Make note of the following for more details on configuring this.

This configuration enables you to identify the data source you configured in the master-datasources.xml file using the dbConfig entry and we give a unique name to refer to that datasource entry, which is “wso2bpsregistry”.
The remoteInstance section refers to an external registry mount. We can specify the read-only/read-write nature of this instance as well as caching configurations and the registry root location. Additionally you must specify the cacheId for caching to function properly in the clustered environment. Note that cacheId is same as the JDBC connection URL to the registry database. You define a unique name “id” for each remote instance, which is then referred from mount configurations.
In the above example, the unique id for remote instance is instanceId.
In each of the mounting configurations, specify the actual mount path and target mount path.

Code Block

language	html/xml
title	Registry configuration for BPS slave node

<dbConfig name="wso2bpsregistry">
  <dataSource>jdbc/WSO2RegistryDB</dataSource>
</dbConfig>

<remoteInstance url="https://localhost:9443/registry">
  <id>instanceid</id>
  <dbConfig>wso2bpsregistry</dbConfig>
  <readOnly>true</readOnly>
  <enableCache>true</enableCache>
  <registryRoot>/</registryRoot>
  <cacheId>root@jdbc:mysql://localhost:3306/ REGISTRY_DB</cacheId>
</remoteInstance>

<mount path="/_system/config" overwrite="true">
  <instanceId>instanceid</instanceId>
  <targetPath>/_system/bpsConfig<config</targetPath>
</mount>

<mount path="/_system/governance" overwrite="true">
  <instanceId>instanceid</instanceId>
  <targetPath>/_system/governance</targetPath>
</mount>

Make note of the following for more details on configuring this.

This configuration is same as above with readOnly property set to true for remote instance configuration.

On each BPS node, open <BPS_HOME>/repository/conf/user-mgt.xml and configure the user stores. In the user-mgt.xml file, enter the datasource information for the user store that you configured previously in the master-datasoures.xml file. You can change the admin username and password as well. However, you should do this before starting the server.

Code Block

language	html/xml

<Configuration>
  <AddAdmin>true</AddAdmin>
  <AdminRole>admin</AdminRole>
  <AdminUser>
    <UserName>admin</UserName>
    <Password>admin</Password>
  </AdminUser>
  <EveryOneRoleName>everyone</EveryOneRoleName>
  <Property name="dataSource">jdbc/WSO2UMDB</Property>
</Configuration>

On each BPS node, open <BPS_HOME>/repository/conf/axis2/axis2.xml and configure the clustering section. The axis2.xml file is used to enable clustering. Well known address (WKA) based clustering method is normally used for BPS clustering. In WKA based clustering, you must have a subset of cluster members configured in all the members of the cluster. At least one well-known member has to be operational at all times.

Code Block

language	html/xml

<clustering class="org.wso2.carbon.core.clustering.hazelcast.HazelcastClusteringAgent"  enable="true">
  <parameter name="membershipScheme">wka</parameter>
  <parameter name="localMemberHost">127.0.0.1</parameter>
  <parameter name="localMemberPort">4000</parameter>
  <members>
    <member>
      <hostName>127.0.0.1</hostName>
      <port>4000</port>
    </member>
    <member>
      <hostName>127.0.0.1</hostName>
      <port>4010</port>
    </member>
  </members>
</clustering>

Make note of the following for more details on configuring this.

Change the enable parameter to true.
Find the parameter membershipSchema and set it as wka.
Configure the loadMemberHost and localMemberPort entries. These must be different values for the master and slave if they are on the same server to prevent any conflicts.
Under the members section, add the hostName and port for each WKA member. As we have only two nodes in our sample cluster configuration, we will configure both nodes as WKA nodes.

On each BPS node, open <BPS_HOME>/repository/conf/etc/tasks-config.xml and change the taskServerMode configuration. BPS is shipped with the task server component as well. By default, when we enable clustering, this component waits for two task server nodes. Hence we need to change this entry to STANDALONE in order to start the BPS server.
<taskServerMode>STANDALONE</taskServerMode>

Info

title	About using AUTO

Note that the Task Server configuration does not have an impact on the BPS server runtime functionality. Hence, using AUTO or STANDALONE here will not affect how the BPEL processes are executed during runtime.

However, note that the default setting <taskServerCount>2</taskServerCount> in the <BPS_HOME>/repository/conf/etc/tasks-config.xml file has an impact here if you use AUTO. When the AUTO setting is enabled, and clustering is enabled, the server will wait till it picks up another node so that there are two Task Server instances up and running. Hence you will need to start both nodes simultaneously.

So if you want to use AUTO, change the taskServerCount to 1 so that you can start the management node first.

On each BPS node, open <BPS_HOME>/repository/conf/bps.xml and configure the following:

Enable distributed lock - This entry enables the Hazelcast-based synchronizations mechanism to prevent concurrent modification of the instance state by cluster members.
<tns:UseDistributedLock>true</tns:UseDistributedLock>

Configure the scheduler thread pool size - Thread pool size must always be smaller than the maxActive database connections configured in the <BPS_HOME>/repository/conf/datasources/master-datasources.xml file. When configuring the thread pool size, allocate 10-15 threads per core depending on your setup. Leave some additional number of database connections since BPS uses database connections for management API as well.
<tns:ODESchedulerThreadPoolSize>0</tns:ODESchedulerThreadPoolSize>

Panel

Example settings for a two node cluster.

- Oracle Server configured database connection size - 250.

- maxActive entry in master-datasources.xml files for each node - 100

- SchedulerTreadPool size for each node - 50

Node ID - Optionally, a unique id can be assigned to each node. Uncomment following elements and give an unique id as following,
<tns:NodeId>node1</tns:NodeId>

...

If needed, you can install a hardware load balancer or an HTTP load balancer such as NGINX Plus as the front end to the BPS nodes. See Configuring NGINX /wiki/spaces/CLUSTER44x/pages/9732195 for details on configuring Nginx as the load balancer for a WSO2 product cluster.

Versions Compared

Old Version 31

New Version Current

Key