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).
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:
|Item||Single-node (small)||Multi-node (medium)||Multi-node (large)||Multi-node (extra-large)|
|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)
|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|
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.
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.
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 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.
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.
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.