QlikView Server is a Windows-only product that can be managed and accessed using a browser. The components can be grouped into four classes:
Load Balancer – required only when multiple WebServers are deployed. Load Distribution amongst other clustered components is managed within the application.
IIS WebServer (recommended) or QlikView WebServer (QvWS) – Delivers the AccessPoint portal and provides browser access to QlikView. Several webserver instances may be clustered using a Network Load Balancer
Directory Service Connector (DSC) – lookup User properties and group membership in User Directory after successful authentication. Several instances of the DSC operate in a Failover cluster managed at application level.
QlikView Server (QvS) – the Associative Engine. RAM & CPU intensive and may be clustered at application level for Load Distribution. This clustering requires a Windows fileserver for the User Document folders that are mounted on each node using UNC path.
User Document folders – collections of QlikView (QVW) documents that contain Visualization and Data and are loaded into memory on a QlikView Server when required by end users.
Reload or Data Access Tier
Distribution Service (QDS) aka “Reload Engine” – multi-process engine which reloads documents in the Source Document folders on a mostly periodic basis. Multiple Reload Engines may be clustered at application level and would require a Windows fileserver for the Source Document folders that are mounted on each node using UNC path. A single Reload Engine is often sufficient unless many documents need to be reloaded at the same time, or the customer requires a resilient configuration.
Source Document folders – collections of QlikView (QVW) documents that contain Script which is executed to retrieve [and if necessary re-organise] data from one/many datasources into a Dimensional Data Model. Some of these documents may perform Data Manipulation and materialization of data into application-managed QVD files but contain no Visualization. Others may contain Visualization and are distributed to the Engine Tier after being successfully reloaded with data.
QlikView Management Service (QMS) – provides the QlikView Management Console (QMC) that can be accessed using a browser to administer the QlikView environment. Multiple instances of the QMS may be configured but only one should ever be running. The QMS is often deployed on the primary/only Distribution Service host.
QlikView Publisher Repository (QVPR) – the [usually] XML repository where the QMS stores the topology of the environment, and the definition of all tasks that may be performed by the Reload Engines. By default, this is in “C:\ProgramData\QlikTech\ManagementService\QVPR\” on the same node as the QMS but can be relocated to a Windows Fileserver where it can be accessed by a failover instance of the QlikView Management Service.
All components may be installed onto Google Compute Engine instances. Load Distribution or Clustering is managed at the Application Level and is administered using the browser-based QlikView Management Console (QMC).
Think about how your users will Authenticate. If they’ll use their Windows credentials, then [at least] the Web Tier hosts should be members of the Active Directory Domain. If the Engine or Reload tiers are clustered, then their need for a FileServer predicates that these hosts should be members of an Active Directory Domain.
All QlikView components can be deployed on a single Google Compute Engine, using local Windows accounts or the QlikView Custom Directory for Forms Authentication.
Google’s Regional Persistent Disk is shown mounted on the Compute Engine to provide storage for Application Data, User and Source Documents.
The QlikView Server tier is usually the first to be scaled out across multiple machines. This requires that the User Document folders are placed on a Windows FileServer.
The Web Tier components may be deployed on the same hosts as the Engine but are shown here on separate nodes. When multiple WebServers are deployed, then a Load Balancer is required to distribute load amongst them. The Load Balancer must be configured with “Sticky Session”.
The Reload Tier hosts are rarely clustered, and this requires that the Source Document folders are placed on a Windows FileServer.
One Windows FileServer is sufficient for both the Source and User Document folders, and the shared configuration AppData that each service must be configured to access commonly.
It is implemented in a Compute Engine with attached Persistent Disk for improved reliability.
Ideally, all Windows hosts that access Shared Resources should be members of the same Active Directory domain, and this should be extended into the Virtual Private Cloud. Alternatively, an old weakness in Windows permits use of identical credentials on the Client and Server hosts to provide access to File Shares.
Some detail is omitted from the diagram because of available space on the page, but you can see:
Google HTTP(S) Load Balancer provides an external address for browsers to use to reach the IIS WebServers that host AccessPoint. These are implemented in distinct instances of the Compute Engine.
The Directory Service Connector has been omitted from the diagram, but would be installed on the WebServer hosts, and configured to connect to the User Repository (typically Active Directory) to lookup Group Membership after successful authentication.
The QlikView Server has been installed on the Web Tier hosts. AccessPoint (on IIS) distributes Load to the QlikView Servers which each mount the User Document folders from the FileServer.
The Reload Engines which interact with Databases to retrieve data into Source Documents are shown also interacting with the shared CIFS FileServer. The QlikView Management Service would also be installed on these hosts, using a QVPR on the FileServer