There are five services that make up a QlikView Server deployment:
QlikView Management Service (QMS): The QlikView Management Service talks to all of the other services to set up their configurations and manage tasks. It also publishes an API that external applications can use to interact with the QlikView Server deployment.
QlikView Server (QVS): The QlikView Server service is the core engine of QlikView when deployed on a server. It loads the QVW documents into memory, performs the necessary calculations to present the correct results, and handles user and document memory allocation.
QlikView Directory Service Connector (DSC): The Directory Service Connector is the service that connects to different user repositories, such as Active Directory, LDAP, or even a custom database of users, to allow configuration of document-level security.
QlikView Distribution Service (QDS): Without a publisher license, the Distribution Service is simply a reload engine, reloading QVW documents on a QlikView Server. With the Publisher license added, it becomes an independent service that can perform reloads anywhere, distribute documents to multiple locations, and can perform many more tasks.
QlikView Web Service/Settings Service (for IIS) (QVWS): QlikView supports deploying its web pages on IIS but also comes with its own web server service—QVWS. If you do deploy on IIS, the Settings Service acts like the QVWS (listening on the same ports) and communicates with IIS to configure the correct settings.
Each of the services maintains their own folder and file structures, and they can all be enabled for SNMP if required.
There are several common deployment options, which we will discuss in the forthcoming sections.
This is a very common option for many customers—especially for the so-called "departmental" implementations. You have one server and all of the services are deployed on that server.
Obviously, this is the easiest option to deploy and it works quite well. It is also the only option available for the SBE server.
Problems only start to arise where there is a scarcity of memory. The QVS will grab as much system memory as it can, up to about 90 percent of physical RAM (this is configurable), and will tend to hang on to allocated memory, especially user cache, once it has taken it. Any reload task will use memory as needed, and that could be a lot of memory if there are complex script processes. If there are reloads happening during the day, the server will come under resource pressure, which can cause errors, failures, and unhappy users.
In this option, which requires a Publisher license, the Distribution Service is deployed on a separate server to the one on which the QVS and other services are deployed. The Publisher server doesn't need to have the same hardware specification as the larger QVS server. Because memory and CPU resources are released when each task is completed, the server only needs enough resources to complete those tasks—it doesn't hold the resource like QVS does.
An Enterprise deployment will require multiple servers with different services running on each. It will also normally have multiple QVS servers using QlikView Cluster technology. An example configuration might be similar to the one shown in following diagram:
The various Servers shown in the previous diagram and their corresponding services are listed in the following table:
|
Server |
Services |
|---|---|
|
Server 1 |
QVS1 |
|
Server 2 |
QVS2 |
|
Server 3 |
QMS, DSC |
|
Server 4 |
QDS (Publisher) |
|
Server 5 |
QVWS (or IIS) |
|
Server 6 |
QVWS (or IIS) |
The Publisher server can also be clustered, in order to extend the resilience of the deployment.
The web servers can also be deployed in a, so-called, DMZ (a security zone, protected by network firewalls that allows people on the Internet to connect to the web server but not to get any direct access to the QlikView Server) to provide the ability to publish QlikView data externally.