The contents of this section are still a work in progress as this content is being tested.
The following diagram indicates the fully-distributed deployment pattern used for high availability.
|Distributed component||Minimum number of nodes||Description|
|Receiver nodes||2||For data analytics to happen, it is necessary to first collect the relevant data you require. DAS provides data agents that capture information on the messages flowing through the WSO2 ESB, WSO2 Application Server, and other products that use the DAS data publisher. The information is obtained by the data receivers and are then stored in a datastore, where it is optimized for analysis. The receiver nodes are used to obtain this data from the data agents.|
A background indexing process fetches the data from the datastore and does the indexing operations. These operations are handled by the indexer nodes in a fully distributed, highly available system.
|Analyzer (Spark) nodes||2||The analyzer engine, which is powered by Apache Spark, analyzes this data according to defined analytic queries. This will usually follow a pattern of retrieving data from the datastore, performing a data operation such as an addition, and storing the data back in the datastore. The analyzer operations are performed by the analyzer nodes.|
The dashboard sends queries to the datastore for the analyzed data and displays them graphically. This function can be distributed to the dashboard nodes.
|Storm nodes||0||Apache Storm can be used to handle any additional load. This can be any number of nodes and need not be used in a fully distributed system unless required.|
- Download and install WSO2 DAS from here.
Make sure that you have allocated the required memory for DAS nodes, and installed the required supporting applications as mentioned in WSO2 DAS Documentation - Installation Prerequisites.
In WSO2 DAS clustered deployments, Spark is run in a seperate JVM. It is recommended to allocate 4GB of memory for Carbon JVM and 2GB for Spark.
- Follow the steps below to set up MySQL.
Download and install MySQL Server.
Download the MySQL JDBC driver.
Unzip the downloaded MySQL driver zipped archive, and copy the MySQL JDBC driver JAR (
mysql-connector-java-x.x.xx-bin.jar) into the
<DAS_HOME>/repository/components/libdirectory of all the nodes in the cluster.
- Enter the following command in a terminal/command window, where
usernameis the username you want to use to access the databases.
mysql -u username -p
- When prompted, specify the password that will be used to access the databases with the username you specified.
Create two databases named
About using MySQL in different operating systems
For users of Microsoft Windows, when creating the database in MySQL, it is important to specify the character set as latin1. Failure to do this may result in an error (error code: 1709) when starting your cluster. This error occurs in certain versions of MySQL (5.6.x) and is related to the UTF-8 encoding. MySQL originally used the latin1 character set by default, which stored characters in a 2-byte sequence. However, in recent versions, MySQL defaults to UTF-8 to be friendlier to international users. Hence, you must use latin1 as the character set as indicated below in the database creation commands to avoid this problem. Note that this may result in issues with non-latin characters (like Hebrew, Japanese, etc.). The following is how your database creation command should look.
mysql> create database <DATABASE_NAME> character set latin1;
For users of other operating systems, the standard database creation commands will suffice. For these operating systems, the following is how your database creation command should look.
mysql> create database <DATABASE_NAME>;
Execute the following script for the two databases you created in the previous step.
mysql> source <DAS_HOME>/dbscripts/mysql.sql;Click here to view the commands for performing steps f and g
Create the following databases in MySQL.
It is recommended to create the databases with the same names given above because they are the default JNDI names that are included in the
<DAS_HOME>/repository/conf/analytics/analytics-conf.xmlfile as shown in the extract below. If you change the name, the
analytics-conf.xmlfile should be updated with the changed name.
When configuring the Fully distributed cluster following setups should be done in each DAS node.
- Follow the steps below to point the user stores of all the nodes to a single user store database, and to mount all governance registries to a single registry and configuration registries to a single configuration registry.
- Follow the steps below to configure the <
DAS_HOME>/repository/conf/datasources/master-datasources.xmlfile as required
Enable the all the nodes to access the users database by configuring a datasource to be used by user manager as shown below.
Enable the nodes to access the registry database by configuring the
WSO2REG_DBdata source as follows.
For detailed information about registry sharing strategies, see the library article Sharing Registry Space across Multiple Product Instances.
<DAS_HOME>/repository/conf/datasources/analytics-datasources.xmlfile as shown below.
For more information, see Datasources in DAS documentation.
To share the user store among the nodes, open the
<DAS_HOME>/repository/conf/user-mgt.xmlfile and modify the
dataSourceproperty of the
<configuration>element as follows.
The datasource name specified in this configuration should be the same as the datasource used by user manager that you configured in sub step a, i.
<DAS_HOME>/repository/conf/registry.xmlfile, add or modify the
dataSourceattribute of the
<dbConfig name="govregistry">element as follows.
Do not replace the following configuration when adding in the mounting configurations. The registry mounting configurations mentioned in the above steps should be added in addition to the following.
- Follow the steps below to configure the <
<DAS_HOME>/repository/conf/axis2/axis2.xmlfile as follows for he nodes to enable Hazlecast clustering.
To enable Hazlecast clustering, set the
clustering class="org.wso2.carbon.core.clustering.hazelcast.HazelcastClusteringAgent"property to
trueas shown below.
To ensure that all the nodes in the cluster identify each other, enable the
wkamode for all of them as shown below.
Add all the nodes in the cluster as well known members under the
<members>element as shown below.
In a fully distributed DAS setup, Apache Spark identifies the worker nodes that analyze data via Hazalcast clustering. Only the nodes that are assigned as analyzer nodes should be identified as Spark workers, they should be in a separate cluster.
For each of the two analyser nodes, list the members as shown below. This groups them in a separate cluster.
For the other nodes that are not analyser nodes, list the members as shown below.
For each node, enter the respective server IP address as the value for the
localMemberHostproperty as shown below.
- Update the
<DAS_HOME>/repository/conf/event-processor.xmlfile of the nodes as follows.
Make sure that the HA mode is enabled as follows.
Distributedmode as shown below.
Set the following property for the two nodes that should function as presenter nodes.
This property should be set only for the presenter nodes.
For each receiver node, enter the respective server IP address under the
HA modeConfig section as shown in the example below.
When you enable the HA mode for WSO2 DAS, the following are enabled by default:
State persistence: If there is no real time use case that requires any state information after starting the cluster, you should disable event persistence by setting the
<DAS_HOME>/repository/conf/event-processor.xmlfile as shown below.
When state persistence is enabled for WSO2 DAS, the internal state of DAS is persisted in files. These files are not automatically deleted. Therefore, if you want to save space in your DAS pack, you need to delete them manually.
These files are created in the
<DAS_HOME>/cep_persistence/<tenant-id>directory. This directory has a separate sub-directory for each execution plan. Each execution plan can have multiple files. The format of each file name is
1493101044948_MyExecutionPlan). If you want to clear files for a specific execution plan, you need to leave the two files with the latest timestamps and delete the rest.
- Event synchronization: However, if you set the
event.duplicated.in.cluster=trueproperty for an event receiver configured in a node, DAS does not perform event synchronization for that receiver.
The following node types are configured for the HA deployment mode in the
eventSync: Both the receiver nodes in this setup are event synchronizing nodes. Therefore, each node should have the host and the port on which it is operating specified under the
Note that the
eventSyncport is not automatically updated to the port in which each node operates via port offset.
management: Both the receiver nodes in this setup carry out the same tasks, and therefore, all nodes are considered manager nodes. Therefore, each node should have the host and the port on which it is operating specified under the
Note that the
managementport is not automatically updated to the port in which each node operates via port offset.
presentation: You can optionally specify one or more nodes in this setup as the presenter nodes. The dashboards in which processed information is displayed are configured only in the presenter nodes. Each node should have the host and the port on which the assigned presenter node is operating specified under the
<presentation>element. The host and the port as well as the other configurations under the
<presentation>element are effective only when the
presenter enable="trueproperty is set under the
<!-- HA Mode Config -->section.
To define the two analyzer nodes as Spark masters, configure the
<DAS_home>/repository/conf/analytics/spark/spark-defaults.conffile as follows.
2 Sparkmasters are created because this cluster is a high-availability cluster. When the active spark master fails, the other node configured as a Spark master becomes active and continues to carry out the tasks os the Spark master.
Specify the number of Spark masters as 2 by setting the following property.
Specify a DAS symbolic link for both nodes as shown in the example below.
The directory path for the Spark Class path is different for each node depending on the location of the
<DAS_HOME>. The symbolic link redirects the Spark Driver Application to the relevant directory for each node when it creates the Spark class path.
For more information about Spark related configurations, see Spark Configurations.
In order to share the C-Apps deployed among the nodes, configure the SVN-based deployment synchronizer. For detailed instructions, see Configuring SVN-Based Deployment Synchronizer.
If you do not configure the deployment synchronizer, it is required to deploy any C-App you use in the fully distributed HA set up to all the nodes.
If the physical DAS server has multiple network interfaces with different IPs, and if you want Spark to use a specific Interface IP, open either the
<DAS_HOME>/bin/load-spark-env-vars.shfile (for Linux) or
<DAS_HOME>/bin/load-spark-env-vars.batfile (for Windows), and add the following parameter to configure the Spark IP address.
Create a file named "my-node-id.dat" in <DAS_HOME>/repository/conf/analytics folder and add a id of your preference. This ID should be unique across all other DAS nodes in the cluster. Same ID should not be in more than one node. If this ID is not provided, a node ID will be generated by the server. This node id is also stored in the Database(Primary record store which is WSO2_ANALYTICS_EVENT_STORE_DB) for future reference.
If, for any reason, you want to replace the DAS servers with new packs and want to point the new packs to the same databases, you need to back up the my-node-id.dat files from both previous installations and restore them in the new DAS packs. If this is not done,
two new node ids will be created while the older two node ids are still in the databases. So altogether, there will be 4 node ids in the database. This might lead to various indexing inconsistencies. If you are going to clean the whole DB, you can start without restoring the older node ids.
When starting the instances you can provide predefined profiles to start the instances as receiver nodes, analyzer nodes or Indexer nodes.
|Node Type||Disabled Components||Option|
|Receiver Node||AnalyticsEngine, AnalyticsExecution, Indexing, DataPurging, AnalyticsSparkCtx, AnalyticsStats ||-receiverNode|
|Indexer Node||AnalyticsExecution, AnalyticsEngine, EventSink, AnalyticsSparkCtx, AnalyticsStats, DataPurging||-indexerNode|
|Analyzer Node||Indexing, EventSink, DataPurging, IndexThrottling, AnalyticsStats||-analyzerNode|
These can be provided at the server startup. For example:
sh wso2server.sh -indexerNode would start the instance as a Indexer Node.
Note: You cannot use more than one aforementioned predefined profiles when starting the server.
If you encountered any similar warn logs as given below,
When your user ID is different to
root which is the default user ID, and if you do not have write access, the following warning message can appear:
To address this issue, follow the steps below:
- Create a directory in a location accessible to the user running the JVM, and have the following substructure:
- Start the DAS server with the following Java option. Alternatively, you can add this Java option to the