Linux Minimum Requirements

Applicable to Sisense on Linux

Previous Step

Below are descriptions and explanations of the minimum requirements for Sisense in Linux environments. If you are looking for the minimum requirements for Windows, see Windows Minimum Requirements

Supported Web Browsers

The Sisense Web Application runs in the following HTML5 supported browsers:

Note: When embedding iFrames, Sisense supports Safari 10 and higher.

Microsoft Edge is not currently supported.

The Sisense Web Application also works in mobile phone and tablet browsers that support HTML5. Click Viewing Dashboards on Mobile Devices to learn more about mobile compatibility.

Minimum System Requirements

Prerequisites

Namespaces TCP/UDP Ports Source

HTTP

TCP

80

Same security group

Custom TCP Rule

TCP

30030

0.0.0.0/0

Custom TCP Rule

TCP 

kubernetes admin

6443

0.0.0.0/0

Custom TCP Rule

TCP

6443

0.0.0.0/0

Custom TCP Rule

TCP

etcd

2379 - 2380

Same security group

Custom UDP Rule

UDP

Gluster

24007 - 24008

Same security group

Custom TCP Rule

TCP

Gluster FS

49152 - 49157

Same security group

Custom TCP Rule

TCP

Calico

9099

Same security group

HTTPS

TCP

Https

443

Same security group

Custom TCP Rule

TCP

Calico – bird?

179

Same security group

Custom TCP Rule

TCP

Gluster

24007 - 24008

Same security group

Custom TCP Rule

TCP

30845

0.0.0.0/0

Custom TCP Rule

TCP

HTTPS

30845

::/0

SSH

TCP

22

0.0.0.0/0

Custom TCP Rule

TCP

10249 - 10259

Same security group

Custom TCP Rule

TCP

30000 - 39999

Same security group

Custom TCP Rule

TCP

Weave - rpcbind

111

Same security group

Custom TCP Rule

TCP

Node exporter

9100

Same security group

The servers must be connected to the Internet and must have network access to the following server list:

Linux outbound ports:

Deployment Options for V8.2.4

Recommended Deployment Options

Single Node Deployments

For single node deployments, Sisense recommends you use Sisense Kubespray for Kubernetes with a local second disk on any of the following operating systems, Ubuntu, Rhel, Centos, Amazon Linux 2.

Multi-Node Deployments

For multi-node deployments, Sisense recommends the following deployment options:

Supported Deployment Options

While Sisense is compliant with Kubernetes 1.14-1.17, Sisense strongly recommends using Kubernetes 1.17. The latest versions of EKS and AKS are currently using Kubernetes 1.17.

Sisense V8.2 is certified for the following deployment options:

Single/Multi Location(Cloud Provider) Kubernetes OS(*) Storage Note

Single Node

Any

Sisense kubespray

Ubuntu , RHEL, Centos, Amazon Linux 2

Local second disk

 
AWS Amazon Elastic Kubernetes Service (EKS) Ubuntu, RHEL, Centos, Amazon Linux 2 FSx  
Azure

Azure Kubernetes Service (AKS) - support Basic networking only

Azure CNI is not supported

Ubuntu, RHEL, Centos NetApp  
Google Cloud Platforms (GCP) Google Kubernetes Engine (GKE) Ubuntu, RHEL, Centos Google Cloud Filestore  
Multi-Node

On Prem

Sisense kubespray

Ubuntu, RHEL, Centos

GlusterFS/NFS

 

AWS

Sisense bundled kubespray

Ubuntu, RHEL, Centos, Amazon Linux 2

GlusterFS/NFS/FSx

FSx uses EBS for Mongo ZK

Amazon Elastic Kubernetes Service (EKS)

Ubuntu, RHEL, Centos, Amazon Linux 2

FSx

 

Azure

Sisense Kubespray

Ubuntu, RHEL, Centos

Gluster

 

Azure Kubernetes Service (AKS) - support Basic networking only
Azure CNI is not supported

Ubuntu, RHEL, Centos

NetApp

 

Google Cloud Platform (GCP)

 

Sisense Kubespray

Ubuntu, RHEL, Centos

GlusterFS/NFS

 

Google Kubernetes Engine (GKE)

Ubuntu, RHEL, Centos

Google Cloud Filestore

 

Any

OpenShift

RHEL

GlusterFS/NFS

OpenShift 3.11, 4.0, 4.3.19, 4.4 and 4.5.

Note: FSx and Google Cloud Filestore are encrypted by default.

For more information about Sisense supported Linux deployment options: 

Deployment Sizes and Recommendations

The table below describes the minimum requirements for your production deployment. The exact deployment parameters depend on your specific use-case and usage needs.

It is important to note that it is possible to exceed the large-scale machine deployment size given in the table below with machines that have more memory and cores.

Deployment Size

Small Scale

Medium Scale

Large Scale

Deployment type:

Single node, cluster optional

Recommended: Cluster

Note: the parameters are for each node

Recommended: Cluster

Note: the parameters are for each node)

CPU

8 Logical Cores

16 Logical Cores

32 Logical Cores

System Memory

32GB

64GB - 128GB

256GB - 512GB

Storage as defined above

Users

200

800

2000

Concurrently Active Users

10

40

100

ElastiCubes

5

20

40+

Number of tables per ElastiCube

20

50

70

Parallel ElasticCubes Build Processes

4

8

20

Live Models

100

400

1000

Max Number of rows per Table

20M

300M

1B

Number of Custom Tables in an ElastiCube

5

10

25

Number of Custom Columns in an ElastiCube

10

20

50

Number of Different Sources (Connectors) per ElastiCube

3

5

10

Considerations

The following are some considerations to take into account when deploying Sisense:

CPU Considerations

Each Sisense widget produces at least one query to the ElastiCube or Live source when viewed. As a dashboard is a collection of widgets, viewing a dashboard produces multiple queries, which in turn raises CPU usage. Concurrent queries affect CPU utilization and are independently spread between different CPUs. While this concurrency is a core activity of Sisense, it is important to consider the correlation between the number of concurrent users/active dashboards and increasing CPU usage. It is especially important to track CPU usage when increasing the number of concurrent users or active dashboards. Lack of CPU resources will cause dashboards to load slowly. When CPU usage consistently increases above 80%, it is recommended to add CPU resources.

In addition, custom tables and custom columns will increase the CPU load at the end of a build process according to the complexity of the functions used by those custom tables and columns. In this case, adding more CPU resources will help to decrease the total build time.

Building an ElastiCube can consume a lot of CPU resources. However, CPU consumption is not linear while performing parallel builds, and it is possible to run several builds at the same time. A single node supports up to twenty parallel builds. It is possible to run build processes and view dashboards at the same time, however, as both are CPU consumers, Sisense recommends that you schedule builds to run at times of low dashboard viewing, like during the night.

RAM Considerations

Building ElastiCubes and viewing dashboards both require memory. While it is possible to view dashboards at the same time as running build processes, the RAM resources required for those activities will be aggregated. When using a single-server Sisense deployment, it is important to take both into account and plan RAM usage accordingly. To prevent out-of-memory build failures, it is advisable to run the build process at low-usage schedules or separate the build and the query nodes to different machines.

The size of your ElastiCube model has a major impact on the memory consumption of a Sisense server during a build and query. This is equally true when considering the row-count per table, the number of tables, or a combination of the two in an ElastiCube model. Memory consumption often peaks when building a custom table. Columns with unique data types, like strings, which are indexed during the build process, are cached in memory, for example, large string columns with many unique values may increase memory consumption.

There is a correlation between the data size on the disk and the required RAM. Sisense InChip© technology will load large portions of the ElastiCube to the memory hence the number of active cubes and the cubes total size is a very important sizing factor for the RAM size.

Disk Space Considerations

In general, when determining how much disk space to reserve for Sisense, keep in mind the size of the data to be imported into your ElastiCube models. You should keep additional space to support your ElastiCube models, as these are duplicated during the build process. The duplicate copy is not removed at the end of the build process but serves as the basis of the next build.

An additional important consideration is the custom columns and tables, which are materialized on the disk during the build process. Hence it is important to add the required disk space for these data to the total estimated data size.

In addition to the imported data size, the ElastiCube also holds metadata like indexes. Actual cube size on the disk will be extended due to this internal metadata, hence it is good practice to plan for 20% overhead on top of the imported data and custom tables.

Typically the ElastiCube data is stored compressed. However, it is good practice to plan for the required disk size without taking the compression into account, since in different scenarios one may choose to disable the data compression for build and query performance improvements.

Data Sources Considerations

Connectors affect memory consumption linearly. The usage of each connector has a predefined (and configurable) memory allocation, hence increasing the number of different connectors which are used during the build process increases the memory consumption.

Next Steps