Clustering

On production systems, it is often desirable to run Scipio ERP in a clustered configuration. Computer clusters are used to split user traffic across multiple machines so that each request is guaranteed a swift response and the system performance reliably even when running under heavy load. The following article will outline the configuration details for a clustered setup.

Please be aware, that clustering is only required for large setups and not a requirement to run the software.

Example: A typical cluster setup

Example: A typical cluster setup

A typical Scipio cluster consists of:

  1. A loadbalancer & Webserver (often the same software), which distribute the load to the application servers
  2. Application servers
  3. Databases

Each of which must be configured to work in a clustered environment. We recommend to use sticky sessions for the webservers, as this simplifies the process tremendously. In theory session sharing is possible, but it will require additional steps to setup the tomcat specific internals of Scipio ERP and remains largely untested.

Scipio ERP Configuration

Simply put, clustering with Scipio ERP works the following way: Each Scipio ERP node is assigned a unique nodeid. This will allow the system to process specific services that are stored inside the database. Afterwards, a distributed cache clearing mechanism is needed to inform each node of important changes, so that they can clear their caches if required.

Scipio ERP

Each system will require a unique instanceId, which can be set in framework\common\config\general.properties:

# -- unique instance id (20 char max)
unique.instanceId=scipio1

Any combination of characters will do.

Distributed Cache Clear

Distributed Cache Clearing is required to keep the local server caches in sync with one another. Distributed cache clear is nothing else than a Service, which is called whenever an update on the database is performed. The service will use a messaging system to inform other Scipio nodes of the change and each will clear their cache. Since the service is implemented using JMS to share the information across a network of individual application server, a JMS server is required.

The jms messaging service is defined in framework\service\config\serviceengine.xml. The following lines need to be uncommented:

<!-- JMS Service Active MQ Topic Configuration (set as default in jndi.properties, the less changes the better) -->
<jms-service name="serviceMessenger" send-mode="all">
    <server jndi-server-name="default"
        jndi-name="topicConnectionFactory"
        topic-queue="ScipioTopic"
        type="topic"
        listen="true"/>
</jms-service>

The above will tell Scipio to use a the “ScipioTopic” and jms messaging. We can recommend to use ActiveMQ here, but any JMS server should do. Copy over the jms library of your choice (here activemq-all.*.jar) and add it to framework/base/lib.

Next, you are required to set the correct JNDI settings, for this open up framework\base\config\jndi.properties and add:

java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
java.naming.provider.url=tcp://172.18.7.4:61616
topic.OFBTopic=ScipioTopic
connectionFactoryNames=connectionFactory, queueConnectionFactory, topicConnectionFactory

Comment out line 25+26 afterwards (we basically replaced these with our new config(. It is possible to add multiple JMS brokers in a chain, by adding them with a comma separation in the provider.url property.

Lastly update framework/entity/config/entityengine.xml set distributed-cache-clear-enabled=”true” on both the default and default-no-eca delegator. ie:

<delegator name="default" entity-model-reader="main" entity-group-reader="main" entity-eca-reader="main" distributed-cache-clear-enabled="true">
 ...
</delegator>
<delegator name="default-no-eca" entity-model-reader="main" entity-group-reader="main" entity-eca-reader="main" entity-eca-enabled="false" distributed-cache-clear-enabled="true">
 ...
</delegator>s