Clustered deployment

This page describes a clustered deployment architecture and lists the pros and cons of choosing this type of deployment.

Benefits of a clustered deployment 

Install Decision Insight (DI) as a clustered deployment when you have:

  • A large volume of events to filter, transform, and normalize from data sources but with only a subset being required for monitoring.
  • A large number of data sources to which to connect.
  • A large number of independent processes/business applications to monitor (and you want to have a centralized view).
  • A large number of users accessing the deployment in order to perform monitoring and/or investigation queries.
  • A single process/business application that must monitor a very large number of transactions and that may also have to compute a complex set of computed attributes.
  • A single process/business application requiring a large and complex set of indicators to compute, typically on a large number of dimensions (mono- or multi-dimensional).

In a clustered deployment, you have two different types of clusters:

  • Functional clusters
  • Technical clusters

For information about the basic concepts of a deployment architecture, see Deployment architectures.

 Important:  All nodes within a DI cluster must use the same version of DI.

Types of functional clusters

Integration and preprocessing cluster

Used by administrator, application builder, data integration specialist

This cluster is used to:

  • Extract information by connecting to production systems. 
  • Transform, normalize and filter data before forwarding that data to the application node(s).

The cluster typically does not store information in the database, apart from states. To ensure resiliency and crash recovery, a node in this cluster may rely on local disk space.

The user interface of the nodes in this cluster is mostly used for administration or troubleshooting purposes.

See also Integration cluster pattern for an example of how to set up an integration cluster.

Application cluster

Used by administrator, application builder, application user

This cluster is used to:

  • Host the monitoring of your product itself.
  • Integrate directly with the production system as a data source, or alternatively, receive data from an integration node via the Decision Insight Messaging System.
  • Execute queries.
  • Serve the dashboards.

This cluster uses all the main capabilities of the product.

This cluster stores data into the database using the normalized application model.

Cockpit cluster

Used by administrator, application builder, application user 

This cluster is used to centralize and merge information from multiple nodes in your deployment.

The cockpit uses the main capabilities of DI. However, data integration is very light-weight and analytics may be limited to high-level aggregations and evaluations only.

See also Cockpit cluster pattern for an example of how to set up a cockpit cluster.

Types of technical clusters

Primary/replica clusters for distributed computing and queries

If you expect that your product implementation will have to handle a large number of concurrent users and computings, you can install the product with one primary node and one or more replica nodes. This feature is called distributed computing and is enabled by default. 

A primary/replica implementation is composed of:

  • One primary node (PN) – absorbs data and executes pre-computings and computings.
  • One or many replica nodes (RN) – execute computings and responds to queries.

RNs receive a complete copy of the database from the PN, which gives them autonomy to run queries and do computings.

You can use primary/replica clusters for:

  • Functional clusters, for example for the integration cluster. See diagram below.
  • Active/passive clusters. In this case, the active cluster may have one primary node and one or more replica nodes, and the passive cluster may be set up similarly. See the application cluster in the diagram below.

For more information about how to deploy a primary/replica cluster, see Install a Primary/Replica cluster.

Active/passive clusters for high availability

Use this type of cluster for high availability (HA) and disaster recovery (DR). In this type of cluster, a single node of the application cluster is active. A backup instance is ready to be started in case the main instance fails – either automatically using a clustering mechanism, or manually following a specific failover procedure. For more information, see High Availability and Disaster Recovery deployment options.

You can use active/passive clusters for functional clusters.  

Examples of deployments

The following provides a few concrete deployment examples and shows which type of user would access which node or cluster. 

Standard primary replica deployment

This is the recommended installation to handle a large number of concurrent users and computings.

HA and replica deployment

This is the recommended installation to handle HA backup in addition to primary / replicas.


Resilient installation with two functional nodes

This installation guarantees the resilience of the data you want to push between your integration and application nodes.


Clustered installation using an application cluster and a cockpit node

Complex clustered installation

Related Links