The only supported shared storage for QlikView Servers and QlikView Distribution servers are Windows-based file shares, if the NAS device emulate a CIFS/SMB or file system it is 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.
- Also if the Windows server share is mapped on a NAS, it is supported. And this is the only way we support NAS at the moment.
- 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
- 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 improving with every version.
- Both Front end and Back end in QlikView touches 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.
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.
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
, and lock files
. It is this dependency, more than any actual latency introduced by network attached drives that causes us to not support NAS storage. As NAS storage solutions emulates 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.
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 amount 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.
The QlikView Management Console displays a different status of tasks, depending 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 collctes 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.
has been designed with support for NAS storage in mind.
Future, major releases of QlikView have architectual changes to support NAS devices on the roadmap, but no time frame or versions are currently available.