Multi-Node Deployments

Sisense provides flexible design choices for supporting high availability (HA) and scalability for your Sisense deployments. Typically, you want to implement multi-node deployments when you want to optimize performance or build in redundancy. Before implementing a multi-node environment, you can ask yourself the following questions:

  • Do you want to improve dashboard load time?
  • Are your ElastiCubes taking a long build time to build?
  • Do you need to support a lot of concurrent users?
  • Do you have a lot of ElastiCubes?
  • Do you need high availability for your system?

If you answered Yes to any of these questions, you may want to consider scaling out Sisense.

The basic Sisense architecture looks like the diagram below where Sisense is installed on a single machine. Your users connect to your machine and you import or connect to your data sources from the same machine. This machine supports the Sisense web application, your data models, and all of your users.

One way to scale out Sisense is to improve your hardware with more storage, CPU, and memory; however, this can get quite expensive and doesn’t provide any redundancy.

Another way to scale out Sisense is to add more machines, thus improving performance and building in redundancy into the system as shown in the diagram below.

While Sisense is fully-functional in a single node environment, a multi-node deployment is necessary for scalability to support large amounts of concurrent users and redundancy in case of a failure of one of the Sisense components. Replicating each of these components provides redundancy and fault tolerance against the failure of any single component. The replicated components are combined into nodes. There are three types of nodes, a build node, query nodes, and an application node. These nodes and their components are described below.

Nodes

Note:

Sisense Cloud deployments using high availability typically have 2 query nodes and 1 build node. Other configurations are available upon request.

Build Node

The build node is responsible for building ElastiCubes and distributing the build to query nodes via the Sisense Orchestrator Service. The Sisense Orchestrator Service is an automated service that you configure on the build node to synchronize and distribute built ElastiCubes to the query nodes. For more information, see Distributing ElastiCube Builds to Query Nodes.

Build nodes include an ElastiCube Server, application database, Sisense add-ons, and the Sisense Orchestrator Service.

The build node is not replicated as its failure only prevents building new ElastiCubes, not issuing queries from Sisense.

Note:

Sisense add-ons must be located on the build node.

Query Nodes

Query nodes are responsible for supporting queries from Sisense dashboards on the application layer. ElastiCube models are distributed by the build node to the query nodes. The query nodes’ ElastiCube models are then combined into ElastiCube Sets to increase redundancy by separating the web and ElastiCube servers across multiple query nodes. If a build node is distributing a build to one ElastiCube server, Sisense automatically directs any queries to the other ElastiCubes in the ElastiCube Set.

The query node can be configured as a single application stack where each node hosts Sisense, ElastiCubes, and an application database. In this configuration, if the machine hosting the components fails, the whole query node will fail. Queries will then be redirected to the next available query node. Another option is to host each component of the query node separately in a distributed application stack. In this configuration, if a component of the query node fails, the rest of the query node is not affected. For an example of a single application stack, see Scenario 1 and for an example of a distributed application stack, see Scenario 2.

Application Nodes

The application node supports your Sisense application. This is the interface you see when you log into Sisense, including the Model Editor, dashboards, etc. In some models, this resides on the same node as the query node.

Components

Sisense has many components that reside on each of the nodes. Some of these components are responsible for supporting Sisense, such as the application database, configuration database, and message broker. Other components, such as a load balancer, Multi-Node Deployment wizard, and ElastiCube Sets are responsible for supporting high availability in Sisense. Each of these components is described in more detail below.

Application Database

The application database is installed with Sisense and supports Sisense. The application database is a central repository for Sisense metadata including user information, permissions, data sources, dashboards. jobs, etc.

If the application database fails, the Sisense web application will fail.

To achieve redundancy and high availability of the application database, a minimum of three nodes is required.

Message Broker

The message broker is a component of Sisense and is responsible for the communication of events between various Sisense services across your Sisense configuration. Sisense availability and functionality are heavily dependent on the broker service. It should be replicated with at least two nodes to ensure that the services can continue to communicate with each other in case the message broker fails.

Configuration Database

The configuration database provides a single representation for the cluster regarding the topology, configurations, and state.

To achieve redundancy and high availability, the configuration service should be replicated with at least three nodes to ensure that your configuration is up-to-date across your entire deployment.

Load Balancer

To support a multi-node configuration, you must handle load balancing on your side prior to directing traffic to one of your Sisense nodes. Load balancing spreads requests across multiple query nodes according to an algorithm you define and the current status of the query node.

When implementing ElastiCube Sets, Sisense’s query nodes operate in active-active mode. This means that each of the query nodes is active and can handle requests when the node is not building and its components are available. For example, traffic could be spread 50-50 across two web servers and if a component fails, a load balancer should redirect traffic to the other available web server.

ElastiCube Sets

Sisense ElastiCube Sets are collections of identical ElastiCube models that allow you to query running ElastiCube s within the ElastiCube Set while other ElastiCube s are building.

Components that Cannot be Replicated

Several Sisense components are deployed as single services that can not be replicated and do not have redundancy:

  • ElastiCube web management
  • Add-ons
  • Scheduled reporting jobs
  • Sisense Orchestrator
  • Build nodes

Multi-Node Configuration

To support more concurrent users and queries, and build in redundancy into your deployment, you must provide additional machines and configure the orchestration between the various Sisense nodes and their services. Sisense makes it easy to implement a multi-node deploment with the Multi-Node Deployment Wizard. This wizard automates the configuration of your nodes.

If you want to implement high availability, after you have run the wizard, you configure the Sisense Orchestrator service that manages the distribution of ElastiCube s across multiple machines.

The following pages describes the multi-node deployments Sisense supports, how to configure them in the Multi-Node Deployment wizard, and how to configure the distribution of ElastiCubes with the Sisense Orchestrator.

Next Steps

.r.