Skip to main content

Qlik Sense Enterprise on Windows on-premises

You can configure a Qlik Sense Enterprise on Windows deployment to meet the specific needs of your organization. As your requirements for performance and scalability increase, so too will the size of your deployment.

The following terms are used in the deployment scenarios:

  • Central node: the central point for managing all nodes in a site.
  • Failover candidate node: a redundant node that becomes the central node if the original central node fails.
  • Scheduler or Reload node: reloads apps on a schedule, but does not serve content to users.
  • Consumer node: serves apps to users, but is not used to create, process, or reload data.
  • Development node: allows users to create and reload new apps, but does not serve normal consumer traffic.
  • Proxy node: provides load balancing of user traffic to other nodes but does not contain a Qlik Sense Engine Service (QES).
Note: An alternative to using a proxy node is to have a proxy installed on each consumer node and balance the traffic using a hardware load balancer.

Deployment scenarios

This section provides four deployment scenarios of Qlik Sense Enterprise on Windows deployments. The deployments described here are examples of a small, medium, large, and extra-large Qlik Sense Enterprise on Windows scenarios. These examples provide an approximation of the type of workload a particular deployment might need to handle. The figures are not intended to set a minimum or maximum limit on your deployment.

If you expect to have performance demands higher than any of the figures below (such as more reloads or apps) then contact your Qlik partner and perform a full sizing exercise. For more general scalability and performance information, see Performance and QMC performance - best practices.

The following table provides some basic assumptions for each type of deployment scenario:

Deployment type assumptions
Item Single-node (small) Multi-node (medium) Multi-node (large) Multi-node (extra-large)
Apps 50 100 1000 1000
Active apps per day 25 50 125 125
Total users (from UDC) 500 1000 50000 50000
Concurrent users (equals active users within the same hour) 50 100 500 1000
Maximum concurrent users in the QMC 2 2 5 10

Average app size (in gigabytes)

0.1 0.1 0.1 0.1
Maximum app size (in gigabytes) 1 2 5 5
Content creation (objects per hour) 20 40 50 50
Reloads per hour 10 20 400 400
Note:  The difference between a large and extra-large deployment in our examples is the number of concurrent users.

Single-node (small)

The following deployment example shows a Qlik Sense Enterprise on Windows single-node site.

In a single-node site, the Qlik Sense services are all running on the same node.

  • Qlik Sense Repository Service

    There is only one instance of the Qlik Sense Repository Service (QRS) running, and it has direct access to the central repository database.

  • Qlik Sense Scheduler Service

    The Qlik Sense Scheduler Service (QSS) acts as both primary and secondary.

This kind of deployment works best in a single time zone, where data reloads can be done at night.

Users access the Hub through the internet to connect to QPS in a Single Node Site. Admin uses QMC through the internet to connect to QPS in the same Single Node Site. QPS connects to QES and QRS through Inter-Qlik Sense service. QES connects to APPS through the internal server. QES also connects to QRS and QSS through Inter-Qlik Sense service. QRS and QSS connect to eachother. QRS connects to the Central Repository DB through the internal server. All connections are two-way connections. Only the HUB and QMC being the external gateways.

Multi-node (medium)

The following deployment example shows a medium-size, multi-node Qlik Sense Enterprise on Windows production deployment comprising three nodes:

  • One central node/reload node on which the Qlik services are running.
  • Two consumer nodes to load balance user demand.

In this configuration, the central repository database, the file share, and the other Qlik Sense services are running on the central node. The two consumer nodes handle app consumption.

Central node/Reload node contains QPS and QSS, and both of them are not connected to other elements in the node. Central node/Reload node also contains QES has a two-way connection to Shared Storage. Shared storage has a one-way connection to QRS, and QRS has a two-way connection to Central Repository DB. Consumer node contains QES, QPS, and QRS, all of which are not connected. The Consumer node has a two-way connection to Central node/Reload node and the Consumer node. The Consumer ndoe contains QES, QPS, and QRS.

Multi-node (large)

The following deployment example shows a large, multi-node Qlik Sense production deployment. A deployment like this provides the ability to scale up app reloads and user load. This deployment consists of the following nodes:

  • Central node/reload node to handle the services
  • Failover canadidate node to handle the services if the central node fails.
  • Four consumer nodes to load balance user demand.
  • One developer node for app development.
  • The repository database (PostgreSQL) and the file share are installed on separate, dedicated servers.
The first consumer node has two-way connections to the second, third, and fourth Consumer nodes. The first consumer node also has two-way connections to the Failover candidate node, the Active central/reload node, the Shared storage, the Central Repository DB, and the Developer node. The first consumer node contains QES, QPS, and QRS. The second Consumer node contains QES, QPS, and QRS. The third Consumer node contains QES and QRS. The fourth Consumer node contains QES and QRS. The second, third, and fourth Consumer nodes all have two-way connections to the Failover candidate node, Active central/Reload node, Shared storage, Central repository DB, and the Developer node. The Failover candidate node contains QES, QPS, QRS, and QSS. The Failover candidate node receives one-way connections from all Consumer nodes, and the Active central/reload node. The failover candidate node also receives one-way connections from Shared storage, Central Repository DB, and the Developer node. The Active central/reload node contains QES, QPS, QRS, and QSS. The Active central/reload node has two-way connections to Consumer nodes, Shared storage, Central Repository DB, and the Developer node. The Shared storage and Central Repository DB has two-way connections to all nodes except for the Failover candidate node. The Developer node contains QES and QRS. The developer node has two-way connections to all nodes except the Failover candidate node.

The central node and failover node must have all services installed. Configure the proxy service on consumer nodes to handle user traffic, and on both the central and failover nodes to handle admin traffic.

Note: The Qlik services on both central and failover nodes are always active.

Multi-node (extra large)

The following deployment example shows an extra large, multi-node Qlik Sense production deployment consisting of seven consumer nodes providing the ability to scale up app reloads and user load. Groups of consumer nodes are dedicated to different size apps. Each consumer node can be configured with security and custom load balancing rules to restrict the size of the apps they can serve.

To ensure that the system can cope with the load, you can pre-load some apps in memory. For example, you could pre-load all medium and large sized apps, ensuring that they can be loaded in less than two seconds, even during peak hours. For more information on pre-loading apps, see App preload - a cache warmer.

Note: With very large deployments, development of applications can be resource intensive. It may therefore be appropriate to have a separate deployment dedicated to app development. If you prefer to keep developer and consumer nodes in the same deployment, ensure the resource limits are suitable for the developer nodes. This includes reload time, hyper cube timeout, and amount of RAM.

This deployment consists of the following nodes:

  • Active central node/reload node to handle the services.
  • Failover candidate node to handle the services if the central node fails.
  • Seven consumer nodes with node clusters dedicated to app size.
  • Two developer nodes for app development.
  • The repository database (PostgreSQL) and the file share are installed on separate, dedicated servers.
Nodes for small apps contains Consumer node, which contains QES, QPS, and QRS. Nodes for small apps has two way connections to Nodes for medium apps, Nodes for large apps, Active central/reload node, Shared storage, Central Repository DB, and Developer node. Nodes for small apps only has a one-way connection to Failover candidate node. Nodes for medium apps contains Consumer node, which contains QES and QRS. Nodes for medium apps has two-way connections to Active central/reload node, Shared storage, central Repository DB, and Developer node. Nodes for medium apps has a one-way connection to Failover candidate node. Nodes for large apps contains Consumer node, which contains QES and QRS. Nodes for large apps has two-way connections to Active central/reload node, Shared storage, Central Repository DB, and Developer node. Nodes for large apps contains a one-way connection to Failover candidate node. Failover candidate node contains QES, QPS, QRS, and QSS. Failover candidate node has one-way connections from all nodes. Active central/reload node contains QES, QPS, QRS, and QSS. Active central/reload node has two-way connections to all nodes except for Failover candidate node. Shared storage, Central Repository DB, and Developer node all have two-way connections to all nodes except for Failover candidate node. Developer node contains QES and QRS.

The central node and failover node must have all services installed. Configure the proxy service on consumer nodes to handle user traffic, and on both the central and failover nodes to handle admin traffic.

Note: The Qlik services on both central and failover nodes are always active.

See also

 

Deploying Qlik Sense Enterprise on Windows