Clustered Deployment

Distributed deployment of CEP enables it to achieve High Availability, and Scalability in terms of memory.

There are two modes of distributed deployment for CEP which are as follows,

Distributed Cache Mode Deployment

WSO2 CEP with Siddhi uses Hazelcast to achieve distributed processing. To enable distributed processing all CEP servers has to be deployed in the same Local Area Network, this enables all the Hazelcast instances of CEP to identify each other using multicast and create an in-memory cluster for supporting distributed processing.

In WSO2 CEP, distributed processing can be enabled at per execution plan level where by only those identified execution plans will use the distributed cache for processing,

Note

In order to enable distributed deployments, prior to starting up the server, users need to enable hazelcast clustering by setting <CEP_HOME>/repository/conf/axis2/axis2.xml's clustering to true.

Follow below steps to enable distributed processing to an execution plan.

Create distributed CEP execution plans with the following properties
Warning

Not following the below conventions will lead to unpredictable results!
- All execution plans across nodes has to have the same Execution Plan Name
- Execution Plans has to have the following Backend Runtime Configuration
```
Siddhi Configurations

Snapshot time interval	  : 0
Distributed processing	  : true
```
  These can be added to the configuration file as below.
```
<executionPlan name="FraudAnalyzer" statistics="enable"
               trace="enable" xmlns="http://wso2.org/carbon/eventprocessor">
    ...
    <siddhiConfiguration>
        <property name="siddhi.enable.distributed.processing">true</property>
        <property name="siddhi.persistence.snapshot.time.interval.minutes">0</property>
    </siddhiConfiguration>
    ...
</executionPlan>
```
- All execution plans should have identical query expressions (Queries has to use same stream names, same type of events and query expressions in all the execution plans have to be in the same order)
- But the input topics need NOT to be the same, by using different input topics users can distribute load when publishing to CEP.
Deploy the execution plans to CEP nodes.

Follow the sample Distributed Purchase Analyzer Sample and Fraud Analyzer step by step guide to better understand this functionality

Persistence Mode Deployment

Using persistence mode enables CEP Queries to span lifetimes much greater than server uptime. This is achieved by taking periodic snapshots and storing all state information & windows in a scalable persistence store. In CEP we use Apache Cassandra as the scalable persistence store in order to achieve high scalability and low latency when persisting data. In this mode if server crashes the same server or another CEP server with the same bucket connected to the same Cassandra Data Store can be restored from the last available snapshot.

WSO2 CEP persistence mode processing can be enabled at per execution plan level where by only those identified execution plans will persist their states,

Follow below steps to enable persistence mode processing for an execution plan.

Create an execution plan with the following properties

Execution plan has to have the following Siddhi Runtime Configuration

Siddhi Configurations

Snapshot time interval	  : 5  (any positive value as required, this is given in minutes)
Distributed processing	  : true			: false

These can be added to the configuration file as below.

<executionPlan name="FraudAnalyzer" statistics="enable"
               trace="enable" xmlns="http://wso2.org/carbon/eventprocessor">
    ...
    <siddhiConfiguration>
        <property name="siddhi.enable.distributed.processing">false</property>
        <property name="siddhi.persistence.snapshot.time.interval.minutes">5</property>
    </siddhiConfiguration>
    ...
</executionPlan>

In order to persist states at shut down use graceful shut down from the CEP server

The steps are as follows :

- - Sign In. Enter your user name and password to log on to the Complex Event Processor Management Console.
  - Click on "Shutdown/Restart Server" menu item under Manage section of the left panel
    This will redirect to the Shutdown/Restart Server page.
  - Click on "Graceful Restart" and click "Yes" to conform Server restart when prompted.