In Qlik Sense, Load Balancing can be configured in two steps.
1. Load Balancing the Qlik Sense Engine
By default, the Qlik Sense Proxy provides Load Balancing for the first node created within a site (the central node).
This action ensures the first proxy is able to send sessions to the first engine. When multiple engines and virtual proxies are installed, user must add load balancing to the new nodes and virtual proxies. If user create a node without configuring the virtual proxy, the node will never actually be used. If user create a new virtual proxy, user must configure it by adding load balancing and selecting which nodes that the virtual proxy can forward work to.
The configuration of a Virtual Proxy provides the capability to add additional engines that are Load Balanced using round robin. It is the Qlik Sense Proxy Service that performs this function.
In addition, it is possible to utilize a third party Load Balancer by configuring the Virtual Proxy to use a “Load balancing module base URI” under the Integration settings. By adding a Load Balancing module base URI additional load balancing options are available (depending on the Load Balancer being used), for example the distribution of load could be based on RAM utilization or CPU utilization.
For examples on how to build a Qlik Sense environment, review the Qlik online Help and our deployment examples.
2. Load balancing rules
This allow user to set up rules for the load balancing of Qlik Sense Apps, restricting specific Apps to only load on specific consumer nodes (rim nodes). For more details please refer below Qlik Sense Help link.
The default load balancing rule allowing the central node access, cannot be disabled!
The Qlik Sense central node needs to, at all times, have all services installed. This includes the engine service. f the purpose of load balancing is to direct traffic to only a specific consumer / rim node, the central node needs to be removed from the engine load balancing options in the Virtual Proxy setup. This will prevent applications from being directed to the central node as well.
We recommend a relatively small central node, configured only as scheduler master (sending reloads to slave nodes), and not being addressed by the virtual proxies as a consumer node.