This section provides guidance on what to consider when planning and designing multi-node sites.
Planning your deployment
When planning the deployment of a multi-node site there are three main areas that need to be investigated.
Amount of content to synchronize
Each node that serves an app needs a copy of the entire data model locally before it can allow users access. Each time the app is reloaded the changed data is synchronized.
This means that the factors that affect the total volume to synchronize are:
- The number of apps
- The size of the apps
- The reload frequency of the apps (and spread over time)
Multiple apps can be synchronized simultaneously. If an app is reloaded faster than it can be synchronized to the other nodes, the synchronization is canceled and starts over.
Based on the information above, it is possible to calculate the amount of data that needs to be synchronized each hour. This has to be compared to the amount of data that can be moved each hour, which is affected by factors such as network speed, the number of nodes, and the Qlik Sense software itself.
Number of nodes
The number of nodes needed in a multi-node site depends on whether you want to spread the load over fewer, but larger, servers or over more, but smaller, servers. Because of the synchronization in Qlik Sense using fewer, but larger, servers requires less synchronization traffic. The role of each server also needs to be considered.
Deployment topology
Qlik Sense is flexible when it comes to how the nodes are laid out and supports different needs for scale, security, geography, and resilience. In addition, the synchronization rules can be used to configure the role of each node and the content that it serves to the users. The requirements for this should be identified when planning the topology of the deployment.
Recommended deployment principles
It is recommended to consider the principles described in this section when planning the deployment of a multi-node site.
Dedicated roles per server
It is recommended to give each node a specific role within the deployment as this allows for better planning of resources and ensures consistent performance for the users. For example, specify if a node is to run scheduled reloads or serve content to users.
Dedicated hardware for the central node (large deployments only)
In large multi-node sites, the central node takes on the load of distributing content to the rim nodes. Depending on the usage, it may be good to dedicate resources for the central node, so that it does not have to compete for resources with user or reload traffic. The server used for the central node could also be a candidate for virtualization.
App development
Apps can be developed using Qlik Sense Desktop or in a Qlik Sense server environment. The latter provides advantages in terms of data governance, security, performance, and collaboration.
The development of apps involves building load scripts and running reloads while building the data model and assembling the user interface. As each iteration of changes made to an app is synchronized to the other nodes, a significant load can be generated on the synchronization process, especially if the app is large or reloaded often. It is therefore recommended to carefully choose the nodes used for development and avoid synchronization of content that does not need to be processed until the app is finalized.
There are two ways to handle app development in a multi-node site:
- Isolate the development activities onto a dedicated development node within a production site.
- Specify a dedicated site for development activities. The advantage of this approach is that it allows an organization to follow their preferred process for testing and releasing new apps.
If the app development is especially intensive, it is recommended to use a dedicated development site.
Synchronize only what is needed
Synchronization rules can be used to significantly reduce the amount of data traffic. For example, an unpublished app that is only used by a developer does not have to be synchronized to nodes that only serve published apps to end users. In addition, apps that only reload QVD files do not need to be synchronized.
Network speed and geographic deployments
The ability to move app content in a reasonable time is affected by the network speed. The better the throughput, the faster the synchronization can be. For best results, the nodes should be on the same network or, if in separate data centers, connected by LAN like network connections.
If the nodes are geographically dispersed and on slower networks, the synchronization will be slower. This may also slow down the synchronization of nodes that are on faster connections. In this case, the volume and frequency of the data to synchronize need to be considered.
Deployment size
The size (that is, the number of nodes) of a deployment depends of the following factors:
- The amount of data to move (per hour)
- The number of nodes that need to receive the data
- The network speed available to transfer the content
- Some overhead for the software and available CPU
It can be difficult to define the number of nodes or possible data transfer ability, but the following should be considered:
- Less data + fast network = You can have more nodes and the synchronization time will be short
- More nodes + slow network = Less data can be synchronized without delays
Examples:
- Moving 5 GB of content (for example, reloaded apps) or less in an hour between eight servers on a typical corporate network should result in quick updates to the content.
- Moving a single 12 GB app between ten nodes on a typical corporate network may take up to 30 minutes. This means that apps of this size should not reload frequently.