QlikView Server currently only conforms with Windows File Share or a Windows-based NAS. This means that storage must be owned, governed, and shared by a Windows operating system instance (typically accessed using a path like \\<servername>\<share>). Clustered Windows file servers are supported as long as they are of the Active-Passive type.
NAS devices emulating CIFS/SMB file systems are not supported.
- Commonly, NAS devices emulate a CIFS/SMB file system, QlikView Server does not support shared storage where the device emulates a CIFS/SMB file system.
- The only supported shared storage for QlikView Servers is a Windows-based file share.
- This means a Windows server share mapped on a NAS drive is supported.
- This requirement applies for all files (.qvw, .pgo, .meta, .tshared and .shared) used by the QlikView Server services.
- The requirement also applies to the Application Data and Notification files used by the QlikView Distribution Service as well as document storage for reloads (.qvw, .qvd)
Environment:
- QlikView Server, all versions
QlikView is a software designed to provide insights into data. As such, it has been designed to be very responsive as data changes.
It has also been optimized over many years to be able to execute reloads and document loads faster, the overall performance improvement with every version.
Both Front end and Back end in QlikView touch many files in parallell, as different files are used to keep track of the running of the system. If Qlik was to just load a single file into memory and then kept it there, all would likely have been fine even with slower storage. It would, however, have meant that no information could have been shared between cluster nodes in a cluster, or that there would have been no possibility of saving user-generated data for example.
Latency
Network-attached drives can introduce latency that prevents the QlikView components from opening, reading, writing to, or locking files in a timely fashion. This can lead to inconsistent locks between clustered nodes, as well as tasks not firing correctly or at all. The QlikView Server nodes in the cluster must have network latency below 4 milliseconds to connect to the file share server. Performance can degrade if this is not the case. See Requirements for Clustered QlikView Deployment.
Latency can also be introduced when the physical disk is not able to keep up with the inbound requests. An evidence of poor disk performance is a high Disk Queue Length, and high disk latency (Disk sec/Transfer). This can be investigated with Performance Monitor (PerfMon). See QlikView - How to log CPU and memory with Microsoft Performance Monitor on a windows 2012 Server (Pe...
Frequency of File Access
QlikView as a product is built as a fully Windows-dependent software. As such, we utilize native Windows APIs and functions to open, read, write, and lock files. It is this dependency, more than any actual latency introduced by network-attached drives that cause us to not support NAS storage. As NAS storage solutions emulate Windows functionality to handle these API calls, they might not be able to handle the load a QlikView system can put on the storage solution.
The frequency with which we touch files is what proves a challenge for the NAS storage.
A QlikView deployment set up using NAS as shared storage normally works quite well during planning and setup and initial deployment, but starts developing issues as the number of users and documents and tasks builds up over time. We do not see this degrade happening when using native Windows File servers, this is the reason we only support Windows-based shared storage.
Examples:
The QlikView Management Console displays a different status of tasks, depending on if the task overview is being used, or the task details in the rightmost pane.
The reason the status for a single task is visualized differently in different regions of the QMC is because these views do not populate from the same underlying endpoint. In the general "Status" page, the left pane connects directly to the QDS service and requests the status of each individual task. In the "Task Details" pane, the QMS reads the underlying Task results files and collects the data on its own. Finding these two not to match, can be explained by the fact that the QDS service is unable to update its own internal status as it has challenges in reaching the file share, in particular, the Application Data folder and the Notification system.
Future plans:
Qlik Sense has been designed with support for NAS storage in mind.
Future, major releases of QlikView have architectural changes to support NAS devices on the roadmap, but no time frame or versions are currently available. For more information see the Shared Network Storage section under Requirements for Clustered QlikView Deployment.
.png "Former Employee"){kind=icon}
