High Availability in Sisense
Sisense provides flexible design choices for supporting high availability (HA) and scalability for your Sisense configuration. To configure Sisense for high availability or optimized performance by scaling out Sisense servers, you must build in redundancy, thus reducing potential downtime or bottlenecks.Note: High availability must be enabled in your license. For more information, please contact your Sisense representative or submit a request to Sisense Support through our community website.
The configuration above represents the Sisense full stack solution. At least one instance of each of the following components must be active to enable you update your data and allow your users to query that data from the dashboard:
Sisense Web Server
The Sisense Web Server hosts the Sisense Web Application that provides the user interface and hosts the API endpoints. If the Sisense Web Server fails, your users cannot access the Sisense Web Application to view dashboards or use the Sisense APIs.
The application database is installed with Sisense and supports the Sisense Web Application. The application database contains dashboard, filters, and user information necessary for ensuring data consistency across all web servers. In addition, the application database is used for authentication when you make calls to Sisense’s APIs. If the application database fails the Sisense Web Application will fail.
The ElastiCube Server is installed locally on your computer and provides access to ElastiCubes. If access to the ElastiCube Server fails, queries from the Sisense Web Application will fail.
The message broker is a component of the ElastiCube server and is responsible for the communication of events between various Sisense services across your Sisense configuration. It should be replicated to ensure that the services can continue to communicate with each other in case the message broker fails.
Understanding High Availability in Sisense
While Sisense is fully-functional in an environment without high availability, a multi-node configuration is necessary for scalability to support large amounts of concurrent users and redundancy in case of a failure of one of the Sisense components.
In a multi-node configuration, Sisense components are replicated. 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 web application nodes. The query nodes, which handle user queries from Sisense, are replicated to support high availability. The build node is typically not replicated as its failure only prevents building new ElastiCubes, not issuing queries from the Sisense.
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.
Query nodes are responsible for supporting queries from Sisense dashboards. These nodes contain a web server, MongoDB, and an ElastiCube server. ElastiCubes are distributed by the build node to the query node. The query nodes’ ElastiCubes are combined into ElastiCube Sets to support high availability 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 a Sisense Web Application, ElastiCube Manager, and a MongoDB. 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.
In addition to query and build nodes, to support a high availability 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.
The URL of your load balancer should be provided as an Alias in Admin > Settings in the Sisense Web Application. This directs Sisense to send traffic to your load balancer, which then sends the traffic to the relevant server.
There are two steps to supporting high availability in Sisense. The first step is to set up a multi-server environment. Once your environment has been set up, you need to configure the Orchestrator that distributes your builds across all the query codes in your environment.
These steps can be done manually by creating and modifying configuration files, but Sisense highly recommends you set up your environment with the steps described above.